lunes, 22 de noviembre de 2010

Mi SCRUM

SCRUM esta bien definido y es facil de aprender pero yo aplicaria algunas variantes.

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:

Para desarrollar un proyecto se estableció desde el principio que diariamente cada miembro del equipo enviará un correo al responsable al final del día indicando que había hecho y además cada vez que se solucione una tarea se debe escribir en un “documento de soluciones técnicas” que tarea se resolvió y como se resolvió a muy bajo nivel técnico.
El proyecto “se aprieta” y se ve claramente que se necesita agilizar la solución de tareas, además al equipo no le gusta el documento de soluciones técnicas.
Una solución podría ser dejar de completar el documento de soluciones técnicas pero seguir con los correos.
De esta experiencia se puede deducir que el documento no aplica para este proyecto pero tenemos dos ganancias:

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..
Este proceso debe durar muy poco en relación con la duración establecida para el proyecto general. Con estas medidas ya se debe poder establecer una mejor división de tareas y una duración justa y equilibrada de cada tarea. Además, se conoce las prestaciones de cada uno de los miembros del equipo.



(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: