Cómo preparar un cronograma de Waterfall a Agile en el desarrollo de software

Programar el Producto Mínimo Viable (MVP) y los hitos de objetivos comerciales

Identifique el producto mínimo viable (MVP) que puede implementar para los usuarios finales (o un subconjunto de usuarios finales) que tenga sentido comercial. Al trabajar con el equipo, puede obtener un pronóstico (no un compromiso) de cuándo se puede lograr esto. Digamos que esto tomará 6 meses.

Sin embargo, tenga en cuenta que su equipo no tiene ninguna experiencia con el desarrollo ágil. Por lo tanto, tendrá que pronosticar esto de manera muy conservadora. Mi recomendación es que forme un equipo y ejecute al menos 3 sprints antes de que pueda tener una idea razonable de la velocidad que se puede usar para la previsión.

A partir de ahí, identifique los hitos de los objetivos comerciales que desea lograr hasta llegar a la versión 1.0 del software. Esto puede ser una meta trimestral, por ejemplo.

Estos objetivos comerciales son lo que programa desde una perspectiva de gestión de alto nivel, no fases funcionales.

Sin embargo, tenga en cuenta que aprenderá cosas sobre el producto de las partes interesadas que vean el código de trabajo al final de cada sprint, así como de los comentarios de los usuarios finales después de implementar el MVP. Además, el equipo de desarrollo aprenderá más sobre la tecnología cuanto más trabajen en ella. Y en base a todos estos comentarios, prepárese para revisar sus objetivos comerciales. Cuando llegue al final de esos dos años, la versión 1.0 puede verse muy diferente de cómo la visualiza hoy. Pero se garantiza que se ajustará mucho mejor al propósito.

No es la respuesta simple. No hay fases. Ya se supone que el proyecto es de dos años. Esto es incorrecto, solo debes reconocer que tienes 2 años de presupuesto para financiar un proyecto.

Los equipos ágiles de scrum programan 5 cosas: standups, planificaciones, revisiones, retrospectivas e iteraciones. Puede programar un equipo Scrum con iteraciones de 2 semanas para tener alrededor de 50 iteraciones durante 2 años.

Siendo realistas, el cronograma del proyecto es desconocido para usted. Financiar el equipo que trabajará en el proyecto. Suponiendo que se trata de un equipo scrum, el propietario del producto, trabajando directamente con el cliente, es responsable de generar la acumulación de productos y priorizarla. Esto dará como resultado una hoja de ruta inicial del producto que identifica en qué orden se entregarán iterativamente al cliente características valiosas para el negocio. La hoja de ruta inicial no le dirá la duración del proyecto.

Como se mencionó en otra publicación, financie la operación del equipo durante alrededor de 3 iteraciones para establecer una velocidad inicial. Usando la velocidad del equipo, es posible comenzar a generar un pronóstico muy aproximado de la duración del proyecto, suponiendo que la cartera de pedidos esté completamente desarrollada y que todos los elementos se calculen aproximadamente. En este caso, si el pronóstico es de +/- 6 meses de los 2 años de presupuesto, eso es bastante saludable. Si no es así, esta es su primera pista de que es hora de comenzar a hacer algo de gestión de expectativas o mitigación de riesgos. Aquí es cuando las partes interesadas ágiles también aprenden que los "programas" de proyectos ágiles son documentos vivos que deben cambiar con frecuencia.

Este es el "calendario" del proyecto. Ahora debe comunicar el orden y el momento aproximado en el que el equipo cree que puede ofrecer valor.

Este "horario" Agile no es un compromiso. Es un pronóstico y el cliente/las partes interesadas deben comprender los supuestos y la variabilidad del pronóstico.

El concepto de un cronograma de proyecto Waterfall se ha ido, ya que no es realista pensar que un plan de 2 años se materializará según lo planeado dentro de dos años.

La entrega iterativa, los ciclos de retroalimentación más pequeños y la construcción de la confianza del cliente reemplazan el cronograma del proyecto en equipos verdaderamente ágiles.

"¡Pero espera! ¡Mis dos años se basan en un acuerdo fijo de alcance/presupuesto con el cliente!" Es hora de reconocer el riesgo de que el resto de su organización siga operando con una mentalidad de cascada y la fricción entre las dos metodologías probablemente producirá resultados mediocres.

Para que las metodologías ágiles como scrum brinden el máximo beneficio, deben adoptarse en toda la organización, no solo a nivel del equipo de entrega.