Scrum para el desarrollo de hardware: adaptar el marco
Scrum fue desarrollado en el contexto del desarrollo de software. El desarrollo de hardware viola varias de sus suposiciones implícitas: los componentes tienen plazos de aprovisionamiento, los entornos de prueba tardan días en configurarse, un prototipo no puede completarse en dos semanas. Sin embargo, equipos de hardware en empresas como Saab, BMW, Boston Scientific y John Deere han adaptado Scrum con éxito. La clave es entender qué se transfiere directamente, qué requiere adaptación y qué es mejor dejar de lado.
Adaptar la duración del sprint
El sprint de dos semanas estándar en el desarrollo de software es a menudo impracticable para el trabajo de hardware. Un ciclo de construcción-prueba para un prototipo físico puede requerir de tres a seis semanas. La Guía Scrum no exige sprints de dos semanas -- especifica sprints de un mes o menos. Los equipos de hardware típicamente usan sprints de tres a seis semanas, calibrados a su ciclo real de construcción-prueba.
Definición de Terminado específica para hardware
La Definición de Terminado debe reflejar las realidades físicas del área: archivos de diseño actualizados en el sistema de control de versiones, lista de materiales reconciliada, prototipo construido según especificaciones, pruebas completadas y resultados documentados, modos de fallo revisados, verificaciones de conformidad pertinentes completadas. La trampa a evitar: una DoD tan ambiciosa que solo pueda alcanzarse al final de todo el programa de desarrollo.
Lo que funciona sin cambios
La planificación de sprint: la disciplina de seleccionar un alcance acotado y comprometerse con él como equipo.
El Daily Scrum: quince minutos son suficientes; las mismas tres preguntas; el ritmo construye cohesión interfuncional.
La retrospectiva de sprint: a menudo citada como uno de los elementos más valiosos por los equipos de hardware.
La autoridad del Product Owner: una sola persona con autoridad para priorizar el backlog elimina la dinámica de aprobación comité por comité.
Qué evitar
El error más frecuente es forzar las duraciones de sprint de software sobre el trabajo de hardware. Un sprint de dos semanas que no puede producir un incremento significativo de hardware probado no es un sprint -- es una actualización de estado quincenal con sobrecarga de proceso adicional. Si el equipo no puede producir algo demostrablemente diferente al final de dos semanas, la duración del sprint debe ajustarse.
XNM Consulting ayuda a las organizaciones de ingeniería y desarrollo de productos a implementar prácticas ágiles y Scrum adaptadas a su contexto.