domingo, noviembre 02, 2008

Scrum: Me encantan las Sprint demos

domingo, noviembre 02, 2008 por Martín


La verdad es que cuanto más trabajo con Scrum, más me gustan las Sprint demos. Como la mayoría sabéis, Scrum se basa en la ejecución de pequeñas iteraciones de varias semanas denominadas Sprints donde se va implementando funcionalidad que se ha decidido al comienzo de cada una de esas iteraciones. Durante los diferentes Sprints se pueden ir lanzando releases, y una vez finalizados todos los Sprints hemos terminado el desarrollo.

Una de las partes más críticas en Scrum es el fin de Sprint. Una vez terminado una iteración se suele hacer una demostración del producto. Estas demostraciones teóricamente deberían incluir a los clientes, pero todo depende realmente de cómo y para qué se está utilizando Scrum en la compañía.

Una de las cosas más curiosas de la demo de final de Sprint es que, al menos en nuestro caso, el desarrollo se para completamente. La gente pasa a centrarse durante una semana completa en sacar la demo adelante, y durante este tiempo pasan muchas cosas. Esto abre la cuestión sobre si es realmente valioso el parar a los desarrolladores durante cinco días completos poniendo esfuerzo en preparar algo que puede que en el futuro cambie, o algo para lo que hay que poner un montón de parches que después habrá que recodificar. Mi opinión es que es tremendamente valioso, básicamente por todo lo que pasa en ese proceso de preparación de la demo:


  • Se realiza un esfuerzo por integrar toda la funcionalidad creada durante las últimas semanas en un formato compacto y demostrable al cliente final lo cual revela numerosos bugs y problemas imprevistos. Lo más importante aquí es que estos problemas se detectan por adelantado en las primeras fases de desarrollo, mientras que en una metodología de software tradicional estos errores se detectarían al final y serían mucho más complejos de resolver.

    Los desarrolladores somos muy vagos en cuanto a end-to-end testing se refiere. A menudo diferentes equipos trabajan en diferentes componentes y funcionan como islas independientes unas de la otras. Descuidar la interación entre componentes puede traer problemas a largo plazo, y las demos ayudan a forzar la integración frecuente de dichos componentes evitando posibles riesgos.

  • Irremediablemente se crearán soluciones temporales, o hablando más claro: parches. Estos parches estarán ahí en la demo, pero su presencia obliga a preparar y planificar soluciones reales para el siguiente Sprint. El equipo se ve obligado a reservar el tiempo necesario para solucionar estos problemas, y eso ayuda a no encontrarse sorpresas no planificadas de última hora y el tener que hacer esos sobreesfuerzos de los que siempre nos estamos quejando.

  • Las demos obligan al pragmatismo y a la creación de artefactos distribuibles. Otro aspecto que yo considero importante es que los desarrolladores no pueden ser "mega-creativos" y crear soluciones que les lleve meses ver la luz (caso aún posible, pero que de darse estaríamos ante proyectos en si mismos y requerirían Sprints propios). El desarrollador se debe centrar en implementar funcionalidad de manera pragmática y siempre pensando en tener algo que entregar, algo que distribuir, algo que se pueda demostrar.

    Esto abre otro debate sobre como integrar en un Sprint funcionalidades no tan fácilmente demostrables como puedan ser cambios internos en la arquitectura, refactorizaciones, etc. Pero eso ya es un tema diferente.

  • Involucración por parte de los desarrolladores. Personalmente creo que la demo no debe ser realizada por única persona, sino que aquí el Scrum Master debe actuar como simple maestro de ceremonias. Obligar a los desarrolladores a participar en la demo les obliga a involucrarse más en la misma. El esfuerzo inevitablemente será mayor ya que no es lo mismo poner tú mismo la cara que el que la tenga que poner otro por ti.

  • El efecto moral de ver que el proyecto avanza. En nuestro caso por ejemplo hacemos la demo para toda la compañía. Vosotros ya sabéis como es el desarrollo de software. A menudo la mayoría de equipos trabajan de manera independiente, y prácticamente sólo tienen contacto para conocer los problemas que unos tienen con el trabajo del otro. "¿Oye, qué tenía que pasar en este escenario?", "¡Este caso de uso está mal, estamos perdidos.", "¡Change Request", ...

    Me atrevería a decir que es común que la sensación cross-team de las personas ajenas al desarrollo de una aplicación al terminar cada iteración sea más pesimista que cuando el Sprint había comenzado, ya que el único input que han tenido estos equpos han sido problemas. El presentar una demo y mostrar que los objetivos marcados a principio de Sprint se han cumplido, y que no todo está tan mal como la gente se piensa, es una fenomenal forma de mostrar que el trabajo se ha realizado, que todo va bien, y de ayudar a recuperar esa moral que se pueda haber perdido durante el esfuerzo de desarrollo.


  • Visibilidad para el cliente. Teóricamente las demos deberían incluir al cliente. En muchos casos esto no es posible físicamente, pero lo ideal es hacerlo. En nuestro caso por ejemplo, las demos internas se trasladan a otro equipo que se encargará de repetirla con el cliente final, ya en sus oficinas. Con la demo el cliente puede comprobar que se está progresando, lo cual en el mundo del software no es tan común, además de poder validar todos sus requisitos y sugerir cambios cuando sea necesario.



Y esto sería más o menos el resumen de lo que pasa durante esos días que se prepara la demo, al menos en nuestro caso. ¿Cómo son vuestras demos? ¿Las hacéis? ¿Se diferencian mucho sobre esto?

comments

5 Respuestas a "Scrum: Me encantan las Sprint demos"
Joserra dijo...
12:05

Me ha resultado curioso que digas que esos días "se para" el desarrollo. !no lo creo! ¿o no corregís bugs esos días? Si no lo hicieseis en ese momento para preparar la demo, os los encontraríais despues!
Lo importante es definir que es "producto terminado", y eso es lo que debe salir de un sprint. Si se define como algo que pueda ir a PROducción directamente, por ejemplo, cambia mucho que si se define como "entregables de muestra al cliente"... aunque en este segudo caso... ¿qué pasa? ¿qué no se terminan BIEN las cosas? :)

Por curiosidad, de qué tiempo estáis haciendo los sprint? ¿tres semanas?.


Martín dijo...
13:04

Muy bien visto! En realidad debería haber escrito: "se para el desarrollo de nueva funcionalidad". Nosotros utilizamos la semana siguiente al fin de Sprint para preparar la demo y el siguiente Sprint. Se trata de un proceso concentrado en bug fixing, en corregir todo lo que ha encontrado QA y en cerrar los objetivos planteados al principio del Sprint, mientras
los diferentes scrum masters preparan la iteración siguiente.

El producto terminado no está hasta el fin de todas las iteraciones planeadas. Aún así al final de cada iteración tenemos un producto "demostrable". Nada de eso va a producción, pero sí se le demuestra al cliente.

Empezamos con dos semanas pero era demasiado corto. Ahora mismo estamos en tres semanas y parece que va bastante bien.


Daniel dijo...
15:00

Nosotros no tenemos una metodología de ese tipo, en fin, y hay dos equipos diferentes. Uno somos el equipo "puro web" que desarrollamos algo más parecido a eso, prototipando, mostrando al cliente cuanto antes, sacando funcionalidad a medida que se avanza... y el otro equipo que viene del desarrollo en cascada, y con eso sigue: años de analisis y años de desarrollo antes de enseñarselo siquiera al "cliente" que no es ni siquiera el usuario, si no habitualmente el jefe y el jefe del jefe del usuario.

Los diferentes grados de satisfaccion del usuario hablan por si mismos... pero como al ser administracion la satisfaccion del usuario es uno de los factores de menos peso... asi de contentos siguen.
Pero bueno, hay que seguir luchando para cambiarlo.

Gracias por compartir que no todo el mundo es así, algo de esperanza queda, jejeje.


Joserra dijo...
10:30

Curiosos planteamiento Martín! :)
Sacas del tiempo del sprint el preparar la demo... ¿por qué? ¿no dejas de medir la velocidad esa semana? En realidad creo que te aportaría más incluirlo en el sprint, la métrica de velocidad va a ser más real, puesto que el tiempo de corrección de bugs también es tiempo de desarrollo de esas funcionalidades.

Aquí todos tenemos nuestros trucos, nosotros hablamos de un "sprint 0", en el que posiblemente no hacemos entregables funcinales, si no an´lisis, prototipados,... etc... y eso tampoco es Scrum "puro" pero... si va bien...


Martín dijo...
10:51

El planteamiento sería similar de algún modo a lo de Eclipse. Para nosotros los Sprints duran 3 semanas y los Sprints se centran en crear nueva funcionalidad y corregir bugs.

Una vez terminado el Sprint nos pasamos una semana centrados en bug-fixing y en preparar el siguiente Sprint, mientras al mismo tiempo preparamos la demo. Ahí no medimos la velocidad, aunque sí que mantenemos los meetings diarios para seguir como va la preparación. Es un periodo que mezcla relax ya que no hay que añadir nueva funcionalidad con la presión de crear una demo efectiva.

Management no se preocupa por el tiempo de ese Sprint siempre que la demo salga bien (hasta ahora siempre), pero sí que es cierto que hay problemillas como gente que pierda carga de trabajo durante esa semana. A veces cuando pasa esto, se adelanta algo de trabajo del siguiente Sprint.