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

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?

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.

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.

Á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á.

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.