Durante el mes de mayo dictaré un curso sobre “Administración de proyectos de software” en el Laboratorio de Calidad de Tecnologías de la Información, en Rosario.
Cuando hablamos con el Gerente del Laboratorio, Fabián Longhitano, sobre el contenido del curso, surgió una necesidad y un desafío que me interesó mucho.
Últimamente estoy presentando temas como Scrum, Critical Chain y otros, a personas que tienen conocimiento sobre las formas y herramientas “tradicionales” de administración de proyectos. Cuando es este el caso, en muchas ocasiones los ejemplos y explicaciones hacen foco en las diferencias, dando por supuesto las similitudes.
Por otro lado, el Laboratorio tiene un curso específico de Scrum, y en este momento yo creo que para la mayoría de los proyectos de desarrollo de software que encaramos en Argentina, Scrum es la mejor opción.
Entonces, ¿Cómo diseñar un curso de administración de proyectos de software, que sea útil y autocontenido pero complementario con el curso de Scrum, para personas que tienen experiencia en proyectos de desarrollo de software pero quizás no educación formal sobre administración de proyectos?
El resultado es un curso que plantea algunas de las herramientas tradicionales, pero desde un punto de vista iterativo e incremental, tomando algunas ideas de FDD, como el análisis y modelado de dominio inicial, y la planificación por funcionalidad (o features), junto con ideas de Critical Chain para la planificación. Algunas de estas ideas ya las presenté en otros cursos.
Adicionalmente, se plantean temas relacionados con la comprensión e interacción del equipo con su contexto. Esto es imprescindibles para cualquier equipo, independientemente de cómo se organice, y no suele ser desarrollados en las capacitaciones de Scrum básicas. Se dice que los 3 principales fuentes de problemas de los proyectos son la comunicación, la comunicación y la comunicación.
Parte de los problemas de comunicación se mejoran increíblemente en Scrum, pero la idea del Product Owner como único stakeholder externo al grupo es una simplificación o una transferencia del problema al Product Owner, que tendrá que manejar las expectativas y necesidades de los muchos stakeholders del proyecto.
Por último, una implementación de Scrum tendrá una definición de "ítem completo" (cuando se considera que un requerimiento está implementado) que inicialmente dejará muchas tareas fuera del equipo, como pruebas de performance, capacitaciones a usuarios, etc. Según un comentario de Ken Schwaber, un equipo puede requerir 3 años para que el producto liberado al final de cada sprint pueda ser pasado a producción sin ninguna tarea adicional. Mientras tanto, y mientras otros equipos, clientes, proveedores sigan utilizando terminología y formas de administrar proyectos distintas de Scrum, el contenido de este curso tendrá aplicación práctica para los asistentes.
El material del primer dictado de este curso se puede encontrar en los post del día 1, día 2 y día 3.
No hay comentarios:
Publicar un comentario