¿Son ágiles los plazos?

Para mayor claridad, una fecha límite es:

Un límite de tiempo o fecha límite es un campo de tiempo limitado, o un punto particular en el tiempo, por el cual se debe lograr un objetivo o tarea.

^{De wikipedia}

Durante toda mi carrera en el desarrollo de software he estado haciendo "Agile", lo que en todas partes parece significar que se cumplieron al menos las siguientes prácticas:

• Sprints semanales o quincenales
• Retrospectivas de planificación de Sprint
• Un dueño del producto
• Melé
• Historias del usuario

Sin embargo, cada proyecto en el que he estado ha insistido en establecer una fecha límite. Dado que Agile intenta centrarse en la planificación adaptativa, la flexibilidad y el cambio; ¿son ágiles los plazos?

Mi propia opinión es que no lo son, ya que veo plazos que conducen a una falta de flexibilidad y falta de calidad. En cambio, creo que proporciona más valor centrarse en Sprints y entregas tempranas. Sin embargo, parece que, en cada círculo en el que he estado, este no es el caso, y se considera que los plazos van de la mano con el desarrollo ágil.

Los plazos son una realidad. La mayoría de las veces tienes que tener algo para cierta fecha. Es inevitable Sin plazos, incluso los proyectos ágiles pueden sucumbir a la Ley de Parkinson :

El trabajo se expande para llenar el tiempo disponible para su finalización.

En otras palabras, si su proyecto puede continuar para siempre, lo hará.

En relación con los plazos, Agile intenta hacer algunas cosas:

• Asegúrese de que todos puedan ver siempre cuánto trabajo se realizará antes de la fecha límite
• Asegúrese de que las características más importantes se completen primero
• Asegúrese de que las funciones completadas sean utilizables, en el sentido de que no dependen de funciones que aún no se han completado
• Asegurar que el desarrollo continúe a un ritmo sostenible

De esa manera, cuando llegue el día inevitable, no tendrá una pila de código inútil, sino un producto probado y que funcione, con suerte, solo las cosas menos importantes sin terminar. Y a nadie le sorprende el producto terminado.

Entonces sí. "Ágil" y "plazos" pueden ser perfectamente compatibles.

Los plazos son un hecho de la vida. Hay cosas que tienen una fecha muy firme.

Necesitamos el software de Comdex

o

Los juegos deben estar en las tiendas antes del Black Friday

y similares. No se puede posponer Comdex o Black Friday; el resto del mundo no funciona de esa manera.

El objetivo que tiene Agile es que las cosas que no cumplan con la fecha límite fallan más rápido (y eso es algo bueno), o el alcance puede ser reexaminado antes para que los recursos puedan enfocarse en el ROI correcto en un de manera más oportuna.

La fecha límite es una fecha difícil que se establece con firmeza. Agile es una herramienta que le permite a uno darse cuenta más temprano en el ciclo de que el software tardará el doble de tiempo en desarrollarse de lo esperado originalmente. Es importante que los gerentes de proyecto puedan darse cuenta de estos problemas más temprano que tarde para poder agregar más recursos, cambiar el alcance, ajustar el plazo (en la situación en la que es un plazo firme y no sólido) o el proyecto cancelado.

La transparencia que Agile busca es la de mostrar los problemas y el progreso al principio del ciclo. El clásico error de entrega en cascada es uno en el que pasaste meses a puerta cerrada y entregaste el producto una semana antes de la fecha límite y te dicen que lo estás haciendo todo mal y que has perdido meses (y ahora has vencido por completo la fecha límite) . La otra falla clásica de la cascada es descubrir una semana antes de la fecha límite que aún le quedan meses. Agile busca dar a conocer estos problemas al principio del proceso.

La otra parte que Agile busca hacer en el contexto de una fecha límite es que incluso si solo una parte de las características acordadas están completas (por cualquier razón), la versión actual del software es útil y desplegable.

Ok, extrañamos tener todo lo que queremos para que el software de impuestos se implemente el 15 de abril, pero tenemos el 75% y lo que tenemos funciona y ha estado funcionando desde que comenzamos en noviembre pasado. Sabemos que no podremos implementar el conjunto completo de funciones desde mediados de diciembre y reenfocamos nuestros esfuerzos en el 80% de la base de clientes.

Se deben cumplir algunos plazos. Obligaciones contractuales, convenios, requisitos reglamentarios. Algunos los imponen los gerentes que desean poner el desarrollo de software en la misma tabla que la fabricación en su hoja de cálculo. Cualquiera sea la causa, la mayoría de las personas no pueden escapar de ellos.

Si está trabajando en un equipo funcional, la comunicación entre los desarrolladores y la gerencia / partes interesadas significa que las personas que necesitan tomar una decisión están bien informadas para decidir si es más importante perder el plazo o continuar con el desarrollo.

Incluso si está entregando historias de usuario completas una vez a la semana, o dos veces al mes, probablemente todavía tenga plazos. Cuando se acerca uno, asegúrese de que sus partes interesadas sepan qué cree que encajará en la fecha límite y establezca expectativas.

Si constantemente está construyendo el mejor software posible con los requisitos que tiene actualmente en cada etapa, entonces una fecha límite al final de cualquier sprint no debería ser un problema en teoría. Prácticamente, este no suele ser el caso, pero tampoco lo son los plazos que aparecen de la nada. Los plazos más importantes que me han dado me fueron comunicados mucho antes, era la expectativa de la calidad y las características que eran el problema.

Los plazos arbitrarios que no tienen consecuencias si se pierden no son muy ágiles, pero hay situaciones en las que, por razones ajenas a los plazos de control del equipo de desarrollo, deben establecerse y mantenerse. Afortunadamente, si los plazos son razonables, hay muchas maneras de invertir la ecuación y manejar los plazos de forma ágil.

Los plazos no siempre son incorrectos. Como todos aprendimos de Obi-Wan:

"Solo los Sith tratan en absoluto"

Es justo decir que en la mayoría de los casos los plazos son tontos, innecesarios y ciertamente no ágiles, pero sería una tontería decir que este siempre es el caso. El caso architypal es un software necesario para un uso urgente, como el software de seguimiento de elecciones. Si el software no está listo a tiempo para las elecciones, no sería sensato ni práctico posponer las elecciones, y no parece estar muy orientado al cliente simplemente para decir 'Lo siento, parece que nos tomó demasiado tiempo. Sé que este software por el que nos está pagando no tiene ningún valor, pero los plazos no son ágiles, entonces, ¿cómo puede realmente mantenerlo en contra de nosotros por no cumplirlos?

No es muy ágil decirle a sus clientes que lo empujen por querer algo que sea urgente, y al final del día alguien tendrá que construir estas cosas. Entonces, ¿cómo podemos hacer felices a los clientes y aún ofrecer soluciones aparentemente razonables a cosas que son urgentes? Bueno, si el desarrollo de software lleva una cantidad de tiempo incierta, y el plazo no es variable, algo más tendrá que ser variable para manejar esa incertidumbre ...

Si la fecha de entrega se mantiene constante, algún otro aspecto se convierte en una variable.Como todos sabemos, puede haber una gran cantidad de incertidumbre en los proyectos de software. Algo debe hacerse variable en respuesta a esta incertidumbre si desea tener éxito en su proyecto, y generalmente esa es la fecha de entrega. Parece bastante natural, de todos modos. Pero esa no es tu única opción. Si está atascado comprometiéndose con una fecha límite difícil, la forma de manejarlo es hacer que sus características entregadas sean variables. Priorice una lista de características, comunique claramente que hay incertidumbre en la cantidad de características que se pueden entregar para esa fecha. Trabaje con el cliente para priorizar estas características para que las más importantes tengan una mayor probabilidad de ser enviadas. Entonces, es lo de siempre, solo cuando se acerca la fecha límite para enviar lo que esté listo para ser enviado. En este modelo,

Si alguien quiere establecer una fecha límite, entonces está bien y la fecha límite se puede arreglar, pero lo que deben entender es que si la fecha límite es fija, entonces el alcance debe permanecer flexible.

tl; dr

En un mundo ideal, no tendríamos plazos y solo entregaríamos las cosas cuando estén listas. Sin embargo, la realidad es que las personas que pagan por las cosas generalmente quieren saber cuándo terminan. Las metodologías ágiles reconocen esto, pero también reconocen que no todo se puede atar.

Esto garantiza que pueda mantener la calidad de entrega en el nivel adecuado para el producto. Si fijas un plazo y un alcance (y un presupuesto), entonces las cosas se apresuran y terminas de vuelta en el viejo mundo de las cascadas con un momento de crisis al final del proyecto. Aumentar el presupuesto generalmente no es la respuesta, porque agregar más desarrolladores y evaluadores no resuelve un problema más rápido. Es una opinión bien conocida (y estoy de acuerdo con ella por experiencia), que cuantas más personas agregue (cada una con sus propias debilidades), más tiempo llevará.

Ahora, normalmente (a menos que realmente entiendan los métodos ágiles) a la persona que paga por el software no le gusta que se lo digan, podemos cumplir con su fecha límite, pero no podemos hacer todo lo que desee. Esto se puede gestionar priorizando las funciones que componen el software. Su discusión de priorización podría ser así:

Equipo de desarrollo (D): "¿Puede priorizar las funciones que desea que se entreguen, con la más importante primero?"

Cliente (C): "Todo es prioridad 1: quiero que todo esté listo para fines del próximo mes".

D : "Eso puede ser posible, pero puede que no sea posible si los requisitos cambian o descubrimos problemas que no esperábamos durante el desarrollo".

C: "Bueno, ¿y si te doy más dinero?"

D: " suspiro ... incluso con más recursos les llevará un mes comenzar realmente; así que si no está seguro de cómo priorizar las funciones, díganos cuáles quiere hacer primero".

C: "Ok, quiero el botón grande pero que sea realmente grande, y luego ... etc"

Ahora puede comenzar a trabajar con las funciones en orden de prioridad. También ayuda mirar hacia adelante con su equipo para aquellos elementos que están en el orden de prioridad y hacer algunas estimaciones iniciales, sabiendo que puede cambiarlos cuando llegue al desarrollo cuando tenga más información. Esto se puede usar para redefinir o crear su hoja de ruta si aún no tiene una. Esto forma la base de su plan de lanzamiento. La hoja de ruta se puede discutir con el cliente, reconociendo que el alcance puede cambiar, pero usted tiene un pedido de cosas para entregar.

Una de las grandes ventajas de Agile es que reconoce que las cosas cambian a medida que avanzas en el desarrollo y te ajustas como lo hacen. Contrariamente a los enfoques más tradicionales, este principio, junto con los entregables regulares de sprint y la comunicación continua con el cliente, significa que, naturalmente, se ve obligado a ser más transparente sobre el progreso, lo cual es algo bueno.

A veces al cliente no le gusta que no obtenga lo que quiere para una fecha determinada, PERO comprenderá por qué y lo que obtiene será de buena calidad. Y 6 meses después de que se entreguen las características, al cliente no le importará o recordará que usted entregó en una fecha determinada, recordará la calidad del producto que todavía está utilizando.

Los plazos se basan tradicionalmente en el ciclo de vida empresarial. El software de impuestos debe estar listo para el 15 de abril. La presentación de informes para el próximo año fiscal deberá realizarse en julio.

El manifiesto ágil establece:

Individuos e interacciones sobre procesos y herramientas

Software de trabajo sobre documentación completa

Colaboración del cliente sobre la negociación del contrato

Responde al cambio sobre el siguiente plan

Los plazos son un contrato. Son un plan No responden a la velocidad de tu equipo. No cambian si pierdes a tus tres mejores desarrolladores.

Los plazos no son ágiles, pero Agile puede darnos su opinión sobre los plazos. Ágil, háganos saber si nuestra velocidad no nos permite establecer una fecha límite sin cortar una característica. También nos avisa si necesitamos contratar para hacer una fecha límite. Y en algunos casos, nos permite saber que una fecha límite es imposible, cuando no quedan características para cortar.

Lo mejor que puede hacer un equipo ágil es dejar que su velocidad y la acumulación de prioridades prioricen los plazos. Esto le dará fechas de entrega estimadas. Si esos caen fuera de la fecha límite, entonces es hora de una conversación seria con el cliente y determinar si la fecha límite es factible.

Yo diría que la entrega de cada sprint no es negociable. Evalúa el trabajo, coloca tamaños de tarjeta y carga lo suficiente como para mantener a su equipo ocupado hasta que finalice el sprint (y el sprint debe ser pequeño, de una semana a un mes). Los "plazos de entrega" deben basarse en la tendencia histórica del trabajo completado contra el trabajo anticipado. Agile no agrega / elimina nada de la vieja idea de restricción de "costo / tiempo / alcance", simplemente usa el alcance como el método preferido para gestionar el deslizamiento sobre la base de que una mejor priorización frente al alcance es generalmente preferible a gastar más dinero o tiempo.

Algunas personas parecen confundir ágil para el "salvaje oeste". Ágil no significa que todo vale. Ágil significa que dejamos de mentirnos a nosotros mismos sobre qué tan bien puede estimar una persona razonable. Básicamente podemos estimar el desarrollo de software dentro de 2 a 4 semanas en el futuro. Más allá de eso, se trata de diferentes grados de swags y conjeturas. Peor aún, el costo de proporcionar estimaciones para las cosas cada vez más en el futuro se aproxima al costo de solo hacer el trabajo. Por alguna razón, los gerentes de proyecto históricamente no han estado dispuestos a admitir estas verdades absolutas a los clientes. Agile simplemente ajusta ese pensamiento al afirmar que hay un límite en cuanto a cuán bien podemos predecir el futuro en la ingeniería de software, y hace un cambio sutil a la "estimación basada en evidencia" para el pronóstico a largo plazo.son capaces de estimar, y podemos proporcionar estimaciones bastante razonables de entrega futura a largo plazo en función de lo que hemos estado entregando hasta ahora.

TL; DR

¿Se ven los plazos [a] gile? ... [D] se considera que los plazos van de la mano con el desarrollo de [a] gile.

Es probable que muchas respuestas se centren en los aspectos de ingeniería de la pregunta. En cambio, abordaré esto desde una perspectiva de gestión de proyectos.

Una fecha límite implica una gran cantidad de planificación inicial que no está en línea con los principios ágiles. En cambio, los modelos de desarrollo iterativo se basan en cuadros de tiempo, cadencia y ciclos de lanzamiento que incluyen la planificación justo a tiempo, pero no la "gran planificación inicial" que generalmente se asocia con los plazos tradicionales de gestión de proyectos.

Todavía es posible realizar una planificación de lanzamiento con metodologías ágiles, pero los planes generalmente se basan en una estimación del número de iteraciones requeridas para cumplir un objetivo en lugar de objetivos de gestión establecidos por fiat. Eso no quiere decir que las fechas de envío no se puedan establecer o que los objetivos no se puedan cumplir, pero la forma en que se definen y se cumplen es bastante diferente a la de las metodologías tradicionales de gestión de proyectos.

Piense en los cuadros de tiempo, no en los plazos

Sin embargo, cada proyecto en el que he estado ha insistido en establecer una fecha límite. Dado que Agile intenta centrarse en la planificación adaptativa, la flexibilidad y el cambio; ¿son ágiles los plazos?

Este es un malentendido común de los principios ágiles. Los marcos ágiles como Scrum y Kanban no se centran en los plazos, sino más bien en el tiempo y la cadencia de entrega sostenible.

En Scrum, por ejemplo, el Sprint no es una "fecha límite". Es un cuadro de tiempo que se llena con la cantidad de trabajo que el equipo estima que cabe dentro del cuadro de tiempo sin desbordarlo, y luego se "termina" o "no termina" cuando expira el cuadro de tiempo. Una vez que se fue, la caja del tiempo se fue para siempre; cualquier trabajo que no se realice debe volverse a planificar y volver a estimarse dentro de un nuevo calendario, igualmente efímero, basado en las necesidades actuales del proyecto (en lugar de las históricas).

La importancia del cronograma es que crea una cadencia predecible para que las partes interesadas revisen el progreso y un ritmo sostenible para el equipo en el que entregar incrementos de valor potencialmente transportables . El trabajo es incremental y sigue la cadencia; Por lo tanto, el concepto de una fecha límite grande y por adelantado no está en línea con los principios ágiles.

Planificación de lanzamiento basada en cuadros de tiempo

Quizás la única área donde las personas tienen más dificultades para mapear procesos ágiles a marcos tradicionales es en la planificación de lanzamientos. La planificación del lanzamiento a menudo implica entregables de alcance fijo o de fecha fija. En los marcos ágiles, la planificación de lanzamiento generalmente se realiza a través de un proceso de estimación donde el alcance se define explícitamente como una variable mutable, mientras que las fechas de lanzamiento se estiman en iteraciones.

Por ejemplo, un proyecto puede comprometerse a lanzar v1.0 de un proyecto al final de 20 iteraciones; El alcance de lo que se publica puede cambiar durante la vida del proyecto (ya que el alcance, las características y las prioridades pueden cambiar al comienzo de cada Sprint), pero las fechas objetivo para cada lanzamiento se fijan en el plan del proyecto. El equipo se esfuerza por entregar un incremento potencialmente transportable en cada Sprint, y la Definición de Hecho incluye controles de calidad, como la integración continua, para garantizar que el proyecto se encuentre en un estado liberable al final de cada Sprint.

Ocasionalmente, verá proyectos ágiles donde el alcance es fijo, pero debido a que el alcance es la variable mutable en los proyectos ágiles, la fecha de lanzamiento puede cambiar con el tiempo a medida que el alcance de cada iteración se ajusta, cambia o se adapta a las necesidades cambiantes del proyecto. . Ciertamente no recomiendo el enfoque de alcance fijo a los equipos ágiles, especialmente los equipos sin experiencia, pero hay momentos en que es el enfoque correcto.

Ver también

• Cómo realizar una planificación de lanzamiento ágil

Piense en los plazos como compromiso. El hecho de que el proyecto sea ágil no significa que no deba comprometerse a entregar funciones específicas para una fecha determinada.

Lo que trae la agilidad es lo que sucede en el medio. En lugar de tener un estricto documento de especificación de requisitos de software que define que debe entregar la función A compuesta de las subcaracterísticas B, C, D y E para una fecha determinada, se compromete a entregar la función A para una fecha determinada, dado que en el etapa inicial, ni usted ni su cliente saben cómo se verá la función, o tendrían las subfunciones B, C, D y E o tal vez B y C, o una docena de otras subfunciones.

Imagine una empresa que anteriormente entregaba productos solo a pequeñas empresas y acaba de firmar un contrato con una gran corporación. Esta gran corporación usa EDIFACT, y parece que el software de contabilidad actual utilizado por su compañía no maneja EDIFACT. Estás pedirá que cree un plugin que hace que, dado que por contrato, su empresa debe estar listo para abril 15 ^º .

La agilidad significaría que los pasos intermedios se entregarán progresivamente y se basarán en comentarios regulares. Básicamente, mostrarás tu progreso a los contadores, y ellos te dirán lo que piensan al respecto, cuáles son los posibles problemas, etc. Esto también significa que tal vez originalmente, los contadores tenían una gran idea que, pensaron, podría mejorar sustancialmente la experiencia del usuario. Tres semanas después, parecía que no solo no mejoraba demasiado, sino que también generaría un mes de desarrollo adicional. Gracias a Agile, puede redirigir sus esfuerzos de esta función a otra cosa, asegurándose de entregar a tiempo.

También debe comprender el punto de vista del cliente:

• A menudo, las empresas necesitan una fecha de entrega específica. Por ejemplo, no puede ofrecer el servicio de transmisión en línea de los juegos olímpicos después del final de los juegos olímpicos. En cuanto a los negocios, esto es simplemente un fracaso, con enormes consecuencias negativas.

• Sin tener un compromiso, es tentador para un desarrollador o un subcontratista ser perfeccionista o hacer que el proyecto sea de baja prioridad. Si bien la regularidad de los sprints ayuda, no evita totalmente este riesgo.

  No me agradan los plazos para eso, especialmente porque los plazos de entrega se producen con mucha facilidad, pero todavía entiendo por qué muchas empresas hacen eso. No siempre es fácil ver que el proyecto está retrasado con solo mirar los sprints: una fecha límite incumplida, en este contexto, puede ser un claro recordatorio de que algo se sale de control y debe tratarse en este momento.

eXtreme Programming informa sobre la planificación del lanzamiento:

La filosofía básica de la planificación del lanzamiento es que un proyecto puede cuantificarse por cuatro variables: alcance, recursos, tiempo y calidad.

Lo que parece justo. También establece que

Nadie puede controlar las 4 variables. Cuando cambia uno, inadvertidamente causa que otro cambie en respuesta. Tenga en cuenta que reducir la calidad a menos que excelente tiene un impacto imprevisto en las otras 3 variables

Y como ya señaló br3w5 , aumentar los recursos es una solución limitada. Probablemente puede agregar un par de personas que ya formaban parte del equipo si fueron enviados a otra cosa. Pero no puede simplemente aumentar el tamaño del equipo de forma rápida e indefinida, al menos no sin la reorganización del equipo, que lleva muchas veces.

Entonces, con una calidad irreducible y recursos fijos: una fecha límite que es una limitación de tiempo, significa que necesita adaptar el alcance. Y el uso de la agilidad le brinda el medio para cumplir el plazo con el alcance más productivo posible. Sin embargo, generalmente puede garantizar que alguna parte del alcance se realizará a tiempo. Esta es la parte en la que puede estimar con confianza que su tiempo estará limitado por debajo de la fecha límite. Por lo general, algo que está muy cerca de lo que ha hecho varias veces y tiene poco desconocido.

El propósito de los métodos de desarrollo de software, cuando se entiende correctamente, es hacernos más productivos al enfocar nuestros pensamientos y proporcionar un lenguaje común para situaciones típicas. Se trata de inspiración y habilitación, no de control mental y culpa.

Seguir un método de desarrollo de software literalmente, sin compromisos, corresponde a lo que se llama radicalismo o fundamentalismo en otros contextos. La forma pura de esta aberración rara vez se ve en la práctica porque generalmente conduce a un fracaso rápido en el mercado. Pero, por supuesto, cuando los desarrolladores compiten en la difícil tarea de implementar un método específico, superar la marca es algo natural.

El problema se ve exacerbado por el hecho de que los misioneros y evangelistas se dirigen principalmente a aquellos que aún necesitan convencerse de usar el método; e incluso si predican moderación, la naturaleza humana asegura que reciba menos atención.

Los plazos no son ágiles, son:

1) Cascada, y 2) Incorrecto.

El software y los plazos no funcionan bien juntos y nunca lo han hecho. En muchos sentidos, los métodos ágiles son una reacción al problema masivo de plazos vencidos o software que se abandonó cuando quedó claro que el plazo no se podía cumplir (así como también los problemas presupuestarios).

Agile intenta inyectar realidad en la situación diciendo "Sabes que la fecha límite o las características van a deslizarse y / o cambiar, lo sabemos, así que comencemos con el pie derecho y ni siquiera pretendamos".

La clave es que la fecha límite se convierte simplemente en una fecha de lanzamiento para la primera versión del software. Eso aún podría estar escrito en piedra, digamos, el software es para uso académico y DEBE ser utilizable al comienzo del período, pero lo que entregará no lo es. Usted tiene un producto mínimo viable que todos están muy seguros de que se puede entregar para entonces, y tiene una carga de "quisiera tener". En lugar de que todos levanten la mano cuando resulta que la lista completa no se entregará antes de la "fecha límite", se asegura de sacar al MVP y tantos de los "quisieran tener" como posible y luego evaluar el costo / beneficio del resto en ese punto.

¡Cualquiera que haya jugado juegos de computadora por mucho tiempo sabe exactamente cómo funciona esto! Si el primer lanzamiento está a la altura de los estándares beta, muchos jugadores están contentos, así de bajas son las expectativas de lo que significan "plazos reales y firmes" en la vida real.

Por lo tanto, los plazos no son ágiles, son remanentes de los días en que la gente pensaba que el software podría tratarse como hardware e ingeniería de acero. Hemos aprendido que esto no es posible ni deseable, ya que arroja la mayor ventaja que tiene el software sobre el hardware: es suave.

Agile trata de explotar esta suavidad permitiendo que los objetivos se desarrollen y cambien en el transcurso del proyecto de una manera que un diseño de puente nunca podría.

Responda "probablemente no"

El Project_management_triangle establece que el costo, tiempo y alcance (y también de la calidad) dependen unos de otros. ("elige dos y consigue el tercero")

Un scrum sprint elige el tiempo fijo (es decir, 7 días = duración del sprint) y el costo (es decir, el presupuesto para 7 miembros del equipo) y estima el alcance (el número de historias que se realizarán en el sprint)

Si la gerencia o el departamento de ventas intentan definir los tres (costo, tiempo y alcance), entonces no es ágil en el sentido de scrum porque el equipo no puede prometer alcanzar el objetivo (sin violar la calidad = definición de hecho)

La gerencia profesional intenta definir el costo y el tiempo y reducir el alcance si es necesario si hay una fecha fija que se debe cumplir.

¿No se puede responder de manera simple y directa?

No hay plazos no son ágiles.

El objetivo es construir lo que pueda de forma iterativa aprendiendo y adaptándose a medida que avanza.

Una fecha límite es "tiene que entregar x por y" que falla en ambos aspectos, ya que promete una entrega fija en un plazo predeterminado (donde ágil dice que no estamos seguros de lo que estamos tratando de entregar, y el aprendizaje de Agile nos enseña que, incluso si sabemos que es muy difícil tener certeza sobre las escalas de tiempo, o es un problema resuelto y no deberíamos hacerlo de todos modos).

Habiendo establecido que la respuesta a la pregunta es "No, los plazos no son ágiles", entonces podemos tener una conversación interesante que aborda la cuestión de "cómo abordamos los plazos en un contexto ágil" y hay muchas cosas buenas pensando en eso en las otras respuestas.

En mi opinión, una respuesta razonable a esto último es que entregaremos incrementos de valor temprano y con frecuencia y veremos dónde estamos a su debido tiempo, pero no hay una talla única para todos.

El grado de agilidad requerido en el trabajo de uno es inversamente proporcional a cuán alto es su posición en el organigrama.

"Ágil" es bueno, por lo que es. "Ágil" significa "mente abierta junto con suficiente competencia". Son los gruñidos en la parte inferior los que tienen que ser los más ágiles.

Si, en los niveles gerenciales, el jefe de cabello puntiagudo era lo suficientemente ágil como para comprender que retrasar una fecha límite una semana generaría un mejor producto o un código más limpio, más libre de errores y más aprovechable para que la empresa ( o la división) ahorra dos semanas en el futuro, esa es una fecha límite ágil.

Pero como el interés propio ilustrado, en realidad no existe.