Una actividad/juego de sensibilización sobre los resultados de la ejecución tradicional (cascada o RUP) en proyectos de software

El JUEGO DE LA MUESTRA ESTADÍSTICA

Hola a todos

Muchas veces antes de dictar un entrenamiento o una charla sobre metodologías ágiles realizo la siguiente actividad  (la aprendí de mi colega Leonardo Agudelo - https://twitter.com/sweepnoise )

1. Trazo una linea divisoria imaginaria, o con cita de enmascarar 
2. Pongo a todo el grupo a un lado de la línea
3. Comienzo a realizar las siguientes preguntas e invito a los que las van cumpliendo pasen al otro lado de la línea
4. y así voy avanzando hasta que veo que es suficiente

La fuerza de la actividad radica en las preguntas y en que todos perciban lo mal o bien que les esta yendo haciendo la ejecución actual de proyectos (adicionalmente que no son los únicos que padecen los problemas de su día a día)

Estas son algunas de las que uso:

Nota: Resaltaré las preguntas que más me han sorprendido.

----

• Categoría: Roles
• Objetivo: Saber con quienes comparto la charla o entrenamiento
• Preguntas
• ¿quiénes son gerentes de proyecto?
• ¿quiénes son comerciales?
• ¿quiénes son desarrolladores?
• ¿quiénes son testers?
• etc

--

• Categoría: Tiempo
• Objetivo: Sensibilizar que la ejecución tradicional (cascada, Rup, o cualquier variación) no es precisa en cuanto al tiempo 
• Preguntas
• ¿quiénes han estado en un proyecto que se ha demorado el cuadruple de lo planeado?
• ¿quienes el triple?
• ¿quienes el doble? 
• ¿quienes han trabajado en un proyecto seguido sábados y domingos incansablemente por más de un año? -(lamentablemente los hay)
• ¿8 meses?
• ¿6 meses?
• ¿4 meses?
• ¿2 meses?
• ¿1 mes?

--

• Categoría: Costo
• Objetivo: Sensibilizar que la ejecución tradicional los costos no son predecibles
• Preguntas
• ¿quiénes han estado en un proyecto que ha costado el cuadruple de lo planeado?
• ¿quienes el triple?
• ¿quienes el doble? 

--

• Categoría: Alcance / Requisitos 
• Objetivo: mostrar que las especificaciones firmadas no son garantía éxito.
• Preguntas
• ¿quienes han estado en un proyecto donde a pesar de haber construido lo que hay en las especificaciones, el cliente afirma "ok, es lo de las especificaciones pero eso no es lo que yo quería"?
• ¿Quienes han estado en un proyecto donde los controles de cambio cuestan mas que el proyecto original?
• ¿a quienes el cliente les ha dicho?
• ¿yo se que yo firmé eso, pero eso no es lo que yo necesito?
• ¿es que esa funcionalidad aun no esta clara y no se como va funcionar?

--

• Categoría: Éxito de los proyectos tradicionales
• Objetivo: Sennsibilizar sobre lo dificil que es ser éxitoso en tiempo, costo, alcance y calidad en un proyecto tradicional
• Preguntas
• ¿quiénes han estado en un proyecto exitoso en tiempo, costo, alcance y calidad? (se sorprenderán.. muy pocos) 

--

• Categoría: Estimaciones
• Objetivo: Mostrar que tan acertadas son las estimaciones en proyectos de software son imprecisas, debido a la incertidumbre.
• Preguntas
• ¿quienes se han equivocado en una estimación el 8 veces, ejemplo dijeron 1 día y se demoraron 8?  -(lamentablemente los hay)
• ¿6 veces?
• ¿4 veces?
• ¿2 veces?

(será que no sabemos en que estamos trabajando)

--

• Categoría: Desgaste del equipo y de la vida personal
• Objetivo: Mostrar la forma en que hemos desgastado nuestras vidas y la de los equipos de trabajo forzando el éxito a toda costa
• Preguntas
• ¿a quienes su familia, novio, novia, esposo, esposa, hijos, hermanos madre, les ha dado un ultimatum...¡o renuncias o no vuelves a saber de nosotros! (aca el resultado ha sido doloroso, algunos comparten que les ha costado el divorcio, o situaciones similares)
• ¿quienes han trabajando seguido mas de ?
• 36 horas
• 24 horas
• 16 horas

--

• Categoría: los riesgos
• Objetivo: Evidenciar los riesgosos que son los proyectos de desarrollo de software
• Preguntas
• ¿ a quienes se les ha dañado una entrega teniéndola completamente lista?

--

• Categoría: Desperdicio /se construye lo que no se usa
• Objetivo: Mostrar cuanto software es desperdicio (la estadística muestra que del 100%, solo el 50% es usado, de ese 50%, el 20% con frecuencia y el 30 rara vez - Chaos Manifesto 2013)
• ¿quienes consideran que el 100% del software que hacen es usado por el cliente?
• ¿el 90?
• ¿el 80?
• ¿el 70?
• ¿el 60?
• ¿el 50?
• ¿quienes consideran que construyen documentación que nunca será usada?
• ¿quienes han estado en un proyecto que no salió a producción?
• ¿quienes han estado en un proyecto que saló a producción pero nadie usa?
• ¿quienes han estado en un proyecto donde dicen, la documentación que se hizo no sirve, volvamosla a construir?

y así.. sucesivamente

Si tienen más preguntas para la actividad, que bueno sería las compartieran...

Como se pueden dar cuenta no son los únicos que viven estos males.

Hagan la actividad y compartan la experiencia en este post, se llevarán sorpresas muy interesantes.

Saludos ágiles

Jorge Abad