En el Corazón de la Planificación

Cuando se hace un análisis post-mortem de un proyecto que ha fracasado, es decir, ha terminado muy tarde, con mucho sobrecoste, mala calidad, etc., y las desviaciones han llegado a tal punto que tanto el cliente como el proveedor declaran que el proyecto ha sido un auténtico fracaso, llegando a veces al extremo de tener que ir a juicio, muchas veces descubrimos que la causa principal es una mala planificación.

Me refiero a esos proyectos que, por ejemplo, deberían haber terminado en 15 meses y duran más de 20, que acaban con pérdidas netas de cientos de miles de euros, o que en el momento de la entrega, el cliente no acepta y por tanto no paga.

El post anterior Fail to Plan is Plan to Fail explicaba la importancia de una buena planificación para la conclusión exitosa de cualquier proyecto. Este post trata de profundizar sobre qué procesos de planificación son, a mi juicio, los más importantes, porque si se hacen mal es como “planificar el fracaso”.

En otras palabras, ¿qué procesos de planificación son causa raíz directa de fracaso, si se hacen mal?

Fail to Plan is Plan to Fail

In their day to day job, Project Managers should master the habit of visualizing about the project. Deliverables are also created twice. Before that deliverables could be tangible, the Project Manager had already imagined them. Before that team members could follow a number of processes and develop many activities, the Project Manager “had already been there”. Starting with the end in mind, in the field of Project Management, means something very specific: planning.

Before insisting about the importance of good planning for every Project (fail to plan is plan to fail), let’s think of what happen when the Project Manager doesn’t have the habit of planning. When you see someone leading a project just doing what customer asks, responding day to day issues and crisis just by reacting. Can you call this to manage a project? 

Retrospectiva del Proyecto Havannah

A continuación tienen un vídeo con un breve resumen de los 5 últimos posts dedicados al caso práctico con métodos ágiles desarrollado en el libro Agile Estimating and Planning, de Mike Cohn.

Espero que les sirva como referente práctico para aclarar conceptos como: iteración, historia, puntos-historia, velocidad, iteration planning, release planning, iteration review, etc. Nada tan efectivo como imaginar estos conceptos en acción en un caso más o menos realista, ¿verdad?

Por favor, no se queden solo con el vídeo, que no equivale a leer el capítulo de más de 50 páginas. Les animo a que compren este buen libro, ideal para comprender mejor los métodos ágiles. Si solo pueden leer una parte, lean el caso práctico desarrollado en el capitulo 23. Si quieren leer este capítulo en español, pueden empezar por aquí.

Quemando las iteraciones del Proyecto Havannah

Quinta y última entrega de la traducción capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, dejábamos al equipo a punto de comenzar la primera iteración de 2 semanas, que habían planificado en 4 historias de 18 puntos. También habían previsto que el proyecto duraría entre 12 y 20 semanas. En este post veremos lo siguiente:

1. El equipo demuestra los resultados de la 1ª iteración (completan 16 puntos de 18) y planifican la 2ª iteración con 3 historias de 18 puntos.
2. Demuestran la 2ª iteración completa al 100% y planifican la 3ª teniendo en cuenta dos nuevas funcionalidades “emocionantes” que ha investigado Diana, de 30 y 35 puntos, respectivamente. Si quieren mantener la planificación en 12-20 semanas, deben renunciar a una funcionalidad emocionante de 30 puntos. Antes de arrancar la 3ª iteración, quedan por quemar 133 story points (más que los 132 que tenían al principio del proyecto, ¿significa esto que van para atrás?).
3. Por último, atendemos a la reunión de revisión de la última iteración del proyecto, finalizado en un plazo 22 semanas, con 2 semanas de retraso sobre la estimación inicial comunicada de 20 semanas, pero a cambio de mucho más valor para el negocio.

En este caso práctico, los métodos ágiles han supuesto una cuantificable mejora del proceso de desarrollo de software, sobre todo comparando con el retraso acumulado del proyecto anterior de 6 meses.

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.

Plan inicial del Proyecto Havannah

Cuarta entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah estaba manteniendo una reunión con una agenda de tres puntos:

1. Planificar la primera iteración.
2. Revisar los resultados de la investigación de mercado.
3. Hacer una estimación preliminar del plan de entregas y el calendario.

El primer punto de la agenda concluyó con el compromiso firme del equipo sobre 4 historias de 18 puntos. A continuación se cubrirán los puntos 2º y 3º, para lo cual es necesario priorizar las 29 historias restantes. Una forma de hacerlo es usar el modelo del profesor Noriaki Kano:

El modelo de Kano sirve para determinar si las características de un producto son obligatorias (insatisfacción si no están), lineales (cuantas más hay, mayor satisfacción producen) o emocionantes (satisfacción si están, pero no hay insatisfacción si no están). El proceso habitual para llegar a estas conclusiones es plantear una encuesta a los usuarios con preguntas funcionales (cómo se sentirían si la característica estuviera presente) y disfuncionales (cómo se sentirían si la característica NO estuviera presente). Una vez se reciben las respuestas, la siguiente tabla permite clasificarlas en 6 categorías: obligatoria, lineal, emocionante, contrario, cuestionable, indiferente.

A continuación se describe cómo transcurre la segunda parte de la reunión.  El resultado de la reunión es que el proyecto durará 7 iteraciones (14 semanas). ¿Por qué? Porque a una velocidad de 18 puntos por iteración, en 7 iteraciones daría tiempo a asumir los 132 puntos previstos en la release. ¿Por qué 132 y no los 146 puntos de todas las historias? Porque el Product Owner no quiere que se dedique esfuerzo a las que resultan indiferentes para el público objetivo (6 puntos) y cree que puede ahorrarse una funcionalidad emocionante de 8 puntos. El equipo ya tiene una estimación para la duración del proyecto, pero el coach insiste en que esta estimación no debería publicarse, sino que es mejor decir que el proyecto durará entre 12 y 20 semanas. ¿Por qué?

Sigan leyendo y lo descubrirán.

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.

Comprometidos como EQUIPO con la primera iteración

Tercera entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah había escrito 32 historias de usuario, que tenían un tamaño de 146 puntos en total. 

En este post, los miembros del equipo dedican dos semanas a terminar otro proyecto mientras la analista Diana comienza la investigación de mercado con una encuesta a potenciales compradores. Al cabo de las dos semanas, el equipo se vuelve a reunir con Carlos, el coach en métodos ágiles, para planificar la primera iteración y comprometerse como equipo para terminar las historias más prioritarias. El resultado es un compromiso firme del equipo sobre 4 historias que miden 18 puntos.

¿Quiere saber cómo se planifica esta primera iteración?

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.
 

Las historias del proyecto Havannah

Continúa la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En este segundo post (véase nota*) veremos la conveniencia de escribir tarjetas físicas y cómo puede organizarse una reunión de brainstorming para hacer que los miembros del equipo vayan deduciendo los requisitos (en forma de user stories). Es recomendable estructurar el brainstorming por temáticas para no dejar ninguna funcionalidad sin analizar.

Casi al mismo tiempo, los miembros del equipo pueden estimar el tamaño o complejidad de los requisitos mediante un juego conocido como planning poker, en el que se estima el tamaño y complejidad de cada historia en unidades llamadas story points.

Estas dos actividades (recopilar requisitos y estimar sus tamaños) son interdependientes porque, a veces, una historia de usuario muy grande hay que descomponerla en varias más manejables.

Una regla básica que hay que recordar es que las historias de usuario deben ser independientes, negociables, valorables, estimables, pequeñas y verificables (Independent, Negotiable, Valuable, Estimatable, Small, Testable -INVEST-).

A continuación se describe cómo transcurre la reunión inicial de análisis de requisitos en un proyecto ágil. Al finalizar la reunión (que puede durar entre 2 y 4 horas), los miembros del equipo del proyecto Havannah habrán consensuado los requisitos con 32 historias de usuario, y también habrá consensuado la estimación del proyecto en 146 story points.

¿Quiere saber cómo se hace?

(*) Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.

Un caso de estudio ágil: El Proyecto Havannah

El siguiente caso de estudio es una traducción del capítulo 23 del libro de Mike Cohn titulado Agile Estimating and Planning. Este capítulo, el autor, con la intención de resumir y ejemplificar la mayoría de los puntos clave del libro, desarrolla el caso práctico de la experiencia del primer proyecto ágil en una empresa ficticia llamada Bomb Shelter Studios, en el que participan las siguientes personas:

• Francisco: Responsable de productos.
• Alberto: Programador.
• Santiago: Programador.
• Carlos: Coach en métodos ágiles.
• Paula: Responsable de pruebas.
• Rosa: Diseñadora gráfica.
• Diana: Analista.
• Laura: Directora financiera.
• Felipe: Director general.

Este post reproduce la traducción del mencionado capítulo, desde que surge la necesidad de probar métodos ágiles para gestionar un nuevo proyecto software hasta que comienza la primera reunión de recopilación de requisitos en forma de “historias de usuario”.
 

¡Ya ha salido mi libro!

Estimados lectores,

Quería anunciarles que ya ha salido mi nuevo libro Los Hábitos de un Director de Proyectos Eficaz, publicado por la editorial Díaz de Santos, con prólogo de mi estimado colega Alfonso Bucero. Aprovecho este post para darle las gracias. De momento solo está disponible en formato papel. Tiene un precio de 22€. El formato e-book lo tienen previsto, pero tardará unos meses. Por ahora pueden adquirirlo de varias formas:

• En cualquier librería pueden pedirlo con el código ISBN: 978-84-9969-421-4
• A través del portal web de Díaz de Santos: http://goo.gl/b3F3a
• En Amazon: http://goo.gl/5ZbB5

Aquí pueden descargar el índice.

A todos ustedes les agradezco el constante seguimiento y los comentarios que van compartiendo. Sigan haciéndolo, por favor. Me animan mucho para continuar.

Muchas gracias!!

Jose Barato.
 

¿Va a usar Agile en su próximo proyecto Software?

¿Ha tenido usted alguna vez la experiencia de un proyecto software que haya fracasado? Si ha estado trabajando en este sector algún tiempo, es casi seguro que le ha pasado alguna vez. ¿Recuerda la sensación cuando se iba dando cuenta de que no iba a ser posible cumplir el plazo, o que el producto sería inaceptable?

Usted intentó alertar a la dirección, pero ellos no querían escucharle. Más bien al contrario, declaraban abiertamente lo bien que iba el proyecto. A usted le parecía un tanto “surrealista” lo convencidos que estaban de que todo iba bien, cuando era obvio que todo iba mal. Los que sabían que su proyecto iba en caída libre, tampoco querían hacer nada al respecto. En vez de intentar salvar el proyecto, se concentraban en salvarse a ellos mismos: El proyecto no iba tan mal (por lo menos en su área no había problemas).