Guía Scrum en Hardware

Nuestro CEO Fabian Schwartz, es cocreador de la Guía Scrum en Hardware, aquí encontrarás un resumen sobre la misma.

Propósito

Está guía tiene como propósito principal definir Scrum en el desarrollo de Hardware; con practicas técnicas especificas y modelos para alcanzar lanzamientos rápidos e iteraciones cortas. Cualquier compañía puede hacer uso de esta Guía y confirmar que su implementación de Scrum en el desarrollo de hardware vaya por el camino correcto, así como también los pasos claros para mejorar su uso. Este documento se refiere a Scrum como está definido en la Guía Scrum (www.ScrumGuides.org) sin ningún tipo de cambio ó modificación.

Scrum en Hardware

Los proyectos ágiles tiene como enfoque el lanzamiento continuo y temprano, así como también el aprovechamiento del cambio como una ventaja para el cliente, incluso en últimas instancias. ¿Cómo podríamos posiblemente permitirnos hacer lo mismo en el desarrollo de hardware?. Esta guía esta compuesta completamente por proyectos de producción y prácticas de equipos, incluidas industrias con reglamentos muy estrictos, y puede ser usada para estructuras organizacionales ó restructuraciones.

Incertidumbre en proyectos de hardware

Los proyectos de hardware involucran más costos materiales y tienden a tener más costos retrospectivos y costos de cambio. Estos, normalmente aumentan durante el ciclo de vida del proyecto y se relacionan de manera inversa con la incertidumbre del proyecto. Los costos son reducidos para realizar cambios, incluso en las últimas instancias de desarrollo; por medio de modularidad, el uso de herramientas flexibles de producción en masa, pocos materiales que son compatibles con las mejores y más flexibles herramientas disponibles, y diseños minimalistas (elegantes).

Stubs y maquetas

Los prototipos ayudan a los equipos a tener un entendimiento general del producto final, manejo de interfaces y evaluar supuestos. Usando un primer borrador de las interfaces de producción pretendidas con prototipos, lo más temprano posible en el proceso, maximiza el aprendizaje y minimiza el riesgo. Recomendamos a los equipos construir stubs de cada modulo que puedan ser conectados durante el primer Sprint.

Modularizar

El producto final debe ser capaz de ser producido en una semana. Esto nos permite una evaluación semanal por parte de cualquiera de las partes involucradas en el proceso, incluyendo los funcionarios de cumplimiento, para reducir el riesgo. Lo anterior, deprecia la necesidad de dividir un proyecto de hardware en etapas ó fases para la reducción de riesgo. En los casos en donde la tecnología para hacer esto aún no exista ni en un equipo, podemos realizar una división por módulos que ponen en cuarentena áreas de largo plazo, complejas ó altamente reguladas. La manera de dividir un proyecto de hardware, “rebanarlo”, es importante. Debe ser posible para los equipos poder evaluar supuestos dentro de su propio modulo sin tener que depender de los demás equipos. Por ejemplo, evaluar la resistencia del viento en la parte exterior de un vehículo funciona mejor cuando solo un equipo trabaja en la parte exterior. Los módulos también pueden ser utilizados para separar las áreas con tiempos de evaluación y ciclos de certificación mas largos, de esta manera las demás áreas pueden ser iteradas y aprobadas más rápido.

Integración continua

Solamente podemos enviar un modulo en el momento en el que haya pasado todas las pruebas y haya sido conectado con los demás módulos de nuestro sistema. Así como los proyectos de software se agilizan por medio de la automatización de la integración, los equipos de desarrollo de hardware tendrían ventajas muy grandes en velocidad si de igual manera realizan la automatización de la integración de lo que múltiples equipos produzcan. Esto significa robots automatizados, ó puede significar también un equipo flexible de manualidades listo para ensamblar la producción de varios equipos y llevarlo a ejecución por medio de una lista de chequeo de las pruebas de integración.

Diseño de la interface

Las interfaces deben ser diseñadas de manera que sean reutilizables. Las interfaces frágiles ó muy elaboradas, con muchos pasos para conectar ó desconectar desmotiva el experimento. Además, deben ser planeadas con al menos el 10% de la capacidad que se necesita. Lo anterior, aumenta el tamaño y peso de los límites entre módulos, y así mismo la velocidad de iteraciones del sistema en general aumenta. Esto nos permite compensar dicho aumento en peso y tamaño mediante la construcción en nuestro espacio, para el crecimiento de nuestro producto terminado, que es el más costoso de cambiar.

Desarrollo impulsado por pruebas y datos

El desarrollo debe ser diseñado de manera que sea posible evaluar supuestos (desarrollo impulsado por pruebas). Los casos de prueba de hardware pueden ser escritos; mediante loT y datos de tecnología de sensores, casi todos los comportamientos de las partes del hardware pueden ser medidos y deberían ser usados para implementar mejora continua.

Equipo

Los miembros del equipo deben poder colaborar, ser co-localizados y emparejados al menos por cada modulo. Los equipos más rápidos que observamos tienen pruebas claras por pasar, una retroalimentación rápida para la validación de nuevas ideas en contra de las pruebas, y están dispuestos a trabajar de manera colaboradora y fuera de su campo de experticia.
Producto funcionando al final de cada Sprint

La prueba definitiva de que Scrum funciona en el desarrollo de hardware es tener un producto que funcione al final de cada Sprint.

Desarrollado por:

Joe Justice, es presidente de Scrum Inc, fundador y CEO del equipo WIKISPEED. El trabajo de Joe incluye colaboraciones con Bosch, Microsoft, Toyota, Amazon, 3M, Ford, Boston Scientific, QuintilesIMS, Chevrolet, MIT, HP Labs y el fundador de Xerox Park entre otros; teniendo como fin la entrega de productos y servicios en Sprints de una semana ó menos.

Fabian Schwartz, fundador y CEO de Scrum Network.

William Newing, fundador de Pink Cherry Blossom, firma de consultoría y Product Owner de WIKISPEED en Lynwood, WA. Fabrica en los Estados Unidos.

Chris Wallace es un entrenador profesional en Scrum, consultor y Product Owner de WIKISPEED en Burleson, TX. Fabrica en los Estados Unidos.

Mary Michael Justice es la Scrum Master en WIKISPEED. Ensambló el primer equipo Scrum en la compañía, y removió impedimentos para construir velocidad y felicidad desde el nivel más alto de la administración.

Original en ingles publicado en: https://www.scruminc.com/scrum-in-hardware-guide/

Aprende en este video cuáles son las claves para aplicar Scrum en hardware