Hay quien se empeña en crear una guerra de metodologías ágiles, que si mejor Scrum, que no que mejor Kanban… Mi opinión es que hay que saber elegir la metodología adecuada según tu modelo de desarrollo y las necesidades que este tenga, no hay una mejor que otra, simplemente hay una más apropiada que otra.
Como ayuda a la hora de tomar esta decisión, propongo un pequeño test para poder escoger la metodología ágil más adecuada (10 sencillas preguntas al más puro estilo revista adolescente), ya sea porque tienes la intención de “volverte ágil” o bien porque ya estás utilizando alguna pero hay algo que chirría:
1. ¿Te enfrentas únicamente a proyectos grandes?
Ten en cuenta que si te decantas por Scrum, lo normal es que hagas sprints de entre dos y cuatro semanas (puedes hacerlo de más o de menos, aunque no es recomendable) por lo que si los proyectos son grandes cobra mucho sentido que vayas haciendo entregas graduales al cliente. Si por el contrario son proyectos muy pequeños, o algunos de ellos lo son, conviene que te plantees la siguiente pregunta.
2. ¿Tiene sentido que todas o casi todas las funcionalidades que desarrollas esperen un mínimo de 2 semanas para estar en producción?
En Kanban cuando finalizas un work item este acaba en producción. En equipos acostumbrados a resolver incidencias o en equipos de investigación parece difícil justificar ante el cliente que lo que ya tienes solucionado o desarrollado tiene que esperar 2 semanas para tenerlo disponible.
3. ¿En tu empresa hay Legacy Code y requiere bastante mantenimiento?
En el mundo ideal de muchos agilistas tenemos una cobertura del 100% , un código limpio, claro y libre de bugs. En el mundo real de la mayoría de los mortales, cada vez lo hacemos mejor, vamos mejorando nuestra cobertura y cada vez nos salen menos bugs, pero “haberlos haylos”. Además, no siempre hemos sido “tan buenos” y siempre hay legacy code que hace aguas por algún sitio.
4. ¿Tienes que entregar un release plan?
Esto sucede en la mayoría de los equipos de desarrollo, no obstante la respuesta afirmativa a esta respuesta está altamente ligada a la primera pregunta que planteo, cuando el proyecto es grande hay que proporcionar al cliente un calendario de entregas de funcionalidades de su producto. Cuándo previenes que a lo largo de tu proyecto van a surgir numerosas tareas inesperadas es complicado proporcionar un release plan.
5. ¿A menudo te encuentras con numerosas tareas “no esperadas” con prioridad alta?
Las dichosas tareas no esperadas son unas rompe-sprints, son al tablón lo que Belén Esteban a Tele5, sea el momento que sea siempre aparecen por algún lado. ¿De verdad quieres que sigan apareciendo? ¿No es mejor tenerlas controladas? Si tienes sprints y siempre te acaban colando este tipo de tareas, quizá Kanban o Scrumban se adapten mejor a tu equipo.
6. ¿En tu equipo hay gente especializada en, por ejemplo, QA o despliegue en producción?
Esta pregunta es muy importante, los equipos que siguen Scrum por definición han de ser multidisciplinares, si tenemos alguién especializado en algo, ¿No nos sirve? ¿Ponemos a alguien con años de experiencia a dedicarse a otras áreas de trabajo?
7. Ante varios productos, ¿puedes alternar la prioridad de un producto sobre otro?
Si tienes dos productos de una dimensión importante tienes que ir dando más prioridad a uno frente al otro en cada sprint, para que al menos un cliente encuentre jugoso el fín del sprint, a no ser que a ambos clientes les puedas ofrecer un flujo constante y regular de entregas.
8. ¿Pueden añadirte tareas más prioritarias sin previo aviso?
Tienes que pensar muy detenidamente cómo vas a poder afrontar o reaccionar ante una tarea que de repente cobra una prioridad máxima, ya sea una que ya estaba en el backlog y que ha cambiado su prioridad, como una no esperada.
9. ¿Toda tu pila de producto está priorizada?
Idealmente tu backlog está perfectamente priorizado, pero a menudo nos encontramos con backlogs parcialmente priorizados o de user stories idempotentes, en este caso si tienes limitado el WIP (work in progress) tu capacidad de reacción ante nuevas tareas o tareas más prioritarias es mucho mayor que si te mueves entre sprints
10. ¿Tienes que proporcionar soporte a tus clientes?
Obviamente, si tienes que proporcionar soporte a tus clientes, nunca sabes cuándo te van a llamar y por tanto vas a tener, sí o sí, tareas inesperadas. Como he mencionado anteriormente, haz que esas tareas estén perfectamente definidas y controladas, tienen que tener hueco en tu tablón.
Conclusiones
Si hay mayoría de respuestas afirmativas en 1, 2, 4, 7 y 9, entonces la balanza se inclina hacia SCRUM. Todo tiene sentido: pila de producto priorizada, sprints, proyectos grandes con entregas incrementales, equipo multidisciplinar…
Si has contestado afirmativamente en la mayoría de estas: 3, 5, 6, 8 y 10, estás muy cerquita de KANBAN con tareas no esperadas, flujo constante de trabajo, bien con equipos especializados o multidisciplinares…
Un momento, ¿Y si hay un empate técnico o no está muy decidido el resultado? Ok, ¿entonces por qué no consideras SCRUMBAN? Tienes toda la potencia de ambas metodologías: iteraciones bien definidas para tus productos y capacidad de reacción para aquellas tareas que “surgen de la nada”, siempre controlando las velocidades por sprint y las velocidades positivas y negativas de Kanban.
Más información | Scrumban
En Genbeta Dev | Ser ágil es algo más que iterar
Dani Jiménez es responsable del área de i+d/labs y desarrollo móvil en idealista.com, dónde lleva trabajando 8 años, y cofundador y desarrollador de worldtaximeter.com, servicio creado en 2007. Lleva varios años inmerso en el desarrollo con metodologías ágiles, pasando por Scrum y Kanban.
Fruto de las tareas de innovación tecnológica ha participado activamente en la arquitectura de idealista.com, así como en el desarrollo de aplicaciones con spring framework, aplicaciones para dispositivos móviles y diversos procesos escalables.
Puedes seguirlo en Twitter: @danibto
