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

Mon, 29/12/2008 - 13:52 - José Ramón Díaz

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:

“Empowerment” del equipo. Reforzar su capacidad de decisión y confianza.
Basadas en iteraciones y entregables funcionales:
- Proporcionando mayor control para el cliente.
- Y mayor control de las versiones por parte del equipo, sobre qué funcionalidades estaban realizadas y cuáles en desarrollo.
Además, compatible con nivel 2 de CMMi

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:

tareas-site-map

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.

Comments

Sun, 14/06/2009 - 08:41 - Raul Uribe (not verified)

Tengo la siguiente duda, cuanto duró su sprint cero? de diseño y planificación...

Entiendo que se trataba de un proyecto fase II o algo así, pero, si hubiera sido un desarrollo completamente nuevo, donde hacia falta la definición de la arquitectura de la solución y el diseño se hace mucho mas pesado...Cuánto le hubieras dado a ese sprint 0?

Slds,

Raúl.

Mon, 15/06/2009 - 07:29 - Jose Ramón (not verified)

Bueno, idealmente me gustaría decir que no lo hubiese hecho ;), si no que desde el principio agregaríamos valor al producto creando historias y favoreceríamos el diseño emeergente...
Pero bueno, que la duración del sprint no la cambiaría ni para el sprint 0, así que la misma que el resto de sprints, en nuestro caso, dos semanas.

Sat, 23/05/2009 - 07:49 - Javier Santillán (not verified)

En el nivel 2 de CMMI no están incluidas las áreas de procesos de Verificación y Validación, pues son pertinentes al nivel 3 donde recién es posible introducir los procedimientos y prácticas correspondientes.
No das una explicación de como gestionan los cambios más allá de la herramienta, puesto a que por regla general esta gestión se hace mediante comité donde puede participar mucha más gente que un equipo de desarrollo, sobre todo en los cambios de alto impacto, donde CMMI no deja alternativa de decisión a un equipo operativo, sino que exige la escalada hasta los mandos gerenciales senior.
Un poco antes, me gustaría saber como es que llevan adelante el proceso de aprobación de los requisitos, ya que en CMMI a partir del nivel 2, es necesario también cumplir con formalidades de aprobación por distintos roles, como Líder de Proyecto, Líder de Testing, Gerente de Calidad y Arquitecto de Sistemas, entre otros interesados y no solo la validación del cliente.
No queda claro como es la cuestión de la Estimación y planificación, ya que típicamente SCRUM, solo planificaría por iteraciones, lo cual lo transforma en un modelo adaptativo y dinámico en ese aspecto, pero CMMI a partir de su nivel 2, ya involucra un área de proceso conocida como Estimación y Planificación, donde la exigencia por procedimientos y prácticas, es ser predictivo con todo el proyecto. Tal vez por eso entiendo que hayan decidido no aceptar cambios sobre las iteraciones. De modo tal que al menos en ese punto hay una fuerte discrepancia con SCRUM.
Cuando indicas Métricas, estás refiriéndote al área de proceso de Medición y Análisis de CMMI-2, de modo tal que necesariamente deben tener completo el modo de registración de avances para el equipo y cada una de sus actividades desglozadas (pero nos indicas que "El problema de la gestión del proyecto como horas cerradas sigue pendiente").De este modo se puede conocer el desvío del proyecto y cuales acciones correctivas tomar. En este punto sería interesante que nos indiques como llevaban las No Conformidades y las Acciones Correctivas, que bajo CMMI deben ser documentadas.
Las métricas y las prácticas enfocadas en el área de proceso de Análisis y Medición cobran sentido en los Informes de Control de Estados (ICE) cada quince días (según nos cuentas) con los interesados de otras capas de la organización.
Aunque indudablemente al adoptar otras prácticas provenientes de otros modelos de trabajo, están abandonando el Modelo CMMI-2, creo que tiene mucho sentido idear otras modalidades que optimicen y compatibilicen el trabajo de la organización entera. Este aspecto está mejor enfocado por la metodología DSDM que Scrum y honestamente, si vuestro equipo sostuvo cierto apego a CMMI-2 y además tuvo consideraciones por las áreas transversales más allá del área de Desarrollo, han estado siguiendo prácticas DSDM más que SCRUM.

Saludos, Javo.

Mon, 25/05/2009 - 22:06 - José Ramón Díaz

Hola Javo!
Intentaré darte respuesta, pero creo que no las tengo todas :)

Cierto, nosotros implementamos unos procesos de verificación muy ligeros, con un mínimo plan de pruebas, pero es que no solo de certificaciones viven los proyectos.

No das una explicación de como gestionan los cambios más allá de la herramienta, puesto a que por regla general esta gestión se hace mediante comité donde puede participar mucha más gente que un equipo de desarrollo, sobre todo en los cambios de alto impacto, donde CMMI no deja alternativa de decisión a un equipo operativo, sino que exige la escalada hasta los mandos gerenciales senior.

El jefe de proyecto tiene potestad de aprobar cambios hasta un % del proyecto, si no creo que deben consultarse al gerente.

Un poco antes, me gustaría saber como es que llevan adelante el proceso de aprobación de los requisitos, ya que en CMMI a partir del nivel 2, es necesario también cumplir con formalidades de aprobación por distintos roles, como Líder de Proyecto, Líder de Testing, Gerente de Calidad y Arquitecto de Sistemas, entre otros interesados y no solo la validación del cliente.

Creo que con aprobaciones de jefe de proyecto y clientes es suficiente.

No queda claro como es la cuestión de la Estimación y planificación, ya que típicamente SCRUM, solo planificaría por iteraciones, lo cual lo transforma en un modelo adaptativo y dinámico en ese aspecto, pero CMMI a partir de su nivel 2, ya involucra un área de proceso conocida como Estimación y Planificación, donde la exigencia por procedimientos y prácticas, es ser predictivo con todo el proyecto.

Bueno, hay una primera planificación global, en base a iteraciones. Después tras cada iteracion se podría replanificar.

Tal vez por eso entiendo que hayan decidido no aceptar cambios sobre las iteraciones. De modo tal que al menos en ese punto hay una fuerte discrepancia con SCRUM.

No veo la discrepancia. La planificación de cada sprint siempre es cerrada. Aceptas los cambios entre sprint, para la siguiente planificación. O sea, durante un sprint puedes recoger cambios, pero los preparas para la siguiente planificación. Creo que es la más estricta teoria de scrum, que no dice que implementes los cambios en cuanto te lleguen.

Cuando indicas Métricas, estás refiriéndote al área de proceso de Medición y Análisis de CMMI-2, de modo tal que necesariamente deben tener completo el modo de registración de avances para el equipo y cada una de sus actividades desglozadas (pero nos indicas que "El problema de la gestión del proyecto como horas cerradas sigue pendiente").De este modo se puede conocer el desvío del proyecto y cuales acciones correctivas tomar. En este punto sería interesante que nos indiques como llevaban las No Conformidades y las Acciones Correctivas, que bajo CMMI deben ser documentadas.

Las no conformidades, ¿bugs? ¿o te refieres a no conformidades con el proceso?. Si son bugs, se recogían en JIRA, donde todo queda registrado, en número y en horas.

Las métricas y las prácticas enfocadas en el área de proceso de Análisis y Medición cobran sentido en los Informes de Control de Estados (ICE) cada quince días (según nos cuentas) con los interesados de otras capas de la organización.
Aunque indudablemente al adoptar otras prácticas provenientes de otros modelos de trabajo, están abandonando el Modelo CMMI-2, creo que tiene mucho sentido idear otras modalidades que optimicen y compatibilicen el trabajo de la organización entera. Este aspecto está mejor enfocado por la metodología DSDM que Scrum y honestamente, si vuestro equipo sostuvo cierto apego a CMMI-2 y además tuvo consideraciones por las áreas transversales más allá del área de Desarrollo, han estado siguiendo prácticas DSDM más que SCRUM.

Bueno, no conozco demasiado DSDM, y ahora que le he echado un ojo lo miraré con más calma. Nuestra idea era aprovechar ideas que creo más acertadas en enfoque para desarrollar software que que las metodologías más tradicionales. Es genial saber que nos hemos acercado a cosas que ya alguien las pensó como buenas e incluso las definió. Scrum es ahora la fuente más abundante de información en ágiles, y era un buen punto de partida.

Thu, 21/05/2009 - 19:39 - Gabriela F. (not verified)

Hola! Muy interesante el relato!
En la certificación, qué presentaron como evidencia de "línea base de planificación"? y las auditorías de QA de proceso, cómo las involucraron en un proceso ágil?

Wed, 27/05/2009 - 20:56 - José Ramón Díaz

La linea base son las tareas inicialmente insertadas en JIRA, asociadas a cada iteración "prevista". Tenemos un pequeño informe en JIRA que saca el estado del proyecto (su EDT) a una fecha concreta.
Las auditorías simplemente cuando tocan, tocan. Van por su lado...

Mon, 25/05/2009 - 19:20 - Javier Santillán (not verified)

Hola Gabriela, no se si sea el ámbito de discusión adecuado, pero es una buena oportunidad par dejar en claro que CMMI tiene una carga y una exigencia que equipos conformados AGILE (típicamente pequeños) no pueden soportar, simplemente por que no tienen la estructura de personal. Al menos eso sucede con equipos para SCRUM, aunque con DSDM se puede tener una estructura tan amplia como lo desees.
Las dos preguntas que vos hiciste sirven para poner "en jacke" a cualquiera que pretenda decir que con un equipo pequeño es posible certificar CMMI-2 o 3, dado que para solo cumplimentar las prácticas específicas para esos dos procedimientos que mencionas, necesitas de un equipo QA completo y al menos dos niveles de gerencia para escalar las aprobaciones.
La Planificación de Proyectos para CMMI es lo que me parece crítico y no es fácilmente adaptable a equipos SCRUM, por que es necesario formar y tener aprobado el Cronograma del Proyecto, lo cual por si mismo significa haber confeccionado un Plan de Iteraciones, Plan de Participación de los Interesados y un Plan de Integración, más un Plan de Riesgos, un Plan de Decisiones Técnicas y un Plan de Capacitaciones o certificar en una matriz de capacitaciones organizacionales, que para iniciar el proyecto el equipo del proyecto tiene las habilidades requeridas.
En lo que a calidad se refiere, debe existir documentación objetiva y sólida confeccionada por el Líder de Proyecto (no Gerente de Calidad ni Líder de Testing) sobre los Objetivos de Calidad y Performance y eventualmente utilizar procedimientos de Gestión de Cambios para modificar requerimientos u objetivos de calidad cuando existen contraposiciones y Procedimientos de Análisis y Toma de Decisiones para establecer esos cambios. Finalmente se debe registrar cuales objetivos se gestionarán estadísticamente.
Si quieres podemos hablar de las revisiones por pares, las cuales no están referidas a (pair programing) sino que son prácticas específicas para un muy alto porcentaje de los productos de software generados.
Todas estas decisiones, principalmente Gestión de Cambio y Toma de Decisiones, se realizan por comité organizacional.
Si considero interesante y posible que la agilidad se puede insertar en toda la organización con prácticas como SCRUM (...muchas otras...según), pero debemos conseguir de una vez por todas que nuestras soluciones de consultoría Agile trasciendan el ámbito del área de desarrollo, por que lamentablemente hasta el día de hoy son pocas las organizaciones que lograron traspasar esa barrera en las organizaciones de envergadura mediana o grande.
Un simple ejemplo es que ni a duras penas logran unificar un criterio para establecer prácticas en Testing o sostener un circuito de auditorías de calidad, sin pretender absorber este departamento QA hasta hacerlo desaparecer para conformarse en el equipo de desarrollo.
Para acercarme a una conclusión, estoy seguro que la simplificación de los procesos debe hacerse concienzudamente, sin ofrecer a las organizaciones "recetas de menudencias" que en un principio parecen ser buenas, pero a la larga podrían dejar el sabor insípido de la pérdida de prácticas que alimentan la base del conocimiento organizacional.

Saludos, Javo.

Tue, 30/12/2008 - 14:12 - Anónimo

Muy interesante el artículo.

Útil el uso de la pizarra y una preguntas relacionadas con el 'hábitat': ¿Cómo estábais distribuidos físicamente? ¿En mesas aisladas? ¿En mesas enfrentadas? ¿Se trabajaba en silencio? ¿Es habitual el hablar? ¿Se escucha música o la gente utiliza auriculares?

Me quedo con algunas frases:
- "sustituimos la gestión de cambios de requisitos, pasando del “Excel” a la gestión de tareas identificadas como “Nuevos Requisitos” en JIRA".
- "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."

Sería interesante, asimismo, obtener el feedback del cliente.

Wed, 07/01/2009 - 09:55 - Jose Ramón (not verified)

Hola!
¿Cómo estábais distribuidos físicamente? ¿En mesas aisladas? ¿En mesas enfrentadas?

Mesas enfrentadas, en islas de 4, uno en cada esquina. Tenemos barreras entre cada mesa, pero no nos impiden vernos las caras para hablar. Te dan "algo" de intimidad, pero te dejan participar en una conversación.

¿Se trabajaba en silencio? ¿Es habitual el hablar? ¿Se escucha música o la gente utiliza auriculares?

En general se trabaja en silencio. Excepto cuando alguien tiene algo que contar (del trabajo o algún chiste también es bienvenido de vez en cuando ;) ) o preguntar. Si hay personas que utilizan auriculares con música, eso a discreción de cada uno.

El "feedback" del cliente era positivo, puesto que veia avances semanales. quizás le proponga pasar por aquí para que escriba su opinión. De todas maneras, en sucesivos proyectos tenemos pendiente involucrar más al cliente en esta forma de trabajar, con el equipo.

Tue, 30/12/2008 - 00:21 - Xavier Albaladejo

Me ha parecido muy interesante que las conclusiones expresen que cuanto más te acercas a Scrum, mejor. Hasta la 5ª conclusión refleja el problema clásico de los proyectos cerrados en precio, alcance y tiempo, debido a la incertidumbre en los requisitos típica de los proyectos de desarrollo de software. Por ello, es mejor seguir las pautas de Scrum de empezar a desarrollar lo que aporta más valor al cliente, mantener el tiempo y coste fijos (en forma iteraciones) y dejar como variable el alcance, permitiendo la entrada de requisitos más prioritarios y dejando de hacer los menos prioritarios, contratando a un equipo por meses o bien como se indica en Un contrato ágil para Scrum.