Este tipo de metodologías minimiza el volumen (entiéndase: cantidad) de documentación y procesos formales con el fin de mejorar la productividad y así reducir los tiempos de ingreso del producto en el mercado.
El Manifiesto Ágil
Individuos e interacciones >> sobre >> Herramientas y procesos
Software funcionando >> sobre >> Documentación extensiva
Colaboración con el cliente >> sobre >> Negociación contractual
Respuesta ante el cambio >> sobre >> Seguir un plan
Aspectos importantes a tener en cuenta
- Agile propone iteracciones cortas que finalizan con un entregable que representa un incremento del producto.
- Los Requerimientos se expresan en forma de User Stories (Historias de Usuario) dentro de un Backlog (registro) que esta priorizado.
- El proceso que propone esta metodología, requiere que haya una interacción frecuente con el Product Owner (Dueño del producto).
Aspectos positivos
- mejoran la productividad
- mejoran la comunicación del equipo
- mejoran la incorporación de los cambios
- mejoran la visibilidad de los avances ante el cliente
Aspectos negativos
- no se produce mucha documentación de los requerimientos, razón por lo cual muchos lo complementan con análisis de riesgos
Metodologías Ágiles más populares
- Scrum
- Extreme Programming (XP)
Scrum
Además de alinearse al Manifiesto Ágil, comprende un proceso controlable muy parecido al modelo Evolutivo Incremental, con roles, reuniones y uso de herramientas.
Roles
- Product Owner
- Scrum Master
- Team Member
El Product Owner
- Es quien representa al cliente dentro de la empresa o grupo de desarrolladores.
- Es el nexo entre ambos.
- Maneja la comunicación con el cliente, así como también el feedback que recibe.
- Posee la visión global del negocio y del producto que se busca.
- Se encarga de armar y establecer las prioridades del Product Backlog (lista priorizada de requerimientos).
El Scrum Master
- Es quien representa al equipo.
- Es el nexo entre el equipo y el Product Owner.
- Es quien se responsabiliza del buen funcionamiento del equipo, creando un adecuado ambiente de trabajo.
- Es un facilitador de reuniones y motivador de acciones sobre su/s equipo/s.
- Provoca que los problemas salgan a flote para que todos los puedan ver y así, en consecuencia, tratar.
- Se ocupa de eliminar los obstáculos que se vayan presentando, imprimiéndole al equipo la dinámica que le haga falta.
El Team Member
- Debe ser autónomo y auto organizado.
- Es reponsable del producto final.
- Toma decisiones de diseño, implementación y pruebas.
- Estima el esfuerzo del trabajo a realizar.
Sobre algunos conceptos que debemos tener muy presente
Sobre los Sprints
Tal como se muestra en la clásica imágen del «Scrun en acción», los ciclos de desarrollo se denominan Sprints, y cada uno de ellos por lo general dura entre 1 a 4 semanas. Aquellos que están desde hace un tiempo llevando a cabo estas prácticas recomiendan no variar su duración durante el proyecto.
Sobre el Product Backlog
Antes de iniciar el proyecto, el Producto Owner construye este elemento de trabajo donde básicamente contendrá la lista de todos los requerimientos del usuario.
A cada uno de estos requerimientos se los denomina «User Story» y representan el «que» del proyecto.
El Product Backlog estará en constante evolución, y por ese motivo el Product Owner es el dueño del mismo y quien se ocupa del mantenimiento y de la priorización de las User Stories.
Sobre el Kick Off del proyecto
Es la primera reunión que se realiza entre todos los miembros del proyecto, es decir, entre el Product Owner, Scrum Master, Team Member y todo aquel involucrado en el proyecto. Aquí, además de relatarse el qué, porqué y cuándo, se priorizan y/o re priorizan los puntos del Product Backlog, haciéndose las correspondeintes estimaciones del esfuerzo de trabajo para cada uno de los requerimientos.
Sobre el Sprint Planning
Para elaborar el plan, se seleccionan las User Stories (los requerimientos) del Product Backlog que se llevarán a cabo durante el Sprint, se confecciona un listado con todas las tareas que se necesitan para comenzar y terminar cada uno de estos requerimientos, indicando su respectivo esfuerzo de trabajo (diseño, programación, revisión de código, pruebas, etc), y finalmente, se asignan responsables para cada una de las tareas listadas (uno y solo uno).
Sobre el Sprint Backlog
El equipo debe comprometerse a finalizar en un Sprint, todo el listado resultante de la planificación del Sprint (Sprint Backlog), llevando a cabo la implementación de cada una de las User Stories seleccionadas.
Sobre la Daily Scrum Meetings
Son las reuniones que se realizan todos los días y conducidas por el Scrum Master.
No deben durar más de 15 minutos, y es donde todo el equipo se reúne y cada miembro comenta en qué estado se encuentran sus tareas, enfocándose en los siguientes aspectos: qué hizo, qué tiene por hacer, qué impedimiento tiene para completar la tarea. El objetivo de estas reuniones diarias pretende que todo el equipo conozca el progreso de las actividades y detectar los desvíos lo más pronto posible. Importante: estas reuniones no son técnicas, y no se discuten sobre aspectos relacionados con la implementación. Para ello se podrán proponer otras reuniones para un subconjunto del equipo que se encuentre involucrado.
Sobre las Sprints Reviews
Es una reunión que se realiza al finalizar cada Sprint.
Los asistentes deberían ser todos los miembros del equipo de proyecto (Product Owner, Scrum Master, Team Members y demás involucrados).
Se revisan todos los items asignados en el Sprint en estado de finalizados (teóricamente deberían ser todos).
El Product Owner los analiza y dá su feedback (teóricamente su aprobación) respecto de estos ítems.
Terminada la reunión, se vuelve a trabajar nuevamente en el siguiente Sprint Planning, hasta acabar con los items del Product Backlog o bien, hasta que el producto satisfaga al cliente.
Sobre la Retrospective
Es una reunión que se realiza cuando finaliza el proyecto.
Los asistentes deberían ser todos los miembros del equipo de proyecto (Product Owner, Scrum Master, Team Members y demás involucrados).
Se analiza el proceso seguido durante todo el proyecto y propone que se respondan las siguientes preguntas:
-qué se hizo bien
-qué se hizo mal
-qué se puede mejorar
-qué se aprendió
Síntesis
Propone entregar incrementos del producto final que se encuentren listos (o lo más próximo a estarlo) para un Release, al final de cada Sprint.
Los incrementos deberán encontrarse «finalizados», habiéndolos probados en su totalidad.
Estos incrementos podrán ser implementados y el cliente podrá usarlo cuando lo requiera.
Cada incremento debe tener la propiedad de aportar nueva funcionalidad respecto de los anteriores Sprints.
Deberán ser probados cada uno de los incrementos anteriores, asegurando que los mismos siguen funcionando hasta la fecha.
El equipo debe auto organizarse, manejar la responsabilidad, tomar decisiones.
Los miembros del equipo no deberían ser novatos.
Son candidatos para este tipo de metodología, proyectos con las siguientes particularidades:
-manejo de requisitos inestables, que requieren respuestas rápidas y flexibles
La característica principal que se debe tener es: ser flexible frente a los cambios.
El objetivo principal a cumplir es: darle visibilidad temprana al usuario.
Ventajas:
- Cada incremento aporta nueva funcionalidad
- Se analiza el progreso en cada reunión permitiendo detectar riesgos de manera temprana
- Flexible y se adapta a los cambios
Desventajas:
- Requiere equipo experimentado y con excelente comunicación
- Requiere de un usuario muy involucrado durante todo el proceso
Seguiré escribiendo artículos vinculados con teoría y proponiendo un debate sobre una temática en particular.
- ¿Tienes duda sobre algún tema en particular?
- ¿Tienes experiencia en Scrum y quieres compartirla?
