El proceso de desarrollo de productos de ingeniería mecánica tiene fallas que se presentan a cualquier ingeniero que haya participado en este flujo de trabajo. Podemos atascarnos haciendo cambios de último minuto en un producto cuando se agregan nuevas funciones. Puede ser difícil rastrear exactamente cuánto progreso se está logrando entre entregables ampliamente espaciados. Encontrar tareas para cada miembro del equipo a lo largo de todo el proyecto puede ser difícil. Aceptamos estos defectos en el proceso de diseño como estándar, pero ¿podría haber una mejor manera?
El desarrollo ágil ha existido en el proceso de producción de software durante muchos años. Reimagina el flujo de producción convencional para productos, basando su metodología en entregas frecuentes, equipos interfuncionales y planificación centrada en plazos estrictos en lugar de especificaciones estrictas. En un contexto más amplio, Agile es una filosofía que se puede aplicar a todos los aspectos de la producción. Adoptar el cambio y establecer bucles de retroalimentación iterativos es el núcleo de las construcciones de Agile.
En el proceso de creación y programación de software, Agile se desarrolló para permitir que los equipos administren y trabajen juntos fácilmente, mientras administran un alcance y una lista de resultados constantemente cambiantes para cada producto. Esta ideología funciona bien para el mundo del software digital y en constante cambio, pero ¿cómo se traduce en el mundo muy divergente del desarrollo de productos de ingeniería?
Cómo Agile se adapta al desarrollo de productos
Agile se divide en diferentes metodologías y procesos que mantienen la naturaleza iterativa y fluida de la técnica en su núcleo. La metodología principal utilizada, especialmente en el desarrollo de ingeniería, es un proceso llamado Scrum.
Scrum toma un proyecto y lo divide en ciclos regulares denominados Sprints. Los sprints generalmente duran entre 1 y 2 semanas e involucran equipos funcionales de 5 a 9 personas. Cada sprint abarca algún segmento de trabajo que el equipo en general ha acordado realizar. Los equipos que trabajan juntos en cada sprint son generalmente multifuncionales y autogestionados. Toman una determinada tarea que se ha establecido en el product backlog (cartera de pedidos del producto), similar a una lista de objetivos para el producto, y lo llevan a una fase de entrega. Un aspecto crucial de Scrum es que cada sprint termina en algún tipo de entrega, ya sea una idea formulada, una simulación útil o un componente completamente diseñado. Esto permite bucles de retroalimentación iterativos en el proceso de diseño y evita que se avance en la dirección incorrecta.
El backlog que los equipos extraen de los documentos de especificación tradicionales del desarrollo de productos de larga data. En lugar de un plan establecido, este backlog consta de elementos priorizados que representan un valor agregado, son de naturaleza comprobable y, en última instancia, capturan el quién, qué y por qué de una tarea. La existencia de un backlog fluido e iterativo, requiere un cambio rudimentario en nuestro proceso de diseño. Es esencial, que comprendamos este concepto a un nivel más profundo.
En nuestro flujo de trabajo típico del producto, comenzamos con una lista de especificaciones de un cliente. Especificaciones arbitrarias como “capaz de sostener 5 libras” o “capaz de levantarse fácilmente”. Estas especificaciones concretas de un cliente, o en ocasiones desarrolladas por equipos de ingeniería al comienzo de un proyecto, establecen pautas estrictas para lo que debe completarse y ser agregado al diseño. Cuando se cumplen estas especificaciones, el flujo de trabajo de ingeniería estándar nos lleva a un proceso llamado “cascada”. Para esto, tomamos estas especificaciones y trabajamos en un ciclo de diseñar-hacer-usar (DMU por sus siglas en inglés) en sucesión. El cambio de Scrum a un backlog, cambia este flujo de trabajo a un proceso iterativo.
El ciclo para el desarrollo del producto se mantiene constante dentro del diseño, el flujo de uso, pero los equipos que usan Scrum operan en paralelo tanto hacia abajo como a lo largo del ciclo DMU, operando en ciclos de retroalimentación iterativos. Trabajar con este flujo permite avanzar constantemente mientras se permiten cambios de diseño, mitigación de problemas y generación de ideas impactantes.
Proceso de manufactura en cascada vs proceso ágil. Imagen cortesía de Redshift.
Volviendo al ejemplo inicial de especificaciones claras, podemos ver cómo un flujo de trabajo Scrum puede beneficiar el diseño de hardware. En la técnica de cascada típica, estas especificaciones se toman a través del ciclo DMU con poca retroalimentación del consumidor o fases entregables medibles. Esto permite que ocurran problemas potenciales. Si las especificaciones se aclaran más tarde o incluso se modifican ligeramente, nos involucramos en el proceso en cascada y terminamos con horas perdidas en la planificación y diseños conceptuales inútiles. Al crear bucles de retroalimentación a través de Scrum, podemos comprometernos constantemente con los objetivos de nuestro producto y realizar cambios en el diseño de manera fácil y efectiva.
Por qué se necesita Agile
Ya hemos visto que el desarrollo ágil permite evitar el desperdicio de horas de trabajo y diseños inútiles. La naturaleza iterativa de la filosofía crea un entorno para el progreso constante en la continuidad de la innovación. Dicho esto, hay aspectos indispensables de por qué aplicar Agile al desarrollo de productos es una tarea beneficiosa:
- Obliga a los equipos de ingeniería a través del ciclo de DMU a un ritmo más rápido para segmentos más pequeños del diseño. Mediante el establecimiento de equipos multifuncionales, las cargas de trabajo se pueden gestionar de forma totalmente autónoma dentro de cada tarea pequeña. El trabajo se puede lograr constantemente sin reuniones más amplias que involucren a todo el equipo de ingeniería. Las reuniones se pueden mantener breves, las tareas se pueden realizar más rápido y se puede establecer un flujo de trabajo constante. Esto beneficia tanto a los ingenieros como a la administración general en el diseño de productos.
- Induce el pensamiento activo y la acción preventiva. En un proceso de diseño típico, creamos un plan de tareas para cumplir y cumplirlo de la mejor manera posible. Este flujo de trabajo “basado en instrucciones” puede funcionar bien, pero fomenta la ingeniería a lo largo de un baño recto y estrecho. Al utilizar técnicas ágiles iterativas, podemos involucrarnos más profundamente en la resolución de problemas durante todo el proceso de creación, tal vez incluso prever posibles problemas. Este pensamiento activo ocurre de alguna manera en los procesos en cascada, pero Agile aumenta su potencial.
- Crea un ambiente para la innovación. El objetivo de cada ingeniero o equipo de ingeniería es avanzar en un proyecto a través de la innovación constante, para finalmente alcanzar el mejor producto posible para el cliente. Los procesos en cascada estáticos solo permiten la mejor solución posible imaginable cuando se imaginaron las especificaciones iniciales y el plan de flujo de trabajo. Agile permite un cambio constante en todo el flujo de trabajo de diseño y crea un entorno perfecto para el crecimiento de la innovación.
Todos estos beneficios generales de Agile, combinados con resultados más específicos de su aplicación en cada flujo de diseño abarcan lo que la convierte en una ideología tan útil para el desarrollo de hardware. Si entendemos su beneficio y sus principios, el siguiente paso es aplicarlo a nuestro flujo de trabajo.
Aplicar donde sea necesario
El comienzo de Agile en el desarrollo de software crea naturalmente algunas disparidades entre la metodología real y su aplicación específica en el ciclo de desarrollo de productos del ingeniero mecánico. Esto se puede ver en cómo cada sprint resulta en un “entregable”. En el ámbito del software, la entrega de un conjunto funcional de código puede lograrse dentro de un marco de tiempo de sprint, pero para nosotros, entregar una parte funcional a menudo no es posible. Es de esta manera que tenemos que tomar estas ideas y crear un enfoque de hardware híbrido que esté “inspirado” por el desarrollo ágil.
Las iteraciones de Sprint, quizás el aspecto más importante del flujo de trabajo de Scrum, se pueden aplicar a la forma en que abordamos nuestros diseños. En lugar de avanzar por el proceso de diseño-uso-uso singularmente, se vuelve mucho más ventajoso segmentar el proceso y trabajar en ambas direcciones. En este sentido, necesitamos tomar ideas o conceptos que tenemos para el proyecto y trabajar en cada uno individualmente dentro de un marco de tiempo de sprint. Para Agile, permanecer dentro de un período de tiempo establecido se vuelve mucho más importante que lograr cada tarea que se imaginó por primera vez. Esto puede evitar que los proyectos superen el cronograma en gran medida.
Una cosa necesita ser aclarada aquí. Este proceso de inspiración ágil basado en el tiempo no significa que el proyecto general pueda resultar en la falta de características necesarias. Más bien, hace que los equipos se concentren en lograr las características necesarias y permite que se realicen características opcionales si el tiempo lo permite. Al comienzo de un proyecto, los equipos a menudo pueden tener ideas que mejoran un proyecto, pero no es necesario incorporarlos al plan del proyecto. El desarrollo centrado en el tiempo permite que se logre lo necesario, con la posibilidad de lo complementario. El uso de esta metodología como ingenieros nos permite optimizar completamente dónde enfocamos nuestra energía.
Siguiendo con la aplicación inspirada, nuestra organización de equipos de ingeniería necesita ser alterada. Cuando las tareas del proyecto se dividen en sprints semanales manejables, los equipos pueden concentrarse más pero también deben ser más diversos. En lugar de los equipos orientados al departamento de desarrollo de ingeniería de larga data, necesitamos crear equipos que involucren a todos los niveles de liderazgo. Esto significa que para los equipos Sprint de Scrum, necesitamos un Líder de Equipo, la persona que controla el equipo pequeño, un Líder de Sprint, la persona que controla el proceso y el Equipo de Desarrollo, los trabajadores. Un líder de equipo y un líder de sprint también pueden participar en el equipo de desarrollo, pero su objetivo principal es controlar el proceso del sprint y el producto final creado por el desarrollo. Tampoco es necesario que haya nada jerárquico sobre quién obtiene qué papel. Puede variar entre proyectos, existe entre ingenieros del mismo nivel; todo lo que hace es establecer el control sobre quién está haciendo qué en una determinada tarea.
Cuando retrocede y examina cómo se configuran la mayoría de los equipos de ingeniería, segmenta el conocimiento y bloquea la comunicación a menudo necesaria. Colocar al personal de diseño en un equipo separado del personal de producción puede resultar en obstáculos de comunicación dentro de nuestro proceso. Los equipos desarrollados por Agile permiten la comunicación para cada sprint entre cada “departamento” necesario, incluso si dicho departamento es solo un miembro del equipo.
La aplicación de Agile a la producción general del proyecto también gestiona la funcionalidad del equipo y el estrés de los miembros individuales. Al segmentar proyectos más grandes en entregas pequeñas y realizables, los equipos pueden obtener un ciclo de retroalimentación más estricto y pueden gestionar los requisitos en una escala mucho más concreta. Esto evita que el ingeniero individual se vea abrumado con lo que debe lograrse en un proyecto, además de ayudar a evitar la dilación o la falta de previsión en la planificación.
Cambiando nuestro proceso de desarrollo de productos
Cuando se aplica correctamente, el desarrollo de productos inspirados en Agile puede evitar multitud de problemas en el proceso de diseño e impactar positivamente en los plazos del proyecto. Al seguir historias, no especificaciones, correr distancias más cortas en lugar de “correr el maratón” y capacitar a los equipos con entregables específicos, nuestra ingeniería en sí misma puede volverse ágil.
Examinar las técnicas ágiles con mayor detalle nos deja con muchos beneficios para la utilización de esta herramienta de flujo de trabajo y muy pocos inconvenientes para su implementación potencial. Como ingenieros y gerentes de proyecto, tenemos que preguntarnos cómo podemos implementar adecuadamente técnicas inspiradas ágiles en los equipos de ingeniería y los recursos que tenemos disponibles. Al segmentar nuestros recursos en equipos más pequeños y tener reuniones scrum diarias, ¿ganamos funcionalidad y previsión? Al iterar en el proceso de diseño en sprints semanales, ¿nuestros proyectos se vuelven más manejables y dan como resultado mejores resultados? Estas son preguntas que debemos hacernos o quizás incluso probar en proyectos aplicables. Como ingenieros, siempre debemos esforzarnos por optimizar e innovar nuestro proceso de desarrollo de productos. Es por esta razón que debemos someternos a una investigación exhaustiva e implementación del desarrollo de productos inspirados en Agile dentro de nuestro proceso de ingeniería específico.
Fuente: Autodesk.
Ver artículo original aquí.
