Manifiesto Agile para mejorar la probabilidad del Software exitoso

El Manifiesto Agile

El Agile Manifesto fue creado en febrero de 2001 por 17 desarrolladores de software que se reunieron en el complejo Snowbird en Utah. "Estamos descubriendo mejores maneras de desarrollar el software haciéndolo y ayudando a otros a hacerlo; A través de este trabajo, hemos llegado a valorar:

Individuos e interacciones más que procesos y herramientas
Software funcional más que documentación completa
Colaboración del cliente más que la negociación del contrato
Responder al cambio más que seguir un plan

Es decir, mientras que hay valor en los artículos a la derecha, valoramos los artículos a la izquierda aun más. "

De acuerdo con el texto del manifiesto anterior, el acento se pone en los elementos de la izquierda. Ser ágil significa:

1. Tener un equipo auto organizado con mejores interacciones y mejor comunicación dentro del equipo; 
2. Enfoque de desarrollo para estar en la creación de un software que funcione que entrega valores de negocio en cada iteración; 
3. Tener una verdadera colaboración con los clientes para ofrecerles la posibilidad de proporcionar una retroalimentación continua durante el desarrollo; 
4. Ser flexible y responder lo antes posible a los cambios de alcance.

Metodologías Agile

Algunas de las metodologías sobresalientes en el marco teórico de Agile son la siguientes:

1. Scrum
2. Kanban
3. XP (Extreme Programming)
4. FDD (Feature Driven Development)
5. AUP (Agile Unified Process)

Con el uso de Agile muchos más proyectos de desarrollo pudieron ser exitosos. De acuerdo con The Chaos Manifesto, The Standish Group 2012, la tasa de proyectos exitosos se elevó de un 14% del total anual a un 42%, mientras que los proyectos con ciertos retos bajaron de 57% al 49%, y los proyectos fracasados disminuyeron de 29% al 9%. El descenso que se registró es en contraste con proyectos desarrollados con la metodología de Cascada (waterfall) clásica.

Descripción de Scrum

En el diagrama se presenta una visión general de toda la metodología Scrum. Mas adelante veremos detalles de los Roles de Scrum, Artefactos, Ceremonias (Reuniones) y Sprints (Iteraciones)

Sprint

Scrum es una metodología iterativa, y el nombre para la iteración es Sprint. 

Sprint 0

Es la iteracion especial realizada al comienzo de un proyecto y le da forma al plan de trabajo sobre el cual construye cada iteración. La duración de cada iteración varia dependiendo de la complejidad y del conocimiento existente de la característica deseada. Durante este Sprint especial se lleva a cabo bastante diseño de sistemas y arquitecturas con el fin de empezar con el desarrollo y darle inicio al primer Sprint.

Durante las iteraciones subsecuentes, se realizarán ajustes a la arquitectura y la ingeniería de sistemas, de llegar a ser necesario. Después del Sprint inicial, todos los Sprints subsecuentes deben ser de la misma longitud. Esta longitud puede estar entre una y cuatro semanas. La longitud recomendada es de dos semanas.

Al inicio del Sprint el equipo debe tener un compromiso claro en el alcance. El alcance del Sprint actual no puede ser cambiado durante el Sprint. 

Las iteraciones cortas permiten que el Dueño del Producto (Product Owner) reciba una retroalimentación del cliente más rápida, estimaciones del desarrollador más rápidas, y actualizaciones de los planes más rápidas, por ende acortando el ciclo de retroalimentación.

Todo proyecto debe tener al menos tres ocasiones en las que los stakeholders (directos implicados en el éxito del proyecto) entreguen su retroalimentación.

Historia de Usuario

La historia de usuario (US por User Story) es una descripción simple y corta de una característica contada desde el punto de vista de la persona que desea la nueva característica, usualmente un usuario o cliente del sistema. 

Criterio de Aceptacion

Una lista de actividades que deben cumplirse para considerar que el trabajo esta terminado.

INVEST (Invertir)

Esta sigla ayuda a recordar un conjunto de criterios ampliamente aceptados, o lista de chequeo, para valorar la calidad de una Historia de Usuario. 

• Independiente
• Negociable
• Valioso
• Estimable
• Small (Pequeño)
• Testable (Comprobable)

Para una Historia de Usuario se puede utilizar el siguiente esquema:

Como un {Tipo de Usuario}, yo quiero {Alguna Meta}de manera que {Alguna Razon}

Epica

Una Historia de Usuario que cubre grandes cantidades de funcionalidad. Debido a que una epica es generalmente muy grande para que un equipo Agil la complete en una iteración, se divide en varias Historias de Usuario más pequeñas antes de trabajar sobre ellas.

Ejemplos - Epica1 Como usuario, puedo respaldar todo mi disco duro, de manera que pueda recuperar los datos cuando sean perdidos.

Esta épica puede descomponerse en un gurpo de historias de usuario:

US1 Como usuario de poder, puedo indicar carpetas para respaldar, basado en el tamaño, fecha de creación y fecha de modificación de manera que ...

 ...

 ...

 US12 Como usuario, puedo indicar carpetas para no respaldar para que mi disco de respaldo no esté lleno con cosas que no necesito guardar, de modo que ...

Jugar Poker

Técnica usada para estimar las historias de usuario en Puntos de Historia SP (Story Points) con valores pertenecientes a la serie de Fibonacci: 1, 2, 3, 5, 8, 13, 21. Utilizando cartas, cada historia de usuario es estimada por todo el equipo. El estimado para una historia de usuario es hecho en secreto por el equipo, luego las cartas son reveladas al mismo tiempo y los miembros del equipo con el menor y mayor estimado deben presentar sus razones para la estimación para la historia de usuario. 

Puntos de Historia - SP

Los Story Points son valores relativos, una historia que fue estimada con dos puntos de historia - 2 SP - debería ser dos veces lo que una historia estimada con 1 SP. Los puntos de historia SP representan el esfuerzo para desarrollar una historia y esto incluye todo lo que pueda afectar el esfuerzo incluyendo cantidad, complejidad, y riesgos asociados con este trabajo.

Cada Historia de Usuario debe:

• crearse usando el esquema visto arriba
• respetar la regla INVEST
• tener definido un conjunto de criterios de aceptación
• ser estimado por el equipo en Puntos de Historia (Story Points) usando la técnica del juego de poquer

Roles del Scrum

Propietario del Producto - es una persona responsable por la bitácora del producto ( el alcance) y por priorizar las características del producto en cada Sprint y sobre el curso de todo el desarrollo del producto.

Equipo - es un equipo auto organizado que incluye a todos los involucrados con el diseño, desarrollo, pruebas y entrega del producto terminado. El objetivo del equipo Agil es entregar un producto de calidad que cumpla con las necesidades de los usuarios.

Scrum Master - Facilita el proceso de scrum y crea un ambiente conducente a la auto organización del equipo. Puede considerarse el coach de todo el equipo. Ayuda a resolver impedimentos. Protege al equipo de la interferencia externa y distracciones. Hace cumplir los periodos pactados.

Artefactos del Scrum

Product Backlog (Pila de Producto) - es una lista siempre cambiante, ordenada y dinámicamente priorizada de requerimientos organizadas por Valor de Negocio. Los requerimientos se descomponen en Historias de Usuario por el Dueño del Producto. Definición de Hecho (DoD Definition of Done) a nivel de la pila.

Sprint Backlog (Pila del Sprint) - contiene todas las historias de usuario comprometidas para el Sprint actual descompuestas en tareas por el equipo. Todos los items en la Pila del Sprint deberían ser desarrollados, probados, documentados e integrados para llenar el compromiso del equipo.

Burndown Chart (Gráfico de Producción ) - Muestra la cantidad de trabajo restante por Sprint. Muestra la correlacion entre trabajo por hacer en cualquier punto en el tiempo y el progreso del equipo.

El gráfico de Burndown es generado normalmente por una herramienta de software, es usado por el Scrum Master para monitorear cada Sprint y es útil para predecir cuando el trabajo para el Sprint actual sería completado.

Velocidad del Sprint - Numero de Puntos de Historia (SP) completados por Sprint 

Tablero

En Scrum los equipos usan Tableros para monitorear las historias de usuario y las tareas para cada Sprint y para cada miembro de equipo.

En la siguiente imagen se puede ver un Tablero de Scrum (con la herramienta JIRA) usada para filtrar todos los incidentes abiertos para un usuario (miembro de un equipo)

Se puede ver, en el tablero anterior, las historias de usuario y sus tareas (para este usuario) agrupadas en tres categorías: 

• Por Hacer
• En Progreso
• Hecho

Ceremonias de Scrum

Scrum Diario - diariamente se hace una reunión de todo el equipo incluyendo el Dueño del Producto no mas de 15 minutos. Cada participante debería responder las siguientes 3 preguntas:

• Que hice yo ayer que ayudara al equipo a cumplir la meta del Sprint?
• Que haré hoy para ayudar al equipo a cumplir la menta del Sprint?
• Veo algun impedimento que me impida a mi o al equipo cumplir la meta del Sprint?

Backlog Grooming - Reunión de Refinamiento de la pila para asegurar que la pila permanezca poblada con elementos que sean relevantes, detallados y estimados de acuerdo con sus prioridades, y en armonía con el entendimiento actual del producto y sus objetivos. La duración de esta reunión no debe superar las 2 horas. Se puede tener un Backlog Grooming cada semana y se debe tener un backlog grooming antes de iniciar el siguiente Sprint.

Planeamiento de Sprint - Es un tiempo restringido a un máximo de 8 horas para un Sprint de 4 semanas. El nuevo Sprint arranca con esta reunión. Un grupo de historias de usuario del tope de la pila de Producto son estimados en puntos de historia y luego descompuestos en tareas y estimadas en horas. Finalmente el equipo , basado en la capacidad del equipo, selecciona un grupo de estas istorias en la nueva pila del Sprint que puede también contener historias de usuario no terminadas en el Sprint previo.

Revisión del Sprint/Demo - Al final de cada sprint tiene lugar una revisión del Sprint o Demo. Durante esta reunión el equipo muestra lo completado en el Sprint. Típicamente esto toma la forma de un demo de las nuevas características o arquitectura subyacente. La duración de esta reunión debería ser de máximo 2 horas.

Retrospectiva del Sprint - reunión que ayuda al equipo a afinar el proceso. Este es un momento para que cada miembro del equipo reflexione acerca de lo que salió bien y las areas de mejora. Deben definirse claramente unos elementos de acción. La duración de esta reunión debería se de máximo dos horas.

Son muchos los beneficios de la metodología Scrum.

• Calidad del producto
• Transparencia
• Flexibilidad
• Menos riesgo
• Más productividad
• Mejor comunicación
• Mejor cooperación