|
 Tener los requisitos cerrados antes de empezar a programar, y trazar con ellos un plan completo ¿es bueno o malo?
La respuesta es distinta si le preguntas a PMI o si le preguntas a la agilidad. Para PMI cada modificación de requisitos es una amenaza para el plan del proyecto, una incidencia que hay que medir y gestionar sus consecuencias. Para la agilidad cada modificación de requisitos es una nueva aportación que va a hacer más valioso el resultado para el cliente. Si nos planteamos si será mejor PMI o Scrum ya nos hemos limitado las opciones.
Si el planteamiento fuera o A, o B, un proyecto cerrado que debe ejecutarse en un plazo relativamente breve por un equipo habituado al trabajo ágil, sería un problema sin solución. Como los ejemplos suelen ser más claros, traigo el que surgió la semana pasada de una posible estrategia flexible para abordar un proyecto real que con requisitos y fecha de entrega cerrada; un plazo de ejecución relativamente corto (tres meses) y un entorno de trabajo ágil: .... Considerando:
- No es
previsible la inestabilidad de requisitos, por lo que los
requerimientos pueden considerarse cerrados o bastante cerrados desde
el principio.
- Se ha dado ya un plazo de 3 meses al cliente.
Haría una previsión global del proyecto (algo que parece propio de gestión predictiva)
1.-
Analizaría los requerimientos (puesto que los tienes completos y
cerrados) y extrairía el gran "epic" o los grandes epics (no deberían
ser muchos, son las grandes historias o fines del sistema)... para
tener clara la visión del proyecto, y lo que el cliente quiere obtener.
2.- Descompondría esos requerimientos en historias de usuario y compondría un backlog.
3.-
Haría una estimación temprana por juicio de experto de ese backlog.
Dicho llanamente: si tienes experiencia en trabajar de forma ágil con
tu equipo, haría la estimación que por mi experiencia considero más
probable para cada tarea.
Si no tienes experiencia en trabajar de
forma ágil con el equipo, llamaría al director técnico del equipo, o
varios miembros, y les pediría que hicieran una estimación de las
tareas (quizá emplearía estimación de póquer).
4.- ¿Es viable?. Con estos datos ya vería si parece que es un proyecto sensato, o si voy a arrancar una marcha fúnebre
5.- En el segundo caso, lo mejor es tratar el tema con los directivos del proyecto antes de empezar. (aunque a veces te puede buscar problemas según la apertura y sentido común de los directivos del proyecto)
Haría
una ejecución ágil para tener seguimiento cercano del avance real del
proeycto y detectar posibles desviaciones rápidamente (porque el plazo
es relativamente corto: 3 meses)
6.- Si se ve un margen
de viabilidad aceptable, transmitiría la visión al equipo, o
identificaría a quién debe asumir esta responsabilidad de Propietario
del producto y empezaría a cortar el backlog y seguir un ciclo scrum.
 |
RSS de los comentarios
De todas formas no estoy muy de acuerdo con lo que se comenta sobre el PMI :
"Para PMI cada modificación de requisitos es una amenaza para el plan del proyecto"
Para el PMI ( almenos en su cuarta edicion ) los cambios son riesgos pero no una amenaza..... es por ello que establece varios procesos y un sistema para controlar los cambios. Tened en cuenta que riesgo no significa algo negativo puesto que hay riesgos positivos. Riesgo solo determina un evento incierto.
Una de las formas que comenta PMI es el "rolling wave planning" por lo que acepta que la definicion no es estatica al inicio sino que se realiza a lo largo del proyecto.
Lo que PMI SI que define como algo muy importante al inicio del proyecto son los requisitos, pero eso no es la definicion de los paquetes o entregables sino una lista con los requisitos ( restricciones externas ) que debe cumplir el proyecto : fechas, arquitectura hardware, disponibilidad de personas, etc......
Creo que es importante aclarar estos temas, aunque yo no estoy de parte de nadie, porque he visto textos parecidos en otras paginas relacionadas con Scrum y en las que tambien he aclarado que no son del todo ciertas a mi modo de ver.