informe nº4 - metodologias agiles - scrum v1.5

8/6/2019 Informe Nº4 - Metodologias Agiles - Scrum v1.5

http://slidepdf.com/reader/full/informe-no4-metodologias-agiles-scrum-v15 1/15

Martin San Juan

Ana lisis de Sistemas

Metodologías

Ágiles y SCRUM

Universidad Tecnolog ica Nac iona l

Fac ultad Regiona l Delta 2011



“Las reglas del juego de desarrollo de

nuevos productos han cambiado.Muchas empresas han descubierto que

para alcanzar la excelencia es necesarioalgo más que las bases actuales de alta

calidad, bajo coste y diferenciación.También se necesita velocidad y flexibilidad.”

Hirotaka Takeuchi e Ikujiro Nonaka

The New New Product Development Game



ÍndiceIntroducción..........................................................................................................................................3Origen de las metodologías Ágiles.......................................................................................................3Diferencias............................................................................................................................................5Diversas Metodologías Ágiles..............................................................................................................5Scrum....................................................................................................................................................7

Qué es SCRUM...............................................................................................................................7El proceso........................................................................................................................................7Las actividades.................................................................................................................................7

Planificación de la iteración........................................................................................................7Ejecución de la iteración.............................................................................................................8Inspección y adaptación..............................................................................................................8

Fundamentos de Scrum....................................................................................................................9Beneficios de Scrum......................................................................................................................10Historia de Scrum..........................................................................................................................13

Conclusión..........................................................................................................................................14



Introducción

Hasta hace poco el proceso de desarrollo llevaba asociado un marcado énfasis en elcontrol de procesos mediante una rigurosa definición de roles, actividades y artefactos,incluyendo modelado y documentación detallada. Este esquema tradicional para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran

tamaño, respecto a tiempo y recursos. Sin embargo, este enfoque no resulta ser el masadecuado para muchos de los proyectos actuales donde el entorno del sistema es muycambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo peromanteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionalescon estas restricciones de tiempo y flexibilidad, las metodologías ágiles emergen comouna posible respuesta para llenar ese vació metodológico. Por estar especialmenteorientada para proyectos pequeños, las metodologías ágiles constituyen una solución amedida para ese entorno, aportando una elevada simplificación que a pesar de ello norenuncia a las practicas esenciales para asegurar la calidad del producto.

Origen de las metodologías Ágiles

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término ágilaplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos dela industria del software, incluyendo algunos de los creadores o impulsores demetodologías de software. Su objetivo fue esbozar los valores y principios que deberíanpermitir a los equipos desarrollar software rápidamente y respondiendo a los cambios quepuedan surgir a lo largo del proyecto.Se pretendía ofrecer una alternativa a los procesos de desarrollo de softwaretradicionales, caracterizados por ser rígidos y dirigidos por la documentación que segenera en cada una de las actividades desarrolladas.

Tras esta reunión se creó The Agile Alliance3, una organización, sin ánimo de lucro,dedicada a promover los conceptos relacionados con el desarrollo ágil de software yayudar a las organizaciones para que adopten dichos conceptos. El punto de partida esfue el Manifiesto Ágil, un documento que resume la filosofía .ágil..

Según el Manifiesto se valora:• Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas. La gente es el principal factor de éxito de un proyecto software. Esmás importante construir un buen equipo que construir el entorno. Muchas vecesse comete el error de construir primero el entorno y esperar que el equipo seadapte automáticamente. Es mejor crear el equipo y que éste configure su propio

entorno de desarrollo en base a sus necesidades.

• Desarrollar software que funciona más que conseguir una buena documentación.La regla a seguir es .no producir documentos a menos que sean necesarios deforma inmediata para tomar un decisión importante.. Estos documentos deben ser cortos y centrarse en lo fundamental.

• La colaboración con el cliente más que la negociación de un contrato. Se proponeque exista una interacción constante entre el cliente y el equipo de desarrollo. Estacolaboración entre ambos será la que marque la marcha del proyecto y asegure suéxito.

• Responder a los cambios más que seguir estrictamente un plan. La habilidad deresponder a los cambios que puedan surgir a los largo del proyecto (cambios en los

3/14



requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracasodel mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Son características quediferencian un proceso ágil de uno tradicional. Los dos primeros principios son generalesy resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y

con el equipo de desarrollo, en cuanto metas a seguir y organización del mismo.Los principios son:

1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas desoftware que le aporte un valor.

2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tengauna ventaja competitiva.

3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo delproyecto.

5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyoque necesitan y confiar en ellos para conseguir finalizar el trabajo.

6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

7. El software que funciona es la medida principal de progreso.8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener una paz constante.9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.10.La simplicidad es esencial.11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados

por sí mismos.12.En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más

efectivo, y según esto ajusta su comportamiento.

4/14



Diferencias

Metodologías Ágiles Metodologías Tradicionales

Basadas en la heuristicas provenientes delas practicas de producción de código

Basadas en normas provenientes deestándares seguidos por el entorno dedesarrollo

Especialmente preparados para cambiosdurante el proyecto

Cierta resistencia a los cambios

Impuestas internamente(por el equipo) Impuestas externamente

Procesos menos controlado, con pocosprincipios

Procesos mucho mas controlado, connumerosas políticas/normas

No existe contrato tradicional o es bastanteflexible

Existe un contrato prefijado

El cliente es parte del equipo de desarrollo El cliente interactua con el equipo de

desarrollo mediante reunionesGrupos pequeños, menos de 10 integrantestrabajando en el mismo sitio

Grupos grandes y posiblemente distribuidos

Pocos artefactos Mas artefactos

Pocos roles Mas roles

Menos énfasis en la arquitectura delsoftware

La arquitectura del software es esencial yse expresa mediante modelos.

Diversas Metodologías Ágiles

Aunque los creadores e impulsores de las metodologías ágiles más populares hansuscrito el manifiesto ágil y coinciden con los principios enunciados anteriormente, cadametodología tiene características propias y hace hincapié en algunos aspectos másespecíficos. A continuación se enumeran algunas metodologías ágiles.

• Crystal Methodologies: Se trata de un conjunto de metodologías para el desarrollode software caracterizadas por estar centradas en las personas que componen elequipo y la reducción al máximo del número de artefactos producidos. Han sido

desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juegocooperativo de invención y comunicación, limitado por los recursos a utilizar. Elequipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos enmejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipodefinidas. Estas políticas dependerán del tamaño del equipo, estableciéndose unaclasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y CrystalOrange (25 a 50 miembros).

• Dynamic Systems Development Method(DSDM): Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo de crear unametodología RAD unificada. Sus principales características son: es un procesoiterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos.Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional,diseño y construcción, y finalmente implementación.

5/14



Las tres últimas son iterativas, además de existir realimentación a todas las fases.

• Adaptive Software Development8 (ASD): Su impulsor es Jim Highsmith. Susprincipales características son: iterativo, orientado a los componentes software másque a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tresfases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas

se inicia el proyecto y se planifican las características del software; en la segundadesarrollan las características y finalmente en la tercera se revisa su calidad, y seentrega al cliente. La revisión de los componentes sirve para aprender de loserrores y volver a iniciar el ciclo de desarrollo.

• Feature -Driven Development(FDD): Define un proceso iterativo que consta de 5pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases dediseño e implementación del sistema partiendo de una lista de características quedebe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad.

• Lean Development(LD) Definida por Bob Charette.s a partir de su experiencia enproyectos con la industria japonesa del automóvil en los años 80 y utilizada ennumerosos proyectos de telecomunicaciones en Europa. En LD, los cambios seconsideran riesgos, pero si se manejan adecuadamente se pueden convertir enoportunidades que mejoren la productividad del cliente. Su principal característicaes introducir un mecanismo para implementar dichos cambios.

• Extreme Programming(XP): Formulado por Kent Beck, es una metodologíacentrada en potenciar las relaciones interpersonales como clave para el éxito endesarrollo de software, promoviendo el trabajo en equipo, preocupándose por elaprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. Se

basa en realimentación continua entre el cliente y el equipo de desarrollo,comunicación fluida entre todos los participantes, simplicidad en las solucionesimplementadas y coraje para enfrentar los cambios. Se define como especialmenteadecuada para para proyectos con requisitos imprecisos y muy cambiantes, ydonde existe un alto riesgo técnico.

6/14



Scrum

Qué es SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto de mejoresprácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible

de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en unestudio de la manera de trabajar de equipos altamente productivos.En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por elbeneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmenteindicado para proyectos en entornos complejos, donde se necesita obtener resultadospronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, lacompetitividad, la flexibilidad y la productividad son fundamentales.Scrum también se utiliza para resolver situaciones en que no se está entregando al clientelo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o lacalidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia,cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar ysolucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando unproceso especializado en el desarrollo de producto.

El proceso

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de unmes naturaly hasta de dos semanas, si así se necesita). Cada iteración tiene queproporcionar un resultado completo, un incremento de producto final que sea susceptiblede ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa comoplan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que leaportan respecto a su coste y quedan repartidos en iteraciones y entregas. De maneraregular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno deinversión mediante la replanificación de objetivos que realiza al inicio de cada iteración.

Las actividades

Planificación de la iteración

El primer día de la iteración se realiza la reunión de planificación de la iteración.

Tiene dos partes:

1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista derequisitos priorizada del producto o proyecto. El equipo pregunta al cliente lasdudas que surgen y selecciona los requisitos más prioritarios que se compromete acompletar en la iteración, de manera que puedan ser entregados si el cliente losolicita.

2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareasde la iteración necesarias para desarrollar los requisitos a que se ha comprometido.La estimación de esfuerzo se hace de manera conjunta y los miembros del equipose autoasignan las tareas.

7/14



Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cadamiembro del equipo inspecciona el trabajo que el resto está realizando (dependenciasentre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el

compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas:

• ¿Qué he hecho desde la última reunión de sincronización?• ¿Qué voy a hacer a partir de este momento?• ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con sucompromiso y de que no se merme su productividad.

• Elimina los obstáculos que el equipo no puede resolver por sí mismo.• Protege al equipo de interrupciones externas que puedan afectar su compromiso o

su productividad.

Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración.Tiene dos partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitoscompletados en la iteración, en forma de incremento de producto preparado paraser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de

los cambios que haya habido en el contexto del proyecto, el cliente realiza lasadaptaciones necesarias de manera objetiva, ya desde la primera iteración,replanificando el proyecto.

2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera detrabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador seencargará de ir eliminando los obstáculos identificados.

8/14



Fundamentos de Scrum

Scum se basa en:• El desarrollo incremental de los requisitos del proyecto en bloques temporales

cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así senecesita).

• La priorización de los requisitos por valor para el cliente y coste de desarrollo encada iteración.

• El control empírico del proyecto. Por un lado, al final de cada iteración sedemuestra al cliente el resultado real obtenido, de manera que pueda tomar lasdecisiones necesarias en función de lo que observa y del contexto del proyecto enese momento. Por otro lado, el equipo se sincroniza diariamente y realiza lasadaptaciones necesarias.

• La potenciación del equipo, que se compromete a entregar unos requisitos y paraello se le otorga la autoridad necesaria para organizar su trabajo.

• La sistematización de la colaboración y la comunicación tanto entre el equipo ycomo con el cliente.

• El timeboxing de las actividades del proyecto, para ayudar a la toma de decisionesy conseguir resultados.

Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de lamanera de trabajar de equipos altamente productivos.

9/14



Beneficios de Scrum

Beneficios de Scrum Como se Consigue

Gestion regular de las experiencias del cliente

El cliente establece sus expectativas indicando el

valor que le aporta cada requisito del proyecto ycuando espera que este completado

Lista de requisitos Priorizada

El cliente crea y gestiona la lista de requisitos del

producto o proyecto, donde quedan reflejadas susexpectativas a nivel de requisitos, valor, coste yentregas.

El cliente comprueba de manera regular si se vancumpliendo sus expectativas, da feedback, ya desdeel inicio del proyecto puede tomar decisionesinformadas a partir de resultados objetivos y dirigeestos resultados del proyecto, iteración a iteración,hacia su meta. Se ahorra esfuerzo y tiempo al evitar hipótesis.

Demostración de los resultados de proyecto en cadaiteración

Al final de cada iteración el equipo demuestra alcliente los requisitos que ha conseguido completar.Tras una inspección del resultado real del proyectohasta ese momento, y considerando el esfuerzo queha sido necesario para realizarlo, el cliente solicitalos cambios que necesita y replanifica el proyecto.

Resultados anticipados (“time to market”)

El cliente puede empezar a utilizar los resultadosmás importantes del proyecto antes de que estéfinalizado por completo.Siguiendo la ley de Pareto (el 20% del esfuerzoproporciona el 80% del valor), el cliente puedeempezar antes a recuperar su inversión (y/oautofinanciarse) comenzando a utilizar un productoal que sólo le faltan características poco relevantes,puede sacar al mercado un producto antes que sucompetidor, puede hacer frente a urgencias o

nuevas peticiones de clientes, etc.

Priorización de requisitos por valor y coste

Al inicio de cada iteración el cliente prioriza la listade requisitos del producto o proyecto en función delvalor que le aportan, su coste de desarrollo y losriesgos del proyecto, cambiando los requisitosprevistos para reaccionar a cambios de contexto enel proyecto.El progreso del proyecto se mide en función de losrequisitos que el equipo completa en cada iteración.

Flexibilidad y adaptación

De manera regular el cliente redirige el proyecto enfunción de sus nuevas prioridades, de los cambiosen el mercado, de los requisitos completados que lepermiten entender mejor el producto, de la velocidadreal de desarrollo, etc.Al final de cada iteración el cliente puede aprovechar la parte de producto completada hasta ese momentopara hacer pruebas de concepto con usuarios oconsumidores y tomar decisiones en función del

resultado obtenido.

Replanificación en el inicio de cada iteración

Se asume que los cambios son parte natural delproyecto. Toda iteración comienza con unareplanificación del proyecto. Esta replanificación noes traumática puesto que Scrum minimiza el númerode objetivos/requisitos en que el equipo trabaja (WIP,Work In Progress) a los que caben en una iteración.Todavía no se ha hecho ningún esfuerzo endesarrollar los requisitos de las siguientesiteraciones.

El hecho los requisitos se completen en función delvalor que aportan al cliente minimiza la probabilidadde que se produzcan grandes cambios en eltranscurso del proyecto.

Retorno de inversión (ROI)

De manera regular, el cliente maximiza el ROI delproyecto. Cuando el beneficio pendiente de obtener es menor que el coste de desarrollo, el cliente puedefinalizar el proyecto.

Priorización de requisitos por valor

Cada iteración el cliente dispone de unos requisitoscompletados y replanifica el proyecto en función delvalor que le aportan los requisitos pendientesrespecto del coste de desarrollo que tienen.

Mitigación de riesgos

Desde la primera iteración el equipo tiene quegestionar los problemas que pueden aparecer en

Desarrollo iterativo e incremental

Un requisito se debe completar en una iteración. Elequipo debe realizar todas las tareas necesarias

10/14



una entrega del proyecto. Al hacer patentes estosriesgos, es posible iniciar su mitigación de maneraanticipada. "Si hay que equivocarse o fallar, mejor hacelo lo antes posible". El feedback tempranopermite ahorrar esfuerzo y tiempo en errorestécnicos.La cantidad de riesgo a que se enfrenta el equipo

está limitada a los requisitos que se puededesarrollar en una iteración. La complejidad yriesgos del proyecto se dividen de manera natural eniteraciones.

para completarlo y que esté preparado para ser entregado al cliente con el esfuerzo mínimonecesario. De esta manera no se deja para el finaldel proyecto ninguna actividad arriesgadarelacionada con la entrega de requisitos.

Productividad y calidad

De manera regular el equipo va mejorando ysimplificando su forma de trabajar.

Mejora continua

Cada iteración el equipo realiza una retrospectivapara analizar su manera de trabajar e identificar losobstáculos que le impiden avanzar al mejor ritmoposible.

Los miembros del equipo sincronizan su trabajodiariamente y se ayudan a resolver los problemasque pueden impedir conseguir el objetivo de laiteración. La comunicación y la adaptación a lasdiferentes necesidades entre los miembros delequipo son máximas (se van ajustando iteración aiteración), de manera que no se realizan tareasinnecesarias y se evitan ineficiencias.

Comunicación diaria del equipo

Todo miembro del equipo conoce cómo el trabajo delos otros miembros impacta en el suyo y cuáles sonlas necesidades de los otros.

Las personas trabajan más enfocadas y de maneramás eficiente cuando hay una fecha límite a cortoplazo para entregar un resultado al que se hancomprometido. La consciencia de esta limitacióntemporal favorece la priorización de las tareas yfuerza la toma de decisiones.Las iteraciones (Sprints) son regulares y de un mespara facilitar la sincronización sistemática con otrosequipos, con el resto de la empresa y con el cliente.

TimeBoxing

Cada actividad de Scrum siempre tiene la mismaduración (1 mes, 4 horas, etc.), con lo que laspersonas aprenden lo que pueden conseguir en estetiempo, cómo organizarse, priorizar tareas y tomar decisiones.

El equipo minimiza su dependencia de personasexternas para poder avanzar (depender de ladisponibilidad de otros puede parar tareas).

Equipo multidisciplinar

El equipo está formado por todas las personas conlas especialidades necesarias para llevar a cabo elproyecto.

La estimación de esfuerzo y la optimización detareas para completar un requisito es mejor si larealizan las personas que van a desarrollar elrequisito, dadas sus diferentes especializaciones,experiencias y puntos de vista. Asímismo, coniteraciones cortas la precisión de las estimacionesaumenta.

Estimación de esfuerzo conjunta

En el inicio de la iteración los miembros del equipoestiman de manera conjunta el esfuerzo necesariopara completar requisitos y sus tareas.

Las personas trabajan de manera más eficiente ycon más calidad cuando ellas mismas se hancomprometido a entregar un resultado en unmomento determinado y deciden cómo hacerlo, nocuando se les ha asignado una tarea e indicado eltiempo necesario para realizarla.

Compromiso del equipo

En el inicio de cada iteración el equipo seleccionalos requisitos que se compromete a completar yentregar al final de la iteración (responabilidad). Elpropio equipo se organiza (autoridad) identificando

las tareas necesarias, su esfuerzo yautoasignandose cada miembro las tareas que secompromete a realizar.

11/14



El equipo se evita caminar mucho tiempo por uncamino equivocado que le obligue a realizar un granesfuerzo para llegar al objetivo esperadoSe asegura la calidad del producto de manerasistemática y objetiva, a nivel de satisfacción delcliente, requisitos listos para ser utilizados y calidadinterna del producto.

Demostración de resultados preparados para ser utilizados y velocidad sostenida

Por un lado, al final de cada iteración el equipodemuestra al cliente los requisitos que haconseguido completar, de manera que estáncompletamente operativos. Por otro lado, para tener

una velocidad de desarrollo sostenida, el equiponecesita desarrollar cada incremento de producto sintener que revisitar aspectos mal resueltos eniteraciones anteriores.

Alineamiento entre cliente y equipo

Los resultados y esfuerzos del proyecto se miden enforma de objetivos y requisitos entregados alnegocio. Todos los participantes en el proyectoconocen cuál es el objetivo a conseguir. El productose enriquece con las aportaciones de todos.

Cliente y equipo trabajando “en equipo”

Cada iteración el equipo y el cliente trabajan juntosen la creación de los requisitos del proyecto (en laestimación de la lista priorizada de requisitos delproyecto), en darles detalle (en la reunión deplanificación de la iteración) y en el análisis delresultado obtenido (en la demostración de losrequisitos completados).

Equipo motivado

Las personas están más motivadas cuando puedenusar su creatividad para resolver problemas ycuando pueden decidir organizar su trabajo.

Equipo autogestionado

El equipo es quien se compromete a completar unosrequisitos determinados en una iteración y quienmejor sabe cómo desarrollarlos. Por ello es elequipo quien se autoorganiza y quien planifica cómotrabajará en la iteración.

Las personas se sienten más satisfechas cuandopueden mostrar los logros que consiguen.

Demostración

Cada iteración el equipo muestra al cliente losresultados que consigue. No está mesestrabajandosin poder exhibir su obra.

12/14



Historia de Scrum

El concepto de Scrum tiene su origen en un estudio de 1986 [1] sobre los nuevosprocesos de desarrollo utilizados en productos exitosos en Japón y los Estados Unidos(cámaras de fotos de Canon, fotocopiadoras de Xerox, automóviles de Honda,ordenadores de HP y otros). Los equipos que desarrollaron estos productos partían de

requisitos muy generales, así como novedosos, y debían salir al mercado en muchomenos del tiempo del que se tardó en lanzar productos anteriores. Estos equipos seguíanpatrones de ejecución de proyecto muy similares. En este estudio se comparaba la formade trabajo de estos equipos altamente productivos y multidisciplinarios con la colaboraciónentre los jugadores de Rugby y su formación de Scrum.

En 1993 se realizó el primer Scrum para desarrollo de software y en 1995 el proceso fueformalizado por Ken Schwaber para la industria del desarrollo de software. En 2001 ungrupo de personas muy relevantes en lo que empezaba a ser el desarrollo ágil escribieronlos valores fundamentales de los procesos ágiles(Manifiesto Agil).

13/14



Conclusión

No existe una metodología universal para hacer frente con éxito a cualquier proyecto dedesarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto(recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. Históricamente,las metodologías tradicionales han intentado abordar la mayor cantidad de situaciones de

contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todoen proyectos pequeños y con requisitos muy cambiantes. Las metodologías ágiles ofrecenuna solución casi a medida para una gran cantidad de proyectos que tienen estascaracterísticas. Una de las cualidades más destacables en una metodología ágil es susencillez, tanto en su aprendizaje como en su aplicación, reduciéndose así los costos deimplantación en un equipo de desarrollo.

informe nº4 - metodologias agiles - scrum v1.5

Documents