Su navegador no soporta JavaScript.
  • LinkedIn
  • YouTube
  • RSS

El Scrum en la Guía de Hardware

Propósito del Scrum en la Guía de Hardware

Esta guía sirve para definir Scrum en Hardware con prácticas y patrones técnicos específicos para lograr lanzamientos rápidos e iteraciones cortas en Hardware. Esta guía es un documento vivo que evolucionará en función de los comentarios de la comunidad y del aprendizaje sobre el terreno. Cualquier empresa puede utilizar esta guía y confirmar su implementación en Scrum en Hardware junto con pasos claros para hacerlo mejor. Este documento se refiere al Scrum tal y como se define en el Guía Scrum sin adaptación ni modificación.

Los proyectos ágiles se centran en la publicación temprana y frecuente, y en aprovechar el cambio en beneficio del cliente, incluso en fases avanzadas del desarrollo. ¿Cómo podríamos permitirnos hacer esto en hardware? Esta guía se compone en su totalidad de proyectos de producción y prácticas de equipo, incluidas industrias altamente reguladas, y puede utilizarse para la estructuración o reestructuración de la organización.

Incertidumbre en los proyectos de hardware

Los proyectos de hardware implican más costes materiales y tienden a tener un mayor riesgo de costes irrecuperables y costes de cambio. Estos aumentan durante el ciclo de vida del proyecto y guardan una relación inversa con la incertidumbre del mismo. Reducimos el coste del cambio, incluso en fases avanzadas del desarrollo, gracias a la modularidad, la flexibilidad del utillaje de producción en serie, el uso de pocos materiales compatibles con el utillaje más rápido y flexible disponible y el diseño minimalista (elegante).
Uncertainty in Hardware Projects

Recortes y maquetas

Plane diagram stubs and mock-up use in Scrum in Hardware
Los prototipos ayudan al equipo a adquirir una comprensión global del producto, manejar interfaces y probar supuestos. Utilizar el primer borrador de las interfaces de la intención de producción con prototipos lo antes posible maximiza el aprendizaje y minimiza el riesgo. Recomendamos a los equipos que construyan stubs de cada módulo que se conectará en el sprint uno.

Modularice

El producto final debe poder fabricarse en una semana. Esto permite una revisión semanal por parte de cualquier parte interesada y de los responsables de cumplimiento para reducir el riesgo, lo que deprecia la necesidad de dividir un proyecto de hardware en fases para reducir el riesgo. En los casos en que la tecnología para hacerlo no exista todavía ni en equipo, podemos dividirlo en módulos que pongan en cuarentena las áreas de largo plazo, complejas o muy reguladas. La forma de dividir un proyecto de hardware "en rodajas" es importante. Cada equipo debe poder probar las hipótesis sobre su módulo sin depender de otros equipos. Por ejemplo, probar la resistencia al viento del exterior de un coche funciona mejor cuando sólo un equipo posee y trabaja en el exterior. Los módulos también pueden utilizarse para separar las áreas con los ciclos de prueba y certificación más largos, de modo que otras áreas puedan iterarse y aprobarse más rápidamente.
modular hardware development scrum in hardware

Integrar continuamente

continuous integration scrum in hardware manufacturing facility
Sólo podemos enviar un módulo si supera todas las pruebas después de conectarlo a todos los demás módulos de nuestro sistema. Al igual que los proyectos de software se aceleran automatizando la integración, los equipos de hardware tienen enormes ventajas de velocidad si también automatizan la integración de lo que producen varios equipos. Esto significa probablemente robots automatizados, y puede significar un equipo flexible de artesanos listos para conectar los productos de varios equipos y ejecutarlos a través de una lista preparada de pruebas de integración.

Diseño de interfaces

Las interfaces deben diseñarse de forma reutilizable. Las interfaces frágiles o elaboradas con muchos pasos para conectarse o desconectarse desalientan la experimentación. Además, deben planificarse con una capacidad al menos 10 veces superior a la necesaria. Esto añade peso y tamaño en la frontera entre módulos. A cambio, aumenta la velocidad de iteración de todo el sistema. Esto nos permite compensar con creces este aumento de peso y tamaño al tiempo que creamos espacio para el crecimiento en nuestro producto final, que es el más caro de cambiar.
nterface Design in Scrum in Hardware

Pruebas y desarrollo basado en datos

El desarrollo debe diseñarse de forma que se comprueben los supuestos (desarrollo basado en pruebas). Pueden escribirse casos de prueba de hardware. Con Internet de las Cosas (IoT) y la tecnología de sensores, pueden medirse datos sobre casi todos los comportamientos de las piezas de hardware, que deben utilizarse para mejorar continuamente.

Equipo

Los miembros del equipo deben colaborar, compartir ubicación y formar parejas al menos por módulo. Los equipos más rápidos que observamos tienen pruebas claras que superar, un bucle de retroalimentación muy rápido para validar las nuevas ideas en función de esas pruebas y están dispuestos a trabajar en colaboración y fuera de su especialidad.

Producto de trabajo al final de cada sprint

La prueba definitiva de tener Scrum en el trabajo de Hardware es si se tiene un producto que funcione al final de cada Sprint.

Sobre los autores

Joe Justice es el fundador y CEO de Team WIKSIPEED. El trabajo de Joe incluye la colaboración con Bosch, Microsoft, Amazon, 3M, Ford, Boston Scientific, QuintilesIMS, Chevrolet, MIT, HP Labs, el fundador de Xerox PARC, entre cientos de otros, para lanzar productos y servicios en sprints de una semana o menos.

Equipo WIKISPEED es un fabricante internacional de automóviles homologados para circular por carretera con operaciones en 23 países y un ciclo de introducción de nuevos modelos de 1 semana; código abierto, productos de construcción colaborativa, como los automóviles homologados para circular por carretera, al igual que los editores de Wikipedia actualizan artículos.

Fabián Schwartz es fundador de ScrumColombia.org, CEO de CASMENA Executive Development y de SBS Management Consultants.

William Newing es el fundador de la consultora Pink Cherry Blossom y Product Owner de la fábrica WIKISPEED Lynnwood, WA, EE.UU.

Chris Wallace es un profesional Scrum Coach, Consultor, y Product Owner de la fábrica WIKISPEED Burleson, TX, EE.UU..

Mary Michael Justicia es el Scrum Master de WIKSIPEED corporativo, reunió al primer equipo Scrum de la empresa, y elimina los impedimentos a la felicidad o la velocidad desde el nivel de alta dirección.

Este documento es copyright 2017 Joe Justice. Se puede utilizar en cualquier lugar sin modificaciones.

6 Comentarios

  1. ismaine Ayouaz
    ismaine Ayouaz en 10/15/2019 en 2:29 pm

    Hola a todos,

    ¿Qué pasa con Agile y Scrum para el equipo de infraestructura y sistemas. cómo implementar una transformación ágil para este tipo de equipos y cómo utilizar mejor Scrum? ¿algún retorno de experiencia para compartir?

    Respuesta
  3. Karin
    Karin en 4/23/2018 en 8:38 am

    Hola :),
    Soy coach ágil de desarrollo de software.
    Ahora empiezo un nuevo proyecto como coach ágil para el desarrollo de hardware.
    Quiero prepararme lo mejor posible. Tiene alguna sugerencia de libros relacionados con Scrum en el desarrollo de hardware?
    Muchas gracias.

    Respuesta

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

es_ARSpanish
en_USEnglish fr_FRFrench es_ARSpanish