Desarrollo ágil: los 3 mejores programas gratuitos según se use Scrum o Kanban (para mi)

[He movido esta entrada y el blog a: http://www.carloshelder.es/blog/desarrollo-agil-los-3-mejores-programas-gratuitos-segun-se-use-scrum-o-kanban-para-mi/]

Es difícil elegir la herramienta perfecta para gestionar nuestro proyecto por la enorme cantidad de software disponible. Supongo que eso se debe a que poca gente se decide a usar uno de las metodologías ágiles de forma pura.

 

Hubo pocas cosa más ágiles que mi
perro Bolígrafo, aunque ya está mayor...

En mi caso particular, me basaré más en Kanban (1) por la ausencia del concepto de Sprint. La aplicación web que voy a desarrollar no es para un conjunto reducido de clientes, sino para usuarios finales. Por ello, me resulta más adecuado pensar en el mínimo producto viable (2), sin límite de tiempo, que en decidir qué lanzar en cada Sprint.
 
Por último, estas metodologías están orientadas a un equipo y parece que acometeré el proyecto yo solo. No obstante, cualquiera de las herramientas de gestión permiten incluir a más personas en el equipo si fuese así en el futuro.



Características que quiero que tenga mi gestor

1. Gratuito para equipos de hasta cinco personas por proyecto, al menos, y para infinitos proyectos.
2. Online, pero que pueda hacerse una copia de seguridad.
3. Que se pueda especificar una duración estimada de la historia de usuario y la real.
4. Que genere gráficos: Burndown, Cumulative Flow u otros.
5. Que las historias de usuario se puedan clasificar (3)
6. Interfaz de usuario sencilla, el uso de la herramienta debe facilitar el trabajo, no complicarlo.

5 + 1 herramientas pasaron a la criba final

Primero, busqué listas y comparativas de las distintas alternativas gratuitas. De esa primera selección dejé fuera herramientas como (entre paréntisis el motivo resumido): Lean Kit (3 tableros Kanban máximo), Kerika (Trello y sus plugins parece mejor), Mingle (complicado y poco preparado para ágil, a pesar de lo que escriben), VersionOne (1 proyecto máximo), RallyDev (1 equipo máximo), Asana (no está orientado a ágil), Strikebase (1 proyecto máximo), Hansoft (escriben algo de un annual lock-in que no me gusta nada), Podio (no está orientado a ágil), ToDo (1 equipo máximo) y Scrumdesk (parece demasiado complejo).

Quedaron 5 herramientas que debía probar con más detenimiento para tomar una decisión. Las 2 primeras las descarté tras un rato de pruebas por los siguientes motivos:

• Pangoscrum (aunque parece simple y será gratuito mientras esté en fase beta, da la sensación que habrá que pagar en algún momento y, además, no veo que se puedan hacer copias de seguridad. Pero el motivo más importante es que no me ha gustado su funcionamiento en general)

• Targetprocess (complejo de utilizar, aunque hay multitud de videotutoriales y posibilidades de personalización. Permite añadir multitud de datos para poder hacer un seguimiento. Diría que es para un público que busque poder medirlo todo. Pero yo, sencillamente, busco un sistema más sencillo de utilizar).

Finalmente, estas son las 3 herramientas que más me gustaron:

• Easybacklog 

Easybacklog

Implementación de Scrum.
Interfaz sencilla.
Aunque empezará a ser de pago en algún momento, dicen que siempre habrá versión gratuita para usuarios light y nunca se restringira el acceso.
Genera gráficos burndown, burnup y velocity de los sprints.
Exporta a excel todas las historias de usuario, a un formato fácil de copiar e introducir en cualquier documentación.
Aunque mi idea era que se hiciesen copias de seguridad a mi ordenador, aseguran que hacen copias de seguridad diarias.
Hay que especificar la duración de cada Sprint, si bien te permite modificarla luego.
Me parece un desacierto que se estime con puntos historia mientras que el tiempo empleado se escriba en días cuando, al fin y al cabo, el software te obliga a elegir el número de puntos historia que se acometerán cada día (en al campo velocity).
Me ha gustado que integre el método de estimación 50/90: en 90 escribiremos la estimación pesimista (ese valor indicará que el tiempo empleado en realizar la historia de usuario será casi seguro menor, con un 90% de probabilidades) y en 50  la estimación exacta (50% de probabilidades de que sea menor y 50% de que sea mayor).

• Kanbanize 

Kanbanize

Implementación de Kanban.
Interfaz sencilla.
Prometen que la versión gratuita (community) siempre lo será.
Permite configurar de formas variadas diversos gráficos, entre ellos el normalmente favorito para representar kanbas, el cumulative flow.
Echo de menos un mejor aprovechamiento de las estimaciones (size en la herramienta). Por ejemplo una gráfica comparando la estimaciones y el tiempo que se tardó o un cumulative flow en base a los puntos historia terminados en lugar de las historias terminadas.
Podemos exportar los datos como XML o CSV. Como backup, para recuperarlos, necesitamos premium y pedirles que nos lo hagan ellos. Como documento formateado "bonito", necesitaríamos encontrar y utilizar un XSL stylesheet para conseguirlo.
Es posible clasificar las historias de usuario por etiquetas o colores.

•  Trello

Trello

Gratuito para un número ilimitado de usuarios.
No es ni es una herramienta específica para el desarrollo ni para el desarrollo ágil, pero se ha hecho muy popular utilizarla para esta tarea y han surgido plugins de terceros que adecúan la aplicación para este sentido.
Para estimar, instalaremos el plugin de scrumfortrello.com y para generar las gráficas www.burndownfortrello.com. Cuando escribamos el título de la historia de usuario, añadiremos los puntos historia estimados entre paréntesis () y el tiempo usado entre corchetes []. Por ejemplo: (2) Elegir software de gestión ágil [5]. Un pequeño impedimento es que, a menos que compremos la versión premium de www.burndownfortrello.com, tendremos que meter los datos estimados a mano y, en cualquier caso, parece que no toma en cuenta el tiempo usado que hemos introducido sino únicamente el que ha transcurrido desde que movimos la historia de usuario.
De la misma forma, existen plugins de terceros para exportar las historias de usuario en un formato adecuado o crear otros gráficos como el cumulative flow.
Como punto negativo es, si lo usamos para Scrum, la ausencia de un backlog común para todos los Sprints.

KanbanFlow

Por último, 1 herramienta que debió quedar fuera en la primera criba, pero que he querido mantener como mención especial:

• KanbanFlow (esta herramienta quedó fuera porque no genera gráficos en la versión gratuita, pero he querido mencionarla porque integra la técnica pomodoro, una idea curiosa que he querido destacar).

¿Cuál elegir?

Cualquiera de esas tres opciones parece un buen acierto, pero hay que elegir una.

Si queremos utilizar Scrum y, especialemente, si queremos explotar el concepto de Sprint y dar algo que funcione al cliente en intervalos regulares de tiempo, la opción que eligiría sería Easybacklog.

Si estimar no es una parte vital y no queremos entregar al cliente algo útil a intervalos regulares sino cuando terminemos algo que queremos que vea, prueba y nos de su opinión para continuar de una u otra forma, la opción que eligiría sería Kanbanize.

Trello puede ser una buena opción tanto para Kanban como para Scrum, prueba de ello es su popularidad. Es una herramienta flexible y los equipos pueden probar otras formas distintas de organizarse (por ejemplo, una columna por desarrollador). También su popularidad ayuda que haya una buena variedad de plugins de terceros. Quizás esta popularidad se deba a que es gratuita para un número infinito de usuarios.

Yo, para este proyecto, voy a utilizar Kanbanize, pero guardo las otras dos herramientas pues estoy seguro de me resultarán también útiles en el futuro.


____________________________
1) He estudiado Kanban, Scrum, XP y Lean (este último no es una metodogía sino un conjunto de prácticas recomendadas).
2) De la filosofía Lean, el enfoque que se seguirá es publicar el primer "mínimo producto viable" que los usuarios podrán utilizar y sugerir mejoras.
3) En mi caso e inicialmente tengo dos grupos. La primera parte es más de investigar y realizar prototipos desechables. La segunda parte será más de programar el mínimo producto viable de la aplicación web.