Las metodologías ágiles son quizá el marco de trabajo más extendido en las empresas y equipos de desarrollo de software a nivel mundial. Su simplicidad basada en equipos pequeños, la multi-fragmentación de problemas complejos, y su filosofía de entregables periódicos en forma de pequeñas unidades funcionales validadas hacen de la agilidad el marco ideal para aumentar la productividad manteniendo el énfasis en la calidad y el cliente.
En la otra cara de la moneda están las empresas de ingeniería, diseño y desarrollo de productos físicos, donde aún privan las metodologías en cascada y el marco de trabajo basado en los principios del Project Management Institute – PMBOK con gráficos de Gantt que ofrecen una estimación general del tiempo de desarrollo de los proyectos de hardware de principio a fin.
Pero en un mundo cada vez más competitivo y con escenarios globales cambiantes, las empresas de hardware deben adaptarse y crear plataformas de desarrollo que sean cada vez más flexibles y den respuesta al cambio minimizando el trauma organizacional. Es por eso que el interés en las metodologías ágiles comienza a crecer dentro del entorno del desarrollo de hardware como una opción para absorber la incertidumbre a medida que el desarrollo avanza en medio de demandas cambiantes, para acercar más el producto final al cliente y para controlar los avances con un enfoque menos generalista e incierto y más específico y predecible desde los costos.
Sin embargo, aunque ya existe un marco de referencia “ágil” para el desarrollo de hardware, la experiencia muestra que existen algunas barreras propias, no comunes con la industria software, que son difíciles de sortear. En mi experiencia estas son algunas de las más importantes:
- La validación. Antes de hacer el release de un pequeño módulo de SW es necesario testearlo como una unidad funcional. Esto funciona muy bien porque el testing de software está mucho estandarizado pero en el hardware existen interrelaciones funcionales, formales e incluso ergonómicas que demandan validaciones/ensayos de distinta índole: simulaciones estructurales, tolerancias de ajuste con ensambles vecinos, validaciones en campo, entre otras. Por este motivo la definición de entregable funcional de hardware tiene un significado diferente, siendo este quizá un prototipo donde fue posible verificar solo aquellas funciones no dependientes de otros módulos, y algunas otras aisladas de carácter ergonómico o formal. La interdependencia física por tanto debe ser tomada en cuenta en la planificación de los sprints para dividir el desarrollo en varios sprints de desarrollo incremental con entregables parcialmente funcionales.
- El costo del cambio. Como una regla de la mano derecha en el desarrollo de hardware, a mayor avance en el proyecto mayor costo del cambio. Esto hace que las metodologías ágiles resulten muy bien en los primeros sprints donde herramientas como la impresión 3D, corte láser o moldeo de resinas permiten tener una aproximación muy cercana a mecanismos o ensambles de baja complejidad. Pero a medida que los sprints entregan mayor complejidad, el costo de fabricación de prototipos y/o de cualquier modificación respecto al diseño previo crece exponencialmente, al igual que se incrementan los tiempos de manufactura. Así, para evitar sorpresas en los costos finales, el entorno de trabajo ágil debe contemplar la naturaleza propia del ciclo de vida de los productos físicos y llevar un estricto control de la cantidad de cambios que pueden incorporarse en etapas maduras del desarrollo.
- La especialización del equipo. Los equipos ágiles de SW se caracterizan por su gran versatilidad y un cierto grado de intercambiabilidad de sus miembros para el desarrollo de las tareas técnicas. Esto se debe a la estandarización de las buenas prácticas en la arquitectura y el coding. Incluso, existen prácticas como el pair-programming que buscan romper la dependencia de alguno de los miembros del equipo. En los equipos de hardware la especificidad técnica es un factor que juega en contra a la hora de redireccionar tareas, pues las áreas del conocimiento son más amplias y varían según el caso. Así, por ejemplo, un diseñador experto en manufactura CNC no podría ser fácilmente sustituible por otro diseñador que se especialice solo en procesos de chapa metálica, o un experto en simulación CFD probablemente no sea el más adecuado para un análisis de vibraciones.
- El tiempo. Pocas veces un Gantt logra predecir el tiempo de desarrollo de un proyecto complejo… o lo predice con un alto grado de incertidumbre, aún con el comodín de los escenarios optimistas y pesimistas. Bajo las metodologías ágiles, el proyecto es controlado al detalle en el corto plazo y proyectado hacia adelante en función de la velocidad promedio que desarrolle el equipo en los primeros sprints, y de la densidad del backlog de tareas a desarrollar, que son responsabilidad del Product Owner y que se irá haciendo más nítida a medida que avanza el proyecto. Renunciar a la sensación de control que da el Gantt es uno de los grandes cambios en el mindset corporativo.
La incursión de la agilidad en las empresas de hardware está ocurriendo de manera más lenta y progresiva de lo que ocurrió en su momento con el software. Es indiscutible su valor como marco de trabajo y como potenciador del desempeño de los equipos, pero así como cada industria es específica, es necesario llevar a cabo pequeñas adaptaciones específicas por parte del los implementadores si se quiere sacar máximo provecho de sus herramientas.