En lo primero en que yo me centraria es en la arquitectura y en la forma de trabajar. Esto es crucial. Lo que haria seria definir una arquitectura lo mas compleja posible y una forma de trabajar lo mas restrictiva posible (1).
A medida que se vaya produciendo el desarrollo puede suceder que la arquitectura y/o la forma de trabajar sea muy rigida. Si esto sucede entonces podemos empezar a "relajar la forma de trabajar".
Ejemplo: 1º El documento es un perfecto manual para un desarrollador que acaba de incorporarse al proyecto. 2º El equipo ve como normal enviar correos al final del día. |
Hay una premisa que siempre hay que tener en cuenta: “Es más fácil introducir restricciones y pautas para el equipo de desarrollo al principio del proyecto que una vez que ya se ha empezado con el desarrollo”
La manera de establecer la duración de los sprints debe ser a partir de pruebas de desarrollo previas al desarrollo verdadero que establezcan unas medidas fiables de lo que se tarda en hacer el trabajo. Propongo lo siguiente:
1º Definir un subconjunto de muestra. El responsable coge una serie de requisitos que solucionan una parte del proyecto representativa e incluso que puede generar un entregable.
2º División de tareas. Se establecen tareas que son repartidas entre los distintos miembros del proyecto atendiendo a sus roles.
3º Realizar el trabajo y tomar muestras. Se realizan las tareas y se toma muestras del impacto temporal de todos los aspectos que se consideren relevantes:
- Tiempo de desarrollo
- Tiempo de gestión
- Integración de las distintas partes
- Comunicación en el equipo
- Etc..
(1) Cuando digo posible me refiero a que tiene que ser lo mas complejo posible dentro de la suposicion de que todos los miembros del equipo puedan entenderlo o puedan llegar a entenderlo.
No hay comentarios:
Publicar un comentario