Mensajería instantánea

Un cliente se ha puesto en contacto con nosotros para desarrollar un sistema de mensajería instantánea para su empresa. Obviamente ya existen muchos productos similares en el mercado, pero el cliente tiene algunas necesidades especiales. Su idea es utilizarlo internamente en su organización para la comunicación entre sus empleados.

Vamos a realizar el desarrollo utilizando Scrum como metodología y, como ya sabemos, eso significa que lo primero es acordar con el cliente las historias de usuario. Supongamos que ya hemos superado esa etapa —se dispone de una propuesta de historias de usuario aquí— y que las hemos apuntado, junto con su valor de negocio según el cliente y su dificultad. Por lo que es hora de continuar con el desarrollo. 

Repositorio del proyecto

Vamos a trabajar en repositorios de código en GitHub —solo con uno debería ser suficiente para todo el proyecto— preferentemente en equipo. A parte del repositorio de código gestionado mediante Git, utilizaremos el Wiki para documentar y, opcionalmente, las "issue" para controlar las tareas que se vayan realizando. 

Elaboración del Product Backlog

Como ya hemos comentado, para la documentación utilizaremos el Wiki del proyecto que nos ofrece GitHub. Por lo tanto, lo primero será crear la página ProductBacklog. Allí escribiremos el "product backlog", donde colocaremos nuestras historias ordenadas según lo vayamos a hacer. Para eso habrá que:

• Estimar la dificultad de las tareas (story points):
  • Se puede hacer con una escala sencilla, como: fácil, normal y difícil.
  • O se puede hacer de forma numérica entre 1 y 6:
    1. Se asigna un 2 a la tarea más sencilla.
    2. Se toma otra tarea y se asigna un 2 si es igual de difícil que la anterior, un 3 si es más difícil pero no el doble de difícil y un 4 si requiere el doble de esfuerzo.
    3. Si se supera el 6 se marca como imposible (7) y la tarea tiene que ser descompuesta en tareas más simples
• Estimar el ratio valor de negocio / dificultad.
• Ordenar las tareas según el orden estimado en que se vayan a desarrollar. Generalmente se pone primero las que proporcionan más valor con menos esfuerzo (mayor ratio), aunque es posible que el Product Owner quiera prioriza algunas características respecto a otras.

Para esto será necesario reunirse con el Product Owner, de tal forma que nos pueda indicar si hay funcionalidades prioritarias o cual será el criterio de aceptación. Esto último seguramente será fundamental para estimar la dificultad de cada historia.

Alternativamente, para la gestión del proyecto se puede utilizar alguna de las herramientas indicadas en el campus, como: taiga.io o trello.com.

Markdown para el Product Backlog

Las páginas del Wiki de GitHub se escriben en notación markdown. En markdown se puede hacer una tabla para el listado de historias del product backlog, como esta:

https://github.com/CANUBE/AstroPack/wiki/Product-Backlog/

de la siguiente manera:

id | Nombre | Descripción | Pruebas aceptación | Dificultad / Story points | Estado (Hecho/No hecho)
---|--------|-------------|--------------------|----------------------------|------------------------
1|ABC|EFG|HIJ|XYZ|NO HECHO 

Planificación del Sprint

En lo que queda de asignatura se harán varios Sprint (al menos 3), de dos semanas cada uno, para implementar las funcionalidades del Product Backlog. Antes de comenzar cada sprint, será necesario que el equipo se reuna para determinar las historias que serán implementadas:

• Si queda alguna duda, es importante cerrar con el Product Owner el criterio de aceptación para cada una de las tareas. Esto es importante para evitar problemas a la hora de que las historias sean aceptadas.
• La lista de historias del sprint (o Sprint Backlog) constituye el documento resultante de esta reunión. A continuación veremos las opciones principales para hacerlo.

Sprint backlog en el Wiki

El mínimo es que, al igual que como en el caso del Product Backlog, se cree una página en el Wiki para cada sprint planificado. Un nombre para dicha página podría ser SprintBacklog-20140401, donde en lugar de 20140401 se indica la fecha de la reunión de planificación del Sprint. Dentro, una tabla como la siguiente con las historias a desarrollar, sería suficiente:

id | Nombre | Descripción | Pruebas aceptación | Desarrollador | Estado (No hecho/Pendiente de aceptación/Hecho)
---|--------|-------------|--------------------|---------------|------------------------
1|ABC|EFG|HIJ|XYZ|NO HECHO

Recuerden:

1. No es necesario asignar a los desarrolladores en la planificación del Sprint. Estos pueden modificar el documento para asignarse una según terminen tareas previas.
2. Las historias hechas se marcan como Pendiente de aceptación, hasta que el Product Owner las verifique. Sólo entonces pueden ser marcadas como "Hecho".
3. A la hora de asignar un número de tareas recuetden tener en cuenta su velocidad de equipo estimada. Es posible que en el primer sprint no la conozcan pero para el segundo ya pueden sumar los puntos de dificultad, para saber cuanto trabajo pueden hacer en cada interacción.

Sprint backlog como issues

(opcional) se puntuará positivamente no usar el wiki sino las issues de Github (ver a la derecha, encima del enlace al Wiki):

1. Se creará un milestone de nombre SprintBacklog-20140401, donde el 20140401 indica la fecha de la reunión de planificación del Sprint, para el siguiente Sprint. Los milestone se crean pulsando en la rueda dentada a la izquierda.
2. Pulsando en New Issue se crea un issue para cada historia. En el título se indica el nombre y en el primer comentario la descripción y la pruebas de aceptación acordadas. Como las historias son nuevas funcionalidades, se pulsa a la derecha, en enhancement, para etiquetar la issue como una mejora. Además, a cada issue se asigna al milestone del sprint que le corresponde usando el menú de la rueda dentada de la derecha.
3. Si durante el desarrollo surgieran bugs responsabilidad de otro compañero, se pueden incluir como una issue, etiquetarlas como bug, incluirlas en el milestone, si deben ser resueltas para este sprint, y asignadas a dicho compañero.

Durante el sprint los desarrolladores se podrán asignar un issue usando el menú de rueda dentada de la izquierda. Podrán hacer los comentarios que quieran sobre el trabajo, enlazar a ejemplos en otras webs o a páginas del wiki, si allí documentaran algo.

Cuando la tarea esté hecha, la issue debe ser cerrada por el desarrollador, pendiente de aceptación por parte del product owber.

Sprint backlog en Taiga o Trello

Taiga incluye un mecanismo para definir el Sprint backlog y para seguir la evolución de las tareas. Mientras que la estructura estándar un Board de Trello  (con las listas de TODO, Doing, Done) también sirve. Usar cualquiera de estas herramientas también se valorará positivamente.

Revisión del sprint

El equipo debe quedar con el product owner para la aceptación de las tareas. Las tareas aceptadas serán marcadas como hechas en la página del Sprint Backlog y en la del Product Backlog.

Después se calculará la velocidad del equipo y se hará una pequeña retrospectiva para ver que se puede mejorar y vuelta a empezar.