¿Es posible Scrum ignorando las buenas prácticas?
La relación que existe entre la metodologías y las buenas prácticas ha hecho correr ríos de tinta. Es una cuestión candente que Luis Fraile o Angel Medinilla (ver la lista de Agile Spain) en la lengua de Cervantes y Martin Fowler en la de Shakespeare, entre otros muchos 'agilistas', han tratado con diferentes posturas. El mismo debate ha surgido en la lista de correo de Agile Spain y seguro que resurgirá en el futuro. Así que no me he podido resistir a escribir sobre el tema.
Mi visión sobre esta cuestión es clara. No me importan las metodologías con M mayúscula, me importa la metodología con m minúscula. Esta distinción la hacen los autores de Peopleware para marcar la diferencia entre 'tener una metodología' y 'trabajar metódicamente'. A menudo nos encontramos con organizaciones que alardean de metodología e ignoran todo método en su trabajo diario. La diferencia entre ambas situaciones está en un única aspecto: las buenas prácticas de ingeniería del software que los equipos de desarrollo utilizan en el día a día.
Tampoco faltan los gestores que pretenden que la gestión de proyectos es un puro problema organizativo, en el que las buenas prácticas de ingeniería del software tiene un papel secundario. Este perfil de gestor es en mi opinión menos útil que el gestor que tiene una visión técnica fundamentada en las mejores prácticas de la ingeniería del software, de los problemas que surgen durante el desarrollo del proyecto. Lógicamente siempre manteniendo el equilibrio.
Desde el punto de vista del espectro metodológico hay dos vertientes claras, metodologías que son prescriptivas en lo que a ciertas buenas prácticas se refiere, como XP o MSF Agile y metodologías que no prescriben buenas prácticas como parte de su receta, como Scrum o CMMI. Scrum es totalmente agnóstico respecto a las buenas practicas. Siguiendo la premisa de que el equipo es en Scrum autoorganizado y autogestionado, este es soberano a la hora de decidir como implementar las historias comprometidas para un sprint. Scrum no exige, en principio, el uso de ninguna buena práctica.
Yo soy partidario de las buenas prácticas por encima de las metodologías. Pero ese no es el tema de hoy. El tema de hoy es contestar la pregunta ¿es posible hacer Scrum sin utilizar buenas prácticas?. Dicho esto veamos que ocurre si un equipo de Scrum decide ignorar las buenas prácticas.
Voy a tratar de demostrar, mediante reducción al absurdo, que no es posible, en proyectos de desarrollo de software, cumplir algunas reglas de Scrum sin utilizar buenas prácticas de ingeniería del software. El punto es que si ignorando algunas buenas prácticas llegamos a la conclusión de que no podemos cumplir alguna de las reglas de Scrum directamente se deriva que no estamos utilizando Scrum. Esto supone asumir también que Scrum solo es Scrum si se respetan sus reglas. Es fácil saber si estás usando Scrum o no, comprobando si estás siguiendo la reglas o no. Voy ha hablar de las tres buenas practicas utilizadas por los equipos de desarrollo ágil: Automatización de la pruebas, construcciones automatizadas y gestión de la configuración.
Un equipo ágil podría elegir no utilizar pruebas automatizadas. El precio que pagaría por esa decisión sería no poder detectar regresiones en el software de manera rápida y no poder asegura que las historias están hechas de manera inequívoca. Sin la posibilidad de detectar regresiones de manera rápida, lo que ocurriría, es que cuando el final del sprint se acercase, el equipo tendría que congelar el desarrollo de funcionalidad, dedicar un tiempo considerable a asegurar la ausencia de regresiones y a asegurar que las funcionalidades están completas, pruebas incluidas. Una de las reglas de Scrum especifica que se debe minimizar el tiempo que se dedica a la preparación del Sprint Review. La conclusión es clara: Sin automatización del testeo es imposible dedicar poco tiempo a la preparación del Sprint Review. Luego sin pruebas automatizadas, no es posible Scrum.
Un equipo ágil podría decidir no usar construcciones automatizadas. El precio que pagaría sería que no podría construir una versión lista para el despliegue con suficiente velocidad y asegurando la ausencia de errores derivados de un proceso de construcción manual. Una de las reglas de Scrum dice que el Producto Owner puede decir tras cualquier Sprint Review poner el software en producción. Sin construcciones automáticas, esta puesta en producción se demoraría y el equipo habría fallado al entregar un incremento de funcionalidad potencialmente entregable, aspecto clave en Scrum. Por lo tanto la conclusión es simple: sin construcciones automatizadas, no es posible Scrum.
Un equipo ágil, podría elegir no usar una política de gestión de la configuración adecuada . El precio que pagaría sería que no podría asegurar que el software entregado solo contiene historias completas. Recordemos que una de las reglas de Scrum dice que el equipo solo puede demostrar características completas y que nada que no se haya demostrado debe ser entregado. De esta premisa se deriva que si nuestra política de gestión de la configuración no es adecuada, no es posible Scrum.
De lo anteriormente expuesto, es simple de concluir que como la automatización de las pruebas, las construcciones automatizadas y la gestión de la configuración adecuadas, son buenas prácticas y sin ellas no hay Scrum, sin buenas prácticas, no hay Scrum.
Es más diría que sin buenas prácticas no hay agilidad, pero eso ya no soy capaz de demostrarlo formalmente. Ya lo decía mi abuelo: quien no siembra no recoge.