Buscar este blog

24 de febrero de 2013

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

17 de febrero de 2013

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

13 de febrero de 2013

¡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:
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.
 

10 de febrero de 2013

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