jueves, 13 de noviembre de 2008

SCRUM ( III )

En el artículo de hoy veremos las diferentes reuniones que se realizan a lo largo de cada uno de los sprints.


Reunión de inicio de sprint

Esta es la reunión de la que nos acordaremos más en el transcurso del sprint sinó la hacemos correctamente. Se realiza al principio de cada sprint, a poder ser un lunes por la mañana, cuando la gente está bien despierta y sin los agobios de toda la semana de trabajo. A ella acuden el dueño del producto, el scrum master y el equipo de desarrollo. La faena del dueño del producto ( como ya hemos visto en anteriores artículos ) es llegar a la reunión con el product backlog priorizado y detallado en sus histórias más prioritarias. En la reunión ( que acostuma a durar toda la mañana ) el dueño del producto explica al equipo cada una de las histórias que cree que van a entrar en el sprint y el entre todos se dedican a dividir la história en las diferentes tareas que la van a componer. Este diálogo es importantísimo ya que ayuda mucho a detallar exactamente lo que se va a implementar en el sprint y evita que al final del mismo haya malentendidos entre el dueño del producto y el equipo de desarrollo. De la misma forma, ayuda a detallar la história tal y cómo la entiende el dueño del producto, ya que el equipo puede creer que para implementar una tarea tiene que hacer un acceso a datos complicadísimo y en cambio el dueño del producto no lo cree necesario. Sin este diálogo, el equipo de desarrollo implementaria este acceso a datos, tardando un montón y haciendo código innecesario ya que el cliente no lo cree necesario.
En esta reunión, una vez detalladas las tareas, el equipo las debe estimar. Hay várias maneras de estimar una tarea, de las quales ya hablaremos algún dia. La estimación también ayuda mucho a refinar las tareas. En la estimación puede quedar reflejado que el equipo de desarrollo cree que para una tarea se debe hacer un algoritmo muy complicado y en cambio el dueño del producto quiere algo más simple. La estimación del equipo saldría con un valor muy alto, valor que sorprendería mucho al dueño del producto y se iniciaria otro diálogo para delimitar el alcance de la tarea.

Cómo podemos ver, aquí queda de manifiesto una de las cosas más importantes de las metodologías ágiles: la comunicación. Es muy importante la comunicación entre los miembros del equipo, desde el dueño del producto hasta los desarrolladores.

La reunión de planificación debe terminar decidiendo entre el equipo y el dueño de producto qué histórias entran en el sprint. Esto lo podemos hacer también de varias maneras ( que también veremos en otro artículo ) pero básicamente de lo que se trata es de estimar la velocidad del equipo en el sprint ( la cantidad de puntos de história que puede hacer el equipo ) y mirar qué histórias de usuario entran en el sprint. Si todavía no conocemos la velocidad del equipo la podemos intentar deducir. Primero asumiremos que un punto de história es el trabajo que puede hacer un desarrollador en un dia de trabajo ( no en un dia ideal, sinó en un dia "normal" ). Esta definición no es importante. Podeis utilizar la definición que queráis. Lo que es importante es que la definición la mantengáis constante a lo largo de la vida del proyecto. No puede ser que un dia utilicemos dias ideales y otro dia dias "normales".

Una vez aclarado esto, sumamos los puntos de história que puede hacer el equipo. Por ejemplo, si somos un equipo de cinco personas, tres de las quales estan a tiempo completo y dos a mitad de jornada, tendremos que en tres semanas el equipo puede asumir 60 puntos de história. A este valor, nosotros le aplicamos otro modificador, para intentar estimar los posibles impedimentos que podamos tener. Un valor normal puede ser un 70%. Por lo tanto, diremos que nuestro equipo es capaz de asumir 42 puntos de historia en un sprint. Teniendo ordenadas las histórias por prioridad, podremos ir viendo qué histórias nos entrarán en el sprint. Por ejemplo, si nuestras histórias hemos estimado que nos ocuparán 6, 10, 8, 12, 4, 8 y 12 puntos de história, decidiremos que haremos las primeras 5 histórias.

Hay dos cosas más importantes que deben decidirse en esta reunión:
  • El objetivo del sprint. Puede parecer superfluo pero és importante definir un objetivo del sprint para que el equipo sepa porqué está trabajando.
  • Definición de acabado. Cómo vimos en el artículo anterior, es vital tener una definición común de acabado entre el dueño del producto y el equipo de desarrollo.

Sprint diário

El sprint diário es la herramienta que nos proporciona scrum para que el equipo pueda compartir conocimiento y se comunique a diário. En esta reunión ( de unos 15 minutos en general cómo máximo ) cada miembro del equipo debe contestar tres preguntas:

  • Qué hice ayer.
  • Qué haré hoy.
  • Qué inpedimentos tengo para realizar mi trabajo.

Esta reunión es muy importante por la visibilidad que dá del proyecto y del trabajo de cada uno. Haciendo asistir a todo el equipo a la reunión evitamos que haya alguien que no haga nada durante un dia. El hecho de tener que decir delante de todo el mundo que no se ha avanzado en nada, hace que la gente trabaje cada día.

Esta reunión también nos sirve para tener el control del avance del proyecto. Gracias al sprint diario podemos actualizar nuestro tablero de scrum ( real o virtual ) y ver cómo avanzan las histórias, ver si tenemos demasiadas histórias en paralelo, demasiadas en testeo, etc. Lo otro que podemos actualizar gracias a la esta reunión es el gráfico de burndown, que nos dá una información muy visual del estado del proyecto y, sobretodo, de la velocidad del equipo, pudiendo ver de un solo vistazo si se llegará a final de sprint con todas las tareas realizadas o no.

Demostración

La penúltima reunión del sprint es la demostración. En la demostración el equipo de desarrollo debe mostrar a todo el mundo los avances realizados en este sprint, es decir, el incremento de valor que han dado al producto. Esto es muy importante porque el equipo se obliga a tener un producto que se pueda ensenyar, en un entorno de preproducción lo más fiable posible. También es importante porque el dueño del producto puede ver si lo que se ha implementado es lo que el pedía, si ha habido algún malentendido, si todo va a la velocidad requerida, etc. A esta reunión también puede asistir otra gente de la empresa, cuya opinión puede ser tenida en cuenta por el dueño del producto para planificar las próximas histórias a realizar. El equipo nunca debe sentirse influenciado por estas opiniones, ya que su interlocutor en qüestión de producto es el dueño del mismo.

Retrospectiva

Es la última reunión de cada sprint. En esta reunión se hace una revisión de cómo ha ido el sprint, qué ha ido bien y qué ha ido mal. Hay várias formas de hacer una retrospectiva. Una de las más habituales y rápidas es hacer una línea temporal en la pizarra e ir apuntando todo lo que se ha hecho en el sprint ( reuniones, impedimentos, logros, etc ). Una vez hecho esto, cada miembro del equipo señala aquellas cosas que le parecen más positivas y aquellas que le parecen más negativas. Las positivas se intentan repetir sprint a sprint. Las negativas se estudian porqué han ido mal y se intenta ver qué se puede hacer para solventar la situación y hacer que vaya mejor en poteriores sprints.


Mini reuniones de diseño

Estas reuniones no son obligatorias pero nosotros recomendamos hacerlas para no sobrecargar en demasía las reuniones de revisión diárias. Su cometido es comentar entre varios miembros del grupo de desarrolladores cosas relativas a decisiones de diseño de la aplicación. Por ejemplo si el miembro A del equipo empieza hoy la tarea "backup de datos de la aplicación" y no tiene claro cómo hacerla, en lugar de empezar una discusión de cómo hacerlo en la reunión de revisión, los miembros implicado se reunen a posteriori para hablar del tema.

Pués esto ha sido todo por hoy. Nos leemos en los comentarios!

martes, 11 de noviembre de 2008

SCRUM (II)

En este segundo artículo sobre Scrum veremos toda aquella "documentación" que generamos a lo largo de la gestión de un proyecto utilizando Scrum. Más allá de la propia documentación del proyecto cómo pueden ser manuales de usuario, archivos de ayuda, diagramas de diseño, etc, hablaremos de la documentación que se genera por el echo de utilizar Scrum. Dado que Scrum es un marco de desarrollo ágil y cómo tal prefiere el software que funciona por encima de la documentación exhaustiva, veremos que la documentación que generamos no es muy amplia aunque, eso sí, muy útil.

Product Backlog El product backlog es el documento donde se describen las histórias de usuario que se quiere que alguna vez esten presentes en nuestra aplicación. Es cómo la lista a los reyes magos. Este documento está mantenido por el dueño del producto, de echo mantener este documento es su principal tarea. Debe mantenerlo actualizado con las histórias que él crea conveninte y, sobretodo, lo debe mantener priorizado. El equipo tiene que saber siempre cuáles son las tareas más importantes para nuestro cliente ( es decir, que tareas tienen un mayor retorno de la inversión ) para así poder centrarse en ellas y dar el máximo valor posible en cada iteración.

Esta lista no tiene porque estar completa al principio del proyecto, de echo, dado que somos un equipo ágil y valoramos el cambio cómo una oportunidad, no nos importa que esta lista vaya variando a lo largo del proyecto. Tampoco hace falta que todos los elementos estén detallados de igual manera; los que tienen que estar más detallados són los que tengan mayor prioridad, los otros ya se irán detallando más adelante. De esta manera gastamos el tiempo del dueño del producto en las tareas más importantes a día de hoy, dejando las menos importantes para más adelante porque quien sabe si al final se van a realizar o se van a modificar.

También es importante acordar la definición de completado ( Definition Of Done - DOD). Sobre este tema, hay un montón de literatura. Cómo muestra os adjunto una imagen sacada del artículo How Do We Know When We Are Done? de lo que entiende el autor por acabado:

Como véis el autor define varios niveles de definición de acabado y es realmente detallista. Es importante tener una buena definición de acabado y que todo el mundo la tenga clara para evitar posibles desviaciones en nuestra estimación por no realizar todas las tareas necesarias.


Sprint Backlog
Es el documento resultante de la reunión de inicio de sprint. En él se detallan lo máximo posible aquellas tareas que se van a realizar en el sprint actual. Se describen con profundidad las histórias de usuario, se dividen en tareas y se estima su esfuerzo. Son estas tareas las que compondran el sprint backlog. Durante el desarrollo del sprint, cada miembro del equipo seleccionará una tarea de entre las más prioritarias cuando acabe de realizar la actual. Esta lista la tendremos que ir manteniendo dia a dia en la reunión de sprint diaria actualizando el estado de las tareas ( no empezada, empezada, acabada ) y actualizando también las horas restantes de desarrollo. Esto nos permitirá mantener los siguiente documentos que pasamos a explicar.

Tablero de scrum
Este tablero nos indica el estado actual de nuestras tareas. Vemos que se compone de una cuadrícula compuesta por filas ( las histórias del product backlog ) y columnas ( el estado de las tareas ). El equipo de desarrollo debe actualizar dicho tablero cada dia en la reunión diária y así todo el mundo puede tener una visión rápida y exacta de cómo se está desarrollando el sprint. También podemos incluir en el tablero las tareas que no estaban planeadas y que se han acabado realizando y las próximas histórias del product backlog, por si acabamos las planeadas inicialmente.
( Imágen extraída del libro Scrum y XP from the trenches de Henrik Kniberg )

Sprint Burndown Chart

En el tablero de sprint también pondremos el sprint burndown chart. Este gráfico nos indica de una manera muy visual cuál es la velocidad del equipo y nos permite vislumbrar si el equipo acabará todas las tareas en el tiempo marcado. Cada día, en la reunión de sprint, el equipo actualizará el tablero de sprint con los datos de avance de estas tareas. Estos datos de avance ( las horas que le quedan a cada tarea ) también se pondrán de manifiesto en el gráfico, haciendo una línea desde el punto de las horas que quedaban por hacer ayer y las que quedan por hacer hoy ( ya que hemos restado las que hemos echo ). Esto, si lo comparamos con la línea ideal que se dibuja desde el punto de máximas horas del dia de inicio de sprint, al punto de horas cero en el úlitimo dia de sprint nos dá información sobre si el equipo avanza a la velocidad adecuada o no. En próximos artículos ya hablaremos de cómo analizar un gráfico de avance.

Y por hoy esto es todo. Nos leemos en el próximo artículo!