¿Alguien está usando metodologías Agile Project Management para el desarrollo de productos de hardware? ¿Cómo lo implementaste? ¿Desde qué sistema hizo la transición? ¿Con qué problemas te encontraste?

Answer 1

No utiliza exactamente las metodologías ágiles en el desarrollo de hardware. Déjame ver si puedo explicar un poco. En la mayoría de los casos, a diferencia de SW donde puede desarrollar y administrar cambios pequeños / menores a la vez, crear sprints de duración relativamente corta, es realmente difícil hacer lo mismo en HW. HW está más desarrollado característica por característica y se realiza un seguimiento continuo para ver si se ha logrado suficiente progreso ya que los horarios basados ​​en sprint no son realistas en la implementación de HW. Se hará todo lo posible para identificar las piezas más pequeñas de hardware funcional que se puedan entregar, esto no siempre es posible. En la mayoría de los casos, el equipo se reúne regularmente, verifica si están en el objetivo, realiza revisiones de progreso e identifica y elimina los cuellos de botella. Como puede ver, no es exactamente una cascada (donde se espera que construya todo el HW a la vez) ni Agile.

Además, en realidad, siempre tiene 3 equipos (HW, Embedded y SW) trabajando en paralelo o ligeramente superpuestos y cada uno de estos tres tiene que ser administrado de manera diferente dada la naturaleza de sus tareas y sus dependencias de otros equipos.

Brevemente, esto es lo que hago para los sistemas que diseño. Una vez que tengo el diseño del sistema y particiono en función de la funcionalidad, las interfaces, etc., exploro cuáles son las mejores metodologías para rastrear e implementar. Si hay subsistemas claramente definidos en SW que no dependen de HW o Embedded, trato de administrarlo con Agile. Muchas veces, SW se puede desarrollar mucho más adelante que HW o incrustado e intento asegurarme de que el SW funcione y luego incrustar, etc. para que pueda aislar los problemas una vez que todo el sistema esté integrado. Embebido es a menudo específico para HW o dispositivo bajo selección, por lo que tienen una dependencia para esperar hasta que se desarrollen los módulos HW particulares. A veces podemos usar emuladores o placas de desarrollo para hacer que el desarrollo integrado sea independiente del programa de desarrollo de hardware y, cuando sea posible, intento usar Agile en cierta medida o metodologías híbridas.

Avíseme si tiene alguna pregunta específica o tiene alguna otra duda.

Answer 2

Actualizar. Desde que respondimos a esta pregunta, hemos ayudado a dos grandes fabricantes de equipos grandes a adoptar Scrum para hardware. En una línea de productos, redujeron un ciclo de actualización de productos de 2 a 3 años a 1 año. Pasaron de ser una de las plantas más caras al productor menos costoso. La gerencia cree que el nuevo producto es probablemente el mejor que jamás hayan construido. Están vendiendo esa versión ahora, así que están empezando a aprender lo que piensa el mercado.

El desarrollo de productos de hardware puro usando Agile está sucediendo ahora. Cuando se hizo esta pregunta, ya había un creciente conocimiento del trabajo que WIKISPEED estaba haciendo para construir un automóvil de 100 mpg usando Scrum, prácticas técnicas de programación extremas y arquitectura orientada a objetos. Desde entonces, un número creciente de empresas está adoptando Agile en sus ferreterías. Las compañías buenas en Agile in Hardware se envían cada semana. Combinan el pensamiento Lean con el pensamiento ágil.

Implemente Scrum como lo haría en una organización de software. El resto lo debes averiguar por su contexto. La diferencia clave entre Agile y Lean es que Agile enfatiza la reducción del costo del cambio, por lo que las mejoras en el producto y el proceso pueden ocurrir fácilmente. Aquí es donde debe ser creativo con cosas como líneas reconfigurables, impresión 3D, etc.

Answer 3

No entraré mucho en la aplicación de técnicas ágiles en el diseño de hardware a nivel de PCB. Históricamente, no creo que esto haya funcionado en absoluto, pero tal vez en tiempos más recientes se han realizado adaptaciones a Agile que proporcionan algún beneficio para el diseño de hardware.

Sin embargo, recientemente me di cuenta del uso de técnicas ágiles aplicadas al desarrollo del código de aplicación FPGA (HDL, como Verilog / SystemVerilog & VHDL).

La diferencia entre el “hardware” y el “desarrollo de FPGA (HDL)” es muy ilustrativa de dónde Agile puede ser útil, y de lo contrario potencialmente lleno de frustración y estrés para aquellos desarrolladores de hardware que se gestionan a través de un método Agile.

Para los ingenieros electrónicos que diseñan hardware a nivel de placa, presionar el ‘botón Compilar’ es un proceso que puede llevar semanas, desde la producción de la documentación de fabricación que luego se envía a (normalmente) fabricantes de PCB de terceros y ensambladores de PCB, devueltos al diseñador para preparación y prueba, completando un ciclo. Obviamente, tales ingenieros tienen que hacer otras cosas mientras esperan que se complete ese proceso sin intervención antes de volver a los resultados de su “presionar el botón de compilación” hace semanas. “Presionar el botón de compilación” en el diseño de hardware a nivel de PCB también suele costar mucho dinero. No es algo que uno haga frívolamente, es poco probable que se realice prácticamente cualquier otro proceso de desarrollo de software / firmware donde los resultados se obtienen generalmente en segundos o minutos, y luego se pueden probar.

Sin embargo, los diseñadores de aplicaciones FPGA, y particularmente aquellos centrados también en pruebas y verificación formal, tienen una realidad mucho más parecida a la del software para vivir, donde no solo las tareas se pueden dividir en subtareas mucho más manejables que pueden tomar solo horas o días de tiempo de desarrollo, pero también se les aplicaron procesos de prueba y verificación coincidentes (ya sea por sí mismos u otros ingenieros). En este mundo, las iteraciones de “compilación” (también conocida como síntesis lógica) y la realización de la verificación formal, pueden llevar de minutos a horas (para cada módulo pequeño), y permiten que Agile se aplique de la manera típica.

Answer 4

El hecho de que los métodos ágiles se aplican cada vez más en casi todos los segmentos de una industria, el PMI-ACP parece cada vez más relevante en el escenario comercial actual.

Waterfall entrega el producto al final, generalmente en 6 a 18 meses, mientras que ágil produce pequeñas iteraciones de software de calidad de producción, ¡generalmente cada 2-4 semanas !, se lo demuestra al cliente y se adapta a los comentarios del producto. Una vez que el producto tiene características mínimas comercializables, los clientes lanzan al mercado, es decir, un tiempo de comercialización (TTM) más corto que produce un mejor retorno de la inversión (ROI)

En cascada, el Gerente de Proyecto elabora todo el plan y realiza el trabajo por equipo. En agile, el equipo se autogestiona, es decir, el equipo realiza la estimación, el compromiso del cliente, la planificación, la programación, la asignación de recursos, la ejecución, el monitoreo, el control y la gestión del cliente. En consecuencia, el rol del gerente del proyecto se transforma en proporcionar infraestructura, administrar partes interesadas externas y eliminar impedimentos del equipo. En resumen, tenemos un equipo capacitado y motivado.

¡Agile cree que los documentos de Just Barely Good Enough (JBGE), es decir, la historia de usuario de una línea como requisito y el código como documento de diseño vivo! En cambio, los enfoques ágiles se centran en las prácticas de ingeniería de software (como programación de pares, desarrollo basado en pruebas, automatización de pruebas e integración continua), propiedad de código colectivo, comunicación informal y colaboración continua con el cliente.

Aquí hay algunos artículos que le ayudarán a comprender la metodología ágil. Los encontré muy útiles. Espero que sea de gran ayuda para ti también.

Los 3 principales métodos de desarrollo de software ágil
¿Qué es ágil?
Bloques de construcción ágiles