Desarrollo de software. No hay magia tras los procesos

Los procesos dan un orden, armonizan actuaciones. Sobre esta base no podemos decir que, en esencia, sean perjudiciales. De hecho pese a que he pasado del amor al desamor con respecto a ellos siempre comento que siguen siendo necesarios pero como background en el que tengan un núcleo mínimo, que sean flexibles y admitan excepciones justificadas.

Cuando se cree que el éxito está tras los procesos es cuando se cae en el error. De ser cierto que aseguran el éxito bastaría con seguir su receta para conseguir desarrollar productos software que satisfagan las expectativas de los usuarios. ¿Alguien cree que si fuera así de fácil existiría hoy día la crisis del software?.

No niego que determinados procesos puedan ser efectivos en condiciones muy específicas pero no creo que en procesos que se consideran martillos de oro o solucionadores universales para todo tipo de desarrollos en todo tipo de contextos.

Cuando un proceso no funciona (en enfoques de desarrollo de software dirigidos por procesos) siempre se le suele echar la culpa al desarrollador: «el proyecto ha ido mal porque no has seguido bien el proceso o porque no se han ejecutado adecuadamente los hitos» o a que el proceso no está lo suficientemente desarrollado lo que da lugar a que se entre en un mayor nivel de detalle y se convierta en una solución más rígida que, por supuesto, funcionará igual de mal o peor (que es lo más posible) que la versión anterior.

La mayoría de los procesos son ad-hoc, lo cual en sí no es malo ni bueno (generalmente las implementaciones de metodologías ágiles suelen ser ad-hoc) pero sí que se debe ser prudente por parte de quien o quienes lo han hecho de considerarlo soluciones universales por mucho que sean el resultado (o se venda así) de años de feedback en proyectos reales.

¿Por qué lo digo? Pues porque la mayoría nos hemos encontrado con las siguientes situaciones: Proyectos que han salido adelante cuando no se ha seguido a rajatabla un proceso que provocaba bloqueos y resistencia y proyectos que han fracasado o que no han tenido el éxito esperado precisamente por seguir procesos rígidos que no se adaptaban a la realidad de los mismos.

Es cierto que no es justo echarle toda la culpa a los procesos cuando algo sale mal (no podemos escondernos tras ellos) pero sí que es verdad que si te exigen trabajar de una manera y no existe flexibilidad tu margen de maniobra queda reducido y se trabaja mucho peor que si tuvieras los pies y las manos liberados.

Desarrollo de software. El uso de prácticas basadas en diferentes metodologías ágiles

Ya sabemos que por mucho que nos quieran vender no hay tallas únicas o fórmulas magistrales en el desarrollo de software. Cada organización, cada proyecto, cada equipo, cada persona es un mundo y además cambia con el tiempo.

Es por ese motivo que la aplicación estricta de determinadas metodologías ágiles de manera generalizada es algo muy complicado, no por el hecho en sí de hacerlo sino porque no resultará efectivo cuando se apliquen a proyectos en donde no encajan.

Coincido con Henrik Kniberg (aunque en la práctica lo olvido casi siempre) en que no se debe confundir el uso de Scrum (por poner un ejemplo, ya que es extensible a cualquier metodología: XP, Kanban, etc…) con el uso de prácticas, estrategias o técnicas de Scrum porque al final se perdería la esencia de lo que es realmente esa metodología. Sin embargo, lo verdaderamente efectivo es conocer esa descomposición de Scrum y aplicar lo que realmente resulte interesante a tu organización y a tus proyectos.

De esta forma no tenemos un conjunto de metodologías sino un conjunto de herramientas y eso resulta mucho más ágil y efectivo.

De fondo pueden existir procesos (o metodologías) que armonicen ciertos aspectos en los proyectos en los que se trabajan, algo que resulta lógico y razonable, es decir, habrá «herramientas» de uso obligatorio pero existirá (o deberá existir) suficiente margen de maniobra para que puedas escoger las que mejor se ajusten al proyecto y su contexto.

Agilidad y documentación

¿Es compatible generar documentación de un proyecto con la aplicación de principios ágiles? Partiendo de la base de que la agilidad está por encima de las metodologías, por supuesto que sí. Ahora bien, si bajamos el nivel y nos ponemos a nivel de métodos o estrategias ágiles mi opinión es que también, si bien habría que tener siempre en cuenta el contexto del proyecto y el tipo de documentación requerida (en ocasiones la exige el cliente según los procesos que tenga establecidos).

En un enfoque iterativo incremental cada evolución tendrá como objetivo realizar una serie de tareas (pila de sprint) que forman parte de un conjunto de tareas más general (pila de producto). Estas tareas pueden ser de distinta índole: construcción, refactorización, testing, configuración de entornos y, ¿por qué no? Documentación que sirva de base para próximas iteraciones (además de documentación que puede ser de utilidad para el mismo sprint, como por ejemplo documentación de entrega del producto que servirá para su instalación, testing, etc… realizado por personas ajenas al equipo.

Desde esa perspectiva sí que es posible generar documentación siguiendo estrategias o metodologías ágiles si bien hay que entender que la excesiva formalización de la documentación (más de la que el proyecto necesita) supone una resistencia para la evolución del producto: más tiempo para documentar, menos tiempo para desarrollar (y no más documentación supone un mejor desarrollo ya que no se trata de cantidad sino de calidad).

Yo soy partidario de que cada funcionalidad a desarrollar se trabaje de manera que tanto usuarios como programadores sepan qué se va a hacer, ¿estrategia? dependerá del proyecto, de los usuarios, del esquema de trabajo, etc… muchas variables. La historia de usuario supone un instrumento que me gusta bastante: trabajo la historia, aplico técnicas de prototipado si es preciso, no es importante la formalidad y sí el contenido, lo importante es que quede claro lo que se quiere hacer. ¿Habrá huecos en la definión? Es posible, preguntemos lo que sea preciso y decidamos si actualizamos o no la historia en función de la respuesta.

¿Qué hacemos con la historia de usuario tras su construcción y tras la iteración? Es importante registrar lo que se ha hecho en cada iteración y no supone mucho trabajo registrar la historia de usuario asignada a cada tarea.

Opiniones sobre esto hay una por cada desarrollador que existe ya que incluso en visiones parecidas puede haber matices más o menos sensibles. Hay quienes prefieren aplicar ingeniería de requisitos (esto nos lleva hacia metodologías más clásicas si bien es compatible con enfoques iterativos e incrementales) y en el otro extremo historias de usuario de usar y tirar. Cada cual aplica sus conocimientos y experiencia al contexto del proyecto, lo importante es satisfacer las expectativas del usuario y hacer un producto de calidad y mantenible, lo demás son instrumentos, con mayor o menor importancia, pero instrumentos al fin y al cabo.

La agilidad no se esconde tras una metodología

Si entiendes que la simple aplicación de una metodología te hace ágil es que no has entendido realmente lo que es ser ágil. El simple hecho de esconderte tras una metodología, de seguirla como si fuera un dogma te deja desarmado ante la adaptación al cambio porque más allá de la misma te encontrarás el vacío.

Precisamente la explosión de las metodologías ágiles ha sido un arma de doble filo, por un lado ha servido para extender el mensaje y por otro ha podido dar lugar a una mala interpretación del mismo por parte de quienes las practican.

La agilidad no tiene ataduras, puedes usar una metodología pero la misma estará a disposición del proyecto y del contexto y no al revés, ¿que hay que cambiar? si hay causa justificada se cambia y no pasa nada.

No siempre vas a poder aplicar metodologías ágiles porque para ello se tienen que dar una serie de circunstancias en el proyecto que no siempre se producen, eso lo sabemos, ¿tenemos que renunciar entonces a ser ágiles? En absoluto. Nuestro background es ágil y si las circunstancias lo permiten tendremos la oportunidad de aplicar sus fundamentos y principios, tal vez no todos, tal vez en parte, tal vez en alguna ocasión.

La agilidad tampoco es ausencia de metodología porque tener unas reglas del juego proporcionan dinamismo al equipo (que se romperá cuando se quiere mantener una reglas que no sirven para el juego que está ahora mismo sobre el tapete).

La agilidad también consiste en entender que puede haber otros puntos de vista, otra forma de hacer las cosas y en la libertad de cada uno de aplicar las prácticas, estrategias y herramientas que consideren más adecuada al contexto del proyecto.

Mike Cohn. Equilibrio entre área usuaria y equipo de desarrollo

El desequilibrio más habitual que nos encontramos en los proyectos de desarrollo de software son aquellos provocados por la falta de implicación del área usuaria. Este desequilibrio suele ser provocado cuando el promotor de la iniciativa que ha dado lugar al proyecto no deja bien claro a la persona o personas que ha dejado a cargo de la definición de la aplicación cuáles son sus responsabilidades y prioridades. También (y en cierto modo por la falta de implicación de las personas designadas) esta falta de equilibrio se produce cuando el equipo de desarrollo cree tener un conocimiento del negocio lo suficientemente importante como para que la opinión de los usuarios quede relegada a un segundo plano.

Es menos habitual pero no por ello raro, encontrarnos con proyectos donde el área usuaria asume el control de tal forma que hasta influye en aspectos técnicos, condicionan la solución técnica más allá de lo que se debiera o entran en la gestión interna del equipo de desarrollo definiendo plazos y/o asignando tareas.

No se trata de que lo funcional y lo técnico estén separados por un muro sino de respetar el espacio que tiene cada uno y escuchando las propuestas que la otra parte hace y consensuando soluciones. Todos nosotros hemos vivido proyectos en donde no existe equilibrio y los resultados no suelen ser buenos.

Sobre este asunto, Mike Cohn realiza la siguiente reflexión: «Para tener éxito, un proyecto debe haber recibido información de personas muy diferentes: por un lado los clientes, por otro lado el equipo técnico. Si cualquiera de ellos domina la comunicación, el proyecto pierde».

Mike Cohn es un consultor que lleva desde el año 1995 aplicando estrategias y metodologías ágiles en proyectos de desarrollo de software en una amplia variedad de organizaciones, tipos de negocio y contextos. También es autor de varios libros y numerosos artículos sobre la materia.

Jim Highsmith. Su visión de la gestión de proyectos ágil

Para Jim Highsmith (traducción libre): «La gestión de proyectos ágil abarca tanto «hacer» y «ser» ágiles, siendo lo segundo lo más difícil».

Gestionar proyectos siguiendo metodologías ágiles no hace necesariamente ágil ni a quien gestiona, ni al equipo de proyecto, ni al proyecto, porque la agilidad no se consigue solo con metodologías porque la agilidad está por encima de ellas.

¿Qué pasa si tu contexto de trabajo no te permite aplicar metodologías ágiles?, ¿desenchufas y ya no aplicas un enfoque ágil? Incluso en las circunstancias más adversas para ser ágil existirán resquicios que te permitirán serlo (con mayor o menor trascendencia).

La gestión ágil debe empezar desde el mismo proceso de definición del proyecto, realizando las tareas que sean necesarias para evitar que desde su inicio sea considerado un Death March Project (en este tipo de contextos los árboles siempre impedirán ver el bosque y la presión y el exceso de carga de trabajo dificultará la creación de un clima donde el equipo de proyecto sea colaborativo y esté motivado) y para asegurarse que los stakeholders, sobre todo el área usuaria, tienen la implicación que requiere el proyecto (ellos tienen que definir la línea de desarrollo del producto, especificar los requisitos, indicar sus expectativas).

Si no se logran esos objetivos (y es posible que así sea porque generalmente podremos intentar influir pero el poder de decisión estará lejos de nosotros) seguimos teniendo el proyecto bajo nuestra responsabilidad y aunque las restricciones establecidas hagan daño al modelo de funcionamiento que nos gustaría implantar, no hay que tirar la toalla para la aplicación de enfoques ágiles, es más, nunca hay que tirarla.

Después la gestión ágil debe contextualizar los métodos de trabajo a la naturaleza del proyecto y del equipo de personas que van a participar en él y estar dispuesto a hacer los cambios necesarios para mejorar si fuera preciso y/o para adaptarse al cambio (para esto es fundamental que la estrategia de desarrollo utilizada y la calidad del software creen la menor resistencia posible).

Y tras eso, mucho más, porque la gestión ágil es un día a día con tu equipo (o equipos) de trabajo y el resto de personas o grupos de personas que intervienen de alguna u otra forma en el proyecto, de manera que se consolide una relación de confianza entre todos ellos (y dentro del equipo de proyecto), que el nivel de implicación de todas las partes se mantenga acorde a las necesidades del proyecto, que la comunicación entre todos sea fluida y que todos se sientan importantes.

¿Están los agilistas obsesionados con los procesos?

Una de las mayores críticas que se tiene hacia los agilistas es que se considera que están obsesionados por el proceso, hasta tal punto de contravenir el siguiente principio del Manifiesto Ágil: «Valorar a los individuos y su interacción, por encima de los procesos y las herramientas».

No estoy de acuerdo con esa crítica porque hace una generalización que creo que no se ajusta a muchas realidades. Si bien tiene un trasfondo real y es el hecho de que se considera agilistas a muchas personas por el mero hecho de trabajar con metodologías ágiles y como he comentado ya en diferentes artículos: «la agilidad es cuestión de actitud y no de metodología«.

La aplicación de metodologías ágiles es una aproximación pero depende mucho del enfoque con el que se trabaje con las mismas y de quiénes intervengan en el proceso.

Si no entiendes o conoces el trasfondo de lo que significa ser ágil la respuesta no te la va a dar ninguna metodología y si te encierras en ella, probablemente estés dando pasos en el sentido equivocado.

Alistair Cockburn. La agilidad es actitud

Hace poco descubrí la siguiente cita de Alistair Cockburn que refleja a la perfección mi sentimiento sobre el concepto de ser ágil: «Ser ágil … es una actitud, no una técnica con sus limitaciones. Una actitud no tiene fronteras, por lo que el enfoque no es preguntarse ¿puedo ser ágil aquí? sino ¿cómo voy a actuar de forma ágil aquí? o ¿cómo podemos ser ágiles aquí?».

Normalmente las empresas de desarrollo de software prestan servicios a terceros y el proceso de desarrollo está muy condicionado por los mismos por lo que resultar complicado encontrar contextos en los que se puedan aplicar metodologías ágiles de forma ortodoxa. Habrá veces donde se puede reorientar el contexto o aislar parte del proceso de desarrollo y otras veces no será posible.

Ahora bien, una cosa es eso y otra tener una actitud ágil en el proyecto. Incluso en las circunstancias más adversas podemos tener como background este enfoque pero para ello hay que tener muy asimilado en qué consiste ser ágil y eso va mucho más allá de la teoría e incluso de años de práctica de aplicación de metodologías ágiles (al final una metodología no es más que una receta a seguir, si solo nos hemos limitado a seguirla y no hemos mirado más allá no habremos comprendido su esencia).

Agilidad no es cutredad

Muchas personas contrarias a las metodologías o enfoques ágiles utilizan como argumento que la agilidad es una puerta abierta a la entrega de versiones de productos deficientes bajo el amparo de un enfoque evolutivo del desarrollo de software basado en la aproximación sucesiva a la versión final de producto y el feedback o dicho de otro modo: como vendrán nuevas oportunidades de seguir evolucionando el software no me esfuerzo por entregar un buen producto (ya se arreglará o ya se mejorará).

Pues no, no es así. Quien hace eso yo no lo considero agilista (opinión personal), es más puede que no lo considere incluso un buen profesional.

La agilidad requiere desarrollos con intención. La intención es la aproximación a un objetivo tirando a dar, minimizando la especulación. Un desarrollo con intención no se puede sustentar en entregas de calidad deficiente porque de lo contrario la evolución del producto será muy lenta y la capacidad de adaptación al cambio, por tanto, disminuye.

Desarrollo de software. Su ley natural: la incertidumbre

No se trata tanto de creer en los enfoques ágiles en el desarrollo de software como de entender y aceptar su ley natural que no es otra que la incertidumbre.

Si se acepta que todo plan puede venirse abajo una o más veces en el proceso de desarrollo y que las causas que lo pueden provocar están en muchos casos fuera de nuestro alcance (en cualquier caso debemos intentar prever los riesgos y evitar su materialización en lo posible) estaremos entendiendo que el proceso de desarrollo de software se realiza en un contexto de incertidumbre en el que necesariamente tendremos que estar preparados para adaptarnos al cambio cuanto antes y con el menor coste posible.

Hay circunstancias que terminan por reventar un proyecto sobre todo si no se quiere asumir presupuestariamente el coste del cambio. Precisamente este hecho es una causas que incide más negativamente en la calidad del producto final ya que por regla general los responsables funcionales entienden de manera muy alegre que el presupuesto inicial soporta todo, algo que no es cierto, ya que si bien pueden intercambiarse los cambios por determinados desarrollos que se tuvieran previstos, llegará un momento donde ese intercambio ya no sea factible. También es posible tener un cierto fondo económico de maniobra en el contrato para estas circunstancias, sin embargo, no suelen ser muchos los contratos que se firman teniendo en cuenta esto y tampoco existe la garantía de que la cantidad provisionada sea suficiente.

Sabemos que hay incertidumbre, que el impacto de la materialización de determinados riesgos afecta al proceso de desarrollo y que es necesario dar una respuesta al cambio. A partir de ahí que cada cual adopte el camino que entienda que es el más adecuado para afrontar esto, ya sea en términos generales como en las circunstancias particulares de un proyecto.

Mi camino lo marca el manifiesto ágil.