Cómo representar un proyecto ágil para personas enfocadas en cascada [cerrado]

Se le ha pedido a nuestro equipo que represente nuestros esfuerzos de desarrollo en un plan de proyecto. Nadie está descontento con nuestro trabajo o cuestiona nuestra capacidad de entrega, solo estamos participando en una convocatoria de TI para planes de proyectos. El problema es que somos un equipo ágil y no hemos pensado en nuestro trabajo en términos de un plan de proyecto formal.

Si bien tenemos una idea general de en qué estamos trabajando a continuación, no estamos 100% seguros hasta que planifiquemos una iteración. Hasta ahora, nuestro equipo ha operado en gran medida en el vacío y no se le ha exigido que presente nuestra metodología o métricas a terceros. Seguimos la mayoría de las prácticas expuestas en la programación extrema .

Celebramos reuniones de planificación trimestrales para tener una idea general de las historias en las que vamos a trabajar durante un trimestre. Dicho esto, nuestras historias están documentadas en tarjetas 3x5 y solo se estiman al comienzo de la iteración en la que se van a trabajar. Después de la estimación, documentamos la historia en Team Foundation Sever . Durante una iteración, adjuntamos código a las historias y marcamos las historias como completadas una vez finalizadas. A partir de estos datos, podemos generar gráficos de quemado y velocidad. Lo más importante es que conocemos nuestra velocidad promedio para una iteración que nos impide morder más de lo que podemos masticar.

No estoy buscando modificar la forma en que hacemos el desarrollo, pero quiero presentar nuestras actividades de desarrollo en un informe que alguien que solo esté familiarizado con la cascada entenderá. En ¿Qué aspecto tiene un plan de proyecto ágil? Kent McDonald hace un buen trabajo al establecer las diferencias entre los planes de proyecto ágil y de cascada. Él especifica las diferencias en las balas consumibles:

• Un plan de proyecto ágil está basado en características
• Un plan de proyecto ágil está organizado en iteraciones
• Un plan de proyecto ágil tiene diferentes niveles de detalle según el período de tiempo
• Un plan de proyecto ágil es propiedad del equipo

Poder explicar las diferencias es excelente, pero ¿cuál es la mejor manera de presentar los datos?

Muéstrales el manifiesto ágil a medias .

Definitivamente te dice de qué se trata el sistema Agile al compararlo con los métodos de cascada :

Individuos e interacciones sobre procesos y herramientas
y tenemos procesos y herramientas obligatorios para controlar cómo interactúan esos individuos (preferimos el término 'recursos')

Software de trabajo sobre documentación completa
siempre que ese software esté documentado exhaustivamente

Colaboración del cliente sobre la negociación del contrato
dentro de los límites de los contratos estrictos, por supuesto, y sujeto a un riguroso control de cambios

Responder al cambio después de seguir un plan,
siempre que exista un plan detallado para responder al cambio, y se siga con precisión

Tenía que hacer esto, una vez. El Equipo quería hacer Ágil, el Cliente quería (y entendió Ágil), un tercero externo (llamado "Auditores"), quería ver informes de Cascadas.

Una razón importante por la que pudimos mentir fue porque a la tercera parte en realidad no le importaba, solo querían marcar casillas. Si el Cliente estaba contento y el Equipo estaba contento, los "Auditores" difícilmente regresarían y mirarían los informes que les dimos, antes de marcar las casillas finales.

No haga esto si el tercero es importante y REALMENTE le importa que esté usando una cascada . Si los auditores saben que usted es ágil y simplemente no han actualizado sus documentos para apoyarlo, entonces puede mentir.

¿Qué haces? Mentira , pero mentira piadosa.

• Reformule las características, como requisito "Debe tener característica".
• Su trabajo es en iteraciones, las iteraciones generalmente duran X semanas, a un plan de cascada le gusta ver cosas generalmente en semanas, por lo que no es un gran problema. Puede etiquetar el final de cada iteración como un hito. Los hitos son una cascada. Las iteraciones tienden a tener un tema (o una epopeya asociada) para que pueda pegar el tema / título épico en el hito (por ejemplo, 21/11 Tener la GUI completa).
• Calcule su velocidad (a partir de sus tablas de quemado / aumento) y calcule cuánto tiempo representa, en promedio, un Punto de historia (al menos a su velocidad actual), esto le dará la duración de la tarea. A menudo son muy inexactos, pero serán significativos hasta cierto punto.
• Su plan tiene diferentes niveles de detalle según el período de tiempo, básicamente el mismo para la cascada. Es posible que un plan de cascada tenga diferentes detalles según la audiencia.

• Un plan ágil es propiedad del equipo. Un plan de cascada es propiedad del Project Manager. Probablemente ya tenga un Project Manager, y probablemente estén haciendo esta traducción . Deberían tomar posesión de este documento traducido y proteger al equipo de las dificultades que podrían llover sobre ellos debido a ello. Es el trabajo de un Gerente de Proyecto Agile o Waterfall proteger al equipo de las distracciones que les impedirán trabajar.

• Seguro que realmente no sabes lo que estás haciendo en la próxima iteración, pero sí sabes más o menos lo que estás haciendo. Tienes una idea de ello, y aún más dura la iteración después. (Escuché esto llamado Radar de iteración). Miente y di que lo haces. y cuando mientas entre dientes sobre la tarjeta de historia que no está en tu radar de iteración, y solo ponla en algún lugar. Espero que no tenga que enviar demasiadas actualizaciones sobre el plan del proyecto, o se darán cuenta de que no ha hecho lo que dijo que haría.

Básicamente esto es un dolor. La traducción será muchas horas de trabajo. Si tienes que hacerlo mucho, automatízalo.

La primera pregunta que debe hacerse es ¿qué quiere realmente el negocio? Algunas empresas están perfectamente felices de ver sprints ágiles representados / desglosados ​​en un diagrama de Gantt. Puede no tener sentido para cualquiera que realmente comprenda los sprints y pueda cambiar regularmente, pero es familiar para las personas que lo solicitan. Luego, junto con el diagrama de Gantt, presente el quemado, etc.

Hemos pasado por algo similar y eventualmente (si Agile está funcionando) se venderá solo (si no es así, ¿por qué lo estás haciendo?). La gente comienza a entender el "esfuerzo" y que cierto equipo puede "quemar" 40 puntos de esfuerzo en un sprint de 2 semanas y en realidad son bastante buenos en promedio para estimar esos puntos de esfuerzo. Una vez que vean los beneficios para ellos, venderán el proceso al resto del negocio por usted. Pero el punto principal es que nunca, nunca, puedes forzarlo a alguien, ya que simplemente se defenderá.