Aunque la agilidad es algo obvio y omnipresente para la gran mayoría de personas que trabajan en este entorno, desde hace un tiempo hasta ahora me estoy encontrando con gente que conoce bien la agilidad, desde un enfoque muy enfocado a la capa didáctica (y también muy técnica en personas más jóvenes) pero donde no se tiene tan claro cuáles fueron los orígenes de todo esto, y sus razones para definirse claro.

La idea es un simple refresco a las bases, es cierto que el manifiesto ya ha cumplido casi los 20 años, por lo que es lógico encontrar profesionales que tal vez no hayan vivido lo anterior, y por tanto determinadas bases no estén tan claras. Al fin y al cabo 20 años es mucho tiempo y las personas que se encuentren en la treintena (por poner un ejemplo) es muy probable que nunca hayan conocido de manera directa lo que provocó dicha declaración de intenciones.

El propio manifiesto es bastante escueto y directo (con alguna leve modificación):

Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

 

Personas, actitudes y acciones sobre procesos cerrados y herramientas

Resultados y software funcional sobre documentación extensiva

Implicación y colaboración del cliente sobre negociación cerrada y contractual

Respuesta ante el cambio sobre no moverse y seguir el plan inicial

 

Aunque hay valor en los elementos en rojo, los elementos en verde prevalecen

y aportan el valor diferencial (lo de los colores es cosa mía, eso no venía en el manifiesto, ellos hablan de derecha e izquierda 🙂 )

 

A ver, leído de esta manera «suena» muy etéreo, hace 20 años no era tan etéreo básicamente porque veníamos de sufrir una serie de cosas que hoy en día parecen impensables, pero que existían, y es más, eran la norma y así se trabajaba hace 20 años, así que he decidido escribir este post 😉

Introducción

Históricamente se han creado y modificado diferentes formas de trabajo para conseguir modelos repetibles y acotables (desde ford hasta hoy en día). Esto obedece a un modelo y unos principios que comulgan con las ideas de que una vez desarrollado “el modelo” se puede repetir una y otra vez logrando siempre los mismos resultados.

Claro, esto está muy bien si siempre puedes separar el diseño de la construcción, pero claro en la ingeniería del software lo de separar el diseño de las operaciones y de la «construcción» no está tan claro.

Y no esta nada claro dado que la enorme complejidad de las reglas de negocio que intentamos automatizar, medir y plasmar en un proceso sobre una interfaz de usuario. Con sus interacciones, entradas, salidas y transformaciones de datos (entre otras muchas cosas..), el escenario que siempre es cambiante (tecnología, requisitos de negocio, competencia, legislación, paradigmas, etcétera) y que es posible realizar un cambio de diseño una vez el software ya existe es funcional y usable,,, pues obviamente era necesario un cambio de enfoque a la hora de crear software.

 

Personas, actitudes y acciones sobre procesos cerrados y herramientas

Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan a crear software y a poder organizar y mejorar el trabajo, de hecho son las guías de operaciones, además al automatizarlos creamos herramientas y estas mejoran la eficiencia, pero de lo que iba esta frase era que: sin personas con conocimiento técnico y actitud adecuada, no se producen resultados.

Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a los objetivos, a la organización, a los equipos, a las personas; y no al revés.

La defensa a ultranza de los procesos (esa inflexibilidad que se veía en ciertas prácticas) lleva a pensar que solamente gracias a ellos (los procesos) se pueden conseguir resultados extraordinarios con personas mediocres y sin implicación.

Lo cierto es que este principio es peligroso (solo procesos – no personas), especialmente cuando los trabajos necesitan creatividad e innovación y cuando desarrollamos software precisamente necesitamos esto, entre otras cosas, por la cantidad de cambios y circunstancias imprevistas que se dan al crear software.

No se trata de eliminar procesos porque si, por ejemplo; es lógico en un despliegue, en una automatización de pruebas o en un plan de contingencias se establezcan, sigan y se trabaje sobre procesos, pero ¿a la hora de cambiarlos debemos seguir un ITIL de libro? o solo debemos entender hasta donde llegan los procesos y hasta donde es importante una persona proactiva, positiva y con ganas de hacer las cosas ?¿, o cuando tenemos que tomar un requisito, nos debemos ceñir al proceso ¿?.

De eso va este punto, no de eliminar los procesos, sino de que prevalezcan los soft skills y las personas sobre procedimientos rígidos, de cambiar dichos procesos cuando no funcionen, de creer más en las personas que en las formas estrictas de hacer las cosas.

 

Resultados y software funcional sobre documentación extensiva

El manifiesto no afirma que no hagan falta los documentos de ningún tipo.

Los documentos son el soporte de la información, permiten la transferencia del conocimiento, registran información histórica y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que; es mejor tener software que funcione, aunque no esté documentado (y sobre todo hablamos a nivel de funcionalidad,,, no de riesgos, legal, despliegues, pruebas de aceptación, etcétera) que tener una documentación excelente sobre productos que no funcionan (o incluso ni existen).

Los documentos no pueden sustituir a las personas y a la comunicación cara a cara, entre otras cosas no pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas, si le añadimos lo que podemos lograr a través de la interacción con prototipos, mockups, etcétera, es obvio que los documentos nunca podrán estar a esa altura.

Por eso, siempre que sea posible debería preferirse reducir al mínimo indispensable el uso de documentación. Generar documentación crea cantidades importantes de trabajo que no aporta un valor directo al producto.

Otro tema es que no exista ni un mínimo de información sobre el producto (información y documentación NO tienen porque ser lo mismo) se puede tener información en forma de historias de usuario, de bugs, de test o de mil cosas, pero definir documentos en plan: todo lo que pueda pasar en el caso X (si, si métrica 3 y esas cosas 😉 ) y ceñirnos luego a esos documentos para justificar un software que no quiere nadie, no es un buen negocio.

Esto va en línea a poder ver anticipadamente cómo se comportan las funcionalidades esperadas sobre prototipos o sobre las partes ya elaboradas de las entregas, si esto es así, se ofrece una retroalimentación muy estimulante y enriquecedora a los clientes, a los desarrolladores y en general a todo el mundo que este involucrado en el proyecto.

También genera ideas imposibles de concebir en un primer momento, por ejemplo: difícilmente se podrá conseguir un documento que contenga requisitos detallados antes de comenzar el proyecto y mucho menos un software completo.

Y por ultimo, y volvemos a lo importante que son las personas en todo esto de crear software, si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, estos documentos se acaban empleando de forma defensiva como barricadas ante departamentos o personas (tu me dijiste, aquí pone, etcétera).

 

Implicación y colaboración del cliente sobre negociación cerrada y contractual

Un contrato no aporta valor al producto desde un punto de vista de software entregado y funcional. Aporta valor en otras areas que no se deben de olvidar en un modelo global de negocio, pero en lo que nos ocupa: desarrollar software desde un punto de vista pragmático, un contrato es una necesidad que establece las líneas divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor (precios, etcétera) y en todo caso, la referencia es clara: un contrato no debe marcar cuando y que se hace, y sobre todo = es imposible cerrar un documento de 1000 páginas y no volver a verse entre cliente y desarrollo hasta que el producto esté terminado.

Este punto del manifiesto va de iteraciones, de incrementos, de cambios tempranos, y de principios lean como el retraso de decisiones, de arquitecturas emergentes, etcétera.

Las prácticas ágiles están especialmente indicadas para productos de software difíciles de definir en el principio con detalle, o que si se definieran así, tendrían al final menos valor que si se van enriqueciendo con retroinformación continua durante el desarrollo, vamos, para el software pensado en entornos donde el cambio es algo habitual.

También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.

Y obviamente todo esto nos lleva a una conclusión: los cambios existen y no van a desaparecer, forman parte de nuestro trabajo como desarrolladores de software.

En el mundo del desarrollo de software, en muy contadas ocasiones (embebido, autómatas, software que controla maquinaria, dispositivos medicos y cosas así) no nos vamos a encontrar con un  ciclo de desarrollo donde no existan cambios sobre el producto (requisitos, arquitectura, etcétera).

Para el desarrollo ágil, el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber ido implementando directamente sobre el producto los cambios y las formas de trabajar que el cliente quiere y donde percibe valor. Obviamente si no hay participación directa del cliente aportando los cambios que necesita es muy complicado que esto suceda.

Además la realidad nos hace ver que es normal que existan cambios y que el cliente los quiera ver y participe, parece algo muy obvio en nuestros días, pero no era lo tanto allá por los 2000.

Por concluir con este punto, y aunque esto es de Perogrullo, en el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra y metros2 por dinero (o llámese líneas de código) no suelen encajar.

 

Respuesta ante el cambio sobre no moverse y seguir el plan inicial

Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente el cambio, la evolución rápida y continua, las entregas recurrentes, etcétera, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos (de nuevo acerca de aquello tan cerrado).

Esto básicamente lo que viene a comentar es una problemática que existía muy, pero muy a menudo, que no era otra cosa que seguir los contratos, las arquitecturas y los modelos, tanto de desarrollo como de tecnologías, soluciones de problemas, etcétera que se habían pactado inicialmente, incluso si se veía que aquello no funcionaba, en aquellos años lo de cambiar no se llevaba muy bien y era más extendido el seguir planes.

Algunos de los principales valores de la gestión ágil son la anticipación y la adaptación; muy muy diferentes a los de la gestión de proyectos típica en aquellos años = planificación y control para evitar desviaciones sobre el plan.

Un modelo ágil no significa que no existan controles, métricas y procesos de gestión de riesgos, de problemas, de incidentes o eliminar los planes de contingencia y continuidad de negocio de nuestra agenda, de hecho, gran parte de muchos de estos conceptos son las propias bases de dichos modelos agiles y son inherentes e indisociables a ellos (por poner solo un ejemplo: las ceremonias de scrum).

De hecho nada más lejos de la realidad que no existan controles y métricas para comprender el estado de un proyecto, este principio se refiere a la capacidad de adaptarse, de cambiar y de solucionar situaciones frente a la actitud de no moverse, no pensar y actuar según el manual porque “siempre se ha hecho así y así está definido” cuando es evidente que este no funciona.

El concepto trata de sintetizar la idea de que si algo no funciona, no te agarres a eso, sal de tu zona de confort y trabaja en efectuar verdaderos cambios.

 

Conclusiones

El manifiesto puso encima de la mesa una problemática que existía, que era común y estaba muy extendida en el mundo del desarrollo de software, gracias a dicho manifiesto y a sus 12 principios básicos, la realidad universal en el desarrollo de software cambio, y hoy podemos dar las gracias a dicho manifiesto.

 

Etiquetas:

Deja una respuesta

Tu dirección de correo electrónico no será publicada.