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.

Un lujo participar en este Breakfast de La Salle que por iniciativa (y algún empujón) de Xavier Albaradejo (experto en Gobierno TI en everis y coordinador del Postgrado en Métodos Ágiles de La Salle Campus Barcelona) nos animo a participar a Adrian Perreau de Pinninck (Artificial lntelligence Researcher y Project Manager de Intelligent Pharma), Miquel Mora (CIO y socio fundador de yaencontre.com), Carlos Iglesias (Consultor tecnológico y en marketing online, co-fundador de Runroom) y Dr. Laurentiu Neamtu (coordinador del Postgrado en Métodos Ágiles de La Salle Campus Barcelona)

Un placer estar con estos monstruos del agilismo... a ver si se me pega algo ;)

Este es un resumen, en una prezi-osa presentación de nuestra experiencia en la implementación de Kanban como herramienta de gestión de tareas, de que problemas o inconvenientes nos encontramos y cómo los hemos podido resolver.
Es tambien un resumen-complemento a los anteriores posts Hola, soy Kanban. Principios de uso y Kanban, cómo resolver sus inconvenientes y se basa en más de un año de adaptación y mejora continua de la metodología. Tomate un minuto y ojalá te sea útil.
Perdona los acentos (la falta de) de la presentación, cosas de la internacionalización. (Mejor visión a pantalla completa)

Solo un poquito de autopromo, para no aburrir, pero por si quereis conocer mejor como aplicamos esto del agilismo en entornos empresariales, es decir en el día a día, adjuntamos un par de links donde se comenta en detalle aspectos importantes de nuestra experiencia y así compartimos que para eso estamos.



El pasado mes de diciembre, en el Blog Gestión de proyectos IT de Jose Vazquez publicaron una extensa e interesante entrevista sobre cómo aplicamos en yaencontre el modelo Agil.

Esta es nuestra experiencia sobre esta metodología para la gestión de proyectos. Después de mucho buscar, documentarnos y otros sufrimientos, empezamos a utilizar KANBAN en los procesos de implantación y personalización de un nuevo CRM para nuestra empresa en septiembre del 2009.
Habitualmente utilizamos SCRUM para la gestion de proyectos técnologicos, pero entendimos que necesitabamos un sistema de gestion aún más ágil, preveiamos constantes repriorizaciones, nuevas peticiones a diario, un entorno de incertidumbre y de continua gestion del cambio (responsable).  Kanban era nuestra "Silver bullet".
Si Taichi Ohno  (el padre del Sistema de Producción "Just in Time" de Toyota) ya utilizaba este sistema, nosotros no íbamos a ser menos.
Pero, vayamos por partes (que decía Jack el Destripador)