SCRUM parte 4: “Introducción” y primeras dificultades que se presentan.

Standard

Bueno ahora continuaré donde me había quedado después de un buen rato de no publicar.

En el último artículo, hablamos de las historias de usuario (SP) y algunas de las características que deben de tener. Una vez completado nuestro product backlog, vamos a proceder a planear nuestro sprint.

3.- Sprint Backlog

Como podemos imaginar es una parte de nuestro product backlog sobre el que se trabajará durante el sprint.

Para esto, de nuestro PB vamos a elegir junto con el Product Owner las historias de usuario que espera que sean completadas para el final del sprint. Es decir, al planear el Sprint, el PO es quien nos dice qué tiene prioridad, el equipo lo que cuida es que en caso de haber dependencias entre historias de usuario, estas se resuelvan.

Por ejemplo en caso de una US que nos pida ingresar con un usuario y contraseña, suena más lógico que primero se programe la US que habla del registro de un usuario, ya que para que un usuario pueda ingresar al sistema, este debería ser registrado. Este es un ejemplo muy simple, y estoy seguro que se le ocurren otros y mejores ejemplos de esto.

4.- Ejecución

Pues bueno, ya sabemos que vamos a hacer durante el sprint, pues ahora sí vamos a llevarlo a cabo.

Scrum es bastante práctico, y lo único que nos sugiere es realizar una reunión diario donde cada miembro del equipo responde las preguntas:

  • ¿Qué hiciste hoy/el día anterior?
  • ¿Qué vas a hacer hoy?
  • ¿Qué necesitas o qué impedimentos tienes para completar tus actividades?

Por experiencia he visto que el mejor momento para realizar esta junta diaria es al principio del día laboral, ya que esto ayuda al equipo a organizarse en caso de que haya historias de usuario o actividades que vayan a ser realizadas por más de un integrante del equipo y sirve para la planeación individual.

Otra utilidad que hemos visto al realizar estas reuniones es que si te apoyas de una burndown chart, puedes ver el progreso de tu sprint

Este ejemplo (Sacado de wikipedia) pudiera representar el avance de un sprint, de tal suerte que cada vez que la línea roja se separa de la azul indica que estamos tardando más  o menos en terminar puntos de historia.

Si realizamos esta revisión a diario podemos detectar de manera temprana retrasos y ejecutar acciones correctivas en el día.

Y pues bueno, esta reunión se llevará a cabo durante el sprint, hasta que haya finalizado.

5.- Retrospectiva

La retrospectiva no es otra cosa que la reunión después del Sprint, donde se revisa cómo nos fue como equipo en el sprint.

  • ¿Se entregaron las US que se comprometió el equipo y en caso de que no, por qué?
  • ¿Qué se hizo bien durante el sprint?
  • ¿Qué pudo haberse hecho mejor?
  • ¿Qué acciones se van a tomar para mejorar el desempeño?

Llevar a cabo esta reunión es muy importante, y hacer estas preguntas también, porque es donde el equipo debe autoanalizarse y aprender de los errores. Otra cosa, muy importante es la última pregunta, donde se tienen que definir acciones PUNTUALES Y MEDIBLES, es decir, no podemos poner deseos como “echarle más ganas”, por el contrario, pudiéramos decir, “vamos a realizar pair -programming”. Esto es una acción que podemos llevar a cabo y al siguiente sprint preguntar ¿Cuantas veces hicimos pair programming?.

En mi experiencia, la retrospectiva es un momento clave para la motivación del equipo, revisión del avance del proyecto, aprendizaje y toma de decisiones. Definitivamente indispensable al implementar scrum.

6.- Entrega/Demo

Scrum nos pide que al final de cada sprint entreguemos funcionalidad. En teoría, cada historia de usuario completada debe generar algo de valor para el Product Owner y ser, en lo posible, lo más separada de otras funcionalidades. Por ejemplo, en un sprint podemos enfocarnos en historias de usuario que tengan que ver con el inventario, y al final, entregar esa funcionalidad y que de así desearlo el PO pueda ponerlo en producción de manera inmediata.

Un ejemplo de esto es que, si una US que implementamos nos pedía poder registrar productos. Si la US fue realizada durante el sprint, esta funcionalidad debería poder ser implementada en producción si así se desea, ya que se considera que para que una US se considere terminada, ya debe incluir pruebas durante su desarrollo.

Scrum promueve el entregar 100%. Esto es, que si a una US no se le realizaron pruebas, no debería haber sido marcada como terminada.

En caso de que sea el último sprint, obviamente se espera que el producto que se entregue esté terminado al 100%.

Es obvio que la probabilidad de que salgan bugs siempre está presente, pero “las pruebas con el cliente” es preferible que estén consideradas como parte del desarrollo. Por eso se busca que de ser posible el PO revise una demo cada fin de sprint.

Pues bueno, hasta aquí llegarán los post relacionados con SCRUM directamente. Sé que es un final abrupto pero escribir más sería redundante desde mi punto de vista.

Espero que les sirva a más de uno y recuerden que en caso de tener dudas o comentarios no duden en publicarlos y trataré de responder lo más rápido posible.

Saludos.

Leave a Reply

Your email address will not be published. Required fields are marked *