Reglas y errores típicos en la gestión de requisitos
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.
