Nuestro equipo está compuesto por ingenieros de software y hardware. El equipo de software utiliza la gestión de proyectos Scrum, mientras que el equipo de hardware utiliza la cascada.
La prioridad de nuestros requisitos de software cambia con bastante frecuencia, por lo que mantenernos ágiles tiene sentido para nosotros. La prioridad de nuestros requisitos de hardware es bastante estática y de movimiento lento, por lo que, de nuevo, seguir con la cascada tiene sentido para nosotros.
La parte difícil es la integración de hardware y software. ¿Existen metodologías para sincronizar de forma determinista estos dos estilos contrastantes de gestión de proyectos?
He trabajado en DO-178B durante algún tiempo, y lo que solíamos hacer era tener hitos designados donde los equipos de software y hardware se integrarían y obtendrían comentarios preliminares (identificar desviaciones de requisitos, nuevos requisitos, etc.). Sin embargo, estamos buscando metodologías que incorporen circuitos de retroalimentación más estrictos.
TL;DR Deberías usar Scrum en ambos equipos.
seguir con la cascada tiene sentido para nosotros
No hay ningún beneficio en tener un equipo de hardware haciendo cascada en absoluto. De hecho, se aplica a cualquier equipo. La elección entre él y los métodos ágiles no es una simple prioridad de requisitos. ¿Por qué se apegaría a un proceso con largos plazos de entrega, grandes gastos generales y poco tiempo de comercialización si puede evitarlo?
lo que solíamos hacer era tener hitos designados donde los equipos de software y hardware se integrarían
En Scrum, el equipo produce incrementos de trabajo y potencialmente entregables de un producto de forma regular. Cuando tienes dos equipos que ejecutan Sprint en paralelo, su definición combinada de hecho también debe cubrir la integración.
El final de cada sprint es un hito del que estás hablando. Si la salida combinada satisface la definición de hecho, está sincronizado.
Sin embargo, estamos buscando metodologías que incorporen circuitos de retroalimentación más estrictos.
Más razones para deshacerse por completo de la cascada :) ¿No le gustaría que su equipo de hardware entregue algo de valor en un mes en lugar de en un año?
Además, tiene sentido usar la misma metodología en todos sus proyectos; esto, al menos, simplificará el aprendizaje. Podría usar cualquier otro enfoque ágil con el equipo de hardware, pero esta diversidad no le servirá de nada.
Convertir su equipo de hardware a Scrum sin duda ayudará. Sin embargo, como dijo Steve McConnell:
...si acepta una sola metodología al 100 por ciento, verá el mundo entero en términos de esa metodología. En algunos casos, perderá oportunidades de utilizar otros métodos más adecuados para su problema actual.
Así que supongamos que la cascada funciona bien para su proyecto de hardware y solo necesita sincronizar los dos.
Recomendaría usar el plan de lanzamiento como punto de dependencia. Al igual que Apple anuncia el lanzamiento de un nuevo iPhone, su equipo de hardware debe anunciar un nuevo lanzamiento de hardware. En tu caso tienes la suerte de conocer la lista de características de antemano.
El equipo de software, a su vez, debe planificar los lanzamientos en consecuencia. Tener 1-2 Sprints de reserva para realizar, si el lanzamiento del equipo de hardware se retrasa.
Tomas Owens
mal