MCGA
METODOLOGÍAS ÁGILES
Ing. Noelia S Franco
Metodologías Ágiles ............................................................................................................................ 3 ¿Qué es una metodología ágil? ....................................................................................................... 3 Valores de una metodología ágil ..................................................................................................... 3 Metodologías ágiles más utilizadas ................................................................................................. 4 Lean Software.................................................................................................................................. 4 Los 7 principios del desarrollo Lean ............................................................................................ 4 Kanban............................................................................................................................................. 7 Limitar el trabajo en curso .......................................................................................................... 8 Métricas Kanban ......................................................................................................................... 8 XP (Programación extrema) ............................................................................................................ 8 ¿QUÉ ES PROGRAMACIÓN EXTREMA O XP? ............................................................................... 9 OBJETIVOS. .................................................................................................................................. 9 Principios básicos ........................................................................................................................ 9 SCRUM ........................................................................................................................................... 15 Qué es SCRUM ........................................................................................................................... 15 Historia de Scrum ...................................................................................................................... 15 El proceso .................................................................................................................................. 16 Planificación de la iteración ...................................................................................................... 17 Ejecución de la iteración ........................................................................................................... 17 Inspección y adaptación ............................................................................................................ 18 Fundamentos de Scrum ............................................................................................................ 18 Requisitos para poder utilizar Scrum ........................................................................................ 19 Beneficios de Scrum .................................................................................................................. 19
Metodologías Ágiles
¿Qué es una metodología ágil? Una metodología Ágil es una metodología efectiva par a modelar y documentar un proyecto de software. Es una colección de valores, principios y prácticas para modelar software que pueden ser aplicados de manera simple y ligera.
Es un método de ingeniería del software basado en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboración de grupos autos dirigidos y multidisciplinarios.
Valores de una metodología ágil Los valores de una metodología ágil son:
Individuos e interacciones en lugar de procesos y herramientas Software funcionando en lugar de documentación detallada Colaboración hacia el cliente en lugar de negociación del contrato Responder al cambio en lugar de seguir un plan
Metodologías ágiles más utilizadas A continuación se muestra un gráfico de las tecnologías ágiles más utilizadas:
Lean Software El Desarrollo de Software Lean tiene sus inicios en el Sistema de Producción de Toyota (TPS) y ayuda a las organizaciones de software a optimizar sus procesos y sus métodos de producción de manera de poder entregar sus productos al mercado de manera más rápida y con mejor calidad. El movimiento Lean puede considerarse como un nuevo método de desarrollo que intenta identificar y erradicar todos los problemas y "desventajas" de metodologías antiguas, como Cascada.
Los 7 principios del desarrollo Lean El Desarrollo de Software Lean fue la base para los métodos del Desarrollo Ágil de Software, y sus representantes principales como Scrum o Crystal Clear. En uno de los libros más populares sobre Lean (Implementing Lean Software Development - from Concept to Cash), Mary y Tom Poppendieck explican cómo implementar Lean siguiendo siete principios.
1. Eliminar el desperdicio
Brindar un liderazgo técnico y de mercado - la organización puede ser exitosa si produce productos innovadores y tecnológicamente avanzados, pero es importante comprender lo que valoran nuestros clientes y conocer la tecnología que se está usando. Crear solamente cosas de valor - debemos ser cuidados con todos los procesos que sigamos. Por ejemplo, debemos asegurarnos que todos estos procesos son útiles y están enfocados en crear valor. Escribir menos código - mientras más código se tenga, más pruebas se va a necesitar, por lo que se necesitará más trabajo. Si escribimos pruebas para funcionalidad que no se necesita estamos perdiendo el tiempo.
2. Crear conocimiento
Crear equipos de diseño y construcción - el líder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los incite a buscar respuestas y volver lo más pronto posible con los problemas que surgen, o con las soluciones inventadas. Mantener una cultura de mejora continua - crear un ambiente en donde las personas estén mejorando continuamente en lo que trabajan - deben saber que no son y no deben ser perfectas - y que siempre tienen algún área que pueden mejorar. Enseñar métodos de resolución de problemas - los equipos de desarrollo deberían comportarse como pequeños centros de investigación, estableciendo hipótesis y realizando varios experimentos rápidos para verificar su validez.
3. Embeber a la calidad
Sincronizar - para lograr una alta calidad en el software nos debemos empezar a ocupar de él antes de empezar a escribir una sola línea de código. Automatizar - automatizar las pruebas, la construcción, las instalaciones, y cualquier cosa que sea rutinaria. Hay que automatizar de una manera inteligente, de forma que las personas puedan mejorar el proceso y cambiar cualquier cosa que quieran sin preocuparse por si el cambio hace que las cosas dejen de funcionar. Refactorizar- eliminar la duplicación de código a CERO - cada vez que aparezca la oportunidad, realizar el refactor del código, de las pruebas y de la documentación para minimizar la complejidad.
4. Postergar el compromiso
Agendar las decisiones irreversibles hasta el último momento responsable - debemos saber hacia dónde queremos ir pero no conocemos el camino del todo, lo vamos descubriendo día a día - lo más importante es mantener la dirección correcta.
Romper con las dependencias - los componentes deben estar lo más desacoplados posible para que puedan implementarse en cualquier orden. Mantener opciones - desarrollar múltiples soluciones para todas las decisiones críticas y ver cuales funcionan mejor.
5. Optimizar el total
Enfocarse en el flujo completo de valor - enfocarse en ganar la carrera completa (que es el software). No hay que gastar esfuerzo en optimizar ineficiencias locales, sino en ver el todo y optimizar a la organización en su totalidad. Entregar un producto completo - los equipos necesitan tener buenos líderes, y también buenos ingenieros, vendedores, especialistas de marketing, secretarias, etc. Todos juntos pueden entregar un gran producto final a los clientes.
6. Entregar rápido
Trabajar en bloques pequeños - reducir el tamaño del proyecto, acortar los ciclos de entrega, estabilizar el ambiente de trabajo, repetir lo bueno y erradicar las prácticas que crean obstáculos. Limitar el trabajo a la capacidad - limitar la cola de tareas al mínimo (una o dos iteraciones por delante es suficiente), no hay que tener miedo al quitar elementos de la cola rechazar cualquier trabajo hasta que se haya vaciado un lugar en la cola. Enfocarse en el tiempo del ciclo, no en la utilización - agregar tareas pequeñas a la cola que no puedan atascar al proceso por un tiempo largo - reducir el tiempo del ciclo y tener pocas cosas para procesar en la cola
7. Respetar a las personas
Capacitar a los líderes de equipo - darles a los líderes de equipo entrenamiento, guías y espacio libre para implementar el pensamiento Lean en su ambiente. Mover la responsabilidad y la toma de decisiones al nivel más bajo posible - dejar que las personas piensen y decidan por su cuenta - ellos saben mejor que nadie cómo implementar algoritmos difíciles y aplicar tecnologías de última generación. Fomentar orgullo por el trabajo - fomentar la pasión y la participación del equipo hacia lo que hacen y cómo lo hacen.
Más info en: http://agileso http://agilesoftwaredevelopment.c ftwaredevelopment.com/leanprincipl om/leanprinciples es
Kanban La palabra Kanban, de origen japonés, se compone de dos términos: Kan que puede traducirse como "visual" y ban, como "insignia", siendo una traducción t raducción aproximada, "insignia visual". El sistema Kanban, orientado al desarrollo de software, está fuertemente ligado al uso del tablero o pizarra Kanban. La pizarra Kanban contiene las tareas que tenemos que desarrollar. La pizarra está estructurada por columnas, que identifican cada una a los distintos estados por los que puede pasar (más o menos secuencialmente), la tarea:
Solicitada Asignada En desarrollo En pruebas Completada Se podría pensar en más estados: validada por el usuario, implementada en producción, etc. Lo importante aquí es el aspecto visual, ya que las distintas tarjetas (una por tarea), siguen de izquierda a derecha en la pizarra, los estados. El aspecto de la pizarra sería tal que así:
Limitar el trabajo en curso Otro aspecto fundamental del Kanban es mantener acotado dentro de unos límites, el trabajo "en curso". La pizarra ayuda mediante su gestión visual. Además, hay dos conceptos importantes:
No podemos comenzar una nueva tarea hasta que la anterior la hayamos terminado. El número máximo de trabajo en curso tiene un límite, que es nuestra capacidad por ciclo o iteración.
Métricas Kanban Para cada tarea deberemos obtener los siguientes datos:
Fecha y hora de inicio Fecha y hora de fin Tiempo real invertido
Como además, tendremos la estimación inicial para la tarea, con los datos anteriores ya tenemos la desviación respecto a lo estimado. El tiempo promedio para completar una tarea, es también importante y a veces conocido como "tiempo de ciclo", ya que es el ciclo medio que nos cuesta pasar una tarea de izquierda a derecha de la pizarra hasta que cogemos una nueva. Más info: printed.pdf
http://www.proyectalis.com/document http://www.proyectalis. com/documentos/KanbanVsScrum_ os/KanbanVsScrum_Castellano_FIN Castellano_FINALAL-
XP (Programación extrema) La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.
¿QUÉ ES PROGRAMACIÓN EXTREMA O XP?
Metodología liviana de desarrollo de software Conjunto de prácticas y reglas empleadas para desarrollar software Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes Originada en el proyecto C3 para Chrysler En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada vez, a través de todo el proceso de desarrollo
OBJETIVOS.
Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos. Mejorar la productividad de los proyectos. Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.
Principios básicos La Programación Extrema se basa en 12 principios básicos agrupados en cuatro categorías: Retroalimentación a escala fina
1. El principio de pruebas :
se tiene que establecer un período de pruebas de aceptación del programa (llamado también período de caja negra ) donde se definirán las entradas al sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se pueden utilizar Ambientes de Prueba (Unit testing frameworks). Un buen ejemplo de un ambiente de prueba es el JUnit para Java Otros ambientes de pruebas para otros lenguajes como C, C++, JavaScript, XML y servicios Web.
2. Proceso de planificación:
en esta fase, el usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema. Se creará un documento llamado Historias del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberación, el cual define de forma específica los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario. Por regla general, cada una de las Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Son muy importantes y tienen que ser una constante las reuniones periódicas durante esta fase de planificación. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y señalar aquellos puntos a los que se les ha de dar más importancia por su dificultad o por su punto crítico.
3. El cliente en el sitio :
se le dará poder para determinar los requerimientos, definir la funcionalidad, señalar las prioridades y responder las preguntas de los programadores. Esta fuerte interacción cara a cara con el programador disminuye el tiempo de comunicación y la cantidad de documentación, junto con los altos costes de su creación y mantenimiento. Este representante del cliente estará con el equipo de trabajo durante toda la realización del proyecto.
4. Programación en parejas :
uno de los principios más radicales y en el que la mayoría de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina. De acuerdo con los experimentos, este principio puede producir aplicaciones más buenas, de manera consistente, a iguales o menores costes. Aunque el pair-programming puede no ser para todo el mundo.
Proceso continuo en lugar de por lotes 1. Integración continua: permite al equipo hacer un rápido progreso implementando las nuevas
características del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su código y reconstruir el sistema varias veces al día. Esto reduce los problemas de integración comunes en proyectos largos y estilo cascada.
2. Refactorización: permite a los equipos de programadores XP mejorar el diseño del sistema a
través de todo el proceso de desarrollo. Los programadores evalúan continuamente el diseño y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimización del código duplicado y/o ineficiente. 3. Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se actualiza
de forma rápida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como máximo. Entendimiento compartido 1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma sencilla. 2. Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia de cómo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración) también ayudarán al equipo
a definir actividades durante el diseño del sistema. Cada tarjeta representa una clase en la programación orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas). 3. Propiedad colectiva del código: código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los métodos tradicionales en los que un simple programador posee un conjunto de código. Los defensores de XP argumentan que mientras haya más gente trabajando en una pieza, menos errores aparecerán. 4. Estándar de codificación: codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona. Bienestar del programador. 1. La semana de 40 horas: horas: la programación extrema sostiene que los programadores cansados escriben código de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generará código de mayor calidad. Como dice Beck, está bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas.
PROCESO DE DESARROLLO La programación extrema parte del caso habitual de una compañía que desarrolla software normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o diseño), uno de desarrollo y los clientes finales. La relación entre el equipo de diseño, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologías tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validación posterior al mismo.
1. Interacción con el cliente. En este tipo de programación el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificación. Tiene un papel importante de interacción con el equipo de programadores, sobre todo después de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de programación existirán pruebas de aceptación de la programación que ayudarán a que su labor sea lo más provechosa posible. Al fin y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo. Se elimina la fase inicial de recopilación de requerimientos, y se permite que éstos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiando de opinión sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo. En XP aparece un nuevo concepto llamado “Historia “ Historia de usuario”. usuario”. Se trata de una lista de
características que el cliente necesita que existan en el producto final. Estas constan de dos fases:
En la primera fase, el cliente describe con sus propias palabras las características y, es el responsable del equipo, el encargado de informarlo de las dificultades técnicas de cada una de ellas y de su coste. A consecuencia de este diálogo, el cliente deja por escrito un conjunto de historias y las ordena en función de la prioridad que tienen para él. De esta manera ya es posible definir unas fechas aproximadas para ellos.
En la segunda fase, el cliente cogerá las primeras historias a implementar y las dividirá en trabajos a realizar. El cliente también participa, pero hay más peso por parte del equipo de desarrolladores, esto dará como resultado una planificación más exacta. Este método se repetirá para cada historia.
A diferencia de otras técnicas, como puede ser UML, en el caso de XP, se exige que sea el cliente el encargado de escribir los documentos con las especificaciones de lo que realmente quiere, como un documento de requisitos de usuario. En esta fase, el equipo técnico será el 'encargado de catalogar las historias del cliente y asignarles una duración. La norma es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programación. Las que requieran menos tiempo serán agrupadas, y las que necesiten más serán modificadas o divididas. Finalmente decir que las historias de los usuarios serán escritas en tarjetas, lo que facilitará que el
cliente pueda especificar la importancia relativa entre las diferentes historias de usuario, así como el trabajo de los programadores que podrán catalogarlas correctamente. Este formato también es muy útil en el momento de las pruebas de aceptación.
PLANIFICACIÓN DEL PROYECTO En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán diferentes iteraciones. Para hacerlo será necesaria la existencia de reglas que se han de seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se sientan realmente partícipes de la decisión tomada. Las entregas se tienen que hacer cuanto antes mejor, y con cada iteración, el cliente ha de recibir una nueva versión. Cuanto más tiempo se tarde en introducir una parte esencial, menos tiempo se tendrá para trabajar con ella después. Se aconseja muchas entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene más posibilidades de detectarse rápidamente. Una de las máximas a aplicar es, los cambios, no han de suponer más horas de programación para el programador, ya que el que no se termina en un día, se deja para el día siguiente. Se ha de tener asumido que en el proceso de planificación habrán errores, es m ás, serán comunes, y por esto esta metodología ya los tiene previstos, por lo tanto se establecerán mecanismos de revisión. Cada tres o cinco iteraciones es normal revisar las historias de los usuarios, y renegociar la planificación. Cada iteración necesita también ser planificada, es lo que se llama planificación iterativa iterativa, en la que se anotarán las historias de usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptación. Estas planificaciones también se harán en tarjetas, en las que se escribirán los trabajos que durarán entre uno y tres días. Es por esto que el diseño se puede clasificar como continuo. Añade agilidad al proceso de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que aún no han estado programados. Este tipo de planificación en iteraciones y el diseño iterativo, hace que aparezca una práctica que no existía en la programación tradicional. Se trata de las discusiones diarias informales, para fomentar la comunicación, y para hacer que los desarrolladores tengan tiempo de hablar de los problemas a los que se enfrentan y de ver cómo van con sus trabajos.
DISEÑO, DESARROLLO Y PRUEBAS El desarrollo es la parte más importante en el proceso de la programación extrema. Todos los trabajos tienen como objetivo que se programen lo más rápidamente posible, sin interrupciones y en dirección correcta. También es muy importante el diseño, y se establecen los mecanismos, para que éste sea revisado
y mejorado de manera continuada a lo largo del proyecto, según se van añadiendo funcionalidades al mismo. La clave del proceso de desarrollar XP es la comunicación. La mayoría de los problemas en los proyectos son por falta de comunicación en el equipo. En XP, aparece un nuevo concepto llamado Metáfora. Su principal objetivo es mejorar la comunicación entre todos los integrantes del equipo, al crear una visión global y común de lo que se quiere desarrollar. La metáfora tiene que ser expresada en términos conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se desarrollará con alguna cosa de la vida real. Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir: Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir una prueba sencilla, y después escribir el código para que la pase. Una vez pasada se amplía y se continúa. En XP hay una máxima que dice "Todo el código que puede fallar tiene que tener una prueba". Con estas normas se obtiene un código simple y funcional de manera bastante rápida. Por esto es importante pasar las pruebas al 100%. Respecto a la integración del soft, en XP se ha de hacer una integración continua, es decir, cada vez se tienen que ir integrando pequeños fragmentos de código, para evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos en la integración final. En todo buen proyecto de XP, tendría que existir una versión al día integrada, de manera que los cambios siempre se realicen en esta última versión. Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del programa. De esta manera se evita que haya partes "propietarias de cada programador". Por esto es tan importante la integración diaria. Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programación en parejas, es decir, hacer que los programadores no trabajen en solitario, sino que siempre estarán con otra persona. Una pareja de programadores ha de compartir el teclado, el monitor y el ratón. El principio fundamental de este hecho es realizar de manera continua y sin parar el desarrollo de código. Las parejas tienen que ir cambiando de manera periódica, para hacer que el conocimiento se difunda en el grupo. Está demostrado que de esta manera el trabajo es más eficaz y también se consigue más y mejor código.
Más info: http://www.cyta.com.ar/ta0502/b_v5n2a1.htm
SCRUM Qué es SCRUM Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, 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 un estudio de la manera de trabajar de equipos altamente productivos. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, complejos, donde se necesita obtener resultados pronto, pronto, donde los requisitos son cambiantes o poco definidos, definidos, donde la innovación, innovación, la competitividad, competitividad, la flexibilidad y la productividad son fundamentales. Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, necesita, cuando las entregas se alargan demasiado, demasiado, los costes se disparan o la calidad no es aceptable, aceptable, cuando se necesita capacidad de reacción ante la competencia, competencia, cuando la moral de los equipos es baja y la rotación alta, alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto. producto.
Historia de Scrum El concepto de Scrum tiene su origen en un estudio de 1986 [1] sobre los nuevos procesos 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 mucho menos del tiempo del que se tardó en lanzar productos anteriores. Estos equipos seguían patrones de ejecución de proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboración entre los jugadores de Rugby y su formación de Scrum (melé en español).
El proceso En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de 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 como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversión mediante la replanificación de objetivos del producto, que realiza durante la iteración con vista a las siguientes iteraciones. Las actividades que se llevan a cabo en Scrum son las siguientes:
Planificación de la iteración El primer día de la iteración se realiza la reunión de planificación de la it eración. Tiene dos partes:
Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de 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 equipo se auto-asignan las tareas.
Ejecución de la iteración Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre 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 su compromiso 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:
Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser 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 las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando replanificando el proyecto. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.
Fundamentos de Scrum Scrum 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í se necesita). La priorización de los requisitos por valor para el cliente y coste de desarrollo en cada iteración. El control empírico del proyecto. Por un lado, al final de cada iteración se demuestra al cliente el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en función de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones necesarias. La potenciación del equipo, que se compromete a entregar unos requisitos y para ello 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 y como con el cliente. El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir resultados. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.
Requisitos para poder utilizar Scrum Los siguientes puntos son de especial importancia para la implantación de una gestión ágil de proyectos como Scrum:
Cultura de empresa basada en trabajo en equipo, delegación, creatividad y mejora continúa. Compromiso del cliente en la dirección de los resultados del proyecto, gestión del ROI y disponibilidad para poder colaborar. Compromiso de la Dirección de la organización para resolver problemas endémicos y realizar cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando una cultura de gestión basada en la colaboración y en la facilitación llevada a cabo por líderes al servicio del equipo. Compromiso conjunto y colaboración de los miembros del equipo. Relación entre proveedor y cliente basada en ganar-ganar, colaboración y transparencia. Facilidad para realizar cambios en el proyecto. Tamaño de cada equipo entre 5 y 9 personas (con técnicas específicas de planificación y coordinación cuando varios equipos trabajan en el mismo proyecto). Equipo trabajando en un mismo espacio común para maximizar la comunicación. Dedicación del equipo a tiempo completo. Estabilidad de los miembros del equipo
Beneficios de Scrum Los principales beneficios que proporciona Scrum son: Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese momento, ya completados) lo cual proporciona las siguientes ventajas:
Gestión regular de las expectativas del cliente y basada en resultados tangibles. Resultados anticipados (time to market ). ). Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado, etc. Gestión sistemática del Retorno de Inversión (ROI). Mitigación sistemática de los riesgos del proyecto. Productividad y calidad. Alineamiento entre el cliente y el equipo de desarrollo. Equipo motivado.
