LAB SCRUM POSTS ALEX BALLARIN

Post 1 Metodologas giles vs tradicionales (3/9/2011)

Introduccin
Mi experiencia en los proyectos tecnolgicos comenz en dos multinacionales del software y la tecnologa, donde pude experimentar en mis carnes las glorias y las miserias de proyectos innovadores y en contextos organizativos frecuentemente complejos. El abuso del modelo heroico, donde equipos altamente motivados pero no bien organizados, alcanzan los objetivos del proyecto al precio de un alto sobreesfuerzo personal que asumen (ms o menos voluntariamente) los miembros del equipo, me hizo entrar con entusiasmo en el mundo de las metodologas de desarrollo y gestin de proyectos (RUP, PMBOK, SCRUM, Metrica3, etc.). Consegu trasladar este inters personal a la prctica profesional y me dediqu unos aos a la venta de metodologa y herramientas para el desarrollo y gestin de grandes proyectos. En este periodo tuve varias oportunidades para conocer las metodologas giles en sus inicios a travs de practitioners entusiastas de estas y de tener con stos encendidos debates acerca de cul era el mejor enfoque. En mi tercera etapa profesional dentro del mundo de la tecnologa aplicada a la gestin, me dedico a la consultora general sobre tecnologa y a la mejora de procesos TIC en organizaciones que adoptan crecientemente metodologas giles. De hecho, la adopcin de SCRUM que hace unos pocos aos era marginal, ahora si no es mayoritaria si es muy frecuente. As pues, a partir del enfoque de alguien que ha conocido el caos (creativo), las metodologas tradicionales y tambin las metodologas giles, tanto como usuario como consultor que ha ayudado a implantarlas, espero hacer una aportacin interesante a este LAB de SCRUM. En una serie de tres artculos, me propongo introducir el contexto de las metodologas y los modelos, identificar como las aplicar con xito las metodologas en funcin del contexto del equipo y como combinar el modelo CMMI y la metodologa SCRUM.

Metodologas giles vs tradicionales

1. Historia de las metodologas y de los modelos. Desde el inicio del desarrollo masivo de software [1] se ha querido encontrar las mejores prcticas y distribuir la experiencia obtenida a travs de la prctica. Esto se ha hecho tradicionalmente mediante metodologas impulsadas por universidades y grandes empreses de tecnologa a travs de metodologas, como la programacin estructurada (1969), SSADM (1980), RAD (1991), RUP y SCRUM (1998) o XP (1999).

Adems, se han generado diferentes modelos de calidad que identifican actividades del desarrollo determinadas como buenas prcticas (el QUE) pero que no prescriben la manera de realizarlas concretamente (el COMO), de manera que los equipos que los adoptan pueden elegir cual es la manera de realizar estas prcticas que mejor se adapta a sus contextos y caractersticas. 2. Donde aplican cada uno Simplificndolo mucho, se puede decir que las metodologas tradicionales (SSAD, RUP, etc.) ponen por encima de lo dems los objetivos de la definicin y del control del trabajo, mientras que las metologas giles priman la libertad del equipo, la comunicacin entre el cliente y el equipo, realizar slo las tareas que aportan valor al cliente, y finalmente definir el trabajo tal y como ste se va realizando para el conocimiento adquirido durante su desarrollo evite realizar tareas innecesarias. Una consideracin importante es el tamao de los equipos. La inmensa mayora de los proyectos se realizan por empresas o equipos muy pequeos (p.e. 1-10 personas) donde las metodologas tradicionales son difciles de aplicar, e incluso imposibles si se quiere hacer de manera exhaustiva. Otro aspecto influyente es el contexto y misin de los equipos, que pueden ser estables en su actividad (p.e. desarrollo de un producto) o cambiar ms o menos frecuentemente de miembros o proyecto. 3. Mitos y realidades Mi experiencia pasando por muchas organizaciones que desarrollan software me dice varias cosas: 1. Cada empresa es un mundo, lo que funciona en un sitio puede fracasar en otro. 2. El compromiso de la direccin con la mejora est por encima de todo lo dems. Cuando toca cambiar los roles de las personas, introducir actividades que no se realizaban antes o atajar malas prcticas, si la direccin no marca pblicamente el camino y acepta los problemas temporales que trae el cambio, la mejora fracasar parcial o totalmente. 3. La experiencia y capacidad de las personas lo cambia todo, un gran mtodo de trabajo no suplir el valor de las personas. 4. Una de las principales dificultades radica en el cambio de las personas. Conseguimos que stas entiendan y se adapten a los roles que les asigna la metodologa? O por el contrario, el nuevo proceso se ve limitado a los cambios que los miembros estn dispuestos a aceptar. Existen diversas creencias falsas que pueden perjudicar la adopcin de una nueva metodologa, sea del tipo que sea. 1. Las metodologas tradicionales son pesadas y que suponen obligatoriamente un todo o nada. 2. Las metodologas giles son ms modernas y mejores que cualquiera de las tradicionales.

3. Las actividades de calidad son intiles y slo funcionan en equipos grandes, no se adaptan a nuestros proyectos. Cualquier cosa que nos quite tiempo de tareas tcnicas (programar, etc.) es una prdida de tiempo. 4. Trabajar con una metodologa gil no supone aplicar disciplina alguna, sin que es una manera fcil de dar estructura su caos imperante sin aadir actividades de calidad. Seguir SCRUM evita realizar testing? Como resmen, existen dos grandes conclusiones: 1. No hay varitas mgicas para conseguir mejorar la calidad y rendimiento de los equipos de manera radical sin cambiar profundamente la manera de trabajar. Y esto no supone en absoluto que los cambios sean difciles si la direccin y los miembros de la organizacin creen en ello decididamente. 2. Cada organizacin en mundo. Aplicar una metodologa estndar de manera rpida y sin trabajar abierta y reflexivamente con los miembros de un equipo suele ser una buena receta para el desastre. En los siguientes artculos se entrar en detalle en los factores que pueden ayudar a aplicar correctamente los modelos y las metodologas a equipos segn su tamao, su objetivo o su contexto.

Para leer ms
[1] http://en.wikipedia.org/wiki/Software_development_methodology [2] http://www.softwarepurist.com/blog/index.php/characteristics-of-sw-co-size/

Post 2 Combinando CMMI y SCRUM (y/9/2011)

En el anterior artculo se introdujo el contexto de los diferentes tipos de metodologas, tanto tradicionales como giles, y algunos factores que determinan el xito de su aplicacin a las organizaciones. En este artculo se profundiza en algunos de dichos factores y se comparan dos enfoques que han ganado mucha popularidad en ltima dcada: el modelo de madurez CMMI y la metodologa de gestin de proyectos giles.

Equipos grandes vs pequeos

El tamao de los equipos, y como estn organizados entre ellos, es uno de los factores ms importantes que se debera tener en cuenta a la hora de escoger qu enfoque metodolgico y organizativo queremos seguir. Equipos pequeos, grandes y organizaciones de mltiples equipos pequeos Los equipos pequeos, p.e. menores de 10 miembros, tpicamente incorporan con ms facilidad las metodologas giles como SCRUM debido a dos motivos fundamenteales: 1) afrontan proyectos con menos riesgo, y por tanto, con menores necesidades de mitigarlo

mediante las prcticas de calidad y 2) tienen menos personal y eso dificulta su dedicacin a las mencionadas prcticas de calidad. Los equipos grandes, p.e. mayores de 15 o 20 personas, por contra muy probablemente realicen proyectos con un tamao y riesgo mucho mayor que justifica la realizacin de muchas actividades de calidad, y adems podrn tener miembros dedicados a actividades de calidad concreta (p.e. diseo de procesos, testing, auditoras, mtricas). Estos equipos tpicamente pueden adoptar y adaptar una metodologa 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 organizacin mediana o grande tiene mltiples equipos que tienen poca o ninguna relacin 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 encargndose de componentes o subproductos. En ambos casos, En estos escenarios, especialmente si no existe un departamento de procesos o una tradicin en la gestin de procesos, suele ser ms sencillo extender el modelo monoequipo de SCRUM a mltiples 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 tecnologa) La naturaleza de los productos realizados por los proyectos es otro factor que determina que enfoque metodolgico y organzativo es ms ventajoso. El desarrollo de software presenta condicionantes diferentes al de otro tipo de productos. En general son proyectos donde la tecnologa es mucho ms dinmica, la duracin del proyecto y de las tareas individuales suele ser reducida, su coste fundamental viene dado por el esfuerzo del personal y la realizacin de cambios es relativamente rpida y barata. Esto ha facilitado que muchos de los proyectos se hagan con una planificacin muy deficiente y an as alcancen parcialmente sus objetivos. Por otro lado, estas caractersticas fueron las que originaron las metodologas giles como SCRUM que responden bastante bien a estos condicionantes. Los enfoques que indico, basados en el tamao de los equipos o en el tipo de proyecto, no son en absoluto nicas sino tendencias de la industria basadas en la facilidad de implantacin y las prcticas actuales. Cualquier organizacin con suficiente conocimiento de metodologa y una visin clara de sus fortalezas, debilidades y objetivos puede adoptar un enfoque diferente con xito.

Como se complementan
En la seccin anterior se discute factores que recomiendan que una organizacin se base en una metodologa tradicional (p.e. RUP) o en una gil (p.e. SCRUM). Tanto si se escoge la aproximacin tradicional o la gil, la implementacin en cada organizacin puede ser ms efectiva si se basa en un modelo de referencia que ayude a la

organizacin a que dicha implementacin no descuide ningn aspecto importante y a que el proceso definido sea ms eficaz y se mantenga efectivo a lo largo del tiempo. Considerando la metodologa gil ms popular, SCRUM, y el modelo de madurez ms extendido, CMMI, veamos cmo 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 ms formal las mejoras que se pueden introducir en los procesos, p.e. mediante las mtricas o las auditoras internas. 2. La planificacin formal ayuda a capturar y dar seguimiento a las decisiones de gestin del proyecto, especialmente cuando los proyectos y la organizacin crecen y la presin aumenta. 3. Ayuda a involucrar de manera comn al resto de la organizacin y a los actores externos, tanto en el seguimiento de los proyectos como en el aprendizaje y difusin de las mejoras. 4. Define ms claramente los roles a nivel de equipo y fuera de los equipos, hecho que facilita la asuncin clara de las responsabilidades. 5. Facilita que se determine la formacin que no puede adquirirse autnomamente por los miembros de los equipos, especialmente importante en proyectos grandes. 6. Normaliza la realizacin de ciertas tareas, de manera que puede reaprovecharse mejor el conocimiento, se es ms eficiente y se evitan problemas de calidad. 7. El desarrollo ms 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 disean 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 fcilmente de vuelta a los procesos. 3. La verificacin 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 pequeos no se ven penalizados por metodologas pesadas. Se pueden definir perfiles de proyecto que aadan nuevos procesos y actividades slo para proyectos grandes. 5. Los miembros del equipo estn en contacto frecuente con el jefe de proyecto, hecho que le aporta informacin muy valiosa para la planificacin y seguimiento del proyecto. 6. La planificacin 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 ms
[1] http://en.wikipedia.org/wiki/Rational_Unified_Process

[2] http://www.amazon.com/Integrating-CMMI-Agile-DevelopmentPerformance/dp/0321714105 [3] http://es.wikipedia.org/wiki/Scrum [4] http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration

Post 3 Combinando CMMI y SCRUM (x/9/2011)

Este tercer artculo concluye la serie dedicada a revisar la relacin entre metodologas tradiciones y giles, y ms concretamente a que pueden aportarse entre s un modelo de procesos como CMMI y una metodologa gil como SCRUM. Para ilustrar este ltimo punto, se discutirn algunos aspectos que suelen discutirse durante las implantaciones de CMMI en entornos cercanos a SCRUM, adems de dar algn ejemplo prctico de cmo se ha implementado.

Como desplegarlo (CMMI&SCRUM)

Aunque hace algunos aos haba la creencia extendida que CMMI y SCRUM eran vas paralelas, en el sentido que nunca se cruzaran, la aparicin 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 podan amplificar sus fortalezas combinndose. Las prcticas son el QU, la metodologa es el CMO! Uno de los conceptos del modelo CMMI que pueden pasar inadvertidos a primera vista es que las prcticas (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 organizacin. Aunque sin conocer de cerca el modelo CMMI, el prrafo anterior pueda parecer confuso, se puede resumir en que las prcticas CMMI son el QU, y las actividades de los procesos de cada organizacin son el CMO. 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 ms fcil entender el encaje de Scrum! Ejemplos de las AP con gil Dos ejemplos de interpretacin de prcticas CMMI con SCRUM son: PP SP1.2 - Establish Estimates of Work Product and Task Attributes. Puede parecer que es obligatorio realizar un anlisis de los requisitos y estimar usando los atributos de los productos de trabajo descubiertos, pero utilizando las tcnicas de SCRUM (backlog, planning poker, anlisis en la iteracin) se puede conseguir perfectamente el objetivo. PMC SP1.1 - Understand Requirements. La reunin de planificacin de Sprint de los diferentes roles del proyecto (product owner, scrum master, etc.) junto con el Sprint Backlog cumplen perfectamente esta prctica. Tambin se podra aadir una checklist para que los desarrolladores se aseguren que entienden los requisitos.

Las anteriores muestras se pueden ampliar fcilmente para demostrar que SCRUM y CMMI no slo no son incompatibles, sin que contrariamente se combinan muy bien para dar respuesta a equipos que quieren ser giles pero conservar un nivel de institucionalizacin de la metodologa que asegure un funcionamiento uniforme entre los diferentes equipos de la organizacin.

Algunas implantaciones de CMMI y SCRUM

Para finalizar este artculo propongo una serie de productos de trabajo con herramientas libres que pueden dar respuesta a una implementacin de SCRUM y CMMI para equipos pequeos y medios: Estimacin inicial y requisitos de alto nivel: OpenOffice Calc [3] Anlisis de requisitos: Wiki de Redmine [4] Estimacin detallada de tareas: OpenOffice Calc [3] Carga automatizada en herramienta de seguimiento: Script de OpenOffice Calc [3] Repositorio de cdigo y documentacin: Subversion [5] / Tortoise [6] Pruebas automatizadas de interfaz (web): Selenium [7]

Para leer ms
[1] http://www.amazon.com/Integrating-CMMI-Agile-DevelopmentPerformance/dp/0321714105 [2] http://warp.es/metodologia [3] http://www.openoffice.org [4] http://www.redmine.org [5] http://subversion.tigris.org [6] http://tortoisesvn.tigris.org [7] http://www.seleniumhq.org

Post 4 Encuesta SCRUM I (2/1/2012)

Objetivo Ventajas de SCRUM Conclusiones

Post 5 Encuesta SCRUM II (16/1/2012)

Desafos de SCRUM Conclusiones

Post 6 Encuesta SCRUM III (30/1/2012)

Uso real de SCRUM Conclusiones

Post 7 Encuesta SCRUM IV (13/2/2012)

Otras prcticas giles Conclusiones