¿Tarde tiene algún significado en las metodologías ágiles?

Esto surgió de algunas de las respuestas y comentarios sobre otra pregunta ( esta ).

He trabajado principalmente con proyectos en cascada y, aunque he trabajado en proyectos ad-hoc que han asumido comportamientos ágiles y he leído bastante sobre ágil, diría que nunca he trabajado en un proyecto ágil "adecuado" .

Mi pregunta es si el concepto de "tarde" tiene algún significado en ágil, si es así, ¿qué?

Mi razonamiento es que con Agile no tienes un plan inicial y no tienes requisitos detallados desde el principio. Es posible que tenga un objetivo de alto nivel en mente y una fecha teórica adjunta, pero ambos pueden cambiar (potencialmente masivamente) y ninguno es seguro.

Entonces, si no sabe exactamente qué va a entregar básicamente hasta que lo entregue y el usuario lo acepte, y si no tiene un horario más allá del próximo sprint, ¿cómo podría llegar tarde de alguna manera que en realidad tiene significado?

(Obviamente, entiendo que un sprint podría extenderse, pero estoy hablando más allá de eso).

Solo para que quede claro, estoy (personalmente) contento con la suposición de que a tiempo los proyectos en cascada (incluso los relativamente grandes) son posibles debido al hecho de que los he visto y he estado involucrado en ellos; no son fáciles ni comunes, incluso Pero son posibles.

No se trata de dejar de actuar, se trata de que yo lo entienda. Siempre he visto el beneficio de lo ágil como nada que ver con plazos o presupuestos (o más bien solo indirectamente), tiene que ver con el alcance: lo ágil se acerca más a lo que es realmente importante que a lo que el equipo del proyecto piensa que es importante antes de que ellos ' He visto algo.

No estoy de acuerdo con que un proyecto ágil no tenga un plan inicial.

Mi experiencia es que los analistas de negocios han pasado bastante tiempo trabajando en reuniones de diseño con clientes y desarrolladores para elaborar una lista detallada de los requisitos alcanzables que se presentan como historias de usuarios. Estos se dividen en tareas con estimaciones adecuadas adjuntas por desarrolladores experimentados.

Una vez que se han identificado las tareas más importantes al comienzo del sprint / iteración, puede comenzar la codificación. Este proceso de selección determina el significado de la iteración en el proyecto general ("Estamos construyendo el proceso de inicio de sesión"). Varios miembros del equipo continúan con las diversas tareas necesarias para hacer realidad esa historia de usuario.

Al final de la iteración, todas las historias de usuario para esa iteración deben estar completas, o llega tarde . Del mismo modo, el desarrollo debería poder detenerse al final de cada iteración y el producto lanzado. Puede que no esté completo en términos de todas las historias de usuario, pero las historias de usuario que se solicitaron en la iteración están completas y el producto puede funcionar hasta esos límites.

"tarde" en una metodología ágil significa lo mismo que significa en una metodología en cascada: las estimaciones estaban equivocadas, el alcance era demasiado grande para el tiempo asignado, aparecieron dificultades inesperadas, el cliente no respondió lo suficiente, los programadores se volvieron flojos, las máquinas se cayeron, tu perro se comió mi código de bytes, etc.

aprendes de él y te ajustas para la próxima iteración

la diferencia es que esto puede suceder cada 2-4 semanas, por lo que las lecciones se aprenden y el proceso se ajusta rápidamente

Sí, pero solo tomará 1 mes saber que no alcanzará su fecha de vencimiento del proyecto final mítico de 9 meses en lugar de 9.

Su razonamiento se basa en el supuesto de que son posibles planes iniciales y requisitos detallados para grandes proyectos. No estoy seguro de que haya mucha evidencia para apoyar eso. ¿Quizás todas las historias de terror son simplemente anecdóticas? A cualquier desarrollador le encantaría trabajar con especificaciones completas y nunca cambiantes con las que el cliente esté totalmente de acuerdo y comprenda.

Cada vez que haces un compromiso de algún tipo, corres el riesgo de llegar tarde. Eso se aplica a ágil también.

Pero sabemos que no puede predecir el futuro, y sabemos que el cliente cambiará constantemente de opinión, y estamos de acuerdo en que es algo bueno. Si aceptamos eso, también debemos aceptar que todos los compromisos son casi siempre incorrectos, lo que, a su vez, hace que la pregunta sobre la tardanza sea fácil de responder: siempre estamos equivocados ( demasiado pronto o demasiado tarde). Todo es cuestión de conjeturas, no importa cuán bien pulido. Tirar una moneda.

Esto es algo que nosotros, como desarrolladores, simplemente debemos aceptar y, desde ese punto de vista, tratar de encontrar otra forma de trabajar, una forma en la que el problema de la tardanza sea mucho menos importante. Un cambio de perspectiva. Creo que la forma de hacerlo es enfocarse en entregar software de trabajo lo antes posible, con la opción de dejarlo cuando el cliente esté satisfecho.

Y de eso se trata Agile. Una forma inteligente de manejar esta incómoda noción de que la tardanza es un hecho y simplemente tenemos que lidiar con eso lo mejor que podamos.

Por ejemplo, llega tarde cuando no cumple con los compromisos que hizo al comienzo de la iteración actual. Esto se espera y debe aprender de esto y adaptar su proceso para que sea menos probable que falle en la próxima iteración. La mejor manera de manejar esto es mantener las iteraciones lo más pequeñas posible.

Para la planificación de iteraciones múltiples, también conocida como planificación de lanzamiento, utiliza la velocidad calculada a partir de las iteraciones completadas y extrapola los datos para predecir una fecha de lanzamiento futura. Recomiendo James Shores' artículo o mi propia (más corto) para más detalles sobre esto. Sin embargo, tenga en cuenta que nunca es un compromiso sólido y más de un "estamos 80% seguros de que completaremos las próximas funciones para esa fecha". Esto puede (en cierto modo) resultar en que llegue tarde, pero el compromiso es solo una probabilidad, no un hecho.

Ahora empareje esto con la promesa básica de agile de que siempre debe estar listo para lanzar software de trabajo, característica completa o no. Esto le da al cliente la libertad de detener el desarrollo cuando cree que el sistema es lo suficientemente bueno, lo que puede suceder mucho antes de lo previsto. También alienta a llevar el proyecto en nuevas direcciones basadas en comentarios reales de la última iteración.

Los puntos anteriores deberían ser más que suficientes para que cualquier cliente tenga el control total del desarrollo, y espero que responda la pregunta sobre la tardanza en los métodos ágiles.

Hay dos tipos de "tarde" en Agile SCRUM>

1. Traspaso: las historias no se "hacen" al final de un sprint, los desarrolladores se "comprometen" a hacer un PBI, por lo que cuando no se hace, se puede considerar llevar.

2. Hoja de ruta: suponiendo que su organización tenga una hoja de ruta y suponiendo que tenga fechas, si se pierden los entregables principales para esas fechas, eso puede considerarse "tardío".