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.

Peter Senge. A veces pequeños cambios pueden cambiar la dinámica

En muchas ocasiones cambiar la dinámica de un proyecto o de una organización requiere realizar grandes cambios estructurales sin embargo hay casos donde se pueden producir mejoras sustanciales con la inclusión de cambios no tan significativos.

Tal vez la maquinaria tiene piezas muy buenas pero faltan y/o sobran algunas, lo que impide que el conjunto funcione de manera adecuada.

Comenta Peter Senge que: “Solo cambiando la forma en que interactuamos podemos compartir visiones, compartir conocimientos y se establecen nuevas capacidades para actuar de manera coordinada”.

La reflexión de Senge se centra en la comunicación y en los procesos que son piezas que pueden atrancar o engrasar la maquinaria si bien es extensible a otros aspectos de carácter organizativo, incluidas las personas.

Desarrollo de software. Cuando se habla del proceso y no del producto

Cuando en la definición y puesta en práctica de un proceso se habla de todo menos del producto algo está fallando. Si en tu organización aplicáis procesos relacionados con el desarrollo de software, échale un vistazo a lo que dedica realmente a cuidar el producto.

Los procesos tienden a cuidarse a sí mismos. Si tenemos en cuenta que los procesos son instrumentos y no objetivos quiere decir que estamos cuidando los instrumentos y no lo que pretendemos conseguir haciendo uso de ellos, teniendo en cuenta que ningún proceso puede asegurar la calidad del software (por mucho que se diga que están precisamente para eso).

Los que definen y fiscalizan los procesos tienden a cuidar a los procesos, no tanto porque crean en ellos sino por protegerse a sí mismos convirtiendo a los procesos como un fin en el que los productos son solo una excusa para preservar su existencia.

Y si los procesos no funcionan se termina echando más leña al fuego: se extienden, se hacen más rígidos, la fiscalización se realiza con más celo, etc… porque se entiende que la culpa no es del proceso sino de las personas que lo aplican y como las personas fallan, ahí están los procesos para solucionarlo todo.

La solución a los procesos no es la ausencia de procesos. Como he comentado en más de una ocasión, unos procesos lo suficientemente flexibles, que admiten excepciones, donde su supervisión tiene en cuenta el día a día de lo que acontece en los proyectos de desarrollo de software es interesante porque proporciona una base común para armonizar ciertos aspectos en los trabajos. Los procesos pierden su utilidad y se convierten en una carga cuando cobran más importancia de la que deben tener y le quiere robar el papel de protagonista al producto.

¿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.

Retrospectiva del proceso

Cuando se implanta un proceso, independientemente de que sea más o menos rígido, resulta conveniente analizar el valor ganado por el mismo como consecuencia del esfuerzo que ha sido necesario para ponerlo en marcha y ejecutarlo.

El valor ganado no es el cumplimiento mismo del proceso porque en sí no es más que un instrumento sino los beneficios reales que ha obtenido su implantación.

Es posible que, por ejemplo, se haya implantado un proceso para que todos los proyectos estén documentados de la misma manera, ¿se ha ganado valor con eso?, ¿qué todos los documentos estén documentados siguiendo unas pautas ha mejorado la calidad del producto final?, es más, ¿ha mejorado la calidad de los documentos?, ¿ha supuesto un ahorro de costes como consecuencia de un estudio más en profundidad del producto?. Estas y otras muchas son las preguntas que hay que contestar ya que el simple hecho de cumplir con un proceso no tiene por qué generar valor pudiendo provocar, incluso, gastos innecesarios y/o pérdida de productividad.

Por ese motivo es fundamental la retrospectiva en los procesos apoyada en métricas que permitan evaluar de la manera más objetiva posible si el proceso está dando resultados en la cual se pida opinión a un conjunto representativo de las personas que tienen que trabajar con él.

Es mejor hacer las modificaciones que sean necesarias en el proceso (o incluso abandonarlo si fuera necesario) que perseverar en el error.

Jim Highsmith. Documentación, proceso, formalidad

Los procesos y la documentación generada en los mismos son instrumentos dentro de un desarrollo de software que de por sí no solucionan los problemas que podamos encontrarnos en los mismos.

Cuando se cree que por sí solos permiten que el proyecto avance estamos pasando de una visión orientada al producto a una visión orientada al cumplimiento de trámites que no es lo mismo ni se le parece.

Puede vestir mucho el cumplimiento a rajatabla de los procesos y la entrega de toneladas de papel, pero lo único que importa realmente es que el producto software satisfaga las expectativas de los usuarios y sea de calidad.

Hay una cita de Jim Highsmith al respecto que no requiere más comentarios: “La documentación no es comprensión, el proceso no es una disciplina, la formalidad no es una habilidad”.

Desarrollo de software. ¿Cuál es el objetivo?, ¿desarrollar productos de calidad o cumplir el proceso?

La respuesta puede parecer evidente pero, ¿a qué conocéis muchos casos en los que precisamente parece que el objetivo es satisfacer un proceso?.

¿Por qué se llega a esa situación? Por el convencimiento de que a través del proceso es cómo se obtienen productos de calidad.

Si esto fuera así el desarrollo de software no tendría historia, no tendría la complejidad que tiene y la inmensa mayoría de los proyectos terminarían con éxito.

El proceso puede ayudar a armonizar los desarrollos dentro de una organización, lo cual puede ser interesante siempre y cuando se determinen líneas a seguir de alto nivel y siempre al servicio del proyecto. También puede ser interesante para establecer un background en la realización de los proyectos pero de igual forma que en el caso anterior siempre que se vea como un instrumento que determina ciertas pautas y que ofrece flexibilidad para poder ser adaptado al proyecto en el que estamos trabajando y que puedan existir excepciones si estuviera justificado.

El objetivo es el producto, siempre el producto, pero no con una visión del mismo como una entidad única tras la cual no hay nada más, eso es un error ya que en la organización habrá otros sistemas de información, habrá otras soluciones sobre las que sera necesario o conveniente integrarse y que si no se tienen en cuenta provocará duplicación de funcionalidades, problemas a la hora de integrar datos, fragmentación de soluciones, etc…

Desarrollo de software. Producto sobre proceso

Producto, siempre el producto, por encima de los procesos, sin que estos deban obviarse o dejarse de lado.

Se ha enfocado y asociado de manera errónea la calidad del producto a la calidad del proceso, lo que ha provocado que los esfuerzos se hayan centrado en el proceso, de tal forma que en muchos casos se considera un fin y no un medio para conseguir el verdadero objetivo que es desarrollar software de calidad.

Y todavía peor que eso, se asocia en muchos casos la calidad del proceso a la cantidad del papel generado y por tanto, de manera transitiva, el producto software era tan bueno como kilos de papel se hubieran generado en el desarrollo.

Por ese motivo, la realización de análisis o conclusiones finales sobre proyectos que se centren exclusivamente o principalmente en aspectos procedimentales me parece un error, entre otras cosas porque incluso en aquellas circunstancias en las cuales el proyecto haya ido bien y haya sido a nivel de proceso ejemplar nos podemos encontrar con que el producto final es muy costoso de mantener por tener una deuda técnica alta o por tener una arquitectura no escalable.

El proceso debe estar al servicio del producto y a las necesidades que se tengan en su proceso de desarrollo, las cuales estarán muy condicionadas por las circunstancias y contexto en que se realiza.

Desarrollo de software. Marc Hamann. Agilidad y pragmatismo

Muchos críticos de los enfoques y/o metodologías ágiles lo son porque no terminan de entender como “algo serio” unas actividades de desarrollo de software que no están sustentadas sobre unos procesos sólidos, resultados de años y años de experiencia e investigación en este campo.

Las metodologías ágiles sistematizan determinadas actividades (lo que de por sí podría encajar en el concepto de proceso) pero los que las aplican tratan de ajustar su práctica y sus actividades al contexto organizativo en el que se trabaja y a la naturaleza de los proyectos, en un enfoque orientado a la mejora continua de las mismas porque a través de ellas se conseguirán mejores resultados.

No se trata, por tanto, de normas o procedimientos absolutamente ortodoxos que siguiéndolos a modo de receta de cocina nos llevan hacia el éxito del proyecto. El desarrollo de software sabemos que no es así.

Me gusta mucho la siguiente cita del desarrollador Marc Hamann ya que resume en pocas palabras este punto de vista: “La agilidad no es una ley ineludible de pureza, pero sí un principio práctico de efectividad”.

Desarrollo de software. La importancia de la opinión de quien está a pie de obra

No contar con los interlocutores adecuados es una causa muy común de fracaso en un proyecto de desarrollo de software.

Entre los principales errores que se suelen cometer en este sentido se encuentra la selección de interlocutores que no participan en el día a día de la ejecución de un proceso. Esto normalmente lleva a soluciones que están alejadas de las necesidades reales de los usuarios reales del sistema de información.

¿Y si se quiere aprovechar el nuevo sistema para hacer cambios en el proceso? Mi consejo es que esos cambios se realicen siempre que sea posible antes de que la aplicación se haya puesto en marcha, recordemos el mantra de que “la informática y el software no resuelven problemas organizativos” y que en el caso de que sea a la vez, todo el mundo tenga muy claro previamente la dirección a la que nos dirigimos.

En cualquier caso, con cambio de proceso o sin cambio de proceso, en la definición de las funcionalidades de un sistema de información, así como para la transmisión de las expectativas en relación a la experiencia de usuario tienen que intervenir representantes de los que van a utilizar el sistema de manera cotidiana, sin que ello suponga restricción alguna a que puedan intervenir, incluso coordinando todas las consultas a las diferentes áreas usuarias, personas que tengan un perfil orientado más a la gestión, es más, alguien al final tendrá que resolver posibles situaciones de conflicto en cuanto a la visión de los procesos y establecer prioridades, lo que hará necesario a que de manera directa o delegada tenga la suficiente autoridad para hacerlo.