Parece el título de una película, pero no lo es 😉 se trata de los doce principios del manifiesto ágil, tal y como escribí en otra entrada, con el paso de los años (casi 20 nada más y nada menos) algunas veces se pierde la orientación original de los motivos por los que se planteó de una manera tan disruptiva un cambio de escena en el panorama del desarrollo del software.

Siendo justos, alguno de los firmantes del manifiesto ya había propuesto unos 10 años atrás (incluso más en algún caso) conjuntos de buenas prácticas muy inspiradas en los 4 puntos básicos o valores del manifiesto ágil.

La cuestión es que, al igual que con los 4 puntos básicos, los 12 principios quedan totalmente abiertos y son de ámbito muy general, la idea de esta entrada y las otras 2 siguientes (quedaba enorme en un solo post – segunda partetercera parte) es explicar mi punto de vista sobre estos principios.

Para mi lo importante es tener claro que la agilidad no es un examen de 160 preguntas, ni hacer cada uno/a lo que le venga en gana cuando le apetezca, ni seguir a pies juntillas una serie de libros, bajo mi punto de vista estos 12 principios, se tocan, complementan, amplían, especifican y dan forma junto con otros principios, como puedan ser los de Lean, XP, TDD, DDD  y tantos otros (aunque al final todos estén muy ligados entre si) al software actual, y la manera de hacerlo, tal y como lo conocemos hoy en día.

 

Los 12 principios

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Es obvio que la referencia hacia el software creado de manera incremental, en iteraciones, de la manera más rápida posible y con entregas frecuentes, junto con el foco en el cliente, no en los documentos cerrados y en  la inmovilidad es lo más importante y es lo que en definitiva aporta valor.

Además se hace hincapié en la satisfacción del cliente, esto es algo que hoy en día nos parece lógico y obvio, pero hace unos años no lo era, recuerdo bastantes casos de equipos orgullosos de haber entregado software que el cliente directamente rechazaba de manera frontal (incluso llegando a los tribunales). El orgullo partía porque el equipo había cumplido perfectamente criterios de madurez, análisis, etcétera, pero claro el cliente no percibía valor en esto, sino en la funcionalidad y en eso… pues ya se sabe.

Y el valor, eso es la clave de todo el software que hacemos, aportar valor al cliente y obviamente que así lo perciba, de lo contrario el valor es = 0.

Y no menos importante y muy explicito: entregas tempranas, esto se explica por si solo, trabajar con entregas tempranas proporciona beneficios que no son cuestionables (retroalimentación temprana, test, cambios, etcétera) de hecho es la única manera de medir como se esta trabajando y si dicho trabajo se acerca al éxito o al fracaso, porque sin entregas ya me diréis que vamos a medir, que vamos a cambiar, etcétera.

Otro tema es que al final te puedes encontrar con que se genera deuda técnica como locos y luego ese valor no se corresponde con el ciclo de vida esperado por el cliente y claro, las expectativas se van al garete, etcétera, etcétera pero eso es también nuestra responsabilidad por no saber gestionar las cosas de manera correcta, desarrollar no es solo picar código, hoy en día el software se hace pensando en como se va a usar (cosa que antes no pasaba tan a menudo aunque teníamos cosas como DCU – UCD en inglés) y ayudando e implicando al cliente, si al final hemos acumulado deuda por no ser capaces de entregar con calidad y de manera rápida es porque algo hicimos mal.

Esto es un tema que, en los inicios de ciertas practicas muy usadas hoy en día, daba dolores de cabeza de manera constante dado que entregar rápido, con valor y sin deuda técnica era algo muy, muy novedosos y donde hacia falta bastante «prueba – error» para ajustar las cosas.

Ayudar a los clientes a crear software es parte indisociable del desarrollo, no tiene sentido hacer productos para que nunca (entregas tempranas) sean usados (valor) por nadie.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

El principio del cambio, que dicho cambio existe, que es necesario y que necesitamos desarrollar con la incertidumbre del cambio como un aliado y no como un enemigo es plausible y es una realidad constatable en cualquier proyecto.

Además, el foco está puesto en el cliente, entendiendo que el cliente puede, y debe proporcionar cambios de manera constante, esto nos lleva a que sin el cliente el software que se desarrolle difícilmente tendrá valor.

Que los requisitos van a cambiar durante el desarrollo del producto es algo obvio, esperable, lógico, positivo y cualquiera que ha desarrollado algo, por pequeño que sea y que se ha llevado al uso real por parte de clientes, es consciente de este hecho.

La idea es que en vez de intentar culpar al cliente de los cambios, cerrar documentos, no mover las especificaciones, etcétera lo que se propone es precisamente lo contrario, que el cliente cambie cosas y que sea el mismo el que decida y que el equipo de desarrollo lo acepte y lo entienda como lo que es en realidad = mejorar el producto e incrementar el valor del mismo dado que dicho valor lo posiciona el cliente y los usuarios del software.

También es obvio que no todos los clientes quieren dicha inmersión y participación en los procesos de desarrollo, pero por eso mismo el equipo debe proporcionar los mecanismos para que el cliente participe y proponga cambios, y esto se debe hacer de una manera realista, comprensiva y entendiendo que los clientes no son desarrolladores de software.

Y el cliente, esto ya es lo habitual pero hubo una época en que no lo fue, participa de manera activa y proactiva con el equipo en el desarrollo del producto, sinceramente pienso que hace dos décadas muchas veces no se dejaba participar a los clientes básicamente por el miedo a los cambios y la incertidumbre, y por otro lado los clientes no querían participan por el miedo al rechazo, la complejidad y el desconocimiento técnico, hoy en día cualquiera tiene un teléfono o trabaja con software y es mucho más sencillo todo, antes no era tan habitual.

 

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

En este punto se vuelve a insistir en que hay que entregar software, este punto es casi la definición de muy alto nivel de un sprint, pero también se puede ver de otra manera dado que no siempre desarrollamos por sprints y no por ello dejamos de entregar software y valor, incluso en muchos casos es mejor no trabajar con sprints 😉

Este principio se ha enfocado muy mal en algunos casos y/o «metodologías» siendo un sufrimiento, poniendo a todo el equipo en sobre esfuerzo, generando deuda técnica a montones y problemas de muchas y diversas índoles precisamente por querer tener siempre un sprint con el mismo tiempo o un plazo inamovible de entrega.

En realidad la cosa va de no extender el tiempo de entrega y liberar lo antes posible,  de ser frecuentes e intentar mantener los plazos y no de estar dos meses trabajando y no liberar nada. De esta manera es bastante más fácil y sencillo controlar el esfuerzo, también repartimos mejor el tiempo, el cliente se acostumbra a un ritmo, etcétera.

Eso es una cosa, y otra muy distinta es que se tenga que hacer, si o si, en dos semanas porque esta escrito en un libro y así lo indica como respuesta valida en un examen tipo test.

De hecho se promueve acortar lo máximo posible los tiempos de entrega y nunca extenderlos demasiado básicamente por una serie de motivos:

Software que se entrega rápido y poco tiempo entre nuevos requisitos es software más predictible (aquí entran muchas cosas, desde las estimaciones, los costes, el esfuerzo, etcétera)

Si intentamos liberar lo más rápido posible y lo hacemos aportando software terminado el numero y severidad de los bugs disminuye de manera notable. Al final es pura matemática.

Y por ultimo, si entregamos software funcional cada poco tiempo tendremos muchísimas más oportunidades de entender que es exactamente lo que percibe el cliente como valor, o si estamos funcionando de una manera correcta o incorrecta lo veremos más rápidamente (aquí puede aplicar perfectamente las archiconocidas retrospectivas)  por tanto las consecuencias serán menos graves y por ende generamos menos deuda técnica y mejor software.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

De nuevo la implicación del cliente tiene el foco, y el objetivo es simple = aportar valor en cada entrega. Hoy en día a nadie se le ocurre que (por poner un ejemplo)  la parte de imagen corporativa, los aspectos legales y la logística trabajen de manera distinta y completamente desacoplados de la parte de negocio que crea software.

Bien, esto antes era lo más normal del mundo, y es más, no solo se creaban «silos» sino que además, se trabajaba casi como equipos distintos con sus respectivos jefes/as, equipos técnicos, etcétera.

Esto obviamente generaba, cuando menos, desconfianza y rechazo entre las partes del proyecto, que en teoría deberían ser una «piña» dado que trabajan con un objetivo común.

Esta idea del manifiesto parte de, por un lado crear equipos multidisciplinares (vamos que todo el mundo trabaje junto en el mismo equipo aunque tengan tareas muy distintas porque el objetivo es el mismo =entregar valor) y por otro eliminar una brecha que era muy latente: el jefe (o rol X) manda y el resto obedece.

Obviamente esto (separar jefe – equipo) es imposible de hacer hoy en día, dado que físicamente no es posible agrupar en un persona todas las tareas necesarias para simplemente liberar una versión, nos hacen falta muchos roles con niveles muy altos de especialización, antes también, pero no existían los abanicos de tecnologías que se dan hoy en día y que si o si requieren de poder trabajar (y confiar) en las personas del equipo, sean responsables de negocio o desarrolladores.

Esta situación, de otra manera, pero en algunas empresas también era bastante habitual, era la guerra entre «comercial» y «desarrollo» u otros departamentos y «desarrollo».

Yo mismo he vivido situaciones en las que realmente se veía un enfrentamiento entre ambas partes cuando era evidente y obvio que comercial vendía lo que hacía desarrollo, y desarrollo solo existía para hacer el producto que comercial vendía, se que parece muy quijotesco pero os aseguro que es real.

Tan real que fue uno de los puntos de verdadera ruptura y que más criticas genero al comparar la agilidad con los modelos más clásicos y predictivos.

Y por concluir con este punto, un responsable de negocio, cuyo negocio esta basado y tiene una dependencia TOTAL de la tecnología no puede trabajar solo y sin el equipo de desarrollo, o haber como es capaz de gestionar a nivel empresarial (estrategia, táctica, etcétera) ese mismo producto, hoy en día se ve directamente como un disparate por ese acoplamiento tan grande, pero hace 20 años el desarrollo de software se veía de otra manera.

 

A continuación tenéis el enlace a la segunda parte (donde se tratan los principios 5, 6,7 y 8) y a la tercera y ultima parte donde además de las conclusiones, también se repasan los principios 9,10,11 y 12).

 

Etiquetas:

Deja una respuesta

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