¿Es Agile más eficiente que Waterfall?
Uno de los Scrum Masters a los que frecuentemente entrenamos nos llama regularmente por problemas con los que está luchando. Bromeó que deberíamos decir "Línea directa Agile, ¿cómo podemos ayudarte?" cuando contestamos el teléfono. Pensamos que era una muy buena idea y por lo tanto comenzamos ahora con una serie de entradas de blog con el nombre Línea directa Agile. Aquí encontrarás nuestras respuestas a las preguntas que recibimos de otros sobre Agile o Scrum. Esperamos que también puedas aprender algo de esto.
Recientemente me pidieron un consejo sobre una discusión que alguien tuvo con un colega. Se trataba de si Agile y Scrum pueden funcionar en cada escenario en el que se desarrolla software. El colega afirmó que no.
El escenario
Supongamos que se va a construir un producto de software que permite a los usuarios hacer evaluaciones cuando leen un e-book. Debe haber al menos dos tipos diferentes de estas evaluaciones.
Con Agile o Scrum, uno intentaría entregar un producto funcional y valioso lo antes posible, así que el objetivo es entregar solo una de las opciones de evaluación, pero que ya pueda ser utilizada tempranamente por los usuarios. Esa sería entonces la v1.0. Algunos sprints después, uno intentaría implementar la segunda opción de evaluación como v2.0.
Con el modelo Waterfall, uno se tomaría tanto tiempo como fuera necesario para entregar ambas evaluaciones en la primera versión.
El colega argumentó en este caso que Waterfall tendría más sentido, porque de lo contrario el riesgo sería muy alto de tener que refactorizar todo el código para poder soportar la segunda opción de evaluación v2.0. Con Waterfall, sin embargo, ambos tipos de evaluación se desarrollarían juntos. Aunque tomaría más tiempo entregar la primera versión funcional, se tendría menos trabajo de seguimiento.
Él es de la opinión de que el método Waterfall ahorra tiempo y es más eficiente porque se necesita menos refactorización si se comienza el desarrollo con los requisitos actuales y futuros simultáneamente. Con Agile, nuestro enfoque está en el "ahora" y en solo un tipo de evaluación.
¿Qué piensas al respecto? ¿Cómo manejarías un grupo de desarrolladores que piensa que con Agile tendrán que rehacer mucho más tarde porque "no se les permitió planificar demasiado adelante"?
Lo que creemos
Hay tres puntos principales que uno debe entender para responder esta pregunta:
Primero: Agile y Waterfall tienen cada uno su área de aplicación. Agile está diseñado para sistemas complicados/complejos, por ejemplo, cuando hay un cierto grado de incertidumbre en los requisitos y/o la tecnología. Waterfall es mejor para proyectos simples, por ejemplo, cuando hay una buena comprensión de los requisitos y la tecnología y estas cosas no cambian. Usamos la Matriz de Stacey para aclarar cuándo se debe usar qué. El problema es que Waterfall falla completamente en un entorno complejo, mientras que Agile en un entorno simple, aunque está asociado con más esfuerzo, todavía funciona. Nuestro ejemplo favorito de esto es organizar una conferencia. Puedes usar Agile, incluso si puede parecer un esfuerzo innecesario.
Segundo: Agile NO es más eficiente que Waterfall. Es más efectivo. Eso significa que tal vez necesites más horas de persona para entregar algo con Agile, pero el producto muy probablemente puede llegar al mercado antes (porque debería haber un release al final de cada sprint y no solo al final del proyecto). Además, los costos operativos totales probablemente son más bajos (porque la calidad y el diseño son mejores y el conocimiento se comparte, por lo que el mantenimiento es más fácil).
Tercero: Con Agile no se trata de desarrollar algo específico más rápido. Se trata del arte de maximizar la cantidad de trabajo no realizado. El estudio Chaos dice que el 65% de un software nunca o raramente se usa. Con Agile, uno intenta identificar y desarrollar el 35% restante que es más probable que se use; después de eso, uno se detiene. Entonces, aunque tal vez tome un poco más de tiempo desarrollar el primer 35%, nos hemos ahorrado desarrollar el otro 65% que nadie usará.
¿Cómo se ve eso con nuestro ejemplo? Bueno, en primer lugar, uno no completaría primero toda la primera evaluación y luego la segunda. Uno identificaría la parte más valiosa de la evaluación. Eso puede ser un cierto tipo de pregunta (por ejemplo, una pregunta de opción múltiple). Entonces uno solo incorporaría una pregunta en la evaluación, la dejaría probar por los usuarios y descubriría si funciona. Incluso se podría entregar la primera opción de evaluación solo con preguntas de opción múltiple. Después de eso, uno incorporaría el siguiente tipo de pregunta más importante. O uno decide que es lo suficientemente bueno y comienza con un nuevo proyecto.
Si el alcance de las evaluaciones realmente está fijado, además sabes que realmente funciona para los usuarios, y no hay incertidumbre con respecto a la tecnología, Waterfall puede ser la mejor opción para este proyecto. Agile también funcionaría, solo que no necesariamente ahorraría tiempo. Por experiencia puedo decir que la mayoría de las personas piensan que conocen y entienden todos los requisitos, pero eso normalmente no es cierto. El esfuerzo adicional con Agile generalmente vale la pena.
Este texto proviene del Blog de Growing Agile y fue traducido por nosotros al español.