Proyecto de desarrollo de productos de larga duración.

Antecedentes: tenemos un proyecto de desarrollo de productos de larga duración, que consta de diferentes características. El equipo de desarrollo consta de 15 desarrolladores y 5 ingenieros de control de calidad. Configuramos lanzamientos cada 5-7 meses. En cada versión, agregamos nuevas características o mejoramos/características existentes. Cada lanzamiento consta de 6-8 sprints de desarrollo (3 semanas cada uno) y 2-3 sprints de estabilización/corrección de errores puros.

Problema: Algunas de las características tardan varios meses o más en completar el desarrollo para estar en el nivel mínimo de entrega o etapa lista para producción. Los dividimos en tareas pequeñas y avanzamos en su desarrollo en cada sprint, pero está listo para la primera demostración solo después de 2-4 sprints y listo para control de calidad/producción después de 5-8 sprints. Esas características son complejas y generalmente consisten en desarrollar infraestructura nueva o mejorada, núcleo/servicios, lógica comercial, interfaz de usuario, Web y luego integración en monitoreo, informes, impresión, marketing, etc. Antes de que todo esté listo, la característica no puede considerarse como completa ( producción lista). Por otro lado, en la misma versión, tenemos pequeñas funciones o mejoras que son mucho más pequeñas y pueden estar listas para la producción en uno o dos sprints...

Pregunta: ¿Alguna idea/consejo sobre cuál podría ser un mejor enfoque si quisiéramos acortar nuestros lanzamientos?

Gracias pavel

Respuestas (6)

Lo que creo que está sucediendo es que está llamando sprints al esfuerzo de desarrollo y luego tiene "sprints" para el control de calidad.

Creo que está utilizando un modelo en cascada en lugar de un modelo incremental. Intentaría diseccionar las tareas en backlog al tamaño mínimo y en cada sprint integrar el control de calidad, para que no espere hasta el sprint 5 a 8 para probar y regrese con las 2-3 semanas o sprints para la estabilización.

Al final de cada sprint, debe tener historiales de trabajo desarrollados y probados, luego, con una estrategia de administración de la configuración, puede implementar esa funcionalidad nueva o modificada en el entorno de estado y, después de la UAT, puede implementarla en el sistema en vivo, de modo que el sistema tenga nueva funcionalidad cada sprint, y al final de los "sprints" de desarrollo y prueba

Creo que está malinterpretando el ciclo de vida "sprint" y SCRUM con el ciclo de vida tradicional.

+1 por la nota sobre el "modelo en cascada". De hecho, el proceso explicado parece una microcascada, en lugar de incremental e iterativo.
+1 definitivamente suena más "cascada" u onda rodante que Agile, lo cual está bien dadas las restricciones y cómo está definiendo el lanzamiento.
Estoy de acuerdo en que no estamos trabajando con una metodología ágil, pero tratamos de usarla como guía y tratamos de avanzar sin problemas. La pregunta se planteó exactamente debido al hecho de que no podemos crear pequeños fragmentos de trabajo listos para la producción, ya que requiere mucho más tiempo del que cabe en una única iteración. No queremos desarrollarlo por separado y luego integrarlo en la rama principal, ya que queremos usar nueva infraestructura que se agrega en cada sprint y podemos ver/demostrar el progreso como un todo y no en ramas separadas que requerirán pruebas para cada una de ellas. .

Creo que la respuesta aquí puede ser una buena herramienta. No sé qué tipo de solución utiliza para el control de versiones, pero creo que cambiar al Sistema de control de versiones distribuido podría ayudar. El principal cambio de mentalidad con el uso de DVCS es que no fusiona todo en un tronco, que tiene que estabilizar antes de pasar a la producción, pero puede agregar diferentes funciones en una versión basándose en la base de código distribuido.

Muchos equipos Kanban se enfrentan al mismo problema, aunque en menor escala y DVCS demostró ser una solución bastante buena.

ACTUALIZACIÓN (basado en un comentario): con DVCS cambia la mentalidad con respecto al trabajo con troncales/sucursales. Lea la introducción de Joel Spolsky a DVCS . También puede consultar el tutorial Mercurial de Joel para familiarizarse con DVCS.

Usamos SVN. No estoy familiarizado con ningún DVCS. De todos modos, la razón por la que no queremos dividirlo en diferentes troncos y luego fusionarlos se debe a 2 razones: 1 - En la rama principal, desarrollamos una infraestructura que podría usarse para la función de ejecución prolongada. 2 - Queremos ver/seguir/demostrar algún tipo de progreso para asegurarnos de que estamos en el camino correcto, incluso si no está listo para la producción. Hacer esto, en dos o incluso más baúles separados, lo hace bastante costoso. Además, cuando la(s) función(es) esté(n) lista(s) para ser integrada(s) a la rama principal, aún requerirá un sprint completo o más para probarlas, debido a la combinación compleja.
Con DVCS, cambia la mentalidad estándar de troncales/sucursales. Lo que haces es básicamente construir tus versiones a partir de partes elegidas del repositorio de código distribuido. Siempre que necesite una demostración de alguna función, puede crear una versión que la incluya. Difícil de describir en pocas palabras: ha leído el artículo de Joel Spolsky como introducción: joelonsoftware.com/items/2010/03/17.html Además, si necesita un buen comienzo, puede consultar el tutorial Mercurial de Joel hginit.com (Mercurial es uno de los mejores DVCS en estos días)

Creo que el problema es que el alcance no está elaborado correctamente. ¿Hay 15 desarrolladores, 5 probadores y ningún analista? ¿Quién está trabajando con la documentación/análisis del alcance?

Necesita a alguien en esta función de " análisis de sistemas ". Necesita a esta persona para dividir el alcance en partes mucho más pequeñas que ahora.

Tenemos analista, lo siento, no lo mencioné. Pero aún no ayuda definir el alcance "listo para producción" que se ajustará a un solo sprint. Lo dividimos en un mandril más pequeño, desafortunadamente no es suficiente para alentar a los clientes a implementar porque quieren que todo esté listo y completamente trabajado antes de que se activen o actualicen.

Comenzaría echando un vistazo a la ruta crítica de su ciclo de entrega.

Planifíquelo con las diferentes duraciones de cada fase y luego vea dónde puede condensar o secuenciar mejor sus actividades.

Tengo que estar de acuerdo con muchos de los comentarios aquí. Parece que estás iterando una estructura en cascada y confundiéndola con Agile. No hay problema con un proceso iterativo en cascada, y creo que puedes encontrar soluciones en la forma en que inicias cada ciclo. Si piensa en cada ciclo como un nuevo proyecto, puede notar que se ha perdido un poco de la metodología. Si no tiene analistas, debe obtener algunos como dijo yegor256. Además, este es un excelente entorno para que realice sesiones de lecciones aprendidas e implemente sugerencias de cambio.

Creo que Pawelbrodzinski brindó la mejor respuesta... pero parece que usted/su equipo es reacio a la rama de código... otro enfoque sería liberar los cambios, que funcionan o no, con cada sprint, haciéndolos solo alcanzables por ciertos roles de usuario o enlaces (por lo que la base de usuarios actual no puede acceder antes de la finalización)... esto podría significar tablas duplicadas (algunas con una nueva estructura para admitir la nueva funcionalidad) y enlaces duplicados (uno a la funcionalidad anterior y otro a la nueva funcionalidad)... no es una buena solución o una que seguiría yo mismo, sino otro enfoque

Proyecto de desarrollo de productos de larga duración.
RespuestasAquíPolítica de privacidad1y, 0v