Cambios y constantes en el desarrollo ágil
El título es un poco grande. Este artículo es sólo una reflexión sobre las preguntas planteadas por los compañeros en una Charla Libre.
Entiendo que lo que quiere preguntar es, si los requisitos marcados en el proyecto por la mañana se cambian por la tarde, ¿aún tenemos que aceptarlos siendo ágiles?
¿Depende? Quizás esta respuesta no sea nutritiva...
Las funciones del software son un reflejo del comportamiento de la vida real. La incertidumbre del mundo real y la complejidad inherente del software. Inevitablemente provocará diversos cambios en la demanda. El modelo de desarrollo ágil no resuelve la fuente del cambio. Al contrario, está diseñado para responder a estos cambios.
Ante cambios repentinos en los requisitos, debemos aclarar si están relacionados con el valor finalmente entregado por el software. (Versión humana: si la función entregada provocada por este cambio de demanda es útil para los usuarios y si puede brindar beneficios a los clientes). Si es así, entonces no hay duda de que debemos aceptarlo incondicionalmente, después de todo, el objetivo del software. La entrega es crear más valor, en lugar de seguir el plan para completar más tareas, completar las tareas dentro de la iteración sin crear valor es más costoso que no completar las tareas. Los cambios repentinos son como emergencias de tránsito en la autopista. Es necesario que establezcamos un carril de emergencia para manejar temporalmente tales situaciones, en lugar de resistir ciegamente porque la tarea se ve interrumpida.
Sin embargo, los cambios frecuentes en la demanda definitivamente no se aceptan, al igual que es ilegal que los vehículos ocupen los carriles de emergencia. En comparación con el modelo de desarrollo en cascada tradicional, el modelo de desarrollo ágil divide una gran cantidad de tareas inciertas en iteraciones a corto plazo. Sólo garantizando que las tareas dentro de cada iteración no se vean interrumpidas se podrán entregar primero las funciones de software de mayor valor. Si un ciclo tan relativamente corto siempre va acompañado de una gran cantidad de cambios en la demanda, es posible que deba haber un problema en algún lugar del equipo. Necesitamos esperar un tiempo para descubrir el problema y resolverlo, en lugar de ". abrazando el cambio" sin pensar. .
Lo que permanece sin cambios en el desarrollo ágil es la velocidad del equipo, que son los puntos de la historia (tareas) que el equipo puede completar en una iteración. Está determinado tanto por las capacidades del equipo como por el ciclo de iteración. La capacidad del equipo es un equilibrio que se alcanza a medida que aumenta la madurez del equipo y no se puede aumentar indefinidamente; el ciclo de iteración depende del equipo, generalmente de 1 a 4 semanas. ¿Por qué debemos esforzarnos por garantizar la estabilidad de la velocidad del equipo? Porque sólo la inmutabilidad puede limitar mejor los cambios.
Por ejemplo, entre dos intersecciones (ciclo de iteración), bajo un determinado límite de velocidad (capacidad del equipo), el número de vehículos que pasan por un semáforo es fijo (velocidad del equipo). Entonces, dentro de una iteración, la demanda de cambio es como un automóvil atrapado en el tráfico. Su paso inevitablemente hará que algunos vehículos esperen una luz roja adicional. Esto debería ser un reconocimiento que el público pueda aceptar. Por lo tanto, si ciertos cambios en los requisitos dentro de una iteración provocan una inversión adicional, entonces deberíamos posponer las tareas que deberían completarse dentro de la iteración. Es una lástima que siempre queremos sumar atascos y queremos que pasen los vehículos originales, por lo que la única forma es conducir a velocidad excesiva, sin mencionar violar las regulaciones, una vez que hay un accidente automovilístico, toda la carretera quedará paralizada. .
He conocido algunos equipos que gritan lemas ágiles y realizan proyectos ágiles, pero parecen no tener nada que ver con ágil. La desconfianza mutua dentro del equipo ha llevado a múltiples posiciones, y la agilidad solo se ha utilizado como arma para controlarse y equilibrarse entre sí. Al principio pensé que era porque tenían poco conocimiento de Agile, pero luego recordé que estos cambios e invariancias no solo existen en los proyectos de entrega de software, sino que también ocurren en cualquier momento y en cualquier lugar del mundo real. De hecho, todos conocen algunas verdades simples. .
¿Quizás no tenga nada que ver con ser ágil? Sólo necesita más espíritu contractual y medios menos restrictivos.