Consideremos un proyecto de software ágil.
Al comienzo de un proyecto, cada historia se puede implementar con bastante rapidez porque la base de código es pequeña, hay pocas dependencias entre las diferentes partes del código, no tenemos que mantener la compatibilidad con versiones anteriores, etc.
Pero a medida que el equipo avanza, la base del código se vuelve más grande y más compleja; requiere más tiempo para comprender todas las dependencias. Necesitamos pasar más tiempo hablando con otros desarrolladores sobre la arquitectura actual. Una Historia que antes se hacía en pocos días, ahora pasa a requerir al menos una semana.
Más cerca del final del proyecto, arreglar incluso un error menor a menudo se vuelve muy difícil porque la base de código es enorme, hay muchas dependencias y restricciones (por ejemplo, compatibilidad con versiones anteriores).
Entonces, a medida que el equipo avanza, su velocidad debería disminuir. La misma Historia al comienzo del proyecto se puede estimar en 1 Punto de Historia, pero esta misma Historia que se desarrolla al final del proyecto puede ser estimada por el equipo en 10 Puntos de Historia o más.
El manifiesto ágil establece que un equipo ágil debe mantener un ritmo constante, ¿es realmente posible?
El equipo, por supuesto, puede comenzar a otorgar más puntos a las Historias para compensar el aumento de esta complejidad, pero eso significaría que el Story Point en sí mismo no es una unidad de medida fija y, por lo tanto, no podemos usar los Story Points para pronosticar el cantidad de tiempo requerida para completar el proyecto.
Hay algunas cosas a considerar.
Con respecto al "ritmo constante", el Manifiesto para el desarrollo ágil de software dice:
Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente.
Esto no dice nada acerca de que la complejidad del trabajo aumente o disminuya con el tiempo. Tampoco habla de la velocidad a la que se realizan los elementos de trabajo. Lo que dice es que el nivel de esfuerzo que todos los stakeholders mantengan debe ser sostenible por tiempo indefinido. Esto es para desalentar las actividades que conducen al agotamiento : días largos, días adicionales u otras actividades de "tiempo crítico" que causan agotamiento físico y mental, estrés, negatividad hacia el entorno laboral o cualquiera de los otros efectos o síntomas del agotamiento. La idea es que desee mantener un equipo estable para los esfuerzos a largo plazo, y el "desarrollo sostenible" y el "ritmo constante" son algo que puede ayudar a promover esto.
El aumento de la complejidad de un sistema con el tiempo es normal, pero hay formas de mitigarlo. El primero es reconocer los dos tipos de complejidades que pueden existir en el sistema: complejidad accidental y esencial. Algunos sistemas son simplemente complejos: provienen de los problemas que se están resolviendo y son inherentes. Es posible que pueda aislar la complejidad, pero existe. La complejidad accidental es algo que se introduce innecesariamente y se puede arreglar.
A medida que un sistema crece y madura, es importante no solo agregar funcionalidad útil, sino también desaprobar y eventualmente eliminar la funcionalidad que ya no agrega valor. Esto es parte de la gestión de productos y debe equilibrar el costo de soporte y mantenimiento de una determinada funcionalidad con el valor que agrega a los usuarios finales.
La deuda técnica es otro factor. Minimizar la deuda técnica imprudente y pagar la deuda técnica prudente puede ayudar a mejorar la capacidad de mantener el sistema. Cuando decida incurrir en una deuda técnica, también tenga un plan para pagarla. Cuando aplica las lecciones aprendidas, tiene casos de prueba sólidos para admitir modificaciones (incluida la refactorización), tiene la documentación adecuada (incluido el mantenimiento de un código legible) y se asegura de que puede pensar en el impacto de las decisiones de diseño, puede reducir el impacto de la complejidad.
Sin embargo, incluso si haces todo bien, disminuirás la velocidad. Lo mejor que puede hacer es minimizar cuánto reduce la velocidad.
Obviamente un caso de Flacid Scrum como lo define Martin Fowler.
Hay un lío del que he oído hablar recientemente con bastantes proyectos. Funciona así:
- Quieren usar un proceso ágil y eligen Scrum
- Adoptan las prácticas de Scrum, y tal vez incluso los principios
- Después de un tiempo, el progreso es lento porque la base del código es un desastre.
Lo que pasa es que no han prestado suficiente atención a la calidad interna de su software. Si comete ese error, pronto notará que su productividad se reduce porque es mucho más difícil agregar nuevas funciones de lo que le gustaría. Ha asumido una deuda técnica paralizante y su scrum se ha debilitado en las rodillas. (Y si has estado en un verdadero scrum, sabrás que eso es algo malo).
La solución es simple en teoría:
Si está buscando introducir scrum, asegúrese de prestar mucha atención a las prácticas técnicas. Tendemos a aplicar muchos de los de Programación Extrema y encajan muy bien. Los XPers a menudo bromean, con alguna justificación, que Scrum es simplemente XP sin las prácticas técnicas que lo hacen funcionar. Dejando de lado los francotiradores, las prácticas de XP son un buen punto de partida, y ciertamente serán mucho mejores que no hacer nada en absoluto.
Aunque en la práctica, las prácticas de XP requieren mucha habilidad y disciplina. Y agregar prácticas de XP a un proyecto ya existente significa que primero debe pagar la mayor parte de la deuda técnica. Y mi experiencia es que podría llevar años de esfuerzo concentrado hacer eso. Por lo tanto, debe adoptar un enfoque más a largo plazo.
Todd A. Jacobs
Todd A. Jacobs