CMMI + Scrum… ¿se puede?
- Detalles
- Publicado: Viernes, 11 Diciembre 2009 00:00
- Escrito por Guido
Hace algún tiempo pensaba en si dos metodologías de desarrollo de software, una tradicional y una ágil, podrían ser combinables. Y pues, a simple vista es difícil dimesionar si dos aspectos distintos de hacer las cosas pueden convivir bajo una misma nube, y llegué a la conclusión que si, pues usualmente las metodologías tradicionales proponen estructuras de trabajo en base a procesos, mientras que las ágiles apoyan el postulado de basarse en las personas para lograr que un proyecto sea exitoso.
Un equipo que adopta Ágil por primera vez tiende a cometer varios errores durante los primeros días. Uno de los errores más comunes es intentar hacer una estimación precisa. Durante la Reunión de Planificación del Sprint de la primera iteración, el equipo no conoce su velocidad y tiende a gastar tiempo intentado crear estimaciones "precisas" o estima usando "colchones" arbitrarios. Gastan demasiado esfuerzo detallando las tareas y estimándolas.
Es bien sabido que en Scrum es muy importante tener software que funcione al final de cada sprint. Pero... ¿por qué? Joe Little comparte 4 buenas razones por las cuales tenemos que enfocarnos en tener software que funciona, siempre.
Trabajando con varios equipos de líderes y gerentes, me di cuenta que necesitan cambiar cómo están organizados para realmente lograr tener equipos ágiles más productivos.
Mucho se habla de la duración de las iteraciones, en especial la duración "ideal" de un Sprint de Scrum. El tamaño sugerido va desde 4 semanas hasta tan pequeño como 2 semanas (e incluso algunos están probando con sprints de 1 semana). ¿Cuál existe una duración ideal? ¿Por qué hay un consenso sobre "mientras más chico, mejor"?
A muchas organizaciones les interesa adoptar Ágil por la habilidad de entregar valor de negocio de forma temprana, incrementar la productividad, realizar entregas más frecuentes y mejorar la moral de los empleados. Hay muchos cursos y libros disponibles que ayudan a los equipos a aprender los fundamentos del desarrollo ágil, pero se suelen enfocar en los desafíos a nivel de equipo, y no tratan muy profundamente los temas organizacionales que pueden ayudar o impedir una transición a esta nueva forma de pensar y trabajar. Este artículo busca mostrar las áreas en donde muchas organizaciones encuentran dificultades para adoptar Ágil, para que puedan estar mejor preparadas al momento de enfrentar el desafio.
Las historias de usuario son...
En Scrum se habla mucho de "quemar puntos" y de su famoso Gráficos de Burn-Down. Y es que resultan una herramienta muy útil y simple de usar, que nos permite ver rápidamente si el equipo llegará a cumplir con su compromiso para la iteración, o si deberá tomarse alguna acción.
"Hacer Scrum" tiene tan poco sentido (y es tan imposible) como crear una instancia de una clase abstracta. Scrum es un framework para sacar a la superficie las disfunciones organizacionales. No es un proceso y no es prescriptivo. El framework básico de Scrum (como ya lo 
Estamos trabajando lo más bien en un sprint, y unos días antes de terminarlo descubrimos un problema en una historia importante que le impedirá al equipo poder terminarla. ¿Qué se debería hacer? ¿Volver la historia al backlog para la próxima iteración, o extender la duración del sprint para poder terminarla? 
Les dejamos la presentación 