¿Decidir la fecha de lanzamiento antes de recopilar todos los requisitos no es ágil?

10

Acabo de empezar a leer el libro Aplicación de UML y patrones de Craig Larman. Lo encuentro muy interesante porque desafía muchas de las cosas que me han dicho en el trabajo. Leí que los requisitos no se recopilan completamente de una vez en forma ágil y se requieren muchas iteraciones para completar la recopilación de requisitos. Si ese es el caso, ¿está poniendo una fecha límite fija, que es lo que me veo obligado a hacer en el trabajo, muy poco ágil, considerando que podría haber algún nuevo requisito innovador (o solicitud de cambio enmascarada como requisito) mañana?

Kaushik
fuente

Respuestas:

19

No hay absolutamente ningún problema "ágil" con tener una fecha de lanzamiento fija si está preparado para mover uno de los otros dos bordes del "triángulo de hierro": los requisitos para lo que debe estar en ese lanzamiento, o los recursos que tiene disponibles . No puede arreglar los tres, y en la práctica, el lado de "recursos" del triángulo a menudo no es muy flexible o no es eficiente modificarlo.

Si hay un nuevo requisito importante mañana, está bien siempre y cuando la empresa esté preparada para aceptar que ese requisito no llegue a la fecha de lanzamiento, es decir, se deslice al próximo lanzamiento.

Philip Kendall
fuente
1
Siempre he sentido que ese lado de los recursos del triángulo es un error. Cambie por calidad y funciona mejor. Pero estás en lo cierto: átame a una fecha de lanzamiento si es necesario, pero las características y la calidad se resbalarán como resultado.
David Arno
1
@DavidArno Yo diría que la "calidad" es parte de la Definición de Hecho, que es en sí misma parte de cada requisito. Y "recurso" sin duda puede tener un impacto significativo en la entrega de recursos si se toma distancia del proyecto.
Philip Kendall
1
@ChristianHackl: Creo que no importa cuál sea la metodología, el desarrollo de software requiere mucho tiempo y mucho dinero si también quieres calidad.
Bryan Oakley
2
@BryanOakley: Eso es cierto. Solo deseo que los evangelistas ágiles realmente reconozcan que sus metodologías no son especiales en este sentido. Una vez que deja atrás la falsa suposición de que ágil le permite tener su pastel y comérselo, entonces puede diseñar el proceso de desarrollo correcto para su proyecto eligiendo si y cuánto "ágil" debe contener.
Christian Hackl
1
@ChristianHackl Ninguna metodología es una bala de plata. Pero el punto principal de "ágil" (un término amplio) no es que deba hacer que las entregas exitosas sean más baratas / más rápidas sino que mantiene bajo el costo de las fallas (inevitables).
Guran
3

Creo que el problema en muchos campamentos ágiles es con la fecha límite. El riesgo con una fecha límite es que asumes que sabes lo que hay que hacer. Como señala, no puede tener una fecha límite para un desconocido.

Lo que se describe en la respuesta de Philip es mucho menos una fecha límite que una restricción. Podríamos decir que tenemos fondos hasta marzo, por lo que debemos hacer el mejor producto posible en ese momento.

Para dar una analogía, supongamos que le pido que vaya a la tienda de comestibles y compre todos los comestibles para la semana y, antes de ir o mirar cualquier precio, quiero que me diga exactamente lo que gastará. Además, serás penalizado si te equivocas. Hará exactamente lo que la gente hace con los plazos del proyecto: elegirá un número en el extremo superior de lo que cree que podría ser el rango porque tiene la menor probabilidad de que lo penalicen. Ahora, digamos que le digo que esto es inaceptable y que debe comprar las mismas cosas que planeó, pero debe hacerlo por $ 50 más barato, o de lo contrario. ¿Qué puedes hacer ahora? Puede negarse, puede posponer el argumento hasta después de comprar, o puede encontrar una manera de engañar la situación. Esto es lo que sucede en muchas organizaciones con plazos establecidos en incógnitas.

Ahora, viendo lo poco saludable que es toda esta situación, Agile simplemente dice: "Si tienes un presupuesto, puedo prometer que te someteré a eso y te daré las mejores comidas posibles para esta semana en esa restricción". Lo cual es una conversación mucho más saludable.

Daniel
fuente
¿Realmente prometes eso a la gente? ¿Qué pasa si está equivocado y otro enfoque cumpliría con la fecha límite con mejores comidas?
Christian Hackl
1
Argumentos similares sobre Agile y los plazos aquí
Eric King
@Cristiano. Seguro. Por lo menos, es lo mejor que puedo ofrecer dentro de esa restricción. Quizás alguien más podría hacerlo mejor o tal vez si las circunstancias fueran diferentes, habría encontrado una mejor solución, pero esas especulaciones no parecen valiosas. Sobre todo teniendo en cuenta que siempre tengo más información cuanto más tarde en el proyecto se pone, cualquier fecha límite estimada que doy ahora será, por su naturaleza, menos informada que cualquier cosa que le cuente más adelante.
Daniel
por supuesto, estamos hablando de un tema bastante complejo en la plataforma StackExchange, que no está diseñado para manejar temas amplios y multifacéticos. Traté de mantener mi respuesta concisa y enfocada para encontrarme con la plataforma. De hecho, es un segmento muy estrecho y se puede decir mucho sobre la naturaleza más robusta del desarrollo de software y la organización del ciclo de vida del desarrollo.
Daniel
@Daniel: Bueno, solo me opongo a la idea de que uno promete resultados ideales a un cliente solo porque cree que usa el mejor enfoque. Eso no es realista.
Christian Hackl
2

Ágil es una técnica, no un resultado. En comparación con cortar el césped, una iteración es como una línea de césped que ha cortado. Si alguien dice "corta todo el césped en 15 minutos", y estás usando ágil, tal vez completarás el 30% al final. Luego, iterará un poco más tarde y lo terminará.

Dingo
fuente
2

Puede tener una fecha de lanzamiento planificada sin problemas. Solo asegúrese de que en esta fecha en particular no tenga cabos sueltos. Usted debe tener un producto que pueda ser enviado al final de cada sprint, pero por lo general no hay ningún daño hecho si no lo hace; Es más un objetivo que enfoca el trabajo en lugar de un requisito. Si tiene una fecha de lanzamiento planificada, debe tener un producto liberable en esa fecha.

Por lo general, tendrá como objetivo tener un producto no probado, pero con suerte liberable, algún tiempo antes de la fecha de lanzamiento planificada, luego se prueba el producto y se corrigen los errores hasta que se cumplen los estándares de calidad, y luego se libera sin ningún pánico necesario. El lanzamiento contendrá lo que estaba listo en ese momento.

Ahora puede que no sea obvio para su jefe que también debe planificar una segunda fecha de lanzamiento, con más funciones implementadas.

gnasher729
fuente