archivo

Archivo de la etiqueta: Jim Highsmith

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.

Tener la capacidad de responder a un cambio de contexto lo antes posible, incluso de anticiparse o tener la capacidad de crear una tendencia solo puedo hacerse desde unas bases flexibles que permitan actuar de forma rápida.

Estas bases son los propios procesos organizativos pero también es cuestión de mentalidad (en general de la organización porque la adaptación al cambio es un esfuerzo común pero sobre todo de las personas que tienen poder de decisión tanto en la dirección como en los mandos intermedios). Es más, me atrevería a decir que es casi más mentalidad que procesos porque estos siempre dependerán de personas que harán más flexibles o rígidos los procesos o que incluso, llegado el momento los pueden obviar si fuera necesario.

Ahí es donde entra en juego la agilidad.

La importancia de adaptarse rápidamente al cambio no solo es cosa del desarrollo de software sino en general a cualquier aspecto de la vida. En el mundo de los negocios y de las empresas no adaptarte rápido al nuevo entorno o a un nuevo segmento de mercado puede suponer tu desaparición como organización o la insignificancia más absoluta de tu organización dentro de él.

A todo esto hay que añadirle el hecho de que los cambios de contextos, de tendencias, la aparición de más competencia y con nuevas ideas, etc… es algo continuo, no va a parar. En ocasiones requerirán menos esfuerzo de adaptación y en otras supondrá el replanteamiento o redefinición completa de determinadas líneas de actuación de la organización.

La siguiente cita de Jim Highsmith resume en pocas palabras esta circunstancia: “La agilidad es la capacidad tanto de crear como de responder a los cambios con el objetivo de obtener beneficios en un entorno empresarial turbulento”.

Comenta Jim Highsmith en el libro “Agile Software Development Ecosystems”: “Los planes son hipótesis a contrastar en lugar de predicciones a realizar”.

Resume la diferencia básica entre un enfoque evolutivo y un enfoque clásico.

El enfoque evolutivo está basado en iterar nuevas versiones del producto y mediante el feedback del usuario determinar en qué se ha fallado y en qué se ha acertado (por el momento) de manera que la siguiente versión sea mejor y más completa (con las nuevas tareas incluidas en el sprint), sin embargo en el enfoque clásico se espera que el proyecto transcurra linealmente porque todos los planteamientos iniciales serán igualmente válidos al final del proyecto.

Sé que la descripción que he realizado del enfoque clásico es demasiado ortodoxa y que todos los que desarrollan según este tipo de metodologías saben que no es así y que hay cambios prácticamente en todas las fases del proyecto o lo que es lo mismo, la predicción es imperfecta. Sin embargo aunque esto suceda el planteamiento en el proyecto seguirá siendo rígido (con determinadas concesiones al usuario) y alejado de un feedback sobre un producto real.

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.

En línea con el artículo de ayer comienzo éste con la continuación de la cita de Jim Highsmith indicada en el mismo (traducción libre): “Los agilistas creen en la adaptación al cambio y que este no se puede planificar desde la distancia. Puedes tener (como persona) flexibilidad, consistencia o una mezcla de ambas, pero esperar que un proceso o una metodología puedan proporcionar máxima flexibilidad y completa predecibilidad a la vez supone sobrepasar los límites de la credulidad”.

Pensar que los procesos o metodologías pueden prever todas las contingencias que pueden producirse en un desarrollo no es algo real, de hecho sabemos que no lo es y supone un problema cuando necesitamos sobrepasar las barreras de un proceso o de una metodología y sin embargo no nos dejan (visión finalista del proceso: el proceso está por encima de todo, incluido el producto que se está desarrollando.

Sin embargo pensar en los procesos o metodologías como instrumentos cambia absolutamente el escenario de partida, el desarrollador, el equipo de proyecto y los stakeholders (si fuera necesario) definen la mejor forma de afrontar una determinada situación.

Cuando se está obsesionado con el proceso, con la repetibilidad, con el control es complicado darse cuenta que la salida no es más de lo mismo sino un cambio de enfoque en cuanto al rol que deben desempeñar en el proceso de desarrollo de software. Sin embargo, una reacción demasiado frecuente cuando los procesos no terminan de dar una respuesta consiste en extender más los procesos y hacerlos todavía más rigurosos.

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

Comenta Jim Highsmith que: “Quien toma la decisión es menos importante que hacer que la gente adecuada intervenga en el proceso de toma decisiones”.

Uno de los mayores errores de las personas que tienen que tomar decisiones, es decir, de todos nosotros porque a nuestra escala lo estamos haciendo continuamente, consiste en acariciarnos el ego tomando decisiones sin contar con nadie o minimizando la intervención de terceras personas.

Puede que seamos (o nos consideremos) los mayores expertos en una materia, puede que las personas que nos tengan que ayudar no tengan ni ese conocimiento ni esa experiencia pero eso no justifica que perdamos la oportunidad de que nos puedan aportar valor porque nadie puede controlar todas las perspectivas y es muy probable que ellos puedan aportar matices que no se hayan tenido en cuenta o puedan aportar ideas que enriquezcan la decisión final que se tome.

Además y por regla general no suele ser tanta la diferencia de conocimientos y experiencia entre la persona que tiene la última palabra y las personas que pueden aportarle valor a esa toma de decisiones (es más, lo normal es que en el área sobre la que se tenga que tomar la decisión, estas últimas tengan un conocimiento mayor, ya sea de base y/o por su mayor proximidad al problema o hecho sobre el que hay que decidir).