En el campo civil y sobre todo asociadas a las TIC´s (Tecnologías de la Información y Comunicaciones), hemos visto surgir en las últimas décadas las tecnologías de ciclo corto y sus modelos específicos de gestión, siendo actualmente las más utilizadas en una gran parte del mercado de consumo y permeabilizándose a otros campos, como el mundo bancario. En esta serie de dos artículos realizaremos una definición de tecnologías de ciclo corto y una forma de gestión de este tipo de proyectos que se conoce como metodologías ágiles (Agile). Finalmente describiremos una estructura creada y ajustada para la realización de proyectos de ciclo corto en el campo de la defensa en el marco de España, terminando con una evaluación crítica de dos resultados reales de sistemas realizados siguiendo este modelo y metodología de trabajo.
En este primer artículo vamos a realizar una breve descripción tanto de las tecnologías de ciclo corto como de las metodologías “Agile” y su aplicación a la realización de este tipo de proyectos (metodología de trabajo). Los actores y roles asignados para estos casos prácticos de aplicación son la Brigada «Guadarrama XII» como usuario final, Teldat S.A. como empresa y el Grupo de Investigación «B105 Electronic Systems Lab» de la Universidad Politécnica de Madrid como equipo de I+D+i. Asimismo y para el segundo proyecto, una vez analizados los resultados del primero que fue utilizado como experimento de trabajo, se incorporó el MALE como observador y enlace institucional con el Ejército de Tierra. Los proyectos que se han desarrollado y sobre los que realizaremos un análisis crítico son un «Puesto de mando inalámbrico a nivel Brigada (C4W)” y un «Sistema de blancos basado en proyección laser con reconocimiento automático de resultados (Blancok)».
Tecnologías de ciclo corto
En el ecosistema productivo actual el parámetro tiempo tiene cada vez más importancia, siendo uno de los bienes más preciados y escasos, por lo que cada vez va cobrando más peso en las estrategias de producción. Poniendo como ejemplo un teléfono inteligente, lo que hoy es una novedad recién salida al mercado, seis meses más tarde está en rebajas y en un año ya está descatalogado. Asimismo, y si pensamos en el mundo militar, podemos ver que en los conflictos asimétricos cada vez se usan más tecnologías civiles adaptadas, que a menudo son más avanzadas que las estrictamente militares desplegadas, con un coste sustancialmente menor y lo que es más importante, con una elevada velocidad de evolución y adaptación, lo que hace bastante complejo disponer de contramedidas para contrarrestar estas amenazas.
En una aproximación tradicional, cuando se aborda el desarrollo de un nuevo producto, se busca la perfección con una definición completa de funcionalidades y a continuación se procede a su desarrollo acorde al PPT acordado (Pliego de Prescripciones Técnicas). Este modelo funciona muy bien en muchos ámbitos, pero en otros se busca una aproximación diferente, donde el objetivo es realizar un producto que cubra las necesidades básicas del usuario final o cliente en un tiempo y coste predeterminado. Es en este modo de trabajo donde aparece el concepto de Time to Market que se define como el tiempo que transcurre entre la concepción de un producto y su lanzamiento en el mercado o distribución al usuario final para su uso. Cuantificar este tiempo es de vital importancia para un producto tecnológico, ya que la rapidez de cambio del propio sector, la creciente y generalmente agresiva competencia hace que llegar mañana ya sea tarde y que hacerlo hoy sea precipitarse, lo que llevaría al fracaso del producto. Puede parecer un contrasentido llegar antes de tiempo, pero esto supone tener inmovilizada una inversión hasta que el producto pueda comercializarse o usarse, lo que no es competitivo en el modelo productivo actual.
En el mundo de la defensa el concepto es exactamente igual si planteamos operaciones reales en escenarios asimétricos, si entramos en el mundo virtual (ciber) o bien en el que está cogiendo cada vez más peso, el ciber-físico y donde ya podemos ver incipientemente una aplicación en explotación, que es el «Internet de las Cosas» (IoT). En estos campos se sigue el concepto de tecnologías de ciclo corto ya que permite disponer de equipos operativos con tiempos de desarrollo cortos, costes contenidos y una rápida y continua evolución de estos, siendo esta última característica la que los hace especialmente difíciles de contrarrestar.
Un ejemplo ilustrativo es el mundo de los teléfonos inteligentes, en cuanto un terminal sale al mercado ya sabemos que ha comenzado la cuenta atrás para el nuevo modelo que supondrá sustanciales mejoras sobre el actual. Estas mejoras no necesariamente tienen que ser objetivas, sino que una gran parte de ellas son subjetivas para el consumidor, básicamente porque en el modelo de negocio se toma como objetivo maximizar el beneficio económico y convencer al potencial comprador de que necesita un cambio es el camino para su optimización. Por ejemplo, una CPU más potente o con más velocidad no es percibida por la mayor parte de los usuarios ya que usan aplicaciones con baja demanda de prestaciones, pero una buena campaña de marketing permite motivar al posible cliente para el cambio de teléfono.
Haciendo paralelismo con los productos militares, una vez se conoce uno por parte de los oponentes, éstos ponen en marcha la industria de ingeniería inversa para desarrollar las contramedidas correspondientes, siguiendo la clásica historia del proyectil y la coraza. Desarrollar productos con metodologías ágiles permite reducir los tiempos entre versiones de éstos, dificultando enormemente la labor de esa ingeniería inversa, ya que los plazos para realizar esta labor se reducen, haciendo muchas veces inviable esta actividad.
Siguiendo con el mundo de los teléfonos inteligentes, sería inconcebible que una empresa tardase varios años en sacar al mercado el nuevo modelo con una calidad óptima. Tanto la evolución de la tecnología como la evolución de las necesidades del consumidor harían que el proceso nunca acabase ya que siempre habría una nueva tecnología que incorporar o una nueva necesidad que satisfacer. Mientras durase el proceso de diseño la competencia se haría con el mercado e introducir un producto en un mercado maduro es bastante complejo. Esto nos lleva a que el Time to Market es cada vez más reducido y que conlleva la puesta en mercado de productos que no son perfectos y que en realidad son versiones mejoradas de los ya existentes.
Otro de los elementos clave para tener éxito en el mercado es estar al día de todas las novedades de la competencia y prever de qué necesidades futuras se van a ir generando como método de reducción de plazos de desarrollo y poder posicionar nuestro producto en el momento preciso y el lugar indicado, aunque esto queda fuera del ámbito de este artículo.
Muchas veces la necesidad de disponer de un producto, bien porque se hace imprescindible para un proyecto o por aumentar la eficacia de algún procedimiento, es el parámetro tiempo el que puede condicionar su eficacia. Por eso todos los procedimientos que sirvan para la consecución del fin que se persigue de una forma rápida, siguiendo la máxima «lo mejor es enemigo de lo bueno», deben ser aplicados.
Hay productos cuyo tiempo de vida viene marcado por la velocidad de los cambios tecnológicos, esto aplica sobre todos a los que la seguridad ocupa una parte importante de su definición. Por ejemplo, en el caso de la seguridad de un canal de comunicaciones, la exponencial evolución de la capacidad de procesamiento de las máquinas permite que los algoritmos que hoy son seguros puedan dejar de serlo.
Es difícil predecir los tiempos de obsolescencia de un producto, pero está claro que, si se controla la tecnología y se tienen procedimientos ágiles de desarrollo, la renovación de un producto obsoleto se puede realizar de una forma rápida sin afectar al entorno en el que estaba instalado el producto en cuestión.
Metodologías «Agile» y ejemplo de implementación: «Scrum»
Las metodologías Agile” nacen en el mundo del desarrollo «software» cuando se observa la tendencia de que la complejidad de los productos va creciendo y que el uso de metodologías tradicionales de trabajo retrasaba mucho la entrega del producto final. Los procesos tradicionales, basados normalmente en un contrato cerrado y con escasa comunicación de los trabajadores, conducían a entregables de mala calidad. Esto, unido a la creciente velocidad en los cambios tecnológicos, llevó a la creación de un nuevo tipo de metodologías que pudiesen acomodar estas nuevas condiciones de contorno.
El significado de «Agile», para los puristas, va más allá que es ser una metodología para el desarrollo de proyectos que necesitan flexibilidad y cortos tiempos de desarrollo, sino una filosofía que conlleva una forma distinta de trabajar y de organizarse, constituyendo un conjunto de ideales y principios que actúan como un faro que nos guía.
En esta metodología el proyecto a abordar se divide en pequeñas partes que tienen que completarse y entregarse en plazos muy cortos. El objetivo final es desarrollar productos y servicios de calidad que respondan a las necesidades de unos clientes cuyas prioridades cambian a una velocidad cada vez mayor.
En marzo de 2001 y sobre la base de la metodología Extreme Programming (Beck, K. (2000). Extreme Programming Explained. Addison-Wesley), se define el «Manifiesto Ágil», inicialmente aplicado al desarrollo software y que define el siguiente modelo de valoración:
• A los individuos y su interacción, por encima de los procesos y las herramientas.
o Este es el valor más importante del manifiesto.
o Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero hay tareas que requieren talento y necesitan personas que lo aporten y trabajen con una actitud adecuada.
o La producción basada en procesos persigue que la calidad del resultado sea consecuencia del know-how «explicitado» en los procesos, más que en el conocimiento aportado por las personas que los ejecutan.
o Sin embargo, en desarrollo ágil los procesos son una ayuda. Un soporte para guiar el trabajo. La defensa a ultranza de los procesos lleva a afirmar que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio no es cierto cuando se necesita creatividad e innovación.
• El software que funciona, por encima de la documentación exhaustiva.
o Poder anticipar como será́ el funcionamiento del producto final, observando prototipos previos, o partes ya elaboradas ofrece un «feedback» estimulante y enriquecedor, que genera ideas imposibles de concebir en un primer momento, y difícilmente se podrían incluir al redactar un documento de requisitos detallado en el comienzo del proyecto.
o El manifiesto ágil no da por inútil la documentación, solo la de la documentación innecesaria. Los documentos son soporte de hechos, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero su relevancia debe ser mucho menor que el producto final.
o La comunicación a través de documentos no ofrece la riqueza y generación de valor que logra la comunicación directa entre las personas, y a través de la interacción con prototipos del producto.
o Por eso, siempre que sea posible debe preferirse reducir al mínimo indispensable el uso de documentación, que requiere trabajo sin aportar un valor directo al producto.
o Si la organización y los equipos se comunican a través de documentos, además de ocultar la riqueza de la interacción con el producto, forman barreras de burocracia entre departamentos o entre personas.
• La colaboración con el cliente, por encima de la negociación contractual.
o Las prácticas ágiles están indicadas para productos cuyo detalle resulta difícil prever al principio del proyecto; y si se detallara al comenzar, el resultado final tendría menos valor que si se mejoran y precisan con retroinformación continua durante el.
o También son apropiadas cuando se prevén requisitos inestables por la velocidad de cambio en el entorno de negocio del cliente.
o El objetivo de un proyecto ágil no es controlar la ejecución conforme a procesos y cumplimiento de planes, sino proporcionar el mayor valor posible al producto.
o Resulta por tanto más adecuada una relación de implicación y colaboración continua con el cliente, más que una contractual de delimitación de responsabilidades.
• La respuesta al cambio, por encima del seguimiento de un plan.
o Para desarrollar productos de requisitos inestables, que tienen como factor inherente el cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes. Los principales valores de la gestión ágil son la anticipación y la adaptación, diferentes a los de la gestión de proyectos ortodoxa: planificación y control que evite desviaciones del plan».
Asimismo, y sobre estos cuatro valores, se definen los doce principios del «Manifiesto Ágil»:
• «Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
• Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
• Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
• Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
• Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
• La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
• El software que funciona es la principal medida del progreso.
• Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica enaltece la agilidad.
• La simplicidad como arte de maximizar la cantidad de trabajo que se hace es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto organizan.
• En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta».
La metodología «Scrum»
«Scrum” es un proceso de estrategia de desarrollo basado en los principios del «Manifiesto Ágil», donde se aplican de forma regular un conjunto de buenas prácticas para trabajar incremental y colaborativamente en equipo.
A principios de los años 80, «Scrum» fue definido por las empresas tecnológicas (Nonaka & Takeuchi, The New New Product Development Game, 1986) y debe su nombre al avance en formación de los equipos de Rugby. Sus principales características son:
• «Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.
• Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en la calidad de los procesos empleados.
• Solapamiento de las diferentes fases del desarrollo, en lugar de realizarlas una tras otra en un ciclo secuencial o de cascada».
Se pueden definir dos tipos de «Scrum», uno técnico basado en reglas definidas y uno pragmático basado en valores ágiles. El técnico, que describiremos en este artículo, es el punto de partida para el aprendizaje de este tipo de metodologías ya que es muy estricto y formal, mientras que el pragmático se aplica cuando ya hay equipos entrenados que han pasado por el técnico y que permite una mayor productividad. En nuestro caso hemos aplicado un híbrido, que describiremos en el siguiente artículo, ya que uno de los puntos clave era obtener proyectos exitosos y donde se ha potenciado que todos los actores estuviesen cómodos como forma de poder comprender la potencialidad de este tipo de metodologías y proyectos.
La metodología se basa en los siguientes puntos:
• Dividir el equipo de trabajo en equipos pequeños, interdisciplinarios y autoorganizados.
• Dividir el trabajo completo a realizar en una lista de entregables pequeños y concretos. Ordenar la lista por orden de prioridad y estimar el esfuerzo relativo de cada elemento.
• Dividir el tiempo en iteraciones cortas de longitud fija (generalmente de 1 a 4 semanas), con trabajo potencialmente entregable y validado después de cada iteración.
• Optimizar el plan de entregas y actualizar las prioridades en colaboración con el cliente, basada en los conocimientos adquiridos mediante la inspección del entregable después de cada iteración.
• Optimizar el proceso teniendo una retrospectiva después de cada iteración.
• Así́ en lugar de un grupo numeroso pasando mucho tiempo construyendo algo grande, tenemos un equipo menor pasando un tiempo más corto construyendo algo menor, pero integrando con regularidad para ver el conjunto.
El «Scrum” técnico está compuesto por los siguientes elementos, pudiendo ver en la figura 1 una representación gráfica:
• Roles:
o El equipo «Scrum» es el equipo completo de personas que trabajan en el proyecto.
o El dueño del producto es el usuario final y por lo tanto el que tiene que tomar las decisiones de cómo se desarrolla el mismo.
o El «Scrum Master» es la figura que se encarga de garantizar que se sigue la metodología de trabajo para el desarrollo del proyecto.
• Eventos
o «Sprint» es cada ciclo o iteración del trabajo que produce una parte del producto funcionalmente operativo y validado por el cliente.
o Reunión de planificación del «Sprint» que se realiza antes de comenzar el «Sprint» a abordar y en ésta se planifica el trabajo a realizar en el mismo, objetivos y tareas.
o «Scrum» diario, reunión de muy corta duración realizada diariamente para hacer una puesta en común del desarrollo de la iteración.
o Revisión del «Sprint», tiene lugar al finalizar cada «Sprint» para realizar la entrega del trabajo correspondiente al hito.
o Retrospectiva del «Sprint», que se realiza normalmente en la misma reunión que la revisión y planificación en la que se pone en común lo ocurrido durante el «Sprint» y propuesta de mejoras.
• Artefactos:
o Pila del producto es el conjunto de funcionalidades, mejoras, tecnologías y corrección de errores que han de incorporarse al producto en los siguientes «Sprint». Es el conjunto de cosas ordenado por prioridad que el cliente espera del equipo de trabajo. La pila no es estática, sino dinámica y evoluciona constantemente con el desarrollo del proyecto, siendo el cliente el encargado de su mantenimiento. Por último, cada elemento de la pila tiene que estar cuantificado con un estimativo del esfuerzo necesario para completarlo.
o Pila del sprint. Cuando se planifica un «Sprint» se realiza una descomposición del o los elementos más prioritarios de la pila de producto en las tareas necesarias para cumplirlo, siendo estas tareas lo suficientemente pequeñas como para poder realizar una fácil monitorización en breves periodos de tiempo, así como del esfuerzo necesario para llevarlo a cabo y su asignación al equipo de trabajo. Es imprescindible que estas tareas sean pequeñas para minimizar el coste y esfuerzo de gestión del proyecto.
o El incremento es el resultado de un «Sprint» y que se caracteriza por estar plenamente operativa para su entrega al cliente. Es importante resaltar que en estas metodologías la calidad es irrenunciable, negociando el tiempo y coste de cada una de las tareas, pero no la calidad de estas.
Resultados
En el siguiente artículo analizaremos sobre los dos productos cómo se ha organizado el equipo de trabajo y los resultados de estos.
En el proyecto C4W, el primero que se desarrolló con esta aproximación, se tomó un centro de mando a nivel brigada y se eliminaron los aproximadamente 7.5km de cableado de señal telefónica e informática, realizando conexiones inalámbricas entre los diferentes elementos. Esto supuso una reducción del tiempo en entrar en operación de, aproximadamente, un 80%, lo que es especialmente útil en unidades como la Guadarrama XII con un alto grado de movilidad y frecuencia de saltos. El sistema es 100% compatible con los equipos actualmente en uso y en el mismo se implementaron las medidas de seguridad requeridas.
El proyecto Blancok es un ejemplo de tecnología de doble uso y su objetivo era «Desarrollar un sistema de blancos basado en iluminadores láser con reconocimiento automático de resultados, que permita mejorar la calidad de la preparación del tiro con fuego real de las armas individuales y colectivas de las unidades, ahorrando tiempo en la instrucción, los costes de los actuales sistemas basados en facsímiles, de manera más ecológica y proporcionando mayor realismo, variedad y dinamismo a este tipo de ejercicios. Asimismo, permitirá la detección en actividades deportivas de tiro y recreativas como paintball o airsoft».
Octavio Nieto-Taladriz García
Academia de las Artes y las Ciencias Militares
Sección de Prospectiva de la Tecnología Militar
Eduardo Robles Esteban
Teldat S.A.