archivo

Archivo de la etiqueta: escala Cockburn

En el artículo anterior, se realizó una introducción de la filosofía que hay detrás de las metodologías Crystal, en este entraremos en el detalle de las mismas.

En primer lugar, ¿por qué reciben el nombre de metodologías Crystal? La denominación Crystal no está elegida al azar, ¿qué es un cristal sino un núcleo común con diferentes caras?.

Las metodologías Crystal se basan en el hecho de que hay que tener en cuenta las características del proyecto para aplicar una metodología (para Cockburn son un conjunto de elementos entre los que se encuentran las prácticas y las herramientas) u otra, no es lo mismo un proyecto en el que intervienen pocas personas que otros en donde intervienen muchas. Entender que todos los proyectos son iguales independientemente de su tamaño es un error que puede derivar desde pérdidas económicas hasta el fracaso completo.

También es fundamental tener en cuenta la criticidad del proyecto, no es lo mismo el desarrollo de sistemas de los que pueden depender la vida de personas o la propia subsistencia de una organización que otros desarrollados para informatizar procesos de gestión pero que no resultan realmente críticos.

Como consecuencia de la consideración de estas dos dimensiones: tamaño del equipo y criticidad surgió la escala Cockburn de clasificación de proyectos software cuyo utilidad va más allá de definir en qué condiciones aplicar una metodología Crystal u ota, sino que también puede ser utilizado para definir la aplicabilidad de otras metodologías diferentes a estas en función de la naturaleza del proyecto.

Las metodologías Crystal van, en función del tamaño del equipo de proyecto, denominándose con colores más oscuros y en función de la criticidad por la dureza del cristal, de manera que tenemos:

– Metodología Crystal Clear (equipos hasta seis personas), Crystal Yellow (equipos entre seis y veinte personas), Crystal Orange (equipos entre veinte y cuarenta personas), Crystal Orange Web, Crystal Red (equipos entre cuarenta y ochenta personas), Crystal Maroon (equipos entre ocheta y doscientas personas).

– Metodología Diamond y Sapphire en función de si del sistema depende la vida de las personas o la subsistencia de la organización.

Las metodologías Crystal tienen, por lo general, los siguientes puntos en común:

– Entregas frecuentes: Se basan por tanto en una estrategia de desarrollo iterativa e incremental. En función de las características del proyecto se pueden establecer entregas desde semanales hasta trimestrales. Esta característica va en consonancia con la naturaleza adaptativa del proceso de desarrollo de software, permitiendo ajustar progresivamente el sistema a las necesidades de los usuarios.

– Mejora reflexiva: La existencia de un desarrollo iterativo e incremental, favorece la mejora del sistema y de los procesos a través del feedback que se obtiene tanto de los usuarios como del propio equipo de proyecto. Si algo no funciona saldrá a la luz más pronto que tarde. Pero no solo es necesario esperar al resultado de las entregas para pensar en posibles mejoras en los procesos, por eso, es frecuente encontrarse con reuniones cada dos o tres semanas del equipo de proyecto específicas para detectar e intentar corregir aspectos de la dinámica del proyecto y del proceso de desarrollo que no están funcionando como debieran.

– Comunicación cerrada u osmótica: El equipo de proyecto debe encontrarse en una misma ubicación física, si es posible compartiendo la misma habitación, mejor. De esta forma se reducen las distracciones y se mejora la concentración, la información fluye más rápidamente dentro del equipo de proyecto, las dudas se resuelven más pronto, se favorece la colaboración entre los miembros del equipo de proyecto. Por otro lado disminuye el overhead inherente a la comunicación a distancia, es decir, se reduce la comunicación por correo electrónico, la necesidad de documentación extra, etc…

– Seguridad personal: En el equipo de proyecto todos tienen derecho a expresas sus ideas y opiniones (dentro de un orden), cada integrante debe tener la seguridad de que no va a ser ridiculizado o no tenido en cuenta sin sopesar siquiera lo que está comentando.

– Enfoque: El enfoque en las metodologías Crystal tiene dos vertientes. Por un lado el enfoque en conseguir que se pueda dedicar tiempo suficiente sin interrupciones en las diferentes tareas de un proyecto para que progrese adecuadamente y por otro el enfoque en la dirección del proyecto.

En el primer caso se establecen períodos de no interrupción a los desarrolladores (por regla general dos horas) y por otro garantizar la continuidad en el desarrollo de las tareas superponiendo desarrolladores con antelación al cambio de proyecto de uno de ellos.

En el segundo caso para conseguir que la dirección del proyecto sea adecuada es necesario que los desarrolladores tengan totalmente claros los objetivos del mismo y que el responsable del proyecto priorice en cada momento los mismos para permitir al equipo de proyecto centrarse en tareas concretas.

– Fácil acceso a usuarios expertos: La participación e implicación de usuarios expertos en el proyecto resulta esencial. Estas metodologías no exigen que los usuarios expertos tengan presencia continua en el equipo de proyecto (se es consciente de que no todas las organizaciones pueden poner personal de estas características al servicio del proyecto), pero sí que como mínimo semanalmente se deben mantener encuentros de al menos un par de horas con ellos y existir accesibilidad para tener comunicaciones telefónicas si fuera necesario.

– Entorno técnico con pruebas automatizadas, gestión de la configuración e integración continua.

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.

Alistair Cockburn, firmante del manifiesto ágil, creador de la familia de metodologías Crystal, de la escala Cockburn de clasificación de proyectos e impulsor de la aplicación de la tećnica de casos de uso para la definición de la interacción actores y sistemas de información (casi nada), realiza la siguiente reflexión en su libro: “Agile Software Development” (traducción libre): “Todavía nos encontramos en la infancia de definir lo que realmente está ocurriendo en los proyectos de desarrollo de software”.

Es cierto que conocemos cosas importantes. Algunos ejemplos son los siguientes:

– Un software se considera de calidad si satisface las necesidades del usuario (principalmente) y se desarrolla dentro del presupuesto y plazo establecido (si ambos resultan razonables).

– Las personas, su correcta comunicación e interacción, la existencia de una relación de confianza, la motivación, la persecución de un fin común son fundamentales para que un proyecto tenga probabilidades de éxito.

– El desarrollo de software tiene una naturaleza adaptativa.

– Las metodologías proporcionan marcos de trabajo y no soluciones. Son un medio para alcanzar un fin y por tanto es conveniente que la técnica aplicada sea la más adecuada al proyecto, pero para conseguir el éxito son necesarias muchas variables más.

– La tecnología es un medio no un fin.

– Resulta complicado que en dos proyectos de desarrollo de software se produzcan las mismas contingencias.

Sin embargo, si todo fuera la aplicación de una serie de reglas todos los proyectos de desarrollo tendrían éxito y no es así. Solo disponemos de nuestra experiencia, nuestros conocimientos, de una serie de realidades que se podrían considerar comunes en los procesos de desarrollo (como las enumeradas anteriormente), una serie de metodologías y una serie de buenas prácticas. Todo lo anterior no es poco, pero como comenta Alistair Cockburn (aunque su cita sea del año 2001 y se haya progresado mucho desde entonces), todavía tenemos mucho que aprender, ya que hay que tener en cuenta que la disciplina de desarrollo de software es relativamente reciente.

Alistair Cockburn, que fue uno de los firmantes del manifiesto ágil, realizó una escala que tenía como objetivo realizar una clasificación de los proyectos de desarrollo de software en función del grado de formalidad que requerían a lo largo de su ciclo de vida. Esta escala tenía una vocación generalista y, por tanto, no estaba enfocada exclusivamente al desarrollo mediante metodologías ágiles.

El objetivo es poner de manifiesto que todos los proyectos no son iguales y que cada uno de ellos requiere dedicarle un esfuerzo desde el punto de vista metodológico acorde a su naturaleza, con el objetivo de optimizar su coste (y duración).

La clasificación de los proyectos se realiza en función de su tamaño y su criticidad.

Desde el punto de vista del tamaño se le asigna un valor en función del número de personas que participarían en el proceso de desarrollo del proyecto. Por regla general se eligen valores de la siguiente secuencia: 6 (proyectos entre 1 y 6 personas), 20 (proyectos entre 7 y 20 personas), 40 (proyectos entre 21 y 40 personas), 100 (proyectos entre 41 y 100 personas) y 200 (proyectos entre 101 y 200 personas). Esta clasificación por tamaño puede variar y encontrarnos con clasificaciones de la escala Cockburn que utilizan otros valores.

Desde el punto de vista de la criticidad se le asigna una de las siguientes opciones en función del peor de los casos que se pueda producir en el caso de un fallo del sistema:

– L: Pérdida de una vida.
– E: Importante pérdida económica que puede poner en riesgo la continuidad de la organización.
– D: Pérdida económica no significativa.
– C: Pérdida de comodidad.

Para determinar el grado de formalidad se crea una matriz bidimensional:

L6 L20 L40 L100 L200
E6 E20 E40 E100 E200
D6 D20 D40 D100 D200
C6 C20 C40 C100 C200

El grado de formalidad crece conforme nos movemos hacia la derecha y hacia arriba.

¿En qué se traduce la formalidad? Lo que se pretende es determinar la metodología a utilizar, pudiendo existir diferentes metodologías válidas para un par concreto de tamaño y criticidad.