¿Son ágiles los plazos?

100

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.

stevebot
fuente
36
¿No es como sprint una fecha límite?
JeffO
12
@JeffO a Sprint es un compromiso, que cambia según la velocidad de su equipo. Los plazos son IMO, compromisos sin honestidad o transparencia para el cliente. No tienen en cuenta la velocidad o la multitud de otros riesgos que intervienen en la realización de proyectos de software.
stevebot
8
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 previsto. 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.
Calphool
8
Aquí está la fecha límite de Ron Jeffries (uno de los autores originales del Manifiesto Ágil): xprogramming.com/articles/jatmakingthedate
Julio
44
Algunos de mis plazos han demostrado ser bastante ágiles.
psr

Respuestas:

147

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.

Eric King
fuente
10
@stevebot Esa es exactamente la situación que provoca la Ley de Parkinson. Nunca he conocido a un cliente que no pueda pensar en más funciones para agregar. Sin plazos, la lista de características, y por lo tanto el proyecto, es infinita.
Eric King
12
@stevebot Creo que nos entendemos, pero tenemos diferentes significados de la palabra "fecha límite". Para mí, una "fecha límite" es una fecha específica. Para usted, una "fecha límite" es un conjunto específico de características prometidas en una fecha específica. Creo que mi definición es el uso más común, y mi respuesta se basa en esa definición. A juzgar por las otras respuestas que has recibido, otros están de acuerdo conmigo. Tómalo como quieras, no me ofenderé. :-) Pero mi respuesta sigue en pie.
Eric King
55
"Siempre habrá expectativas y siempre es posible que la velocidad de tu equipo te haga perder las características más básicas". Si está implementando Agile correctamente, entonces esa afirmación es absurda. Su backlog DEBE tener prioridad según el valor máximo para el cliente. Si no es así, POR CUALQUIER MOTIVO , entonces no estás practicando ágilmente. Estás practicando algo más.
Calphool
77
"Tenemos que enviar algo antes del 28 de julio". La fecha límite en esta oración es el 28 de julio. Puede hacer que el "algo" sea un conjunto predeterminado de requisitos, o puede ser lo que esté listo. La parte de "algo" no es la fecha límite. La fecha es la fecha límite.
Eric King
55
@stevebot "(La respuesta) engaña al lector a creer que Agile + Deadlines = perfectamente bien". Ese es el punto, sin embargo. Agile está perfectamente bien con los plazos. O sin. Elige tu opción. Decir lo contrario es básicamente decir "Bueno, ya que tenemos una fecha límite, ¡no podemos hacer este proyecto tan ágil!" Que es una tontería. He trabajado en muchos proyectos que han tenido plazos y han sido "ágiles". ¿Son ágiles los plazos? Bueno, no lo son no ágil.
Eric King
24

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.


fuente
2
Estoy de acuerdo con usted, aunque cambiaría la importancia de sus dos afirmaciones. # 1 Agile se centra principalmente en asegurarse de que la versión actual del software sea útil y desplegable. # 2 En segundo lugar, nos ayuda a darnos cuenta cuando el alcance es completamente irracional antes para que los propietarios de productos puedan volver a priorizar y mantener el objetivo del n. ° 1.
Calphool
2
@ user40980 Esto es horrible. Sí, hay cosas que tienen una fecha firme. sin embargo, no puede producir una cantidad infinita de trabajo en un tiempo finito. Los plazos no pueden ser ágiles, excepto cuando solo se producen después de la estimación. Esa es una advertencia extremadamente importante. Es por eso que planifica un sprint, para determinar exactamente qué trabajo se puede completar. Una fecha límite fija y dura en la que todo debe estar completo a pesar del esfuerzo NUNCA puede ser ágil.
EKW
18

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.

Encaitar
fuente
13

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,

Perros
fuente
11

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.

br3w5
fuente
77
"Entonces, 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". Absolutamente.
Eric King
Esta es probablemente la respuesta más ágil aquí. El hecho de que no tenga muchos votos es un testimonio de lo ampliamente mal entendido que es ágil.
PostCodeism
10

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.

stevebot
fuente
1
A veces, debe realizar el envío antes de una fecha determinada, no negociable (fecha límite). En ese caso, lo mejor que puede hacer un equipo ágil es dejar que la fecha límite impulse su trabajo atrasado, dando el conjunto de características estimado en la fecha límite. Si este conjunto de características estimado no cumple con los requisitos del cliente, entonces es hora de una conversación seria con el cliente y determinar si el proyecto es factible.
Eric King
@EricKing sí, tienes razón, Agile puede trabajar con plazos, creo que he estado leyendo tus declaraciones como "los plazos son ágiles" en lugar de "Agile trabaja con plazos".
stevebot
Gracias por tu comentario. Creo que ambos hemos estado hablando el uno al otro por un tiempo, y tal vez solo se necesita un cierto enunciado para hacer que las cosas hagan clic. No he tenido la intención de decir "las ofertas son ágiles", pero puedo ver cómo se vería de esa manera. Lo siento por eso.
Eric King
6

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.

Calphool
fuente
Por cierto, Cal, estoy bastante de acuerdo con todo lo que estás diciendo aquí. y no creo que contradiga lo que escribí.
robert bristow-johnson
5

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

CodeGnome
fuente
... más o menos ... pero con el tiempo es mejor que el equipo se centre en lograr que el trabajo se adapte bien a esos "cuadros de tiempo". Si solo acepta que sus cuadros de tiempo y su trabajo completado no están relacionados, entonces está haciendo codificación de vaquero, y es completamente impredecible. Diría que tal vez comience como "cajas de tiempo" y con el tiempo se convierta en una fecha límite algo no negociable a medida que el equipo mejora al predecir cuánto trabajo pueden manejar en un sprint. Se trata de un autoaprendizaje en equipo para ser excelente en la estimación a corto plazo, porque de ahí proviene la previsibilidad.
Calphool
4

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.

Arseni Mourzenko
fuente
Gracias, pero ¿por qué la regularidad de los sprints no evita totalmente este riesgo? Además, me gusta su ejemplo de los Juegos Olímpicos, pero creo que un requisito es ese alcance y costo y no está limitado. Si puse un desarrollador en ese proyecto y se me pidió que entregara todas las funciones, la fecha límite realmente no ayudaría y probablemente nos llevaría a entregar un producto de muy baja calidad.
stevebot
La regularidad de los sprints no evita el riesgo porque es relativamente fácil para un gerente engañar a las partes interesadas para que piensen que el proyecto va bien. Cosas como "No implementamos esto porque has puesto énfasis en esas dos cosas durante nuestra última reunión" o "Dos de nuestros desarrolladores están de vacaciones, así que solo hicimos la mitad del trabajo durante este sprint". son difíciles de discutir para las partes interesadas, y en cada detalle del sprint, pueden perder la imagen general del proyecto.
Arseni Mourzenko
entonces tiene un problema con la transparencia y poner una fecha límite en la parte superior no ayudará. Esas excusas también se lanzarán fácilmente en la fecha límite y esto es casi siempre lo que veo que sucede en la vida real.
stevebot
1

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.

Juh_
fuente
0

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.


fuente
-1

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.

Nagora
fuente
3
No tengo idea de por qué la gente te rechazó. He estado haciendo desarrollo de aplicaciones ágil / xp durante más de 10 años en una compañía Fortune 100, lo introduje aquí de hecho, y no veo absolutamente nada de malo en lo que dijiste. Te volví a votar a cero, porque quien te rechazó tiene que ser un novato ágil que todavía se aferra a su vieja realidad porque Dios sabe qué razón. La gente es demasiado simplista. Piensan que "el software y los plazos no funcionan bien juntos" es un absoluto. Tu objetivo es alcanzar CADA fecha límite de sprint. Simplemente no mientes sobre tu capacidad para alcanzar fechas estimadas de largo alcance. Es así de simple.
Calphool
77
@Calphool Tengo problemas para decir que los plazos son en cascada (existen sin importar qué metodología se use, incluso existen para los codificadores de vaqueros) y son incorrectos (existen debido a limitaciones externas de tiempo, no más incorrectos que "tenemos que tener esto código ejecutado en ese hardware con un rendimiento mínimo "). Es una limitación de tiempo en lo que es una solución aceptable. La presentación de impuestos antes del 15 de abril es una fecha límite. Tener el software para el distribuidor antes del 1 de noviembre para que pueda estar en los estantes antes del 27 de noviembre es una fecha límite. Ninguno de estos está mal.
44
@MichaelT: Si aún no lo ha hecho, le sugiero que lea el libro de Tom y Mary Poppendiecks "Desarrollo líder de software Lean: los resultados no son el punto". Simplemente está transmitiendo un meme bastante popular en círculos magros / ágiles. Si usted y su equipo se centran en los plazos más de lo que se centran en la mejora continua, en realidad no están viviendo ágilmente. Puede que estés haciendo scrum, pero no viviendo ágilmente. ¿Existen plazos a largo plazo? Obviamente. ¿Son en lo que deberían enfocarse los equipos ágiles? Absolutamente no. Los plazos son incidentales para el pensamiento ágil.
Calphool
44
@MichaelT El OP se refirió a los plazos de los proyectos y eso es a lo que estoy respondiendo: plazos a largo plazo establecidos por un primer ministro al comienzo de un proyecto en lugar de un sprint. Ciertamente, hay plazos de una especie ágiles, pero tienen una naturaleza muy diferente a lo que la gente suele decir con los plazos de los proyectos, pero tal vez sea la semántica el problema aquí.
Nagora
3
@Ellesedil: dígame cuál es su característica más importante, o su conjunto mínimo de características comercializables, deme unas semanas o unos meses para construir un historial con su conjunto de características deseado (varía según cuánto solicite, toma más tiempo predecir cuánto tiempo llevará llegar a la luna vs. Pittsburgh). Entonces te lo diré, y dado que mi estimación se basó en entregas reales de software útil , podremos contar con la estimación, a diferencia del cuento de hadas que me estás obligando a darte desde el principio.
Calphool
-1

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.

k3b
fuente
-1

¿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.

Murph
fuente
-2

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.

robert bristow-johnson
fuente
55
Una fecha límite que se puede mover no es una fecha límite. Eso se llama una fecha calendario. Las fechas límite son cosas como el Black Friday, ya sea en la tienda o no. Aún así, Agile significa que tengo lo mejor que puedo tener para esa fecha límite.
MSalters
entonces, si no cumple con ese plazo, pero está en la tienda la semana siguiente, ¿siempre muere el fabricante? faltar ese plazo incurre en costo. pero, ¿qué pasa si ese costo es más que compensado con un mejor producto, que impresiona más a los clientes con su primera impresión ( "nunca tiene una segunda oportunidad de causar una primera impresión" ) y tiene otros beneficios que exceden ese costo? si la administración es lo suficientemente inteligente como para tomar una decisión táctica de diferir la liberación (es superar el plazo, no abandonarlo) en beneficio de los clientes y el fabricante, ¿no es eso "ágil"?
robert bristow-johnson
¿Alguna vez ha tenido fechas límite para el Black Friday con Walmart? La sensación que tuve fue que si te equivocaste este año, no tendrás una segunda oportunidad el próximo año. Eso es literalmente "no hay segunda oportunidad".
MSalters
3
escucho el código en el área de instrumentos de audio y música. ciertamente el producto tiene que salir por la puerta para ganar dinero con él. pero los plazos de entrega literalmente han provocado que una basura mal desarrollada salga por la puerta con la que los clientes, la compañía y los futuros desarrolladores se vieron obligados a vivir durante años.
robert bristow-johnson
55
Lo que sucede con las ventas del Black Friday es que es un intento de marketing para crear una falsa escasez de tiempo y producto con el fin de lograr que las personas se comporten de manera irracional y compren cosas que de otro modo no harían. Este ejemplo de comportamiento irracional inducido no parece ser tan diferente de algunos enfoques para la gestión de proyectos de software. Al argumentar que crear escasez falsa de tiempo con el software no es una buena idea, no estoy diciendo que la escasez real de tiempo sea imposible porque obviamente lo son en algunos contextos (y son cruciales en eso).
shuttle87