A la hora de hacer una estimación, se debe tener en cuenta lo siguiente:

1. Las estimaciones son estimaciones, es decir, aunque le dediques mucho tiempo, no llegaremos a una precisión del 100%
2. Las estimaciones se deciden colaborativamente, incluyendo a quienes harán la tarea ( esto último es muy importante)
3. Se deben realizar como la combinación de:
- Opinión del experto
- Analogía: comparar con otras tareas ya estimadas
- Disgregación: separar una tarea en varias

Dentro de las metodologías ágiles, una de las propuestas para estimar es jugar al Planning Pocker, que combinas las técnicas anteriores.

Brad Appleton ha juntado y expandido dos de sus recientes entradas en su blog para escribir el artículo The Unchangeable Rules of Software Change donde describe con gran claridad su visión de cómo es y cómo debería ser la gestión de requisitos.

Este artículo se basa en su experiencia práctica de consultor en varios equipos donde ha visto cómo unos no tenían metodología ninguna, otros intentaban definir todo a priori guiados por metodologías pesadas y otros no hacían análisis de requisitos ninguno pensando que así aplicaban un método ágil. O lo que es peor, el mismo equipo iba dando tumbos de un extremo a otro.

En resumen, los errores típicos que Brad destaca entre tumbo y tumbo son:

1. No disponer de ningún mecanismo de control de cambio
2. Evitar cambios de alcance durante el proyecto
3. Parálisis del proyecto debido a un excesivo tiempo recogiendo requisitos
4. No hacer captura de requisitos de ningún tipo
5. No realizar planificación de las iteraciones (tras pasarse a un método supuestamente ágil)
6. Demasiada planificación de las iteraciones

Para curarse estos errores Brad plantea sus cuatro reglas básicas de la gestión de requisitos, pero os dejo que lo leais en el propio artículo.

En una entrada en su blog titulada Why GANTT Charts Were Banned in the First Scrum, Jeff Sutherland nos explica su opinión sobre los diagramas de Gantt. En ella defiende porqué los dejó fuera de SCRUM, aunque reconoce que pueden ser útiles para mostrarlos a gente externa (pero sólo en esos casos).

Hoy he leído dos entradas de blogs que me han parecido muy esclarecedoras en relación a preguntas que me han venido a la cabeza más de una vez ¿cómo de largas deben ser las iteraciones de un proyecto? ¿qué ventajas tiene hacerlas más largas o más cortas?

El primero de ellos es The Pros and Cons of Short Iterations de Mishkin Berteig y el segundo Planning with the Horizon of Predictability leído en el blog Agile in Action.

La idea sobre la que construyen es la del horizonte de predictabilidad, es decir cuanto tiempo que puedes predecir en el proyecto antes de que surjan interrupciones, cambios en requisitos, cambios de prioridades, etc. Este horizonte es diferente en cada proyecto y quizá incluso en cada momento y el tamaño de las iteraciones debe adaptarse correspondientemente para que funcionen correctamente.

Escrito por Martin Fowler
Traducido por Jesús Pérez
Revisado por Carmen Vidal

De vez en cuando la gente se pregunta si una especialidad particular puede ser usada de forma incremental: " No se puede hacer (seguridad | diseño de interfaz de usuario| bases de datos | internacionalización | *) con un proyecto ágil porque este aspecto tiene que ser desarrollado realizando un gran diseño inicial".

Cuando se me hace una pregunta como esta, me encuentro perdido porque desconozco esa especialidad. El diseño de aplicaciones es algo de lo que pienso que puedo hablar, pero no sobre diseño seguridad - y mi interrogador bien puede ser un reconocido experto en este campo.

A pesar de mis limitaciones reconocidas en el campo del que se habla, no voy a decir que sólo se puede usar diseño planificado en ese área. Lo que puedo decir es que realmente no sabemos si se puede hacer el diseño incremental en aquella área. He visto bastantes casos en los que la gente ha dicho " no se puede usar el diseño incremental para x " sólo para averiguar que se puede. El diseño de aplicación es de una forma, el diseño de bases de datos es de otra. De esto modo, hasta que la gente pruebe el diseño incremental de un modo serio, no estoy dispuesto a excluirlo.

Parte de la dificultad de evaluar esta pregunta está en que es demasiado fácil hacer el diseño incremental mal. Si se hace el diseño incremental de un forma incontrolada, con alta probabilidad se termina con un lío de diseño - para hacer el trabajo de diseño incremental se necesita algo que haga el diseño convergir al orden. En el articulo "Está el Diseño Muerto" me referí a éstas como prácticas de habilitación. Para el diseño de software, las pruebas, integración continua y refactorizar son las prácticas clave que permiten que el diseño del software converja y evitar la entropía del software. Cuando hablamos de algo más, como el diseño de UI, la cuestión encontrar cuáles son las prácticas de habilitación. Pueden ser similares o inspiradas por las del diseño de software, o pueden ser diferentes. En el diseño de base de datos, por ejemplo, la migración de datos incremental es una práctica de habilitación clave. Hasta que se encuentre un buen conjunto de prácticas de habilitación, el diseño incremental es algo frágil.