Hace un tiempo escribí un post titulado usar Evernote en Proyectos Ágiles, donde proponía usar Evernote como tablero virtual. En la práctica he usado este método en algunos proyectos y me ha gustado por varios motivos, principalmente porque es una herramienta que cuenta con mucha aceptación y sobre todo por la buena documentación que queda al final: Evernote es una herramienta que anima a a la gente a escribir sobre historias, personas, retrospectivas, impedimentos, etc. Este método que yo proponía, sin embargo, tiene varios inconvenientes: hay que compartir la cuenta del Product Owner, no es cómodo repriorizar historias, y el equipo técnico prefiere usar otras herramientas para manejar sus tareas.
Asana últimamente me está gustando más. Yo uso Asana para mi productividad personal, para interaccionar con los alumnos, en proyectos, para ponerles deberes a mis hijos... En los proyectos ágiles, Asana siempre ha sido mi opción de tablero virtual para el sprint backlog, pero me empeñaba en mantener Evernote para el resto de la documentación. Hasta que pensé: ¿Asana también serviría para documentar? Mi motivo principal para usar Evernote era que funciona offline, es decir, aun cuando la gente no esté conectada a Internet, pueden seguir escribiendo. Si no hay conexión, entonces Asana no se puede usar. ¿Esto es una verdadera limitación? Si no hay cable, hay wifi, y siempre puedo usar la wifi del teléfono… Conclusión: me quedo con una herramienta para todo lo que tenga que ver con gestión por tareas, y esa herramienta es Asana, no necesito más.
En este post voy a tratar de explicar cómo me propongo usar Asana a partir de ahora, como única herramienta de gestión bajo metodología Scrum. Si quieren ver en Asana el ejemplo que he preparado (como si fueran el Scrum Master) pueden usar este acceso:
- www.asana.com
- usuario: jose.barato@pmpeople.es
- password: pmpeople
Después creo un proyecto REL1 para las historias del product backlog que deban ponerse en producción el 16 de noviembre (due date del proyecto Asana). El Product Owner debe ser el dueño de todas las historias de usuario. Si quiere anotar el tamaño en story points, por ejemplo, puede quedar entre paréntesis en el título. En Asana es sencillo priorizar moviendo las tareas arriba o abajo (también pueden etiquetar con el método MoSCoW).
Las etiquetas pueden usarse para indicar a qué módulo funcional pertenece la historia. En Asana es cómodo filtrar por etiquetas: Si pulsamos en la etiqueta “feature 1” por ejemplo, salen todas las historias que configuran esta funcionalidad.
También es cómodo filtrar etiquetas. Por ejemplo, aquí vemos qué historias son de la funcionalidad 1 y obligatorias en la release 1:
En la planificación del sprint, si se quiere asignar, por ejemplo, una historia al sprint 1.1 (creo que es buena práctica indicar con un prefijo a qué release pertenece el sprint) es tan sencillo como añadir un nuevo proyecto a esa tarea.
En el proyecto sprint1.1 veríamos las historias planificadas para esas 2 semanas. El equipo técnico puede añadir las tareas que descomponen las historias. Me parece recomendable agrupar por secciones las tareas con sus historias para saber en todo momento a qué historia se refiere una determinada tarea.
En el scrum diario, los miembros del equipo podrán referirse a las tareas, anotar o comentar impedimentos, etc. Cuando un miembro del equipo decide hacer una tarea, puede poner su nombre en “assignee” y en qué fecha se compromete a terminarla en el campo “due date”. La especificación de la tarea puede ir en el campo “description”. Si quiere anexar documentación, puede hacerlo dese su ordenador, Google Drive, Dropbox, etc. Si hay que preguntar a algún stakeholder, es ágil usar el campo comentarios, mejor que por email. Si alguien termina una tarea, la marcará como completada y todos los followers lo sabrán al revisar su inbox.
No me parece que sea necesario usar los tres famosos tableros kanban (to-do, in progress, done). En Asana ya se sabe que una tarea es “to-do” porque no tiene assignee, estará “in progress” porque está asignada y no completada, y estará en estado “done” cuando se haya completado. El equipo puede reordenar la lista de tareas pendientes moviendo las tareas arriba y abajo, según su prioridad.
Tampoco hace falta elaborar un “information radiator”, Asana ya tiene una gráfica burn-up por proyecto, que podría usarse como release burn-up y como sprint burn-up:
A la hora de hacer el sprint review, solo deben demostrarse las historias cuyas tareas se hayan completado. Cuando en la demo los stakeholders validen una historia, el Scrum Master puede marcar esa historia como completada, en caso contrario puede devolverla al product backlog simplemente quitándole el proyecto que identifica el sprint. El feedback de los stakeholders también puede anotarse en ese momento.
Después de la demo puede crearse otra tarea para anotar las conclusiones de la retrospectiva del sprint.
No hay comentarios:
Publicar un comentario