Ágil: picos y la línea de tiempo general

El equipo está comenzando su primer proyecto Agile de capital A, y parece que el proyecto se alineará muy bien con la metodología (es decir, probablemente solo podamos tomar un libro ágil y seguirlo como una receta), con un poco de confusión:

El proyecto involucra tres cosas con las que nadie en el equipo tiene experiencia: Integrarse con el Sistema de Nómina Foo, ser capaz de manejar el tipo de archivo XYZ89 (donde "XYZ89" = algún tipo de archivo del que nunca haya oído hablar) y convertir algunos otros archivos para que puedan ser manejados por el Frobnobdicator.

Según tengo entendido, la práctica estándar de Agile sería programar picos para cada uno de estos, después de lo cual podemos determinar cuánto tiempo van a tomar (no estoy seguro de que haya muchas posibilidades de que el cliente decida no hacerlo). ellos, ya que son requisitos bastante sólidos del proyecto)

Entonces mis preguntas son:

¿Hacemos todos los picos por adelantado en la primera iteración para obtener una mejor estimación del tiempo que llevará hacerlos y / o poner en marcha un "esqueleto ambulante"?
Si no es así, ¿no estaría el cronograma total del proyecto a merced de que uno de estos picos regrese con datos de que esta historia en particular tomará más tiempo de lo que planeamos?

¿Cuál es la mejor forma de manejar múltiples picos cuando son básicamente requisitos no negociables de un proyecto?

agile

Respuestas:

La forma en que he manejado estas incógnitas sombrías en mi plan de proyecto antes es intentar configurar el tiempo para que el equipo de desarrollo haga prototipos de la funcionalidad desconocida de antemano. Esto brinda el beneficio de dar a conocer claramente lo que se requerirá para realizar las tareas especializadas, demuestra que son técnicamente factibles y educa al resto del equipo sobre las posibles dificultades que deben evitarse cuando comience el desarrollo activo.

Esta es la razón por la cual muchos proyectos ágiles generalmente comienzan con un, lo que me gusta llamar, Sprint 0 .

Piense en ello como atar sus zapatos para correr, estirarse y ponerse vendas en los pezones justo antes de comenzar un maratón. Este tiempo se puede usar para hacer la planificación inicial del proyecto y la creación de la historia del usuario, el diseño y la implementación de la arquitectura, la creación del marco de software y los desarrolladores pueden trabajar en cualquier prototipo y prueba de conceptos para cualquier tecnología nueva o desafíos técnicos desconocidos que harán que la historia del usuario sea un punto Estimación mucho más fácil.

— árbol de arce
fuente

¡Las vendas en los pezones son una necesidad absoluta! ¡Y también lo es Sprint 0 para todos menos los proyectos más triviales y de menor riesgo!

— Michael

Debería hacer las cosas en el orden de prioridad establecido por el propietario del producto (o cliente). No tiene sentido suicidarse por algo que fue realmente agradable de tener. La idea es que si se acaba el tiempo y no se hace algo, deberían ser los elementos de menor prioridad.

Si no priorizan lo que quieren, tendrás dificultades.

Si las cosas son relativamente iguales, no comience con el elemento más difícil: comience con una victoria fácil, lo que le dará al equipo la oportunidad de acostumbrarse a trabajar juntos utilizando la nueva metodología y al cliente cierta confianza en que pueden entregar cosas de esta manera. Una vez que se haya establecido, afronta algo difícil. Mida la complejidad del elemento difícil contra la complejidad de las cosas más fáciles que acaba de hacer, y comenzará a tener una idea de cuánto tiempo puede llevar superarlo.

Los elementos complejos no son realmente "picos". Son simplemente cosas que requieren más esfuerzo para darse cuenta. Divídalos en tareas más simples tanto como sea posible.

— Matthew Flynn
fuente

Creo que en este caso tienen que ser picos, porque nadie en el equipo ha trabajado nunca con el sistema Foo Payroll, los archivos XYZ89 o el Frobnobdicator antes. No tenemos idea de cuánto tiempo llevará la integración con esos sistemas.

@ Jordania: entiendo eso, pero si basa sus estimaciones en un modelo de complejidad, en lugar de un modelo por hora, puede controlar lo que va a tomar. Sí, tiene una curva de aprendizaje en formatos de archivo y API, un poco más de complejidad. Sí, tienes que trabajar con la gente de Nómina, un poco más de complejidad. Eso puede significar que solo puede trabajar en uno de esos elementos y nada más en una iteración.

— Matthew Flynn

Recomiendo ver las Historias de usuario de Mike Cohn aplicadas ( amazon.com/User-Stories-Applied-Software-Development/dp/… )

— Matthew Flynn

Claro, entiendo el valor de estimar en términos de complejidad relativa en lugar de horas. La parte que me confunde es que si este enfoque fuera correcto para la situación que describí, parecería que los picos nunca se usarían en ningún proyecto (los desarrolladores solo dirían "eh, eso parece un 3, esto parece un 5 ", a pesar de que nadie sabe nada sobre la integración con el sistema Fizzbot)

Bueno, mi esperanza es que si nadie sabe sobre Fizzbot, dirían que parece más un 13 o un 21, y luego desglosan las tareas: 1. Aprende algo sobre Fizzbot. 2. Construya acceso básico a Fizzbot. 3. Maletín modelo para uso real de Fizzbot. 4. Construir pruebas de integración. 5. Construye una verdadera integración de Fizzbot ... Ya sabes, divide las piezas en cosas que sean comprensibles y con un poco de tamaño.

— Matthew Flynn

Una posible solución es crear una tarea para hacer una prueba de concepto para descubrir cómo resolver el problema y cronometrarlo, luego agregar esa historia a un sprint con otras historias.

Todavía está entregando valor y un producto al final del sprint, incluso si se trata de una aplicación de consola pirateada. La idea es que no estás hundiendo la productividad de todo el equipo, si te quedas sin tiempo, agregas otra tarea similar al próximo sprint.

— Bob el conserje
fuente