¿Es posible Scrum ignorando las buenas prácticas?

Siempre podemos ignorar las buenas prácticas, quizás no pase nada malo 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.

6 comentarios sobre “¿Es posible Scrum ignorando las buenas prácticas?”

  1. Para hacer Scrum no es necesario utilizar buenas prácticas de desarrollo de software … si no haces desarrollo de software.

    Lo que quiero expresar es que Scrum por sí mismo es una manera de trabajar (y de pensar) que aportaría mucho en ámbitos que no son desarrollo de SW (es decir, donde no se aplican estricamente las prácticas mencionadas, aunque se pueden aplicar otras bastante «equivalentes»).

    Yo mismo utilizo Scrum en consultoría y PMO. Por otro lado, si los departamentos de Producto utilizasen como base este patrón, quizás nos entenderíamos más. Y si nuestros políticos (de cualquier partido) lo utilizasen (como medio de trabajo y de pensamiento) y con eso diesen ejemplo, a lo mejor tendríamos un país más productivo.

    Por último, añadiría algunas prácticas más de desarrollo de SW (quizás triviales) que también facilitan realizar cambios : estandares de codificación, buenos comentarios en el codigo y patrones de diseño.

  2. @Xavier: Totalmente de acuerdo con lo que dices. Scrum es aplicable en proyectos fuera del ámbito del desarrollo de software. Un ejemplo claro es el equipo de documentación escenarios de Team System.

    Yo en este artículo, hablo de proyectos de desarrollo de software.

    Supongo que la conclusión es que Scrum es mucho más fuerte cuando se combina con las buenas prácticas propias del dominio del tipo de proyecto en el que se lleva a cabo Scrum.

    Además las prácticas que tu citas son tan importantes o más que las que yo cito, yo solo seleccioné tres para mi ‘reducción al absurdo’.

    Gracias por tu comentario…

    P.D.: Aprovecho a recomendaros que visitéis http://www.proyectosagiles.org, que es una iniciativa de Xavier más que recomendable.

  3. No he leido más. He parado cuando dices que CMMI es una metodología «…que no prescriben buenas prácticas como parte de su receta».
    CMMI es un conjunto de buenas prácticas, no es una metodología.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *