cambio"Tras algunos momentos difíciles, paramos la implantación de CMMI y retomamos técnicas ágiles, más colaborativas. Aquí describimos esta experiencia en la implantación de un marco Scrum distribuido y en la creación de una cultura kaizen".

"... La opinión de diferentes expertos y la experiencia en empresas veteranas resaltaban la importancia de establecer procesos compartidos que pudieran ser empleados por todos. Expertos en consultoría nos aconsejaron la implantación de CMMI en ambas ciudades. Se realizó un estudio inicial de viabilidad para lanzar la nueva empresa en Bangladesh e implementar CMMI con la ayuda de una consultora externa. Aunque veíamos muchos desafíos, parecía muy prometedor."

"... Encontramos un partner competente con el que firmamos un contrato por el que nos ayudaría a alcanzar un nivel 3 de CMMI certificado en año y medio ... Uno de los directores más experimentados de la organización se trasladó a Bangladesh durante dos años como director general."

 

De CMMI a Scrum

 

"Todos los nuevos empleados de Bangladesh vinieron durante un mes a Dinamarca, en otoño de 2005 para conocer y trabajar junto con el equipo local, comprender bien el dominio del negocio y establecer un entendimiento cultural entre las dos empresas ... En ese momento no éramos conscientes del impacto de poner el objetivo en la certificación para integrar las dos ciudades. En lugar de que nuestro objetivo fuera crear valor para el negocio y ofrececer soluciones eficientes a nuestros clientes, teníamos por meta estratégica establecer un proceso marco y cumplir una serie de prácticas clave para las áreas de proceso de CMMI ... "

"... Los equipos trabajaron con energía, pero era obvio que cada vez estaban más enfocados en producir documentos para cumplir con las áreas de proceso y alcanzar el nivel 3 de CMMI, que en proporcionar valor de negocio a nuestros clientes ... Ninguno de ellos había requerido que tuviéramos la certificación CMMI. Parecía como si los equipos, al mantener la comunicación basada en documentos, se aislaran el uno del otro. La cultura de inicio era un 'nosotros' y 'ellos' con malentendidos en los requisitos escritos ... Creamos requisitos documentados para dar solución a un problema cuyo dominio no comprendían ni el equipo de Dinamarca ni el de Bangladesh. Parecía como si los documentos de requisitos abarcaran sólo la parte visible del iceberg sin considerar la parte sumergida."

"... Un tercer problema era el incremento de tiempo necesario en la integración del código de cada equipo. Trabajábamos con Microsoft TFS para equipos distribuidos... "

"Necesitábamos mejorar: - Colaboración y comunicación. - Ciclos de feedback técnicos y de negocio - La comprensión cultural - Conocimiento del dominio y requisitos."

"Empezamos a probar scrum en un equipo danés que trabajaba con el proyecto más complejo. Los resultados fueron tan buenos que hicimos un despliegue global de scrum tanto en los equipos daneses como en Bangladesh, y decidimos poner CMMI en suspenso. La estrategia de implementación de scrum era empezar con los equipos que trabajaban en proyectos locales en Dinamarca y Bangladesh, y cuando alcanzaran un ritmo estable, implementarlo también en los equipos distribuidos que participaban en proyectos comunes en ambas ciudades."

"Para lograr un ritmo sostenido de coordinación en la gestión de los equipos, establecimos la siguiente estructura de "scrum de scrums" con cuatro niveles de reuniones diarias (15 minutos cada una): - Reunión scrum de equipo - Reuión scrum de equipos - Reunión scrum de coordinadores - Reunión scrum entre coordinadores y CTO ... A pesar de la comunicación entre equipos, aún estábamos lejos de que pudieran centrarse en una visión compartida del producto completo. Como resultado íbamos viendo que la arquitectura se iba debilitando y empezaban a crecer dialectos de código y desconfianza entre los equipos. Al hacer retrospectivas de forma regular entre todos, se identificaron los principales problemas y se determinó que era el momento de crear equipos globales de scrum con miembros en cada una de las ciudades".

"Las 8 áreas que identificamos para crear un entorno ágil distribuido, que permitió a las personas desarrollar la colaboración y confianza necesaria para mejorar de forma continua y desarrollar buen software son:

1.- Estructura global para gestionar un flujo de trabajo valioso, definido y enfocado.
2.- Institucionalización de un ritmo de feedback tanto técnico como de negocio.
3.- Infraestructura técnica global.
4.- Mejora continua de las prácticas de desarrollo.
5.- Gestión ágil de requisitos y planificación.
6.- Capacitación de los equipos para conocer el dominio del problema.
7.- Mejorar la comprensión inter-cultural con visitas in-situ entre equipos.
8.- Protocolos de comunicación."

"De esta forma, en poco tiempo SoftwarePeople se convirtió en una empresa con equipos distribuidos, muy eficiente a la hora de entregar valor de negocio. En 2008 fue adquirida por una gran corporación americana con la que ahora desarrolla soluciones globales. El proyecto de implantación de CMMI sigue en suspenso."

Este es un resumen a módo de síntesis a través de citas textuales del paper "From CMMI and isolation to Scrum, Agile, Lean and collaboration" de Mads Troels Hansen y Hans Baggesen, que explica el recorrido que realizó SoftwarePeople A/S de 2005 a 2008, y cómo aprendió a trabajar con equipos distribuidos en oficinas de países diferentes.

Y éstas son las diapositivas con las que sus autores lo han presentado en Agile2009 Conference y XPDays 2009.


 

Aunque cada empresa tiene su propia realidad, y los "copia-pega" tal cual del marco de una empresa a otra suele encajar de aquellas maneras, esta experiencia real de tres años de evolución y mejora, y el conocimiento que encierra es un elemento más que valioso para el fondo de armario de un gestor :-)
 
Enlaces:

Comentarios   

+1 #4 David Arteaga 28-02-2013 11:34
El refrán "en pueblo de ciegos el tuerto es rey" calza muy bien para este artículo. Soy un practicante del Scrum y las prácticas ágiles, y también del CMMI y otros marcos de referencia. Jeff Sutherland, creador del Scrum, en su libro Scrum Papers dice "Como con cualquier otro modelo, existen buenas y malas implementaciones del CMM. Creemos que las malas implementaciones son una de las principales razones para la existencia de la crítica negativa del CMM." Yo agrego: "Existen también malas implementaciones de Scrum y eso no significa en absoluto problema alguno con el Scrum". Esto no es una guerra, todos queremos hacer mejor software. El CMMI no establece en ninguna parte el uso de plantillas en word o excel que nadie use o que sólo sirvan para una evaluación eso es totalmente inapropiado. El CMMI NO GENERA UN VOLUMEN DE DOCUMENTACIÓN TOTALMENTE INNECESARIO, lo hacen las personas, esto es un error, así como lo es (de acuerdo a lo que dice Jeff Sutherland) creer que el enfoque ágil significa no documentar. Es extraño que alguien crea que un grupo de colegas diseñaron un modelo de mejora para empeorar el desempeño de una organización. Si van al cine a ver una película y salen decepcionados, es un error concluir que el cine es una decepción. Simplemente fue una película mal hecha. No hay mucho espacio aquí para dar mas experiencias, pero les animo a investigar las buenas experiencias, ¿qué diferente sucedió en las buenas implantaciones CMMI? ¿Qué aprendizaje hay que rescatar de organizaciones que han implementado exitosamente CMMI y Scrum? (exitosamente no significa certificadas sino que han logrado mejorar). Les dejo el desafío.
Citar
0 #3 Juan Palacio 10-12-2012 15:24
Yo soy de la opinión de que son cosas distintas, y la suma de ambas sólo interesa a los vendedores de ambas.
Citar
0 #2 Juan Quijano 10-12-2012 14:42
Buenas,

Estoy justamente ahora metido en un proceso de madurez, como CMMI encapsulando Scrum en la parte de desarrollo.

Y mi duda principal es qué tiene que ver un proceso de Madurez con una metodología de producción?

Podría dar ejemplos reales de implementación de la documentación requerida por CMMI en un Product Backlog y cumplir con todos los requisitos.

A ver si saco tiempo y empiezo a escribir sobre ello.
Citar
+3 #1 Lars 09-12-2012 16:26
CMMI es un auténtico cáncer para el desarrollo de software y debería ser considerada oficialmente como una mala práctica.

CMMI genera un volumen de documentación totalmente innecesario y obliga a dedicar muchísimo tiempo en aspectos burocráticos sin aportar ningún valor añadido.

A ver si algún día estos conceptos tan evidentes calan en España de una vez aunque me temo que no sucederá en el medio plazo. CMMI es el paraíso para los jefes vendedores de humo que no tienen ni idea de los aspectos técnicos y por desgracia en España este perfil es mayoritario.
Citar

Escribir un comentario


Código de seguridad
Refescar