Realmente depende de cómo su equipo de hardware entregará artefactos útiles que su equipo de software pueda usar para desarrollar, y cómo los equipos están configurados para comunicarse entre sí.
Por lo general, encontrará que el equipo de hardware construirá un producto, lo llevará a una etapa de prototipo para probarlo, y solo entonces el equipo de software obtendrá algún tipo de documentación de requisitos del equipo de hardware. No es necesario decir que esta no es siempre la mejor manera de hacerlo, ya que el software generalmente se desarrolla muy tarde en el proceso, y generalmente no tiene más remedio que trabajar con una metodología basada en cascada. Por el lado positivo desde el punto de vista del equipo de hardware, si de repente necesitan cambiar algo, el equipo de software no necesitará modificar su software. El problema aquí, por supuesto, es que su tipo de hardware promedio necesita desarrollar productos de esta manera, y espera que cualquier cosa que lo beneficie con la ayuda del equipo de software.
Como alternativa, si su equipo de hardware está construyendo un producto y actualizando los requisitos de software a medida que avanzan, y aún mejor, si involucran al equipo de software desde el principio, ya que cada característica de hardware se está planificando y simulando, entonces tiene la oportunidad de equipo de software para trabajar de una manera mucho más ágil. Naturalmente con esto quiero decir que el equipo de hardware es el cliente, y le da al equipo de software una lista de problemas que deben resolverse en el software. El equipo de software puede discutir con sus clientes las prioridades relativas de cada requisito, y tan pronto como el prototipo de hardware esté listo, el software probablemente estará disponible en una versión de lanzamiento anticipado, y puede usarse para ayudar a probar el hardware. Si los requisitos cambian, es de esperar que el equipo de software tenga la agilidad para cambiar el software a medida que avanzan, y puede proporcionar comentarios anticipados al equipo de hardware antes de que el diseño del hardware se comprometa con el prototipo. El equipo de software también tiene acceso directo al cliente al principio del proyecto, lo que significa que pueden tener una mejor idea de lo que necesitan burlarse, y cómo hacerlo, mientras esperan que el hardware pruebe.
Siendo realistas, no encontrará una metodología ideal que simplemente se ajuste a las necesidades, y puedo garantizarle que tendrá que hacer muchos ajustes sin importar qué metodología elija adoptar o desarrollar. El problema real es que desea intentar que la sincronización entre los equipos sea fácil de administrar, y significa que necesita encontrar una manera de aumentar la cantidad de contacto y entrada entre los dos equipos lo antes posible en el proceso, incluso si parece "derrochador" o "contra-intuitivo" hacerlo. Este es un gran problema en la empresa con la que estoy trabajando actualmente. Nuestro "padre" europeo está luchando con este problema exacto, mientras que el equipo aquí en Oz parece ser capaz de mantener las cosas funcionando un poco mejor, y '