archivo

Archivos Mensuales: mayo 2011

Escribo mucho últimamente sobre Alistair Cockburn y es casi sin querer. Lo que pasa es que conforme voy adentrándome más en la lectura y comprensión del movimiento ágil en el desarrollo de software, voy conociendo iniciativas en las que este autor ha participado de forma individual o colectiva, como son por ejemplo, el manifiesto ágil, la PM Declaration of Interdependence o la escala Cockburn de clasificación de proyectos, además de otras no estrictamente ligadas a este movimiento como es su aportación a la extensión de la popularidad de los casos de uso. Además de todo lo anterior, me siento muy identificado con su particular visión del desarrollo de software.

En este caso, voy a tratar el conjunto o serie de metodologías Crystal desarrolladas por Alistair Cockburn y que surgieron con anterioridad al manifiesto ágil, de hecho su origen se remonta a mediados de la década de los noventa. Su apoyo al movimiento ágil es una consecuencia de su forma de entender el desarrollo de software y que queda perfectamente reflejado en Crystal.

Crystal está orientado principalmente en las personas que participan en el proyecto de desarrollo de software, ya que Cockburn entiende que en ellas está la clave para que el proyecto tenga oportunidades de éxito.

Concretamente el autor indica que Crystal está centrado en:

1.- Las personas
2.- La Interacción
3.- La comunidad
4.- Las habilidades
5.- Los talentos
6.- Las comunicaciones

Es decir, orientado al equipo de trabajo y a las personas que lo componen tanto a nivel individual como de su pertenencia a un grupo. Para Cockburn los procesos pese a ser importantes son secundarios, respecto a los principios en que está orientado este conjunto de metodologías, ya que la propia complejidad de la gestión de los equipos para obtener de los mismos el máximo rendimiento, teniendo en cuenta que están formados por un conjunto diverso de personalidades, experiencias, talentos y habilidades, es de por sí el principal problema que hay que resolver en el desarrollo de software.

Si extendemos esto a otras personas que participan en el proyecto, como pueden ser los usuarios que hacen las especificaciones del sistema, así como los responsables técnicos del cliente (en el caso de servicios de desarrollo que se prestan a terceros), la complejidad crece exponencialmente ya que a todo lo anterior hay que sumar los intereses de organizaciones distintas o incluso de departamentos distintos dentro de una organización.

Antes de entrar a realizar una breve descripción de las metodologías Crystal, que analizaremos en el próximo artículo, voy a exponer una serie de principios que definió Cockburn en 1999 y que definen el comportamiento de las personas dentro de los equipos de proyecto (o equipos de trabajo en general):

– Las personas son seres comunicativos, haciéndolo mejor cara a cara, en persona, con preguntas y respuestas en tiempo real.

– Las personas tienen problemas para actuar de manera consistente todo el tiempo.

– Las personas son altamente variables (cambiantes), varían de un día a otro y de un lugar a otro.

– Las personas generalmente quieren ser buenos ciudadanos, son buenos observando, tomando iniciativas y haciendo todo lo que sea necesario para el proyecto funcione.

Hay palabras, frases, que de repetirlas empiezan a perder todo su valor. Un ejemplo de ellos lo tenemos en destacar la importancia del capital humano, de las personas ya que es algo que se comenta muy frecuentemente como unas buenas prácticas de gestión, pero que después se pierde y queda muy oculta tras la importancia del capital estrictamente económico.

El capital humano, la importancia de las personas, del trabajo en equipo, debe pasar de los libros a la realidad. De eso eran muy conscientes los firmantes del manifiesto ágil o del PM Declaration of Interdependence. No hay proyectos sin personas, no hay éxito sin la colaboración de todos los que participan en el proyecto.

Se trata de establecer un entorno que favorezca que los integrantes del equipo de proyecto estén motivados, sean productivos y colaboren entre sí. Eso no da carta de naturaleza a que las personas que forman parte del equipo de trabajo hagan lo que quieran, quien no entienda que su trabajo es fundamental para que el proyecto salga adelante, quien no comprenda que si no cumple afecta al trabajo de todos sus compañeros, quien anteponga sus intereses individuales a los del grupo, sobra.

Ser productivo no es algo absoluto, como mínimo se trata de realizar por unidad de tiempo de la manera más eficaz posible el trabajo que podemos desarrollar en función de nuestras ganas, conocimiento, experiencia, entorno y naturaleza de la actividad que se realiza. Después si entendemos que progresar en este sentido nos favorece y si las circunstancias personales y profesionales no actúan en contra, iremos incrementando ese umbral.

Sin embargo ser productivo (teniendo en cuenta que la productividad y calidad de la ejecución de la tarea deben ir de la mano) no garantiza que los resultados conseguidos tengan un impacto positivo en la organización.

Estaríamos en estos casos ante una productividad desaprovechada o una productividad vacía. Por eso no solo es importante propiciar un entorno que fomente la productividad de los equipos de trabajo y las productividades individuales dentro de ellos, sino que el enfoque de las tareas que se encomiendan sea el adecuado.

Si sistemáticamente se desaprovecha la productividad no solo se está perdiendo una oportunidad presente sino que se está creando un caldo de cultivo para que el entorno productivo vaya desapareciendo. Cuando empiezan a existir apreturas económicas comienzan a tomarse decisiones, unas más justificadas y acertadas que otras, que por regla general tienden a romper la cohesión de los equipos y a desmotivar al personal.

Brian Marick es un experto en testing y en el lenguaje de programación Ruby. Fue uno de los firmantes del manifiesto ágil.

Toda la problemática del desarrollo de software viene originada por su naturaleza adaptativa que es el resultado de la infinidad de contingencias que se pueden producir a lo largo del proceso de desarrollo. Si lo que sucede a lo largo del proyecto fuera más previsible probablemente existirían menos problemas.

Sobre este tema Brian Marick realizó la siguiente reflexión:

“La verdadera complejidad de nuestro trabajo es que todo esta planificado bajo condiciones de incertidumbre e ignorancia. El código no es lo único que cambia: las calendarios se deslizan, se añaden nuevos objetivos, los requisitos cambian desde que se definen y durante el desarrollo, es cuando todos los participantes llegan a comprenden mejor el producto que se está implementando.”

Como en la traducción hay cambios sensibles respecto a la cita original (he realizado los cambios para que la idea quede más clara), os la pongo a continuación:

“The real complexity in our jobs is that all planning is done under conditions of uncertainty and ignorance. The code isn’t the only thing that changes. Schedules slip. New milestones are added for new features. Features are cut from the release. During development, everyone – marketers, developers and testers – comes to understand better what the product is really for.”

Si un proveedor entiende que en un proyecto es suficiente con hacer una entrega o una serie de entregas donde las funcionalidades que van a utilizar los usuarios a corto plazo tengan una cierta calidad, pero donde se descuidan otra serie de funcionalidades que tardarán más en ser probadas, está muy equivocado.

Tal vez sirva para cerrar el proyecto, pero el cliente, cuando se empiece a encontrar con un problema tras otro, se acordará muy mucho de quién ha realizado el trabajo.

Si la intención es fidelizar clientes, con lo complicado que es hoy en día conseguir eso, hay que entender el sistema que se desarrolla como una entidad en la que hay que cuidar la calidad en toda su extensión. Esto es compatible con hacer más énfasis en unos módulos que en otros, siempre y cuando en cada uno de ellos se supere un umbral mínimo de calidad exigible.

A veces buscar y conseguir un éxito cortoplacista supone encontrar un fracaso a largo plazo.

Entregar un hito, documental o de software, en malas condiciones por el hecho de cumplir un plazo solo sirve para que el cliente se enfade (y con razón). Al final supone una pérdida de tiempo mayor, por la vuelta a atrás del entregable, el tiempo que se ha dedicado a la revisión y el esfuerzo necesario en realizar las correcciones.

Por curioso que parezca, lo mejor que puede pasar es que se detecte que no está en condiciones porque el impacto de que el entregable se considere definitivo y se pase, por ejemplo, el producto a explotación con fallos que pongan en riesgo la disponibilidad del sistema, un manejo eficiente del mismo, una pérdida de datos o una combinación de estos problemas con otros muchos más que se pueden producir.

Si no cumples los plazos, no los cumples. Si no se ha podido replanificar o si has cometido el error de no avisar que va a existir una desviación, toca dar la cara, mucho mejor esto que entregar algo defectuoso, ya que el pecado es doble, no has cumplido el plazo porque entregar un hito así no es cumplir nada y otra incurrir en el riesgo de entregar algo de mala calidad.

A veces la fecha es inamovible y los plazos incumplibles y a veces el cliente lo sabe, otras no y otras se hace como que no lo sabe. Solo en estos casos, puede estar justificado entregar por entregar, pero advirtiendo siempre con suficiente antelación hasta dónde se puede llegar y los riesgos que se van a asumir y por supuesto, dentro de las posibilidades, intentar que la entrega tenga la mayor calidad posible.

La PM Declaration of Interdependence, actualmente llamada The Declaration of Interdepence for modern management, está compuesta por seis principios que tienen como objetivo mejorar el resultado de los proyectos mediante la aplicación de una serie de estrategias en la gestión de proyectos (inicialmente estaba orientada a responsables de proyectos que aplican metodologías ágiles, aunque puede generalizarse su utilidad a gestores que utilicen otras metodologías).

Fue consensuada en 2005 por quince profesionales de reconocido prestigio en el campo del desarrollo de software entre los que se encuentran un par de autores del manifiesto ágil como son Alistair Cockburn y Jim Highsmith.

Los seis principios son los siguientes (traducción libre):

Nosotros…

– Mejoramos el retorno de la inversión – haciendo continuo hincapié en el valor de nuestro enfoque (ágil).

– Obtenemos resultados fiables mediante – la interacción continua con el cliente y la responsabilidad compartida.

– Esperamos la incertidumbre y la tratamos a través de – iteraciones, anticipación y adaptación.

– Damos rienda suelta a la creatividad y a la innovación mediante – el reconocimiento de que las personas son lo más importante y creando un entorno donde puedan marcar la diferencia.

– Mejoramos el rendimiento a través de – la responsabilidad del grupo por los resultados y la responsabilidad compartida en la efectividad del equipo (el grupo en su conjunto es responsables del éxito o del fracaso y los componentes del equipo de proyecto tienen que colaborar en que el grupo funcione).

– Mejoramos la efectividad y confianza a través de – la aplicación de estrategias, procesos y prácticas específicos para el proyecto en cuestión.

Como la traducción que he realizado tiene cambios respecto al manifiesto, os pongo a continuación los principios tal cual se publicaron:

“We …

– Increase return on investment by — making continuous flow of value our focus.

– Deliver reliable results by — engaging customers in frequent interactions and shared ownership.

– Expect uncertainty and manage for it through — iterations, anticipation and adaptation.

– Unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.

– Boost performance through — group accountability for results and shared responsibility for team effectiveness.

– Improve effectiveness and reliability through — situationally specific strategies, processes and practices.”