Requisitos y planificación
Juego del Valor de Negocio
Submitted by blogger on Jue, 04/02/2010 - 01:59
Uno de las objetivos que tenemos en Agile Spain es crear y traducir contenido sobre las metodologías ágiles en Español.
Por este motivo, he traducido el Juego del Valor de Negocio creado por Veera Peeters y Pascal Van Cauwenberghe, el cual es un juego de simulación sobre prioridades de funcionalidades e historias de usuario así cómo su valor de negocio. Este juego se ha jugado varias veces en diferentes conferencias como la XP o Scan Agile con muy buenos comentarios sobre él.
Podéis encontrar el juego en aquí (pagina en inglés) o bajarlo directamente desde éste enlace directo. Espero que lo encontréis de utilidad y también, cómo no, que os divirtáis y aprendáis jugando.
Planning Pocker
Submitted by cvidal on Vie, 27/07/2007 - 10:56
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.
Reglas y errores típicos en la gestión de requisitos
Submitted by jferrer on Sáb, 18/02/2006 - 20:50
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:
- No disponer de ningún mecanismo de control de cambio
- Evitar cambios de alcance durante el proyecto
- Parálisis del proyecto debido a un excesivo tiempo recogiendo requisitos
- No hacer captura de requisitos de ningún tipo
- No realizar planificación de las iteraciones (tras pasarse a un método supuestamente ágil)
- 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.
¿Qué tienen de malo los diagramas de Gantt?
Submitted by jferrer on Lun, 13/02/2006 - 16:52
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).
Ventajas e inconvenientes de iteraciones cortas
Submitted by jferrer on Jue, 26/01/2006 - 22:14
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.
