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.

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.

Tom DeMarco realizó la siguiente reflexión en su libro “The Deadline: A Novel About Project Management” (1997): “El problema de los procesos estándar es que la gente pierde la oportunidad de tomar importantes atajos”.

Cuando los procesos son tan rígidos y parece que lo único importante es cumplir con ellos se pierde la visión de que no se trabaja para el proceso sino para realizar un software de calidad.

Esta visión negativa del autor de lo que supone una gestión balanceada hacia el proceso donde las personas pasan a ser algo con menos importancia ha sido una constante en DeMarco desde que en el año 1987 publicase junto a Timothy Lister el libro “Peopleware: Productive Projects and Teams” que extendió precisamente el concepto de Peopleware en el que sitúa a las personas como elemento principal en el desarrollo de software (el concepto fue utilizado inicialmente por otros autores, datándose su origen en el año 1977).

Es bien sabido que los fundamentos del Manifiesto Ágil son anteriores a su publicación, en el caso de la publicación indicada nos encontramos catorce años antes (y veinticuatro si consideramos el origen del concepto).

Es normal que entonces se tuviera problemas con una orientación a procesos descompensada y desgraciadamente sigue siendo normal ahora, entre otras cosas por la dificultad que tenemos los seres humanos de aprender de nuestros errores y porque en entornos académicos durante muchos años se ha hablado mucho de procesos y poco o nada de las personas.

El proceso debe establecer un marco general de trabajo con la suficiente flexibilidad para permitir una adaptación a los diferentes contexto que nos encontramos en los proyectos de desarrollo de software y a los cambios que se producen en los mismos y se tienen que definir con la finalidad de cumplir una serie de objetivos establecidos por la organización, entre los que nunca estará el propio proceso en sí.

El enfoque evolutivo del desarrollo de software desde una perspectiva ágil consiste en ir descubriendo el camino hacia el cumplimiento de las expectativas de usuario a través de la oscuridad de la incertidumbre que rodea a los proyectos, de la resistencia que encontremos y de los cambios de dirección y sentido que provocan los cambios de contexto.

La brújula es el feedback sobre iteraciones del producto teniendo como base nuestro background como desarrolladores de software y la intención con que se afronta cada evolución del sistema (una cosa es tener que descubrir el camino y otra no tener muy claro realmente a dónde se quiere ir) y nuestro motor el funcionamiento real como un equipo de trabajo.

Los enfoques clásicos, predictivos por naturaleza, entienden que desde el principio se sabe cómo llegar al producto que se desea y que en cualquier caso a lo largo del proceso de desarrollo se podrían realizar ligeros ajustes.

La realidad que nos encontramos en los proyectos de desarrollo de software nos indica que en la mayoría de los casos no se sabe qué es lo que se quiere realmente (o por lo menos con la suficiente precisión como para poder plantear un enfoque clásico) y que el camino para llegar a ese objetivo tiene muchas curvas, subidas y bajadas, asfalto de distinta naturaleza y diferentes condiciones climáticas.

Yo estoy plenamente convencido de que para que un proyecto de desarrollo de software tenga posibilidades de tener éxito es fundamental que las interrelaciones personales entre los miembros del equipo de proyecto y entre los stakeholders deben funcionar. No hablo de amistad, hablo de profesionalidad y confianza.

Cuando nos enfrentamos a un problema en el proceso de desarrollo, muchas veces se trata de un duelo entre nosotros y el problema, por ejemplo si hay que programar un componente es un duelo intelectual entre nosotros y el algoritmo o algoritmos necesarios para llevarlo a cabo. Por muy difícil que sea ese duelo, lo normal es que sean mucho más fáciles de tratar que cualquier contingencia en la que se vean involucradas personas.

Cada uno de nosotros es un mundo, con nuestros propios intereses personales y profesionales y en donde nuestro estado de ánimo puede ser diferente de un día para otro.

Por este motivo, saber gestionar situaciones en las que están involucradas personas es muy importante dentro del proceso de desarrollo de software.

Una mala gestión de esas situaciones puede acabar con el proyecto o poner una resistencia que dificulte en gran medida la consecución de los objetivos, requiriéndose un mayor esfuerzo que tendrá un impacto en la materialización en el producto de las expectativas de los usuarios (si se pierde el enfoque en los objetivos y se desvía atención a problemas entre equipos o en el seno de un equipo)y también en aspectos presupuestarios porque el avance en el proyecto será más desordenado y en cada iteración o evolución perderá fuerza la intención como consecuencia de una menor atención por parte de la mayoría de las personas y equipos involucrados en el proyecto.

La siguiente cita de Alistair Cockburn resume perfectamente esta situación (traducción libre): “El fondo real del término ágil no se ha alcanzado todavía porque la gente todavía desvía su atención a la religión del proceso o al sueño de las matemáticas y olvida que nuestra industria está construida sobre personas que trabajan juntas, inventando y decidiendo sobre la marcha. Lo repito una y otra vez, lo importante son las personas, los seres humanos, con todos sus defectos. Las matemáticas y los procesos son relevantes, pero muchos más fáciles de gestionar que tratar con las personas reales que están delante nuestra”.