Miquel A. Mora's Kaizen

Running Lean, de Ash Mayura, es el complemento, o la evolución ideal del libro de Eric Ries Lean Startup.
Si bien en el libro de Eric, nos comenta en profundidad las bases y principios del método Lean aplicado a las Startups, en el libro de Ash, nos ofrece un proceso, riguroso y disciplinado para iterar del plan inicial hacia el plan que definitivamente funciona (antes de quedarnos sin recursos) mediante el aprendizaje validado y la contabilidad de la innovación.
Running Lean nos ofrece el COMO aplicar el metodo, paso a paso. Basado en tres "fases"

• Alta Complejidad - cuando ninguna persona o grupo tiene la solución perfecta
• Alta Diversidad - cuando una variedad de diferentes actores, habilidades, estilos u opiniones deben contribuir a un mejor esfuerzo colectivo
• Plazos Inmediatos - cuando es urgente obtener resultados extraordinarios

El Modelo Kano + Ponderación de Funcionalidades
Recientemente, en el Agile2011 conference Sergey Dmitriev, presentaba una nueva técnica de priorización El modelo Kano Ponderado.
Esta técnica, utiliza el modelo Kano, tal como hemos descrito en un post anterior, para categorizar las funcionalidades. Pero ademas añade a esta categorización un valor de priorización basada en la técnica de Ponderación de requerimientos (story weighting)


De esta manera, las funcionalidades, son valoradas según criterios como coste de desarrollo, y otras variables importantes o estratégicos para la empresa. Algunas de estas variables pueden ser, Valor de Oportunidad de mercado, Valor de comercialización, Ventaja competitiva, Reducción de costes,...

Siguiendo el anterior post sobre Técnicas de Priorizar tareas, quiero comentar la que, personalmente, me atrae especialmente. El método de priorización basada en el Modelo o Análisis de Kano
Esta técnica fue desarrollada por Noriaki Kano, experto en gestión de calidad y satisfacción del cliente a finales de los `80. Con esta técnica podemos determinar que funcionalidades son realmente importantes para los usuarios y cuanto lo son.

Hace unos días mi hijo, de 6 años escogía los regalos de reyes de un catalogo de regalos.
Marcaba con un circulo los regalos que el  quería. Este.. Huy este también... Este.... Sobre todo este.... y este...
TODOS los regalos de niño estaban seleccionados. Esto a quien tenga el placer de tratar con "esos locos bajitos" seguro que le suena.
Le comente a mi hijo la necesidad de macar solo los más importantes para él, que los reyes solo eran tres (recursos limitados) y tenían que repartir los regalos de todos los niños en una sola noche (tiempo limitado). No podrían entregar TODOS los regalos, solo los verdaderamente importantes. Después de asegurarme de que lo había entendido, le di un rotulador fluorescente "rosita" y le dije que marcara solo los regalos importantes.
En dos minutos tenia TODOS los regalos para niños marcados (de nuevo)

Y no se por que extraña razón me acorde de algún Product Owner priorizando su product backlog (...)
Me viene a la cabeza algún tablero de Kanban con todas las tareas agrupadas incluso apiladas unas sobre otras en la parte superior de la columna "Pendiente". Le dijeron al product que pusiera arriba las tareas prioritarias... Y no es un caso aislado.
El pasado mes de noviembre, Pau Cervera de teoce consultores, en su conferencia sobre Critical Chain Project Mangement, comentaba su experiencia con un Product Manager, que pidió algún método para marcar las tareas prioritarias. Pongamos un pequeño adhesivo rojo, acordaron. En pocos días la practica totalidad de tareas estaba marcada con el adhesivo rojo.

Técnicas de priorizacion

Para muchas necesidades de desarrollo, hablar ágil (scrum/kanban) puede ser todo lo necesario para gestionar los proyectos de una manera eficiente. En este contexto, la gestión con una visión basada en ciclos iterativos con historias o tareas creadas por los equipos puede ser suficiente.
Sin embargo, a nivel de cartera, hay otra clase de necesidades de la organización, donde la gobernabilidad y el modelo de gestión para el desarrollo de negocio requiere artefactos adicionales y niveles aún más altos de abstracción y gestión. Pensamiento Lean.

Y van 7 años consecutivos que la empresa VersionOne realiza la que creo que es la mayor encuesta sobre uso y adopción de métodos ágiles en el desarrollo de proyectos. Analysis.Net Research son los encargados de analizar las más de 6.000 encuestas del año pasado.
Realmente resulta muy interesante poder ver los resultados de estas encuestas, pero más sorprendente es ver la evolución de las practicas ágiles a lo largo del tiempo. Para muestra he creado algunos gráficos que muestra la tendencia o cambios en algunos aspectos interesantes que me gustaría compartir.
Metodología más usadas




Evidente como destaca SCRUM y curioso como Extreme Programming pierde seguidores. He puesto Kanban porque aunque no salía en las encuestas de 2008, 2009 y 2010, entro en la del 2011 por primera vez per con mucha fuerza y podría identificar una tendencia (y porque me encanta ;)

Hace algunas semanas, coincidí con Humberto Schwab en un GiLD Openday Socratic workshop.
Coincide plenamente con el espíritu de las metodología Agiles.

Mi resumen en esta Infografía de la utilización de Historias de Usuario como medio para recoger los requerimientos de manera ágil.

Kanban funciona perfectamente como sistema de producción. El tablero de Kanban nos permite tener una muy buena visión sobre el trabajo en curso y una gestión optimizada de las cargas de trabajo previstas.
Pero cuando una tarea se finaliza, debemos crear algún sistema o método para conservar la información referente a esta tarea y su creación a modo de histórico o como consulta. Esta opción ya viene integrada en los software de gestión de proyectos existentes. Pero nosotros no utilizamos ninguno, al menos por el momento

Con el Framework SCRUM, utilizamos las Historias de usuario para recoger los requerimientos de manera ágil.
Las Historias de usuario están lejos de ser un requerimiento de software basado en documentación extensa, muy detallada y sin posibilidad de cambiarse realizado por un analista de procesos, como podría "desear" algún programador.

Tampoco son especificaciones que se han de desarrollar tal como se han concebido, sin ninguna concesión por "tecnicismos", con un resultado que sea exactamente el esperado, y en un corto plazo de tiempo, como algún "jefe de producto" esperaría.
En esta presentación exponemos de manera amplia el ¿Por qué? ¿Qué son? ¿Cómo son? las historias de usuario.