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).

¿Usar Evernote en Proyectos Ágiles?

Quizá usted ya conoce y usa habitualmente Evernote, una herramienta muy popularizada para tomar notas desde el ordenador, el portátil, la tablet, el móvil, etc. Las notas quedan guardadas “en la nube”. Ya no tenemos que usar libretas ni cuadernos. Podemos tomar notas en todo momento y en todo lugar. Es una herramienta tan presente en nuestro día a día para profesionales y estudiantes, que muchos de nosotros ya no sabríamos vivir sin ella y por supuesto no nos parece un gran coste los 5 € al mes que cuesta el modelo premium (si bien la versión gratuita es completamente funcional).

Lo que seguramente no hace todavía es usar Evernote como tablero virtual para proyectos ágiles. A mí personalmente me parece que la “estructura flexible” del contenido que pueden tener las notas de Evernote, la capacidad de mover notas de unas carpetas a otras, de etiquetarlas, etc., hacen que me parezca una herramienta muy en sintonía con el estilo “low-tech, high-touch” que se demanda en los proyectos ágiles. Por supuesto, un equipo usando un tablero físico en una sala dedicada es insuperable. Quizá en estos proyectos sea cierto eso que dicen muchos colegas de que “la mejor herramienta es ninguna”. Pero un repositorio centralizado con la información del proyecto también tiene sus ventajas, sobre todo cuando hay algunos miembros del equipo que no comparten la misma ubicación.

Si quiere saber cómo le doy yo esta funcionalidad de tablero virtual a Evernote, siga leyendo, por favor. Las pantallas que muestro son de un ejemplo preparado en Evernote con mi propia cuenta de usuario. Puede verlas usted mismo entrando en Evernote por web o desde la aplicación desktop, usando como usuario y contraseña la palabra “pmpeople”.

¿Agile es no planificar?

¿Cuándo fue la última vez que le tocó gestionar un proyecto predictivo? Ya sabe, uno de esos en que se debe invertir mucho tiempo y esfuerzo en la fase de planificación, la mayor parte del trabajo empieza a quedar clara desde el principio, el cliente firma los requisitos, y su misión fundamental como Project Manager es minimizar las desviaciones de tiempo, coste, alcance y calidad.

No es que no vaya a haber cambios durante la ejecución, también habrá muchos problemas, pero los interesados esperan de usted que coordine todos los cambios de forma integrada, que les haga seguir un proceso de solicitud, evaluación, aprobación, etc. Todo el mundo es consciente de que los cambios tienen un alto coste, pocos se toman la molestia de defender la necesidad de alterar algo: no quieren ser los culpables de que el proyecto sufra retraso o sobrecoste.

Quizá en ciertos sectores (construcción, ingeniería, etc.) este tipo de proyectos siguen siendo la norma. Desde luego no es el caso de los proyectos de desarrollo de software, o en los proyectos de consultoría, donde al principio suele estar poco claro el producto del proyecto. ¿Podríamos generalizar a todo proyecto de los “trabajadores del conocimiento”, donde los entregables y el trabajo son de tipo “intelectual”?
 

"Sharpen the Saw" managing Projects

The seventh habit of highly effective people, according to Covey is “sharpen the saw”. Effective people devote time not only to “cutting the tree” (production: getting the golden eggs) but also to “sharpening the saw” (production capacity: feeding the goose). The principle of renovation, or continuous improvement, is important to be effective: we have to fight sedentary habits, the experience is more and more complex, public victories are more and more interdependent, and our scheme of values has to be constantly reinforced.

The time we devote to self-renewal belongs to the category of important but not urgent (quadrant II, the quadrant of effectiveness). There are many other tasks important but not urgent (big rocks) we need to solve week after week to get a feeling of fulfillment and personal effectiveness. 

"Informivore" Stakeholders

We human beings are different from animals in many aspects, of course. Maybe one of the most differential is our need to communicate, especially when something concerns us deeply and we see it as a threat, or a substantial change. We are information consumers. 

We eat information. As a species, we could be called informivore.

When we are hungry of information, we expect the worst, especially in projects. We think something is going wrong. Apart from gossips and misunderstandings, we have plenty of own past experiences to feed our worst fears and negative expectations. 

Information is power, but is not ethical (nor effective) to hide information to avoid problems. We should not be afraid to deliver bad news. We will be judged as ineffective if our communication is not clear, concise, complete, timely, relevant, compelling, predictable, reliable, confidential, etc. 

Fail to Plan is Plan to Fail

En su día a día, un Director de Proyectos Eficaz debe ser un especialista en visualizar su proyecto. Los proyectos se crean dos veces: primero se hacen reales en nuestra mente, los creamos en nuestra “bola de cristal”; finalmente acaban siendo una realidad para los interesados. Antes de que se vean los entregables, el Director del Proyecto ya los había imaginado. Antes de que los miembros del equipo sigan los procesos, el Director del Proyecto “ya había estado allí”. Empezar con un fin en la mente, en el ámbito de los proyectos, significa algo muy concreto: planificar.

Una buena planificación es clave para el éxito de cualquier proyecto (como se dice en inglés, fail to plan is plan to fail, que podría traducirse como: fracasar planificando es planificar el fracaso). Cuando observamos que alguien gestiona un proyecto haciendo lo que le manda el cliente, reaccionando a los problemas y crisis que surgen en el día a día, ¿de verdad podemos llamar a eso gestionar un proyecto?

Madurando como Director de Proyectos Eficaz

De la misma manera que hay un camino secuencial para llegar a la madurez como persona efectiva, podemos decir que hay un camino secuencial para llegar a la madurez como Director de Proyectos Eficaz.

Ese continuum de la madurez del que habla Covey (dependencia, independencia e interdependencia) nos sirve, como no podría ser de otra manera, para distinguir los grandes niveles de madurez de un Director de Proyectos. Es decir, un Director de Proyectos puede ser Dependiente, Independiente y finalmente, Interdependiente.