archivo

Archivo de la etiqueta: agilismo

Jim Highsmith en su libro “Adaptive Software Development” realiza la siguiente reflexión: “El aprendizaje rápido requiere iteraciones: intentar, revisar, repetir”.

Aprender sobre hechos y no trabajar indefinidamente sobre hipótesis es para mi la esencia de la iteración.

Es cierto que la hipótesis dura (para bien, para mal o para regular) hasta que tenemos el resultado definitivo del proyecto en producción ya que hasta que de manera completa no se utiliza en un contexto real no podemos medir con precisión la satisfacción con el producto pero también lo es que la niebla se despeja poco a poco conforme el usuario va probando versiones parciales del mismo (en producción real preferiblemente) y va proporcionando su feedback.

En este proceso no solo aprende el desarrollador sino que también aprende el usuario porque de lo que cree que quiere (que no deja de ser una idea abstracta y a gran escala) a la solución que realmente le satisfaría, hay un largo trecho.

Anuncios

Es evidente, no hay nada más que ver la gran cantidad de conferencias, seminarios, certificaciones, etc… que tras el agilismo hay también un negocio. Muchas personas contrarias al movimiento ágil lo utilizan como argumento para deslegitimarlo: “…si la agilidad es algo tan positivo no entiendo porque es necesario darle tanto bombo”.

A mi no me parece mal que haya quienes quieran ganar dinero o ganarse la vida mediante la divulgación de este enfoque de desarrollo de software ya sea desde un punto de vista generalista o mediante la divulgación de estrategias o metodologías concretas y, por tanto, no entiendo que eso pueda ser utilizado como arma arrojadiza contra el agilismo.

¿Qué hay cierta saturación? Es posible pero no por ello tiene que ser negativo. Cada desarrollador, cada profesional expresa su punto de vista basado en su experiencia (contextualizada por los tipos de proyectos, tipos de clientes y la cultura de la región o regiones en las que ha trabajado) y su conocimiento y lo hacen a través de publicaciones, artículos, seminarios, conferencias, etc… Cada cual tiene algo que decir y probablemente tenga cosas que aportar con respecto a los demás porque se habrá encontrado con circunstancias diferentes que le habrá llevado a trabajar de una determinada manera o incluso trabajando en circunstancias similares ha podido aplicar un enfoque o un estrategia diferente.

Lo que sí hay que tener en cuenta que cada uno de esos expertos expresa su punto de vista, influido por el contexto o contextos en los que ha trabajado por ese motivo lo importante es reflexionar sobre lo que te cuentan, aplicar aquellas prácticas que consideres interesantes y no perder la atención si no consigues encajar lo que te cuentan con tu entorno laboral (tal vez no puedas llevar a la práctica lo que te dicen tal como te lo dicen pero es posible que haya ideas que permitan que en determinadas circunstancias puedas enfocar mejor los proyectos o determinadas contingencias dentro de los mismos).

La respuesta es compleja ya que depende del enfoque que tengas por lo que dar una respuesta en términos absolutos hará que los resultados en muchos casos sean erróneos.

En cualquier caso y con respecto a enfoques clásicos de desarrollo sí que supone una fuerte ruptura si bien la tendencia natural de la mayoría de los que han aplicado ese tipo de enfoque ha sido tender hacia enfoques más flexibles aproximándose a lo que sería un enfoque ágil. De hecho se venían aplicando enfoques ágiles, así como estrategias y metodologías mucho antes de que el Manifiesto Ágil fuera publicado.

¿Por qué una ruptura respecto a los enfoques clásicos? Porque sitúa en primer lugar al producto y a las personas mientras que en los enfoques clásicos todo estaba supeditado al proceso (o por lo menos estaba por encima del producto y las personas).

Según el enfoque clásico, estas son las etapas y los hitos a cumplir en cada una de ellas obteniendo análisis y diseños que después se materializarían mucho más tarde en un producto software (planteamiento más rígido). Hasta la entrega del producto el usuario no realizaba un feedback sobre un elemento no abstracto, hasta entonces lo menos abstracto con lo que había trabajado eran prototipos.

Pero no se trata solo de intentar que el feedback del usuario sea de la mayor calidad posible y cuanto antes, sino que se trata sobre todo de entender la singularidad de los proyectos y de su realización en un contexto concreto que probablemente cambie, lo que hace necesario centrar la atención en el producto y en las personas que intervienen en su definición y construcción, se trata de adaptarnos por tanto al producto que se va a desarrollar dentro del contexto en que se realiza el proyecto, no se trata por tanto de aplicar una metodología o un proceso como un martillo de oro que asegura el éxito en todos los casos sino de adecuar nuestros esquema de trabajo al producto que vamos a desarrollar.

En un entorno con una incertidumbre inherente es fundamental poder adaptarse al cambio y eso implica por un lado no poder estar atado con procesos rígidos (salvo que el contexto del proyecto o la naturaleza del producto que se desarrolla te obligue a ello) y por otro la existencia de una comunicación fluida entre todos los participantes en el proyecto pudiendo realizar, dentro de los márgenes que existan para ello, ajustes sobre condiciones o planificaciones que previamente se han establecido.

El enfoque ágil no es la consecuencia de hacer menos pesados los enfoques clásicos, no se trata de trabajar con procesos más ligeros o entregar menos documentación (no es solo eso), sino que supone un cambio más radical (entre otros): producto sobre proceso, cambio del modelo de comunicación entre las personas y adaptación al cambio.

Leyendo una lista de correos sobre desarrollo ágil y Scrum de hace algo más de diez años me he encontrado con una interesante cita de Tim Rentsch de hace treinta años: “…La programación orientada a objetos será en los años 80 como la programación estructurada lo fue en los 70. Todo el mundo estará a favor de ella. Cada proveedor promoverá sus productos y le dará apoyo. Cada gestor pagará por ella. Cada programador la practicará (diferentemente) y nadie sabrá que es lo que es”.

Es cierto que cuando se expande un concepto y se convierte en moda se tiende a ir ciegamente hacia ese modelo sin ni siquiera pensar los fundamentos que hay detrás de él. Se cree que por el simple hecho de haber golpeado fuerte es necesario seguirlo sin condiciones.

No te conviertes en agilista por aplicar Scrum (o estrategias similares), como no te hace carpintero saber utilizar una sierra, una lija y un martillo. Primero es necesario adquirir actitud ágil entendiendo por qué surge este movimiento y cuales son sus fundamentos. Aplicar estrategias, enfoques, metodologías, instrumentos, etc… viene después.

Según Beedle la reflexión de Rentsch era totalmente válida para la década de los 90′, situando la tasa de absorción de la programación orientada a objetos en torno a 20 años o más que es más o menos el tiempo que predice (lo hizo hace diez años) que se tardará en que el agilismo no sea solo un concepto extendido, sino que además sea mayoritario su entendimiento entre sus practicantes.

Siempre hay un desencadenante, un artículo, un libro, una conferencia, unas prácticas que observas en terceros (en mi caso fue la lectura del Manifiesto Ágil) que lo único que hace es poner frente a ti una realidad que sentías, que llevabas dentro pero que la formación que recibiste, la forma en que se enfocaban los proyectos en los que trabajabas, lo tenían a un lado.

Ya estabas cansado de proyectos con desgaste, de proyectos con éxito exiguo, de fracasos pese a que te dejaste la piel en ello. Necesitabas algo que te hiciera creer de nuevo en el desarrollo de software, algo que fuera natural a él y eso lo encontraste en la agilidad.

La agilidad es ciertamente un proceso. Lleva su tiempo. La agilidad no es aplicar una metodología concreta, la agilidad es una forma de entender el desarrollo de software en la que lo importante son las personas y el producto y en donde todo lo demás aún siendo importante son instrumentos a nuestra disposición para ser utilizados o no de una u otra forma en función del contexto en el que trabajemos.

Si tu formación no ha sido clásica, si has tenido siempre la suerte de trabajar de esta forma lo verás como lo más natural del mundo, quienes venimos del otro lado la agilidad nos ha devuelto la ilusión.

La ilusión por una forma de entender este trabajo aún sabiendo que cada proyecto es un mundo y que nada asegura que pueda resultar un fracaso.

La agilidad no viene de la noche a la mañana, ya venías aplicando técnicas ágiles como ya se venían haciendo desde muchos años antes del Manifiesto Ágil y tiempo después de ese momento en el que descubriste este mundo seguirás teniendo actitudes lejos de la agilidad. Es un proceso con el que hay que tener cuidado porque puede parecer que es la piedra filosofal que convierte cada proyecto en oro y sin embargo no es así, se sientan unas bases que después tienes que aplicar dentro de un contexto que puede ser variable y con unas restricciones de fondo y en ese mar puedes naufragar, de hecho naufragarás tarde o temprano y más de una vez, no lo dudes.

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.

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.