En el proyecto en el que me encuentro actualmente (equipo de 4 personas) hemos logrado poner en práctica toda la teoría conocida sobre SCRUM. Algunas aplicadas 100% según la documentación, otras, adaptadas a los requerimientos del proyecto en sí.
Esto no es nuevo, todos sabemos que la guía para el desarrollo ágil existe, podemos aprender y usar de ella todo lo que enseña, pero al final… cada proyecto es un libro aparte que se escribe a su forma y bajo sus propios requerimientos.
Uno de los puntos que no puede faltar (adaptado o no) en un desarrollo ágil es el Daily Stand-Ups. Esas reuniones de 15 minutos en las que intercambiamos qué hacemos, qué hemos hecho y qué problemas tenemos.
Este tipo de reunión está definida en el desarrollo SCRUM de la siguiente manera:
Daily Stand-Ups (Scrums)
During a sprint, the team, the ScrumMaster, and the product owner (mejor no invitarle a todas 😛 ) commit to meeting once daily in the same place and at the same time to discuss any issues that are preventing work from being done. Meetings are held with everyone standing and time boxed to no longer than 15 minutes. Anyone interested is invited to attend these meetings; however, only the people classified as Pigs are allowed to speak at these meetings.
At the meeting, each team member answers the following three questions:
• What have you done since yesterday?
• What are you planning to do today?
• Do you have any problems preventing you from accomplishing your goal? What progress has been made on existing impediments? Can the blockage be removed or must it be escalated? (The ScrumMaster looks after this area.)
La aplicación de este tipo de reuniones dentro de un proyecto crea un entorno de trabajo sumamente favorable. Todos conocemos qué ha hecho o qué está haciendo cada miembro del equipo, todos aportamos solución a los posibles problemas y todos estamos capacitados en un momento dado de asumir una tarea determinada. Los cuellos de botella en un entorno así, son detectados muy pronto y permite a su vez, darle una pronta solución.
A grandes rasgos, el problema sobre qué hace cada miembro del equipo estaba resuelto. Todos éramos capaces, sin pérdida alguna de tiempo, de asumir o colaborar con la tarea de otro. Pero… (Grrrrrr!!!… siempre hay peros)
Nos dimos cuenta que algo más detallado se nos estaba escapando. Cada tarea asignada a un miembro del equipo normalmente está compuesta por Bugs, Tasks, o Issues. La solución a nivel de código que se daba a cada elemento muchas veces no contaba con la calidad suficiente, o simplemente no se aplicaba una solución que pudiera ser reutilizable. A este nivel de detalle en los Daily Stand-ups, no llegábamos.
Una primera solución fue enviarnos un correo al final del día en el que cada uno contábamos qué había hecho (a nivel de Bugs, Tasks o Issues) hablando un poco de la solución implementada en cada caso, pero ( y más peros…) Somos informáticos, odiamos trabajar de más 😀 y, escribir este correo a final del día iba a terminar perdiéndose.
Pensando un poco en el correo y la información que recogíamos nos dimos cuenta que esto al final era lo mismo que mirar toda la actividad realizada durante el día en el TFS (Team Fundation Server) ¿Por qué entonces no preguntarle al TFS lo que cada miembro del equipo había hecho durante el día? Incluso, ¿Por qué no preguntarle al TFS lo que había hecho por sí solo durante el día? (Builds de integración continua fallidos, Works Items creados, etc.)
Si pudiéramos tener acceso al TFS desde internet, la solución hubiera sido más simple, pero en la mayoría de los casos esto no es así. Al final, desarrollamos una tarea que recoge toda la información del TFS realizada en el día y nos envía un resumen por correo 🙂
La solución nos pareció interesante y por si pudiera ser reutilizada por alguien más, la publicaremos acá en cuanto le apliquemos un poco de Refactoring y le pongamos una cara bonita.
Jo pues que idea más buena !!!
aunque eso sí, la información que se recoja diariamente para cada usuario depende de la calidad con la que se dé de alta en TFS los elementos de trabajo. 😀
Salu2 y a ver con que nos sorprenden
jajaja.. 😛
Pues sí… pero te puedo avanzar que la calidad de los Work items ha mejorado mucho después de tener la herramienta trabajando 🙂
El informe le llega al PM y a todos los miembros del equipo, por lo que evitas por todos los medios que toda tu actividad durante 8 horas de trabajo solo diga:
– «Arreglar el error»
😛
¿Muerte a los correos?…no paro de sonreír desde que lo he leído 🙂
Muy buena idea pero me surgen algunas preguntas:
En ocasiones puede que al finalizar el día no se haga check-in, la tarea no está terminada, el código no es estable, épocas de mucha carga (no hay tiempo). ¿Como comprobáis el avance diario en este caso?
Como han comentado antes, si las descripciones de cada item tienen que ser más exhaustivas…¿no «relentiza» esto un poco el desarrollo?. Aunque supongo que todo tiene un precio!
Última pregunta. ¿No tiene el iPhone un botón de devolver llamada?
Excelente…¡como siempre!!
Saludos
Manera de reirme la mia con tu comentario.. 🙂 te contacto para hablar mañana 😛