archivo

Archivo de la etiqueta: metodologías

Los procesos y las metodologías delimitan un camino y eso de por sí restringe las posibilidades de actuación. Esto no es ni bueno ni malo de por sí, depende realmente de hasta dónde llegan esas restricciones y de las posibilidades que tenemos de hacer excepciones cuando el proyecto lo requiera.

Cuando un proceso o una metodología entran en un nivel de detalle alto nuestro margen de maniobra se reduce, si quien controla (en el caso de que haya alguien) el cumplimiento de la misma no permite excepciones nuestra frontera empieza y termina allí, esto podría ser interesante cuando tienes la mayor parte de los detalles de un proyecto bajo control pero sabemos que esas condiciones, prácticamente ideales, son complicadas de conseguir.

No se trata de elegir entre extremos sino de ser flexible ya que no siempre es problema de la rigidez de quién especifica los procesos, también es importante que nosotros seamos flexibles y entendamos que la organización también necesita gestionarse y que por ese motivo, a veces, se establecen ciertas premisas que aunque puedan no gustarnos los gestores entienden que son necesarias (aunque no por ello tienen que ser acertadas siempre).

Al final es cuestión de que todas las partes sean sensatas y no se posicionen en esquemas de funcionamiento que no se adapten a un contexto y a las necesidades del proyecto.

Es cierto que pueden existir ciertas reglas o patrones que se repiten con una cierta asiduidad en los proyectos de desarrollo de software pero en muy pocas circunstancias se da el caso de que la receta aplicada en otro proyecto garantice el éxito en el que estás trabajando.

Sí que es bueno conocer esas experiencias, esas buenas prácticas, esos patrones, esos antipatrones, ese cuerpo de conocimiento pero sabiendo que se trata de herramientas que están a nuestra disposición si entendemos que son de utilidad para el proyecto (y no siempre lo serán).

Se trata de conocimientos y experiencias de terceros y si le vas sumando tu propia experiencia la caja de herramientas ofrecerá más posibilidades y será más precisa. No obstante y por encima de todo se encuentra nuestra capacidad de entender que cada proyecto es distinto y que cada situación puede requerir soluciones particulares.

Alguna vez he comentado en el blog que no entiendo muy bien esos casos en los que vienen empresas o consultoras a proponer la implantación de un conjunto de procesos o metodologías sin haberse preocupado en conocer las particularidades de la organización del posible cliente, como si tuvieran entre manos una talla única que encaja en todas las situaciones.

Me parece muy interesante la siguiente reflexión de Alistair Cockburn: “Si se sigue una metodología tal cual, tendrás una que se adapte a algún proyecto en el mundo, pero probablemente no el tuyo”.

La palabra proceso nos crea la imagen mental de burocracia y esto es así no porque nos hayamos levantado de esa manera una mañana sino porque la mayoría de nosotros ha sufrido procesos de desarrollo de software que daban lugar a un mayor coste que a un beneficio real y que estaba lleno de hitos y entregables que se convertían en un obstáculo más que solventar en el ya de por sí complejo camino que son los proyectos de desarrollo de software.

Sin embargo, por mucho que no soportemos los procesos, muy probablemente aplicamos determinadas metodologías, estrategias o prácticas que en esencia también son procesos, lo que pasa es que como muchas de ellas para nosotros son automatismos o confiamos en sus resultados, no las vemos de esa forma.

¿Qué quiero decir con esto? Pues que tal vez el problema no se encuentra en el concepto sino en su definición e implementación, en la falta de una visión orientada a su mejora continua (si un proceso no sufre ajustes algo está pasando) y a la falta de flexibilidad que se ofrece a la hora de adaptarse a las particularidades concretas de cada proyecto.

Un proceso debe aportar, no restar. Si nos pone límites ficticios que dificultan nuestro margen de maniobra quiere decir que nuestros resultados en el proyecto estarán condicionados por impedimentos que perfectamente podrían haberse eliminado, ¿no es absurdo en estos casos abogar por la ortodoxia en lugar de la solución que más conviene?.

En los proyectos de desarrollo de software intervienen infinidad de variables y es el resultado de la colaboración de una serie de personas y no hay nada más impredecible que un ser humano, por ese motivo la definición de los procesos debe tener en cuenta esa circunstancia.

No se trata de acertar a la primera sino de tener capacidad de ir adaptándolo y mejorándolo con la experiencia y de dotar a su aplicación de la flexibilidad suficiente (incluyendo excepciones) para adaptarse lo máximo posible a las necesidades concretas que requiere el proyecto.

Intentar ser ágil a través de la simple aplicación de metodologías lleva generalmente a convertirte en un esclavo de las mismas y en consecuencia a estar al dictado de procesos que limitarán tu margen de actuación y que no te permitirán adaptar las metodologías a las circunstancias o lo que es lo mismo no te permitirá utilizarlas como instrumentos o herramientas que es lo que realmente deberían ser.

Importante, limitan porque tu dejas que te limiten y eso ocurre generalmente cuando no has terminado de asimilar qué significa ser ágil. Otro motivo lo tenemos en que resulta muy cómodo dejar que las metodologías piensen por uno.

Es cierto que la simple aplicación de esas metodologías ya suponen un cambio positivo en la dinámica de trabajo, no lo puedo negar, y es posible llegar a través de ellas a comprender la agilidad, no sin antes, y de manera muy probable, haber caído en la trampa de convertirlas en ley, si bien eso también pasa muy frecuentemente cuando, a priori, crees lo que significa ser ágil.

Nuestro conocimiento y nuestra experiencia constituyen nuestro verdadero background a la hora de afrontar un proyecto de desarrollo de software y las diferentes contingencias y cambios de contexto que se van a producir en el mismo. Todo lo demás: metodología, procesos, buenas prácticas, herramientas, etc… son instrumentos que utilizaremos según convenga y que en el caso de que haya alguno de carácter obligatorio (por si se quiere armonizar algún aspecto del desarrollo entre proyectos diferentes) debe ser lo suficientemente flexible para ofrecernos el margen de maniobra necesario para poder adaptarnos a la nueva situación e incluso prever la posible existencia de excepciones cuando exista una circunstancia que lo justifique.

La repetibilidad es algo deseable, ¿por qué no querer industrializar una manera de hacer las cosas que nos permita alcanzar el éxito con una alta probabilidad?, sin embargo en el desarrollo de software donde cada proyecto es algo singular y en donde los contextos cambian es buscar una quimera.

Por tanto, la repetibilidad basada en términos absolutos es algo que deberíamos descartar de base, lo cual no quiere decir que en función de las características de un proyecto apliquemos unas estrategias de fondo que nos puedan resultar de utilidad (pero como instrumento no como un martillo de oro).

Sobre esto, Jim Highsmith opina lo siguiente: “Los agilistas creen que las buenas prácticas y procesos puede mejorar la consistencia pero que la repetibilidad es una fantasía”.

El desarrollo de software no es solo son procesos, metodologías, arquitecturas, programación, etc… hay algo más, mucho más importante que es la relación entre las personas que intervienen en el proyecto.

Si falla esa relación, esa comunicación entre las personas, esa búsqueda de un objetivo común, esa necesidad de trabajar juntos para alcanzarlo difícilmente va a funcionar todo lo demás por muy bien que se trabaje.

También está el bagaje profesional y personal, ese background que te ayuda a intentar tomar las mejores decisiones (aunque no siempre se acierte) incluso en contextos complicados y/o que no son conocidos por nosotros.

Si se trabaja como un equipo se tendrá la capacidad de integrar el background de todos, si no es así no es ya que no se aproveche ese talento y esa experiencia sino que esas diferentes visiones tenderán a convertirse en fuerzas que empujan en distinto sentido y provoca situaciones de bloqueo en el proyecto, desgaste, etc…

Ken Schwaber considera que no todo son procesos y metodologías, sino que hay algo más: “Una metodología te dice lo que tienes que hacer, un proceso es un framework que establece algunas restricciones. Una metodología no puede decirle a la gente que hacer cuando nunca han estado allí”. Es decir, tras la metodología quedan los desarrolladores (las metodologías son generalizaciones y no pueden tener en cuenta cada situación concreta de un proyecto) que son los que al final tienen que tomar las decisiones.

En el desarrollo de software no existen verdades absolutas, ni tan siquiera esas que tienes tan arraigadas basadas en tu formación, conocimiento y experiencia.

A lo largo de la realización de un proyecto se parte de un contexto inicial que va a ir evolucionando y esos contextos probablemente serán diferentes a los de tu proyecto anterior y siguiente. Tenemos que adaptarnos a las circunstancias porque lo más probable es que las circunstancias no se puedan adaptar a nosotros.

Solo es posible la adaptación si estamos dispuesto a ello.

Si creemos que determinados procesos, metodologías y prácticas garantizan el éxito nos estamos creando una resistencia para la adaptación al cambio que nos condicionarán en el caso de que tengamos que aplicar estrategias que se salgan de esa norma.

No se trata de cambiar por cambiar, sino de hacerlo con intención y con sentido en el contexto del proyecto. Ambos factores (intención y sentido) lo son si analizamos y entendemos por qué es necesario salirnos del guión (siempre en relación a un contexto).

Y esta idea es extensible a ámbitos más allá de un proyecto por ejemplo al de la propia gestión de un departamento de desarrollo a la hora de eligir un framework o background base de funcionamiento, ¿debe funcionar una gestión de procesos que ha funcionado en otra organización?, ¿acaso su contexto es el mismo? No se trata de reinventar la rueda o aplicar de base el no inventado aquí, sino de interpretar esas estrategias acorde a la realidad de la organización, del Departamento, de los objetivos que se quieren lograr, del negocio y todos los factores que se consideren relevantes.

Tal vez la única verdad absoluta es que no hay verdades absolutas, o tal vez no.