Mes: diciembre 2008

Técnicas ágiles y CMMi nivel 2 en un proyecto de Banca

Introducción

Recientemente en Biko obtuvimos la certificación CMMI nivel 2. Tras un periodo de estudio de los procesos convenientes para el funcionamiento de la organización, estos fueron validados y aprobados mediante el SCAMPI.

Este nivel de la metodología formal se centra en determinadas áreas, como planificación, gestión de requisitos, métricas, y verificación y validación.

En Biko, CMMI ha servido para uniformizar criterios importantes sobre la gestión de los  proyectos, que dada la heterogeneidad de los múltiples proyectos desarrollados en la organización, ha sido un hito muy importante.

Pero CMMI en su nivel 2 no especifica nada sobre las metodologías de desarrollo o gestión del equipo, ni del proceso concreto de creación de software. Es por eso por lo que hemos ido un paso más allá, y hemos buscado técnicas para el mejor control del desarrollo.

Las metodologías ágiles de desarrollo van hacia otro objetivo que las metodologías formales. Se centran “en los individuos y sus interacciones más que en procesos y herramientas”. Algunas de las más importantes son las basadas en el concepto de “Lean development”, u otras más concretas como pueden ser “Scrum” y “XP”.

Nuestra idea era empezar a experimentar con los desarrollos con metodologías ágiles, en concreto con Scrum, para poder mejorar la eficiencia del equipo. En este artículo presentamos la primera aproximación que realizamos, nuestra implementación y conclusiones.

 

Escenario

Tras un proyecto desarrollado con algunos problemas para un cliente de Banca, se nos plantea hacer un segundo desarrollo. Es entonces cuando buscamos la solución que mejor pueda solucionar los problemas encontrados anteriormente.

Los problemas a los que intentamos dar solución:

  • Pérdida de control del proyecto por los desarrolladores. Conocen parte del proyecto, pero a veces repetimos soluciones diferentes para el mismo problema.
  • Se intentó entregar por iteraciones, pero estas nunca quedaban definidas, y pronto se perdió el control exacto de las funcionalidades incluidas en cada entrega.
  • Las peticiones de cambio generadas por un cliente muy pendiente del desarrollo del proyecto, eran muy numerosas. La gestión de requisitos mediante una hoja Excel no ayudaba demasiado.
  • El cliente quedó medianamente satisfecho con el producto final, pero éste quedó con carencias importantes. Además, la etapa de desarrollo fue muy dura tanto para el equipo como para el cliente.

Organización y Gestión

Para el segundo proyecto nos planteamos utilizar metodologías ágiles, para mejorar la eficiencia del equipo. ¿Por qué? Estos son algunos de los puntos que tomamos en cuenta como punto de partida, donde las metodologías ágiles podían ayudarnos más:

Como primera experiencia nos basamos en Scrum. Pero no la implementamos al 100%, realmente la adaptamos. Así que “no decimos que usamos Scrum”. Pero, ¿por qué lo modificamos?

  • El alcance ya estaba definido con el cliente. Los contratos a precio cerrado no son el mejor encaje para las metodologías ágiles.
  • Requeríamos un análisis previo, para la validación por el cliente, una fase inicial donde estudiásemos la globalidad del proyecto. En ese momento nos pareció la mejor solución para evitar los continuos cambios que se habían sucedido anteriormente. Cerrar el alcance en el inicio de una manera más clara no es un concepto demasiado ágil, pero las presiones por las desviaciones en proyectos anteriores nos hicieron pensar que podía ser útil.

Como este proyecto era la continuación tecnológica de uno anterior, minimizábamos el riesgo, y podíamos extrapolar mejor las conclusiones de la implantación.

  • Proyecto tecnológicamente conocido: El primer proyecto fue el que estableció las bases tecnológicas, y salvó los escollos más importantes en esta área. Teníamos mucho trabajo por hacer, para mejorar la plataforma creada, pero consistía en refactorizar elementos.
  • Cliente recurrente: conocíamos cómo trabaja, y podíamos adaptar nuestra manera de desarrollar para su satisfacción.

El equipo

El equipo, visto desde el prisma de sus roles tradicionales ha sido: dos desarrolladores, un diseñador, y un analista funcional y un jefe de proyecto. Realmente el equipo que trabajó bajo las premisas de gestión ágil de dedicación a tiempo completa al proyecto fueron todos excepto la gente de diseño, puesto que trabajaron en momentos más puntuales.

Los perfiles eran bastante distintos en cuanto a experiencia, conjugando dos personas con un año escaso, con otras de casi 10 años en el desarrollo de software. La autogestión del equipo fue un hecho desde el primer momento, teníamos claro qué tareas se debían realizar, y cada persona era autónoma para decidir cuáles realizar, compartiéndolo con el equipo o discutiéndolo. Las reuniones diarias y de planificación de iteración (Sprin) eran una asignación de tareas por acuerdo.

Desarrollo

La idea inicial era utilizar Scrum para el desarrollo del proyecto. Sin embargo, echando la vista  atrás no podemos decir que lo hayamos utilizado, puesto que hemos hecho modificaciones importantes, y no hemos aplicado todas sus técnicas.

Antes de empezar el ciclo de iteraciones hicimos una fase cero del proyecto:

  • Arranque del proyecto: Preparación del catálogo de requisitos (Product Backlog).
  • Fase 0: Análisis funcional, y diseño de la interfaz y su arquitectura. Esta fase fue requerida por el cliente para su validación.
  • Fase N, Iteraciones semanales: Trabajo definido por el equipo. Cierre con demostraciones de la versión y puesta en desarrollo para el cliente.

Nuestro grado de avance y situación lo llevamos simultáneamente en una herramienta de gestión de proyectos (JIRA) y en una pizarra blanca:

image005(1)

  • La pizarra proporciona una inmediatez del trabajo efectuado/restante que da una sensación de control del proyecto muy importante. Es un mapa del site que se puede ver con solo girar la cabeza, y ¡no hay que hacer un solo click! Scrum recomienda un tablero de tareas con “post-it”, pero creemos que esto es igual de útil.
  • JIRA nos proporciona soporte para asociar a las tareas documentación, partes de horas, comentarios de los desarrolladores, enlaces al código de Subversion…, a costa de un mayor gasto de gestión, pero que, una vez habituados a la herramienta, es muy escaso. Además también nos proporciona el EDT (Estructura de Desglose de Tareas) actualizado, basándonos en las tareas cerradas/abiertas y sus estimaciones.

    También sustituimos la gestión de cambios de requisitos, pasando del “Excel” a la gestión de tareas identificadas como “Nuevos Requisitos” en JIRA.

Por tanto, teníamos la información duplicada, en la pizarra y en JIRA, pero el coste de mantener ambos no es elevado. La pizarra proporciona inmediatez en la visión del proyecto, y JIRA nos proporciona trazabilidad con el código.

Por cada iteración definíamos qué trabajo íbamos a realizar para entregar (Sprint Backlog) como resultado de esa semana (Sprint).

Cada 15 días, además, realizábamos una reunión de seguimiento con las personas no directamente implicadas: gerente y diseñador. Estas reuniones se hacían de manera bastante informal, pero eran una práctica acordada en el desarrollo de CMMI. Daban más visibilidad del desarrollo a las partes implicadas.

Conclusiones

Este ha sido un proyecto de introducción de novedades en gestión del equipo de desarrollo de software. Estamos aplicando por ejemplo en otros proyectos una aproximación mucho más estricta de Scrum. Pero he aquí algunas conclusiones que podemos extraer:

  • Las iteraciones semanales son demasiado cortas. Este proyecto era de duración reducida, pero unas iteraciones tan cortas introducen mucho “ruido” del cliente demasiado cerca de la siguiente finalización de la iteración.
  • No aceptar cambios en el plan de iteración (solo corrección de “bugs” de la iteración anterior, para lo que se deja un tiempo) es una gran idea. Puedes controlar cómo funcionas respecto a tu planificación.
  • El equipo controla todas las partes del desarrollo. Las reuniones diarias de 10’ son puestas como ejemplo y destacadas por los integrantes del equipo como una maravillosa práctica. Los perfiles de menos experiencia se benefician en gran medida de las reuniones diarias, donde se les resuelve el 90% de sus problemas. Nunca se bloquean en un trabajo más de 8 horas sin que el equipo lo sepa. Todo el equipo involucrado ha destacado la utilidad de las reuniones diarias, especialmente la gente con menos experiencia.
  • El problema de un proyecto con horas cerradas sigue pendiente. Tienes unas horas de una estimación inicial al inicio de proyecto, que engloban a todas las funcionalidades, y realmente no ves y estimas adecuadamente las tareas hasta el principio de cada iteración.
  • La primera iteración o fase 0, es muy interesante, porque proporciona una base común para el trabajo posterior. En este caso no teníamos problema para la solución técnica, pero si no hubiese estado hecha en un proyecto anterior, posiblemente la hubiésemos planteado aquí. De esta manera podemos establecer una base de cómo realizar las cosas, útil especialmente trabajando con desarrolladores más inexpertos.

 

Artículos relacionados

 

Métricas ágiles y cuadro de mandos integral para Scrum

La métrica más importante en un proyecto ágil como Scrum es el valor que se está dando al cliente. Mediante esta métrica, el cliente puede conocer la velocidad con que retorna su inversión y saber cuándo ya no es necesario seguir con el proyecto, por que los beneficios pendientes de obtener ya no compensan sus costes.

Sin embargo, cuando se mide a una persona o a un equipo de una determinada manera, sus acciones pueden desviarse en exceso hacia ese objetivo y descuidar otros aspectos también importantes como, por ejemplo, la calidad, los costes, los riesgos, la sostenibilidad de la velocidad con que obtienen objetivos, etc. Por ello, puede ser necesario utilizar un conjunto de métricas de diferentes aspectos relacionados, creando de esta manera un cuadro de mandos integral ágil (agile balanced scorecard).

graficos-progreso-scrum

 
Selección y uso de las métricas
Respecto al valor aportado al proyecto, es recomendable que esté basado en un único indicador económico clave con el que el cliente pueda medir todos los objetivos del proyecto, de forma que permita guiar la toma de decisiones y la forma de invertir en el proyecto.
Para el resto del cuadro de mandos se debe escoger el mínimo número de métricas que permita tomar decisiones sobre los resultados del proyecto y las necesidades del cliente (tras un análisis causal de los problemas que están mostrando, siempre recordando que el uso de una métrica puede condicionar la actuación de las personas). Se debe minimizar tanto el coste e impacto que se añade al trabajo ordinario del equipo (hay que ir registrando lo que sucede, cosa que puede incluso desvirtuar la métrica) como su coste de recolección, proceso y presentación. Por todo esto, cuando un problema específico esté resuelto, hay que plantear si tiene sentido seguir recogiendo las métricas asociadas.
Es conveniente mostrar en el cuadro de mandos los objetivos de la iteración, entrega, proyecto, programa u organización, según sea el ámbito del cuadro de mandos (mostrar la velocidad con que se consiguen los objetivos del proyecto o guiar e informar sobre la estrategia de la organización y su cumplimiento).
En los equipos ágiles es común que las métricas surjan ante una necesidad del equipo, como una forma de mejorarse. Por ejemplo la velocidad del equipo puede ser una herramienta para que el equipo planifique y tome compromisos, e incluso para cuantificar una mejora.
Será fundamental presentar las tendencias de las métricas a lo largo del tiempo (los valores en un momento dado pueden deberse a situaciones puntuales), con diferentes niveles de agregación en función de las necesidades: diario, iteración, etc.
 
Métricas ágiles del cuadro de mandos
La mayoría de las métricas más importantes derivan de las herramientas propias de Scrum (la lista de requisitos priorizada, la lista de tareas de la iteración y los gráficos de trabajo pendiente), por lo que el momento natural para actualizar este cuadro de mandos es tras la retrospectiva de la iteración.
Notar que en una gestión ágil de proyectos carece de sentido utilizar algunas de las métricas más utilizadas en proyectos tradicionales o en cascada, como por ejemplo:
  • El porcentaje de completitud de un objetivo o requisito: en un proyecto ágil, para poder determinar cuando se completa un requisito o entrega se utiliza concepto de esfuerzo pendiente, así como qué objetivos están completados o cuáles no (al cliente no le interesan los que están en curso ya que no puede hacer uso de ellos)
  • Los diagramas de Gantt: no aportan más información que la que aportan las herramientas propias de Scrum.
Las métricas de uso más común se muestran en negrita. Las que no aparecen en negrita se muestran como ejemplos de métricas que se pueden utilizar de manera más temporal para analizar problemas concretos.
Métricas de productividad y efectividad de la entrega
  • Velocidad con que se completan objetivos/requisitos en cada iteración. Idealmente debería aumentar con respecto al tiempo (productividad). También permite ir extrapolando la fecha de finalización del proyecto en función de cuando se vaya a completar todo su alcance.
  • Tiempo de entrega de un requisito tras su petición o Lead Time (responsividad a necesidades del cliente, Time to Market, tiempo de servicio), en función de la criticidad de la petición (urgente, etc.) y cumplimiento de los Acuerdos de Nivel de Servicio (ANS / SLA).
  • Urgencias y prioridad/valor de los requisitos completados, para comprobar si existe desalineamiento con los objetivos del proyecto y/o la estrategia de la organización.
Métricas de resultados del proyecto
  • Velocidad con que se aporta valor al negocio (desde el punto de vista del cliente).
  • Valor acumulado.
  • Requisitos completados en la iteración.
  • Próximos requisitos a desarrollar.
  • Cambios incorporados y requisitos añadidos sobre el alcance inicial del proyecto.
  • Número de requisitos completados respecto al total de requisitos (métrica que también permite observar cambios de alcance).
  • Días de trabajo ideales pendientes (métrica que permite proyectar la fecha de finalización del proyecto).
  • Desviación de resultados de proyecto respecto a planificación inicial.
Métricas de situación financiera
  • Retorno de Inversión (ROI) pendiente, el valor pendiente respecto al coste pendiente, para saber cuándo finalizar el proyecto (ver la cláusula de finalización anticipada del contrato en el artículo Un contrato ágil para Scrum).
  • Presupuesto disponible y/o presupuesto gastado.
  • Desviación financiera respecto a la planificación inicial.
Métricas de calidad
Expectativas:
  • Satisfacción del cliente / usuario, respecto a los resultados del proyecto y a la colaboración con el equipo.
  • Ambiente en el equipo
Calidad funcional:
  • Incidencias (defectos encontrados por el cliente o usuarios del producto), por estado y por criticidad.
  • Errores (defectos detectados internamente, bugs), por estado y por criticidad.
  • Cobertura de las pruebas.
  • Trazabilidad.
Mantenibilidad:
  • Días de deuda técnica.
  • % de código en SCM (e.g. GIT), motor CI (e.g. Jenkins),  herramienta de control de calidad de código (Sonar).
    • Separando las partes «nuevas / refactorizadas» del monolito.
  • Cumplimiento de estándares de codificación, normativas, regulaciones, etc.
  • Comentarios en el código.
  • Complejidad ciclomática del producto.
  • Tamaño de las operaciones.
  • Calidad de la documentación (existencia y cobertura de la documentación funcional, técnica, de pruebas, de implantación, operativa, etc.).
Métricas de riesgos, impedimentos, proceso y mejora continua
  • Riesgos (severidad y mitigaciones) e impedimentos: considerando las dependencias o sinergias con otros equipos o proyectos, la implicación del cliente, los problemas tecnológicos, el resultado de las retrospectivas, etc.
  • Lecciones aprendidas.
  • Actividades de mejora a planificar (comunicaciones, formaciones, soporte, herramientas, etc.).
  • Uso de prácticas específicas: número de integraciones, tiempo de refactorización, de TDD, revisiones expertas, etc.
  • Situaciones anómalas: sobreesfuerzo, requisitos no completados, terminaciones anormales de iteración, interrupciones, sospechas de mala aplicación del proceso (por ejemplo, si el cliente se muestra sorprendido en la demostración de la iteración), etc.
  • % de personas que no intervienen en las reuniones diarias de sincronización.
 
Conclusiones sobre el estado del proyecto
Este apartado debe contener un resumen con las métricas más importantes y las relaciones entre ellas, así como las lecciones aprendidas y próximas acciones de mejora (tras un análisis causal de problemas como, por ejemplo, el que se realiza en una retrospectiva), de manera que el cliente pueda tomar decisiones informadas y dirigir los resultados del proyecto.
Hay que recordar que muchos de los problemas detectados y disfuncionalidades de la organización ya estaban ahí antes de utilizar una gestión ágil de proyectos como Scrum, no son el resultado de aplicarla. La transparencia que proporciona Scrum los hace más visibles, lo cual ayuda a priorizar y tomar decisiones (de manera conjunta con las personas implicadas para consensuar la mejor solución). Para ello es necesario disponer del máximo apoyo de la Dirección para alinear comportamientos, recursos y resultados con la estratégia de la organización.
 
Más información