¿Qué modelo de desarrollo de software ha funcionado mejor para los equipos de software con gran dependencia de los equipos de hardware?

Hay una serie de mejores prácticas competitivas para el desarrollo de software. Por lo que he encontrado, muchos equipos se han beneficiado de las prácticas ágiles en algunos casos. Sin embargo, en algunos otros casos, el uso del Proceso Unificado ha sido defendido por grandes empresas como IBM.

Los temas comunes que encuentro parecen funcionar bien para los equipos que desarrollan principalmente software.

Estoy interesado en saber qué ha funcionado mejor para las personas que han trabajado en tiendas donde hay un equipo al otro lado que produce el hardware en el que se ejecuta su software. Por ejemplo, un equipo arma una caja con varios equipos personalizados; mientras que necesitas desarrollar el software que funcionaría en esas cajas. No puedo encontrar un modelo de desarrollo (ágil, espiral ...) que funcione mejor en este caso.

Cualquier sabiduría es esta área será muy apreciada.

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 '

Probablemente soy parcial, ya que he trabajado más en el lado del hardware de los grandes equipos de desarrollo de productos de software y hardware. El hardware puede ser muy costoso de revisar si está diseñado o diseñado incorrectamente. A menudo, un error en el diseño del hardware es tan costoso que significa cancelar todo el proyecto. Arreglar un error de máscara de chip puede costar más que el salario anual de docenas de ingenieros. Entonces, veo que el objetivo principal del equipo de software para el primer 50% del ciclo de desarrollo es asegurarse de que el equipo de hardware no falle. Esto puede significar olvidar el código de la aplicación final y su diseño al principio, y solo trabajar en simulaciones de arquitectura y rendimiento de hardware, herramientas para ayudar al equipo de hardware a completar y verificar su diseño,

Espere ser ágil, no solo sobre las especificaciones del cliente, sino también sobre varias peculiaridades / errores sorprendentes en la plataforma de hardware, donde una solución de software puede tener mucho menos impacto en el cronograma que un giro de hardware.

Uno de los principales inquilinos de Agile es "fallar temprano". Con el hardware, esto no podría ser más cierto. El hardware de producción en masa es extremadamente costoso. Además, el hardware físico no puede simplemente "parchearse" como el software. Para exacerbar estos problemas, los equipos de hardware tienden a enfrentar menos al cliente que los equipos de software en la práctica, y tienden a estar acostumbrados al modelo de desarrollo "big bang".

Por estas razones, no detectar problemas de hardware tan pronto como sea posible es típicamente un orden de magnitud más costoso que no detectar problemas de software antes. Los clientes esperan requerir actualizaciones de software, pueden dejar de trabajar con usted por completo si tienen que lidiar con un retiro de hardware.

En resumen, no esperar y prepararse para problemas de hardware temprano es el mayor desafío de un modelo de desarrollo al desarrollar software y hardware en paralelo.

Absolutamente debes anticipar el fracaso. Obtenga un prototipo temprano. Usa el prototipo para desarrollar contra. Espere que sea un fracaso. Aprende del fracaso. Enjuague. Repetir. Asegúrese de que todos esperan que los prototipos de hardware sean revisados ​​/ criticados / rediseñados en función de los comentarios de las partes interesadas.