domingo, 14 de junio de 2009

Scrum

Scrum es un proceso de desarrollo de software iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Fue aplicado por Jeff Sutherland y formalizado por Ken Schwaber. Poco después, Sutherland y Schwaber se unieron para refinar y extender Scrum.

Scrum no está concebido como método independiente, sino que se promueve como complemento de otras metodologías, incluyendo XP, MSF o RUP. Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos, implementación y demás técnicas. Se define como un proceso de management y control que implementa técnicas de control de procesos.

Scrum se basa en los siguientes principios ágiles:
  • Colaboración estrecha con el cliente
  • Predisposición y respuesta al cambio
  • Prefiere el conocimiento tácito de las personas al explícito de los procesos
  • Desarrollo incremental con entregas funcionales frecuentes
  • Comunicación verbal directa entre los implicados en el proyecto
  • Motivación y responsabilidad de los equipos por la auto-gestión, auto-organización y compromiso
  • Simplicidad. Supresión de artefactos innecesarios en la gestión del proyecto


Roles

Product Owner
  • Representa a todos los interesados en el producto final
  • Financia el proyecto
  • Provee los requerimientos del sistema
  • Prioriza los features
  • Adapta los incrementos de cada Sprint
Scrum Master
  • Representa el management del proyecto
  • Es responsable de velar y difundir los valores y las prácticas de Scrum
  • Su tarea principal es remover impedimentos
Equipo de Desarrollo
  • Típicamente de 5-10 personas
  • Multi-funcional
  • Los miembros deben ser full-time
  • Los equipos son auto-organizativos
  • Sólo puede haber cambio de miembros entre los sprints

Ciclo de Vida de Desarrollo



El Sprint es el período de tiempo durante el que se desarrolla un incremento de funcionalidad. Constituye el núcleo de Scrum, que divide de esta forma el desarrollo de un proyecto en un conjunto de pequeñas "carreras". La duración máxima de un sprint es de 30 días. Durante el sprint no se puede modificar el trabajo que se ha acordado en el Sprint Backlog. Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede hacer el Scrum Master si decide que no es viable por algunas de las razones siguientes:
  • La tecnología acordada no funciona
  • Las circunstancias del negocio han cambiado
  • El equipo ha tenido interferencias


Artefactos

Product Backlog
Listado con los requerimientos del sistema.
Contiene: features, requerimientos de desarrollo (no funcionales), tareas investigativas, bugs.

Es responsabilidad del Product Owner:
  • Contenido,
  • Priorización,
  • Disponibilidad
Está dado por una combinación de:
  • Trabajo basado en funcionalidad
  • Trabajo basado en tareas
Es un documento dinámico que incorpora constantemente las necesidades del sistema. Se mantiene durante todo el ciclo de vida (hasta el retiro del sistema).

Sprint Backlog
  • Trabajo o tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo un incremento de funcionalidad
  • Las de mayor duración deben intentar descomponerse en sub-tareas de ese rango de tiempo
  • En Scrum se debe ir registrando los tiempos día a día para poder armar el gráfico de avance del proyecto
  • El equipo agrega tareas cuando lo crea necesario, pudiendo eliminar las que considere innecesarias, y ajusta estimaciones a medida se avanza
Burndown Chart

El Burndown Chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.


Reuniones

Spring Planning Meeting: Acude el equipo, el Scrum Master y el Product Owner.
  • El equipo de desarrollo toma el objetivo del Sprint y decide las tareas necesarias para los ítems del Product Backlog
  • El equipo se auto-organiza acerca de cómo alcanzar el objetivo del Sprint
  • El Scrum Master NO asigna las tareas a los individuos
  • El Scrum Master NO toma decisiones por el equipo
  • Se crea el Sprint Backlog de acuerdo a las prioridades de negocio que establece el Product Owner

Daily Meeting: Reunión diaria del equipo con duración máxima de 15 minutos.
  • Todos los días en el mismo sitio y a la misma hora
  • Se recomienda que sea la primera actividad del día
  • Deben acudir todos los miembros del equipo
  • Moderada por el Scrum Master, que pregunta a todos los asistentes:
  • ¿Cuál ha sido el trabajo realizado desde la última revisión diaria?
  • ¿Cuál es el trabajo previsto para hoy?
  • ¿Hay algo que necesitas, o que te impide realizar el trabajo previsto?
  • No se permite entrar en divagaciones o salirse del guión
  • Sólo habla la persona que informa de su trabajo, el resto escucha y no hay lugar para otras conversaciones
  • Cuando un miembro informa de algo de interés para otros, o necesita ayuda de otros, estos se reúnen al terminar la revisión diaria
  • Las personas externas que estén presentes no pueden intervenir ni distraer, y el Scrum Master puede limitar el número de personas externas asistentes si lo considera oportuno
Sprint Review Meeting: Reunión en que participa: Scrum Master, Product Owner, Equipo, todas las personas implicadas en el proyecto.
  • Duración máxima: 4 horas
  • Finalidad: presentar al Product Owner y a las demás personas las nuevas funcionalidades implementadas
  • Las funcionalidades no implementadas no se presentan
  • En la reunión, los miembros del equipo muestran las nuevas funcionalidades
  • Al final de la reunión se interroga individualmente a todos los asistentes para recabar impresiones, sugerencias de cambio y mejora, y su relevancia
  • El Product Owner trata con los asistentes y con el equipo las posibles modificaciones en el Product Backlog
Sprint Retrospective Meeting: Acude el equipo y el Scrum Master, y opcionalmente el Product Owner.
  • Todos los miembros del equipo responden a dos preguntas:

  • ¿Qué cosas fueron bien en el último sprint?
  • ¿Qué cosas se podrían mejorar?
  • El Scrum Master anota todas las respuestas
  • El Equipo prioriza las mejoras posibles
  • El Scrum Master no proporciona respuestas, sino que ayuda al equipo a encontrar la mejor forma de trabajar con Scrum
  • Las acciones de mejora localizadas que se puedan implementar en el próximo Sprint deben introducirse en el backlog como elementos no funcionales

Conclusiones

Scrum es una metodología ágil ideal para modelar proyectos críticos y complejos, en los que la calidad y velocidad de implementación son fundamentales, pero donde los requerimientos son vagos o muy cambiantes.

El énfasis de Scrum está en buscar que los proyectos de desarrollo le aporten a las organizaciones el mayor valor posible a muy corto plazo, con resultados de calidad que respondan a las necesidades reales del negocio.

A favor, tiene que:
  • Hace foco en entrega rápida de producto
  • Existe feedback continuo y frecuente sobre el progreso del desarrollo, gracias a las reuniones diarias y de revisión de sprint
  • Da libertad al equipo de trabajo de usar las prácticas de desarrollo que prefieran
En contra, tiene que:
  • Puede caer en un modelo de codificar y probar, si no se realiza un coaching
  • El QA está embebido informalmente en muchas partes del ciclo de vida
  • Establece en el equipo de desarrollo una fuerte aversión a la documentación

Fuentes

Apuntes de la materia 75.51 de FIUBA: Técnicas de Producción de Software I. Clase Scrum. Versión 1.2: Mayo 2008