archivo

Archivos Mensuales: agosto 2012

La respuesta a esta pregunta dependerá de si eres programador o tester y de la experiencia que hayas tenido en modelos de trabajo en los que intervienen ambos tipos de perfiles.

Como he leído en más de una ocasión: el objetivo del testing no es encontrar incidencias sino de proporcionar información sobre la calidad del producto (algo que cubre un dominio mucho más amplio de actuaciones).

Alcanzar ese objetivo no es fácil porque requiere un cierto background previo:

– Que los programadores consideren a los testers y los testers a los programadores como parte de un mismo equipo que busca un mismo fin: el desarrollo de un software de calidad que satisfaga las expectativas de los usuarios. Esto requiere tirar muros para conseguir una mayor cercanía (no necesariamente física, aunque si lo es, mejor).

– Un mismo fin no se ve de igual manera si existen diferentes niveles de implicación: Todos somos, dentro de nuestro rol, importantes para alcanzar los objetivos del proyecto y por tanto nuestro nivel de implicación para conseguirlo debe ser el mismo.

– Que los objetivos de calidad del software estén consensuados entre todas las partes y sean acordes a la naturaleza del producto y al contexto del proyecto. Además se debe dar la posibilidad a que sean modulados en función de los cambios que a buen seguro se producirán a lo largo del proceso de desarrollo.

– Que los mecanismos y métricas para medir el grado de cumplimiento de los objetivos sean conocidas y objetivas.

– Que los procesos no obstaculicen un modelo de trabajo que requiere flexibilidad y comunicación continua (sin comunicación este modelo no funciona).

Hace poco me encontré con la siguiente cita de Heinz von Foerster : “Actúa siempre para incrementar el número de opciones”.

Lo contrario a incrementar el número de opciones es incrementar el número de restricciones y por tanto acotar nuestra capacidad de ser flexibles y en consecuencia limitar nuestro margen de actuación a la hora de adaptarnos al cambio.

Me parece una reflexión muy interesante tanto para un enfoque ágil en los proyectos de desarrollo de software como prácticamente en cualquier ámbito de la vida.

Cuando tomamos decisiones (algo que hacemos casi constantemente) estamos actuando a favor o en contra del número de opciones que tendremos con posterioridad a la misma. En determinados momentos tendremos que tomar decisiones más restrictivas ya que no siempre es posible tener abierto todo el rango de posibilidades. Sin embargo, pese a esto, resulta interesante que las restricciones no vayan más allá de lo que realmente se necesita, con el objeto de no eliminar innecesariamente opciones o posibilidades que después nos pudieran resultar de utilidad.

Me parece muy interesante la siguiente cita de Brian Marick: “Trabajar solo es trabajar sin red”. La cita la realizó reflexionando sobre el “pair testing” si bien es aplicable, en mi opinión, a todos los campos del desarrollo de software.

Respeto a quienes quieren trabajar solos, es su decisión y tiene sus ventajas y sus inconvenientes. Todo empieza y termina en ti y detrás tuya no hay nada ni nadie, es como dice Brian Marick, un salto sin red.

Sin embargo en el contexto de un equipo de proyecto hay que pensar en términos de equipo y no en términos individuales. Tienes tus tareas pero no eres ajeno a la dinámica de un equipo, formas parte de un engranaje y la maquinaria no funciona si cada componente lo hace a su aire.

La reflexión de Marick es extrapolable a los resultados de una determinada versión del producto, si lo revisa otro equipo o se revisa de nuevo el trabajo estaremos dando una oportunidad a detectar deficiencias y a reducir la incertidumbre sobe el resultado final.

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.

Muchas veces cuando se cuestiona la visión ágil en el desarrollo de software parece que se viene a decir que los agilistas desean el cambio y que si no lo hay, ellos mismos se encargan de que lo haya.

Mi opinión es que no es así. A todos el mundo le encantaría tener una receta que siguiéndola de principio a fin diera lugar a un proyecto con éxito. Si tuviéramos esa receta la aplicaríamos porque ¿para qué complicarnos la vida?. El cambio da lugar a quebraderos de cabeza, la línea recta es mucho más sencilla, el cambio por regla general no gusta, no es cómodo, salvo en aquellos casos donde el camino iniciado sea incorrecto o estemos en una situación en la que no lleva a ningún sitio. Es decir, el cambio (provocado) solo cobra sentido si es para mejorar un determinado estado o situación

El cambio es el resultado de que todo está en “movimiento” bajo un contexto de incertidumbre (no sabemos qué va a pasar, podemos tener sospechas o predicciones, tener los riesgos bajo supervisión e incluso con contramedidas, pero no es posible tener todo bajo control): el proyecto, el cliente, el negocio, nuestra propia organización, los usuarios, nosotros mismos, etc… Si estos cambios afectan al proyecto hay que reaccionar y cuanto antes mejor y para que la adaptación sea rápida se requiere flexibilidad, actitud y orientación al producto, además de unas condiciones de partida que faciliten (permitan) el cambio: procesos que permitan realizar los ajustes rápidamente, equipos de proyecto que tengan conciencia de la realidad del desarrollo de software, una arquitectura y un software mantenible, etc…

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.

Muchos desarrolladores tenemos el defecto de ir a donde no nos llaman, a prestar atención a tareas que son ajenas o que no deberían ser prioritarias y como consecuencia de ello no ponemos todo nuestro enfoque, energía y atención en lo que debe ser nuestro trabajo.

El tiempo es limitado, si lo repartes mal lo prioritario se resiente.

El inconveniente de meterte donde no te llaman no es solo el tiempo perdido sino los líos en los que te terminas metiendo que a su vez requerirán más tiempo y te quitarán concentración en tu trabajo. Generalmente no sienta bien que te metas en los asuntos de otro como a ti tampoco te suele gustar que se metan en los tuyos.

Sé que es difícil estar ajeno a todo pero sabemos que tan importante es prestar atención a lo prioritario como no hacerlo en aquello que ni nos va ni nos viene. Quienes consiguen centrarse en lo suyo (o hacerlo más tiempo) tienen una gran ventaja sobre aquellos que no lo hacen ya que estos últimos tienen que recorrer más kilómetros para llegar al mismo destino.

Es lo que digo muchas veces: el talento es importante pero la actitud y la forma en que se emplea es lo que realmente marca la diferencia. El talento solo, es fuerza bruta que a veces puede dar resultados y otras no conseguir nada o incluso empeorar la situación ya que hay que tener en cuenta que esto es un trabajo en equipo y dentro de ese equipo, si no funcionas no quiere decir que sumes cero sino que lo más probable es que restes.