¿Los plazos son ágiles?

Los plazos son una realidad. La mayoría de las veces tienes que tener algo en una fecha determinada. Es ineludible Sin fechas límite, incluso los proyectos ágiles pueden sucumbir a la Ley de Parkinson :

  

El trabajo se expande para completar 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 cuánto trabajo se realizará dentro de la fecha límite
• Asegúrese de que las funciones 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 hayan completado
• Asegúrese de que el desarrollo continúe a un ritmo sostenible

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

Así que sí. "Agile" y "deadlines" 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 Viernes Negro

y similares. Uno no puede posponer Comdex o el Viernes Negro, 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 fracasen más rápido (y eso es algo bueno), o que el alcance se pueda volver a examinar antes para que los recursos se puedan centrar en el correcto ROI de una manera más oportuna.

La fecha límite es una fecha difícil que se establece firmemente. Agile es una herramienta que le permite a uno darse cuenta anteriormente en el ciclo de que el software tardará el doble en desarrollarse como se esperaba 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 la fecha límite (en la situación en la que es una fecha límite firme y no sólida) o el proyecto cancelado.

La transparencia que Agile busca es la de mostrar los problemas y el progreso antes en el ciclo. El fallo clásico en la entrega de cascadas es uno en el que pasó meses a puerta cerrada y entregó el producto una semana antes de la fecha límite y se le dice que lo está haciendo todo mal y que ha perdido meses (y ahora ha cumplido con la fecha límite) . La otra falla clásica en cascada es descubrir una semana antes de la fecha límite que aún faltan 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 funciones acordadas están completas (por cualquier motivo), la versión actual del software es útil e implementable.

  

Ok, nos perdimos de tener todo lo que deseamos para el software de impuestos que se implementará el 15 de abril, pero tenemos un 75% y lo que sí 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 reorientamos nuestros esfuerzos en el 80% de la base de clientes.

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

Si está trabajando en un equipo que funciona, entonces la comunicación entre los desarrolladores y la administración / partes interesadas significa que las personas que necesitan tomar una decisión están bien informadas para decidir si es más importante faltar 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, es probable que tenga fechas límite. Cuando se acerque uno, asegúrese de que sus partes interesadas sepan qué cree que encajará dentro de la fecha límite y establecerá las expectativas.

Si está creando constantemente el mejor software que puede con los requisitos que tiene actualmente en cada etapa, entonces una fecha límite al final de cualquier sprint en teoría no debería ser un problema. En la práctica, 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 no se cumplen no son muy ágiles, pero hay situaciones en las que, por razones ajenas a los límites de control del equipo de desarrollo, se deben establecer y mantener. Afortunadamente, si los plazos son razonables, hay muchas formas de invertir la ecuación y manejar los plazos de forma ágil.

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

  

"Sólo los Sith tratan en absolutos"

Es justo decir que, en la mayoría de los casos, los plazos son tontos, innecesarios y ciertamente no son ágiles, pero sería absurdo decir que este es siempre el caso. El caso architypal es el software necesario para un uso sensible al tiempo, como el software de seguimiento de elecciones. Si el software no está listo a tiempo para la elección, no sería sensato ni práctico posponer la elección, y no parece estar muy orientado al cliente simplemente para decir 'Lo siento, parece que hemos tardado demasiado. Sé que este software por el que nos está pagando no tiene ningún valor, pero los plazos no son ágiles, así que, ¿cómo puede realmente ponerlo en nuestra contra por no cumplir con ellos? "

No es muy ágil decirle a sus clientes que lo empujen por querer algo que sea sensible al tiempo, y al final del día alguien tendrá que construir estas cosas. Entonces, ¿cómo podemos hacer felices a los clientes y seguir ofreciendo soluciones aparentemente razonables a cosas que son sensibles al tiempo? Bueno, si el desarrollo de software toma una cantidad de tiempo incierta y la fecha límite no es variable, otra cosa solo 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 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 manejar eso es hacer que las características entregadas sean variables. Priorice una lista de características, comunique claramente que existe incertidumbre en la cantidad de características que se pueden entregar en esa fecha. Trabaje con el cliente para priorizar estas características, de modo que las más importantes tengan una mayor probabilidad de ser enviadas. Entonces, el negocio sigue como siempre, solo cuando la fecha límite se extiende alrededor de usted el envío de lo que está listo para ser enviado. En este modelo, el envío de más funciones es el análogo al envío en una fecha anterior, y el envío de menos funciones es el análogo del envío en una fecha posterior.

Si alguien quiere establecer una fecha límite, eso está bien y la fecha límite puede ser fija, 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 simplemente 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 puede estar atado.

Esto garantiza que pueda mantener la calidad de entrega en el nivel correcto para el producto. Si fijas una fecha límite y un alcance (y presupuesto), entonces las cosas se apresuran y terminas de nuevo en el antiguo mundo de las cataratas con un tiempo 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 vista conocida (y estoy de acuerdo con ella por experiencia), que cuanta más gente agregue (cada una con sus propias debilidades) cuanto más tiempo lleve.

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

  

Dev Team (D): "¿Puede priorizar las funciones que desea que se entreguen, con las más importantes primero?"

     

Cliente (C): "Todo es prioridad 1: quiero que se terminen el mes próximo"

     

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

     

C: "¿Y si te doy más dinero?"

     

D: " suspiro ... incluso con más recursos, les tomará un mes comenzar realmente; así que si no está seguro de cómo priorizar las características solo nos dicen cuáles quieres que se hagan primero ".

     

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

Ahora puede comenzar a trabajar con las funciones en orden de prioridad. También es útil mirar con anticipación con su equipo a los elementos más bajos 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 orden de cosas por entregar.

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

A veces, a los clientes no les gusta que no obtengan lo que desean para una fecha determinada, PERO que entiendan por qué y lo que obtienen serán 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 aún está utilizando.

Las fechas límite se basan tradicionalmente en el ciclo de vida de la empresa. El software de impuestos debe estar listo para el 15 de abril. La presentación de informes para el próximo año fiscal podría tener que hacerse en julio.

El manifiesto ágil dice:

  

Personas e interacciones sobre procesos y herramientas

     

Software de trabajo sobre documentación completa

     

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

     

Respondiendo al cambio siguiendo un 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.

Las fechas límite no son ágiles, pero Agile puede darnos información sobre las fechas límite. Ágil nos deja saber si nuestra velocidad no nos permitirá establecer una fecha límite sin que se reduzca 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 hay características por cortar.

Lo mejor que puede hacer un equipo de Agile es dejar que su velocidad y el backlog priorizado impulsen los plazos. Esto le dará fechas estimadas de entrega. Si quedan fuera de la fecha límite, es hora de hablar seriamente con el cliente y determinar si la fecha límite es incluso factible.

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

Algunas personas parecen confundir ágil con el "salvaje oeste". Ágil no significa que todo vale. Ágil significa que dejamos de mentirnos acerca de qué tan bien puede estimar una persona razonable. Básicamente podemos estimar el desarrollo de software en un plazo de 2 a 4 semanas en el futuro. Más allá de eso, todo es un grado variable de swags y conjeturas. Peor aún, el costo de proporcionar estimaciones para las cosas más allá en el futuro se acerca al costo de solo hacer el trabajo. Por la razón que sea, los gerentes de proyecto históricamente no han estado dispuestos a admitir estas verdades absolutas ante los clientes. Agile simplemente ajusta ese pensamiento al afirmar que existe un límite en cuanto a qué tan bien podemos predecir el futuro en la ingeniería de software, y hace un cambio sutil a "estimación basada en evidencia" para el pronóstico a largo plazo. Al dar la entrega segura en porciones pequeñas, y la entrega basada en la evidencia para cosas a largo plazo, obtenemos algo parecido a lo mejor de ambos mundos: podemos ser sinceros acerca de lo que realmente somos capaces de estimar , y podemos proporcionar estimaciones bastante razonables de la entrega a largo plazo en el futuro en función de lo que hemos estado entregando hasta ahora.

TL; DR

  

¿Son las fechas límite [a] gile? ... [D] se ve que las líneas principales van de la mano con [a] gile development.

Es probable que muchas respuestas aquí se centren en los aspectos de ingeniería de la pregunta. En su lugar, 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 iterativos se basan en cajas 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 el proyecto tradicional plazos de gestión.

Todavía es posible realizar la planificación de lanzamientos con metodologías ágiles, pero los planes generalmente se basan en una estimación de la cantidad de iteraciones requeridas para cumplir un objetivo en lugar de los objetivos de gestión establecidos por fiat. Esto no quiere decir que no se puedan establecer las fechas de envío o que no se puedan cumplir los objetivos, pero la manera de definirlos y cumplirlos es bastante diferente a la de las metodologías tradicionales de gestión de proyectos.

Pensar en cajas de tiempo, no en fechas límite

  

Sin embargo, todos los proyectos en los que he estado han insistido en establecer una fecha límite. Dado que Agile intenta centrarse en la planificación adaptable, la flexibilidad y el cambio; ¿Los plazos son ágiles?

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 time boxing y una cadencia sostenible de entrega.

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 se ajustará dentro del cuadro de tiempo sin desbordarlo, y luego se "hace" o "no se hace" cuando el cuadro de tiempo expira. Una vez que se ha ido, la caja de tiempo se ha ido para siempre; cualquier trabajo que no se realice debe volver a planificarse y volver a calcularse dentro de un nuevo cuadro de tiempo igualmente efímero basado en las necesidades actuales (más que históricas) del proyecto.

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

Planeación de la versión basada en cajas de tiempo

Quizás la única área en la que las personas tienen más dificultades para asignar procesos ágiles a los marcos tradicionales es la planificación de lanzamientos. La planificación de la versión a menudo implica entregas de alcance fijo o de fecha fija. En marcos ágiles, la planificación de lanzamientos generalmente se realiza a través de un proceso de estimación donde 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 las 20 iteraciones; el alcance de lo que se publica puede cambiar a lo largo de la vida del proyecto (como el alcance, las características y las prioridades pueden cambiar al comienzo de cada Sprint), pero las fechas objetivo de cada lanzamiento se fijan en el plan del proyecto. El equipo se esfuerza por ofrecer un incremento potencialmente despachable para cada Sprint, y la Definición de Realización incluye controles de calidad, como la integración continua, para garantizar que el proyecto se encuentre en un estado de liberación al final de cada Sprint.

Ocasionalmente, verá proyectos ágiles en los que el alcance es fijo, pero dado 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 para los equipos ágiles, especialmente los equipos sin experiencia, pero hay veces en que es el enfoque correcto.

Ver también

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

Piense en los plazos como un compromiso. El hecho de que el proyecto sea ágil no significa que no deba comprometerse a entregar determinadas características para una fecha determinada.

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

Imagine una empresa que anteriormente entregaba productos solo a pequeñas empresas y que acaba de firmar un contrato con una gran corporación. Esta gran corporación usa EDIFACT, y parece que el software de contabilidad actual que usa su compañía no maneja EDIFACT. Se le solicita que cree un complemento que haga eso, dado que contractualmente, su empresa debe estar lista para el 15 de abril ^th .

La agilidad significaría que los pasos intermedios se entregarán progresivamente y se basarán en la retroalimentación regular. Básicamente, mostrarás tu progreso a los contadores, y 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 tuvieron una gran idea que, pensaron, podría mejorar. sustancialmente la experiencia del usuario. Tres semanas después, parecía que no solo no lo mejora mucho, sino que también se traducirá en 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 de el 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 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 gustan las fechas límite para eso, especialmente porque los plazos de entrega se producen con mucha facilidad, pero todavía entiendo por qué muchas empresas lo hacen. No siempre es fácil ver que el proyecto está atrasado con respecto al cronograma al observar solo los sprints: un plazo no cumplido, en este contexto, puede ser un claro recordatorio de que algo está fuera de control y debe tratarse en este momento.

eXtreme Programming dice acerca de la planificación de lanzamientos:

  

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

Lo que parece justo. También afirma que

  

Nadie puede controlar las 4 variables. Cuando cambias uno, inadvertidamente haces 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 señaló en br3w5 , aumentar los recursos es una solución limitada. Probablemente pueda agregar un par de personas que ya formaban parte del equipo si se enviaran a otra parte. 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, lo que lleva muchas veces.

Entonces, con una calidad irreductible y recursos fijos: una fecha límite es una limitación de tiempo, significa que necesita adaptar el alcance. Y el uso de la agilidad le proporciona el medio para cumplir el plazo con el alcance más productivo posible. Sin embargo, generalmente puede garantizar que parte del alcance se realizará a tiempo. Esta es la parte en la que puede estimar con confianza su tiempo para ser limitado por debajo de la fecha límite. Por lo general, es algo que está muy cerca de lo que has hecho varias veces y 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.

Siguiendo un método de desarrollo de software, literalmente, sin compromisos, corresponde al llamado 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 rápido fracaso 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 un hecho natural.

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

Los plazos no son ágiles, son:

1) Cascada, y 2) Mal.

El software y los plazos no funcionan bien juntos y nunca lo han hecho. En muchos sentidos, los métodos Agile son una reacción al problema masivo de los plazos perdidos o el software que se abandonó cuando se hizo evidente que el plazo no podía cumplirse (como también los problemas presupuestarios).

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

La clave es que la fecha límite se convierte simplemente en una fecha de lanzamiento para la primera versión del software. Es posible que aún esté escrito en piedra (digamos, el software es para uso académico y DEBE ser utilizado al comienzo del plazo), pero lo que entregará no lo es. Usted tiene un producto viable mínimo que todos están muy seguros de poder entregarle para ese entonces, y tiene una carga de "me gustaría tener". En lugar de que todos levanten la mano cuando resulta que no se entregará la lista completa antes de la "fecha límite", se asegurará de que el MVP salga por la puerta y que muchos de los "les gustaría tener" como posible y luego evaluar el costo / beneficio del resto en ese momento.

¡Cualquiera que haya jugado a juegos de computadora por un período de tiempo sabe exactamente cómo funciona esto! Si la primera versión es compatible con los estándares beta, muchos jugadores están contentos, por lo que las expectativas de lo que significan "fechas límite firmes y reales" en la vida real son muy bajas.

Por lo tanto, los plazos no son ágiles, son remanentes de los días en que la gente pensaba que el software podí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 el software tiene sobre el hardware: es suave.

Agile trata de explotar esta suavidad al permitir que los objetivos se desarrollen y cambien a lo largo del proyecto de una manera que el diseño de un puente nunca podría hacer.

Responda "probablemente no"

El Project_management_triangle indica ese costo, tiempo y alcance (y también calidad) dependen unos de otros ("elige dos y obtén el tercero")

Un sprint de scrum elige tiempo fijo (es decir, 7 días = duración del sprint) y costo (es decir, presupuesto para 7 miembros del equipo) y estima el alcance (la cantidad de historias que se hará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 hacerlo. Prometo alcanzar la meta (sin violar la calidad = definición de hecho)

La administración profesional trata de definir el costo y el tiempo y, si es necesario, reduce el alcance si se cumple alguna fecha fija.

¿No puede responderse esto simple y directamente?

No los plazos no son ágiles.

El objetivo principal es construir todo lo que puedas de manera iterativa, aprendiendo y adaptándote a medida que avanzas.

Una fecha límite es "usted tiene que entregar x por y" que falla en ambos casos en el sentido de que está prometiendo un entregable fijo en una escala de tiempo predeterminada (donde ágil dice que no estamos seguros de lo que intentamos Entregar, y el aprendizaje de Agile nos enseña que incluso si sabemos que es muy difícil tener certeza sobre los plazos, o si 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 aborde la pregunta de "cómo abordamos los plazos en un contexto ágil" y hay una Mucho bien pensado sobre eso en las otras respuestas.

En mi opinión, una respuesta razonable a este último es que entregaremos incrementos de valor temprano y con frecuencia y veremos dónde nos encontramos en el momento oportuno, pero no hay una talla única para todos.

El grado de agilidad requerido en el trabajo de uno es inversamente proporcional a la altura de su posición en el organigrama.

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

Si, en los niveles de gestión, el jefe de pelo puntiagudo fue lo suficientemente ágil como para entender que el vencimiento de una fecha límite de la semana dará como resultado un mejor producto, o un código más limpio, más libre de errores y más apalancable para que la compañía (o la división) ahorra dos semanas en el futuro, ese es un plazo ágil.

Pero al igual que el interés propio ilustrado, en realidad no existe.