domingo, 23 de octubre de 2011

Combinando CMMI y SCRUM (2)


Nota: este artículo se publicó originalmente en el LAB SCRUM de la web THEPROJECT.
Este tercer artículo concluye la serie dedicada a revisar la relación entre metodologías tradiciones y ágiles, y más concretamente a que pueden aportarse entre sí un modelo de procesos como CMMI y una metodología ágil como SCRUM.
Para ilustrar este último punto, se discutirán algunos aspectos que suelen discutirse durante las implantaciones de CMMI en entornos cercanos a SCRUM, además de dar algún ejemplo práctico de cómo se ha implementado.
Como desplegarlo (CMMI&SCRUM)
Aunque hace algunos años había la creencia extendida que CMMI y SCRUM eran vías paralelas, en el sentido que nunca se cruzarían, la aparición de literatura como [1] y de primeras implantaciones donde se combinaban [2] llevó a la comunidad CMMI (auditores, consultores y miembros de organizaciones con CMMI) a considerar que ambos enfoques no eran únicamente “compatibles”, sinó que podían amplificar sus fortalezas combinándose.
¡Las prácticas son el QUÉ, la metodología es el CÓMO!
Uno de los conceptos del modelo CMMI que pueden pasar inadvertidos a primera vista es que las prácticas (p.e. PP SP1.1 – Estimar el alcance del proyecto) no son actividades recomendadas de un proceso, sinó requisitos que deben cumplir las actividades de los procesos propios de cada organización.
Aunque sin conocer de cerca el modelo CMMI, el párrafo anterior pueda parecer confuso, se puede resumir en que “las prácticas CMMI son el QUÉ, y las actividades de los procesos de cada organización son el CÓMO”. Esto quiere decir que las actividades que realizamos pueden utilizar otros productos de trabajo y tareas que las sugeridas mientras se cumpla el objetivo. ¡De esta manera, es mucho más fácil entender el encaje de Scrum!
Ejemplos de las AP con ágil
Dos ejemplos de interpretación de prácticas CMMI con SCRUM son:
  • PP SP1.2 - Establish Estimates of Work Product and Task Attributes. Puede parecer que es obligatorio realizar un análisis de los requisitos y estimar usando los atributos de los productos de trabajo descubiertos, pero utilizando las técnicas de SCRUM (backlog, planning poker, análisis en la iteración) se puede conseguir perfectamente el objetivo.
  • PMC SP1.1 - Understand Requirements. La reunión de planificación de Sprint de los diferentes roles del proyecto (product owner, scrum master, etc.) junto con el Sprint Backlog cumplen perfectamente esta práctica. También se podría añadir una checklist para que los desarrolladores se aseguren que entienden los requisitos.
Las anteriores muestras se pueden ampliar fácilmente para demostrar que SCRUM y CMMI no sólo no son incompatibles, sinó que contrariamente se combinan muy bien para dar respuesta a equipos que quieren ser ágiles pero conservar un nivel de institucionalización de la metodología que asegure un funcionamiento uniforme entre los diferentes equipos de la organización.
Algunas implantaciones de CMMI y SCRUM
Para finalizar este artículo propongo una serie de productos de trabajo con herramientas libres que pueden dar respuesta a una implementación de SCRUM y CMMI para equipos pequeños y medios:
  • Estimación inicial y requisitos de alto nivel: OpenOffice Calc [3]
  • Análisis de requisitos: Wiki de Redmine [4]
  • Estimación detallada de tareas: OpenOffice Calc [3]
  • Carga automatizada en herramienta de seguimiento: Script de OpenOffice Calc [3]
  • Repositorio de código y documentación: Subversion [5] / Tortoise [6]
  • Pruebas automatizadas de interfaz (web): Selenium [7]
Para leer más

Participación en Bcn Dev Conference 2011

Hola a todos,

finalmente han escogido mi ponencia "MEJORANDO LA GESTIÓN DE LOS EQUIPOS DE DESARROLLO" para presentar en el Barcelona Developers Conference 2011.

El objetivo principal de dicha ponencia es mostrar las experiencias de mejora de procesos de software con CMMI e ISO 15504-SPICE en varias pimes, dentro del Plan Avanza, de la mano de Bdigital y Cynertia Consulting.

Dentro de esta presentación se destacarán aspectos de este proyecto, como la gestión del cambio, la buena sintonía entre modelos como CMMI y metodologías ágiles como SCRUM, los beneficios obtenidos y las problemáticas halladas.

Os esperamos en las sesiones BcnDevCon 2011, no dejeis de saludarnos si nos vemos por allí.

Alex Ballarin @ Cynertia Consulting

lunes, 3 de octubre de 2011

Combinando CMMI y SCRUM (I)


Estos posts han sido publicados inicialmente en el Lab "Project Management SCRUM" de TheProject.ws.


En el anterior artículo se introdujo el contexto de los diferentes tipos de metodologías, tanto tradicionales como ágiles, y algunos factores que determinan el éxito de su aplicación a las organizaciones.
En este artículo se profundiza en algunos de dichos factores y se comparan dos enfoques que han ganado mucha popularidad en última década: el modelo de madurez CMMI y la metodología de gestión de proyectos Ágiles.

Equipos grandes vs pequeños

El tamaño de los equipos, y como están organizados entre ellos, es uno de los factores más importantes que se debería tener en cuenta a la hora de escoger qué enfoque metodológico y organizativo queremos seguir.

Equipos pequeños, grandes y organizaciones de múltiples equipos pequeños

Los equipos pequeños, p.e. menores de 10 miembros, típicamente incorporan con más facilidad las metodologías ágiles como SCRUM debido a dos motivos fundamenteales: 1) afrontan proyectos con menos riesgo, y por tanto, con menores necesidades de mitigarlo mediante las prácticas de calidad y 2) tienen menos personal y eso dificulta su dedicación a las mencionadas prácticas de calidad.
Los equipos grandes, p.e. mayores de 15 o 20 personas, por contra muy probablemente realicen proyectos con un tamaño y riesgo mucho mayor que justifica la realización de muchas actividades de calidad, y además podrán tener miembros dedicados a actividades de calidad concreta (p.e. diseño de procesos, testing, auditorías, métricas). Estos equipos típicamente pueden adoptar y adaptar una metodología como RUP [1] y obtener el provecho de tener definidos los procesos de desarrollo donde participan equipos grandes con muchos roles diferentes.
Existen otros escenarios donde una organización mediana o grande tiene múltiples equipos que tienen poca o ninguna relación entre ellos. Esto puede pasar en una empresa que realice proyectos para clientes o bien, en menor grado, en una que desarrolle un producto complejo con equipos encargándose de componentes o subproductos. En ambos casos,
En estos escenarios, especialmente si no existe un departamento de procesos o una tradición en la gestión de procesos, suele ser más sencillo extender el modelo monoequipo de SCRUM a múltiples equipos debido a la facilidad que éste introduce para el seguimiento de los equipos (con las herramientas roadmap y sprint backlog).

Por tipos de proyecto (web, alta tecnología)

La naturaleza de los productos realizados por los proyectos es otro factor que determina que enfoque metodológico y organzativo es más ventajoso.
El desarrollo de software presenta condicionantes diferentes al de otro tipo de productos. En general son proyectos donde la tecnología es mucho más dinámica, la duración del proyecto y de las tareas individuales suele ser reducida, su coste fundamental viene dado por el esfuerzo del personal y la realización de cambios es relativamente rápida y barata.
Esto ha facilitado que muchos de los proyectos se hagan con una planificación muy deficiente y aún así alcancen parcialmente sus objetivos. Por otro lado, estas características fueron las que originaron las metodologías ágiles como SCRUM que responden bastante bien a estos condicionantes.
Los enfoques que indico, basados en el tamaño de los equipos o en el tipo de proyecto, no son en absoluto únicas sino tendencias de la industria basadas en la facilidad de implantación y las prácticas actuales. Cualquier organización con suficiente conocimiento de metodología y una visión clara de sus fortalezas, debilidades y objetivos puede adoptar un enfoque diferente con éxito.

Como se complementan

En la sección anterior se discute factores que recomiendan que una organización se base en una metodología tradicional (p.e. RUP) o en una ágil (p.e. SCRUM).
Tanto si se escoge la aproximación tradicional o la ágil, la implementación en cada organización puede ser más efectiva si se basa en un modelo de referencia que ayude a la organización a que dicha implementación no descuide ningún aspecto importante y a que el proceso definido sea más eficaz y se mantenga efectivo a lo largo del tiempo.
Considerando la metodología ágil más popular, SCRUM, y el modelo de madurez más extendido, CMMI, veamos cómo pueden complementarse. Para ello, es necesario conocer tanto las actividades, roles y productos de SCRUM [3] como la estructura y áreas de proceso de CMMI [4].
Las principales mejoras mutuas que puede traer el uso conjunto de SCRUM y CMMI son:

Mejoras que CMMI aporta a SCRUM

1.       CMMI ayuda a determinar de una manera más formal las mejoras que se pueden introducir en los procesos, p.e. mediante las métricas o las auditorías internas.
2.       La planificación formal ayuda a capturar y dar seguimiento a las decisiones de gestión del proyecto, especialmente cuando los proyectos y la organización crecen y la presión aumenta.
3.       Ayuda a involucrar de manera común al resto de la organización y a los actores externos, tanto en el seguimiento de los proyectos como en el aprendizaje y difusión de las mejoras.
4.       Define más claramente los roles a nivel de equipo y fuera de los equipos, hecho que facilita la asunción clara de las responsabilidades.
5.       Facilita que se determine la formación que no puede adquirirse autónomamente por los miembros de los equipos, especialmente importante en proyectos grandes.
6.       Normaliza la realización de ciertas tareas, de manera que puede reaprovecharse mejor el conocimiento, se es más eficiente y se evitan problemas de calidad.
7.       El desarrollo más formal de requisitos de cliente ayuda a estimar y planificar mejor el proyecto que un simple “roadmap” de producto.

Ventajas de implementar CMMI usando SCRUM

1.       Los procesos que se definen se suelen realizar realmente, ya que se diseñan ligeros y de un seguimiento frecuente y compartido por el equipo.
2.       El aprendizaje en los proyectos es continuo, mediante las reuniones SCRUM y las retrospectivas, y esto suele llevarse fácilmente de vuelta a los procesos.
3.       La verificación y el seguimiento a los riesgos se realizan de una manera manual mediante las reuniones del equipo y las demostraciones al cliente.
4.       Los proyectos pequeños no se ven penalizados por metodologías pesadas. Se pueden definir “perfiles de proyecto” que añadan nuevos procesos y actividades sólo para “proyectos grandes”.
5.       Los miembros del equipo están en contacto frecuente con el jefe de proyecto, hecho que le aporta información muy valiosa para la planificación y seguimiento del proyecto.
6.       La planificación de las tareas basadas en un roadmap ayuda a mantener el trabajo centrado en las prioridades de cada momento y evitar realizar trabajo innecesario.

Para leer más