¿Scrum es Poderoso o es Eficiente?:
Aquellos que no conocen los fundamentos de una metodología la implantan como si fuera una religión

Scrum es poderoso porque es una religión

Scrum es poderoso porque es una religión. Si quieres alcanzar el cielo de la tecnología, ese lugar idílico donde todos los proyectos finalizan en plazo, debes seguir puntualmente cada uno de sus ritos.

 Scrum, como el resto de religiones ágiles, sabe que nos enfrentamos a problemas complejos dentro de un entorno cambiante. Así que en lugar de trabajar por los siglos de los siglos, abordaremos la construcción de la solución mediante una sucesión de pequeñas iteraciones. Al final de cada una de ellas analizaremos qué se ha conseguido y qué se debe hacer a continuación dada la nueva situación del entorno.

El ritual SCRUM es como sigue:

El Account Manager descubre una necesidad del cliente y junto con el Sumo Sacerdote o Product Manager, preparan una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realizan sacrificios a Poseidón y ofrendas a Baco para lograr que el cliente la firme.

Este es el ritual más complicado de las religiones ágiles y al que menos atención se presta en los Textos Sagrados. Los clientes no quieren comprometer presupuestos determinados a cambio de productos indeterminados. Si lo piensas, en los proyectos realizados según los ancestrales ritos de Waterfall, el alcance estaba definido pero en media sólo se entregaba el 50% de lo acordado. Nada nuevo bajo el sol.

En un concilio, cliente, Account Manager, Product Manager, y Product Owner, describen el sistema a desarrollar en forma de Epics y Features, que son descripciones de las funciones del sistema con una extensión de entre una línea y un párrafo. Para guardar este diseño de alto nivel, en lugar de tablas de piedra se utiliza el Product Backlog. Ahorramos así tiempo de análisis que usaremos después en el desarrollo.

Posteriormente, en un conciliabulo entre Product Owner, Product Manager y programadores, descomponen Epics y Features en Historias de Usuario, que tienen la forma ‘Como usuario <perfil de usuario> soy capaz de hacer <tarea> y así consigo <valor para el negocio> ’. En lugar de usar rollos de papiro, este diseño de bajo nivel se guarda en el Team Backlog.

Es el momento de comenzar los ritos de implementación.

El primero es formar un equipo Scrum con un Product Owner, un Scrum Master y entre tres y siete consultores. Sus puestos de trabajo deben estar próximos entre sí y deben poseer los conocimientos y la experiencia necesarios para implementar de extremo a extremo las Historias de Usuario; definir la arquitectura, hacer el diseño de detalle, codificar, probar, integrar y documentar.

Cada iteración comienzan con la ceremonia del Sprint Planning. El equipo se reúne con cliente y Product Manager para decidir qué Historias de Usuario van a intentar ejecutar durante el Sprint, que dura entre tres y cuatro semanas. Cliente, Product Manager y Product Owner saben qué historias de usuario son prioritarias. Scrum Master y programadores conocen su velocidad de ejecución.

Durante el Sprint, el equipo diseña las Historias de Usuario, las codifica, desarrolla las pruebas unitarias y prueba el software construido. Sólo si el código supera las pruebas se considera finalizado y apto para presentar al cliente. El Product Owner ayuda a los programadores a interpretar las Historias de Usuario. El Scrum Master convoca a maitines o Daily Scrum, donde al comienzo de cada jornada los consultores comentan unos con otros durante unos minutos el avance de su trabajo y piden ayuda en caso necesario.

Finalizado el Sprint, el Product Owner celebra el Sprint Review, donde entre viandas y refrigerios, el equipo scrum muestra a cliente, Account Manager y Product Manager las Historias de Usuario que han conseguido completar. Aquellas que obtengan el pláceme del cliente serán ofrecidas para su puesta en producción. Aquellas que no, junto con a las Historias que no se han finalizado, serán devueltas al team backlog para participar en nuevos Sprint Planning.

Hay una ceremonia final para un selecto grupo de iniciados, el Sprint Retrospective. Aquí Scrum Master, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de mejorar sus habilidades y ser más productivos en las siguientes iteraciones.

Sigue religiosamente este ritual y tus proyectos llegarán a buen puerto con la bendición de los Dioses.

Scrum es eficiente porque cumple las Cuatro Leyes

Scrum, al igual que Time & Material, es una metodología que cumple las Cuatro Leyes y por tanto es más eficiente que las metodologías clásicas de desarrollo en cascada o Waterfall. Veamos cómo lo hace.

 1ª ley. Las especificaciones son inciertas, imprecisas e infinitas. La primera ley nos advierte de que el tiempo empleado en especificar es, en general, tiempo perdido y que no es posible finalizar por completo los trabajos.

En Scrum el diseño es muy liviano; los requisitos del usuario se capturan en forma de Epics y Features, cuya extensión es de una línea o de un párrafo. Posteriormente Epics y Features se descomponen en Historias de Usuario cuya extensión también es de una sola línea. El tiempo que se ahorra en la especificación se dedica a desarrollar código, asumiendo que buena parte del mismo deberá modificarse una vez lo presentemos a cliente.

Para mitigar el problema de las especificaciones infinitas, la variable de ajuste en Scrum es el alcance, así que el cliente asume que seguramente no se concluirán todos los desarrollos, pero que el software construido tiene una calidad adecuada y resuelve sus principales necesidades.

2ª ley. One Project, One Team, One Site. La segunda ley nos advierte de que en el desarrollo de software son muy importantes los vínculos emocionales y la confianza. La mejor forma de construir relaciones es mediante el contacto diario. Para construir la confianza es necesaria la dedicación exclusiva de todos los consultores a un mismo proyecto.

En Scrum los equipos de desarrollo están formados por entre cinco y nueve consultores cuyos puestos de trabajo están próximos entre sí. El grupo es autosuficiente para hacer sus tareas, incluye no solo a programadores y testers, sino también al Product Owner, que ayuda al resto del equipo a interpretar las historias de usuario, al Scrum Master, que vigila que los procesos sean livianos y, en caso necesario, pueden haber también dentro del equipo arquitectos de sistemas.

3ª ley. Presión x Talento = Constante. La tercera ley nos recuerda que el avance de los desarrollos sólo depende del número de buenas ideas que del grupo, y no del número de participantes ni el número de horas que trabajen. Es necesario desarrollar el talento y para eso es perentorio disminuir la presión.

De nuevo, el hecho de que la variable de ajuste sea el alcance nos ayuda a rebajar la presión; no es obligatorio acabar todas las Historias del sprint, no es obligatorio desarrollar todos los Epics y Features. Lo construido es lo mejor que se podía hacer con el plazo y presupuesto disponible.

Aunque la variable de ajuste sea el alcance, puede existir la tentación de incrementar la jornada de trabajo, lo que conllevaría un retraso de los desarrollos. El Scrum Master y en su defecto el Product Owner deben ser capaces de bloquear esta presión. Recientes estudios proponen que rebajar la jornada a cinco horas diarias puede lograr incrementos de productividad del orden del 30%.

4º ley. El triangulo de Acero. La cuarta ley enseña que Alcance, Plazo y Calidad están relacionados de tal forma que si fijas dos de ellos, el tercero se degrada. Nunca, nunca, nunca sacrifiques la Calidad.

En los modelos tradicionales de desarrollo en cascada o Waterfall, se fijaban Alcance y Plazo lo que generaba dos efectos negativos:

  • Al sacrificar la calidad, se entregaban al cliente productos insuficientemente probados que producían incidencias graves cuando entraban en producción. La resolución de estas incidencias son tareas no programadas que poco a poco ocupan todo el tiempo disponible para las tareas programadas de desarrollo. Es la lluvia ácida.
  • Como las especificaciones son infinitas nunca se completaban los desarrollos, generando disputas entre todos los grupos involucrados; el cliente, la dirección de la empresa tecnológica, los Jefes de Proyecto, los Líderes Técnicos y los Programadores y Testers.

Como hemos repetido en los puntos anteriores, en Scrum la variable de ajuste es el Alcance, por lo que estos dos riesgos quedan convenientemente mitigados. Para fijar el plazo se acuerda un periodo de desarrollo dividido en varios sprints, y para fijar la calidad, sólo aquellos desarrollos que han superado los test de calidad se entregan al final de cada sprint.

Deje su comentario