viernes, 2 de marzo de 2012

Encuesta sobre el uso de SCRUM (2 de 4)


Encuesta sobre el uso de SCRUM (2 de 4)

En el artículo anterior se analizaban las respuestas sobre las ventajas percibidas por Scrum, provinientes de la encuesta que pasé a algunos de mis alumnos del Máster en IT Project Management de la UPC School.
En esta continuación del análisis, me centraré en el bloque de preguntas que trata sobre otra parte que no suele “airearse” demasiado: las dificultades reales de adopción y aprovechamiento de Scrum.

Desafíos de SCRUM

P3.1. Adecuación a mi proyecto o empresa.

La primera pregunta se plantea como encaja Scrum con la empresa del encuestado, donde pueden influir factores como la cultura de la empresa, de las personas concretas que forman el equipo del encuestado, si la empresa realiza proyectos externos o internos, o si existe poca o mucha volatilidad de los miembros de los equipos, entre otras.
La opinión mayoritaria es bastante clara, 2 de cada 3 encuestados opina que no se adapta bien (poco o nada). Buscando una explicación a esta respuesta, en las preguntas del bloque Ventajas de Scrum se identifica la tendencia que los equipos aprecian los beneficios internos de Scrum más que en la interacción con otras figuras de la empresa, posiblemente porque éstas no conozcan bien o crean en la efectividad de Scrum.
En este caso, podríamos encontrarnos con una explicación similar, los miembros de los equipos pueden pensar que “quien manda” no está por la labor de adaptarse a la filosofía de Scrum, más que la posibilidad que la empresa no fuese capaz de sacar un rendimiento a su uso, como principal impedimento para la adopción de Scrum.
P3.1. Adecuación a mi proyecto o empresa.
Total
1. Nada
2
2. Poco
6
3. Bastante
4
Respuestas
12
 

P3.2. Credibilidad de los métodos ágiles respecto a los tradicionales.

Esta segunda pregunta se interesa por una de las posibles dificultades más habituales de cualquier cambio en una organización, la falta de credibilidad en el nuevo modelo.
Ya decía Maquiavelo en El Principe, su célebre tratado sobre política, que los cambios suelen ser difíciles porque quienes creen que van a perder con ellos oponen resistencia y quienes van a ganar, no suelen saberlo y por tanto, no presionan a favor de éstos.
Centrándonos más en el terreno práctico, creo es es una opinión consensuada que las metodologías ágiles son principalmente “de techies para techies”. Muchos jefes de proyecto con largo recorrido, y los directores de área, suelen ver su función más como un “control de horas” donde los “cambios” deben ser minimizados porque sólo traen desviaciones, que una participación activa en el proyecto para maximizar el valor entregado al cliente y mantener el equilibrio entre alcance y recursos de manera proactiva.
Otra opción realista, y en ocasiones compatible, es pensar que Scrum puede no adaptarse realmente a la empresa y al tipo de relación que se establece con los clientes. Algunos factores comunmente identificados (ver [1], [2] y [3]) son:
·         Proyectos con una gran inversión en materiales
·         Proyectos con un alcance y fecha comprometidos a priori
·         Mantenimientos correctivos urgentes (¡Kanban!)
·         Etc.
La metodología en general es poco conocida, apreciada y vista como una herramienta efectiva para solucionar los males endémicos de muchos grupos de desarrollo. Dentro de esta visión pesimista, las metodologías de gestión de proyectos tradicionales han conseguido abrirse paso más que las ágiles, probablemente porque muchos de aquellos que tienen capacidad de decisión hoy en día sobre si adoptarlas o no, se vieron expuestos a ellas en funciones de desarrollo antes de la llegada de las metodologías ágiles.
P3.2. Credibilidad de los métodos ágiles respecto a los tradicionales.
Total
1. Nada
2
2. Poco
7
3. Bastante
3
Respuestas
12
 

P3.3. Falta de soporte de la gerencia.

Este es otro de los factores clásicos, y fatales, para el cambio en las organizaciones. Sin el soporte de la gerencia, habitualmente con sus propias preocupaciones y percepción de las prioridades, es muy difícil que ningún cambio llegue a buen puerto y sea sostenible.
En este caso, no se observa un escenario tan desfavorable, 5 de los 12 opina que la gerencia le apoya bastante o mucho. Aún así, es una cifra baja que puede explicar porque muchos proyectos de implantación de Scrum fracasan y porqué la percepción de los miembros de los equipos es pesimista respecto a la capacidad de la organización de adoptar esta metodología (P3.1).
P3.3. Falta de soporte de la gerencia.
Total
1. Nada
4
2. Poco
3
3. Bastante
3
4. Mucho
2
Respuestas
12
 

P3.4. Falta de conocimientos internos para implentar SCRUM.

Esta pregunta trata de identificar la preparación de los encuestados, tanto teórica como práctica, para implementar esta metodología y trabajar regularmente con ella.
Dado que no todos los encuestados han usado Scrum en sus empresas, se puede considerar normal que sólo el 50% considere que esto no sería un problema.
P3.4. Falta de conocimientos internos para implentar SCRUM.
Total
1. Nada
3
2. Poco
3
3. Bastante
3
4. Mucho
3
Respuestas
12
 

Conclusiones

A nivel general, teniendo en cuenta los beneficios que observan los encuestados sobre Scrum y las dificultades que afirman, podría pensarse que Scrum es una metodología que se ve útil pero que no tiene un gran conocimiento y aceptación fuera de los equipos, y a menudo también dentro de los propios equipos.
Para vencer este desconocimiento y falta de credibilidad, los desarrolladores que quieren implementarlo deberían llevar la argumentación sobre los beneficios de Scrum al contexto y preocupaciones de los gerentes. Algunas de estos factores deberían ser:
·         Capacidad de vender y planificar los proyectos con un riesgo económico asumible
·         Capacidad de dar un seguimiento claro conjuntamente los clientes
·         Posibilidad de mantener el control por parte de la dirección

Para leer más


Encuesta sobre el uso de SCRUM (1 de 4)


Encuesta sobre el uso de SCRUM (1 de 4)

Que Scrum es una tendencia creciente en los últimos años, y que además entre 2010 y 2011 se ha situado probablemente en el liderazgo de las metodologías de desarrollo de software, ya no es ningún secreto.
Aún sabiendo esto y teniendo a nuestra disposición gran cantidad de información sobre el proceso, técnicas de apoyo, herramientas y otros, sabemos relativamente poco sobre el impacto real en las empresas.
Yo he pasado por diferentes empresas que utilizaban Scrum, de manera intencionada o usando aproximaciones, y tenía mis opiniones pero quería tener una base de datos más amplia.
Por ello desarrollé una encuesta y la pasé a mis alumnos del Máster en IT Project Management de la UPC School, obteniendo 16 respuestas. A partir del análisis de los resultados, he pensado publicar una serie de posts que hoy comienzo. Estos son:
  • Post 1: Ventajas de SCRUM
  • Post 2: Desafíos de SCRUM
  • Post 3: Adaptaciones de SCRUM
  • Post 4: Uso de prácticas ágiles dentro de SCRUM
También me gustaría poder compartir esta encuesta con los demás, como una apertura de este lab a aquellos que lo leais.
Por último, quería agradecer a David Coloma su apoyo técnico en el análisis de la encuestra.

Ventajas de SCRUM

Las preguntas de esta sección se engloban bajo el grupo “P2. ¿En que aspectos de la gestión de los proyectos podría ayudarte SCRUM?”.

P2.1. A estabilizar las jornadas de trabajo.

El primer análisis de esta pregunta es que, sorprendentemente, un 60% de los encuestados afirmen que la aplicación de Scrum les ayuda nada o poco.
Si revisamos el número de proyectos realizados con Scrum (P4.4) vemos que son pocos. Otro factor relevante podría ser la falta de conocimientos que reporta un 50% de los encuestados en la pregunta P3.4.
Otros factores que podrían influir son la falta de credibilidad de Scrum (P3.2) y de apoyo de la gerencia (P3.3). Esto último es una señal de alarma, pues son factores “asesinos” de la efectividad del cambio en cualquier organización.
Curiosamente, las respuestas a las preguntas P2.3 y P2.4 parecen indicar que los equipos sí tienen voz sobre la planificación y el seguimiento, hechos que parecerían ser contradictorios con los resultados de esta pregunta.
P2.1. A estabilizar las jornadas de trabajo.
Total
1. Nada
3
2. Poco
4
3. Bastante
4
4. Mucho
1
Respuestas
12
 
 

P2.2. A clarificar la relación con el cliente y el comercial.

Otra de las ventajas que frecuentemente se destaca de Scrum es la mejora en la comunicación con los actores externos al equipo, como son frecuentemente el cliente y el comercial.
Los números de esta pregunta admiten poco margen de explicación, más del 80% de los encuestados opina que no mejora la comunicación. La explicación de este hecho podría venir por la baja credibilidad de Scrum en la organización (P3.2) y el limitado apoyo por la dirección (P3.3).
Estos factores podrían indicar que si bien el equipo usa internamente Scrum, la gerencia y comerciales no están muy implicados en la comunicación con los clientes.
P2.2. A clarificar la relación con el cliente y el comercial.
Total
1. Nada
5
2. Poco
5
3. Bastante
1
4. Mucho
1
Respuestas
12
 
              
                                      

P2.3. A planificar más racionalmente los proyectos.

A pesar que las anteriores preguntas, reflejaban un balance negativo, parece que los equipos si reconocen una clara mejora interna en la gestión de los proyectos. 2/3 de los encuestados afirma que Scrum le ayuda bastante o mucho a planificar más racionalmente los proyectos.
Esto parece indicar que los equipos sienten más control sobre su trabajo, más aún teniendo en cuenta la sensación de tener más voz sobre los aspectos de planificación que se refleja en la siguiente pregunta (P2.4).
P2.3. A planificar más racionalmente los proyectos.
Total
1. Nada
4
3. Bastante
6
4. Mucho
2
Respuestas
12
 
 

P2.4. A dar más voz al equipo durante el seguimiento del proyecto.

Otra de las características principales de las metodologías ágiles es sin duda el enfoque más horizontal, autónomo y participativo de los equipos. Esto debería influir en la sensación de ser tenido en cuenta a la hora de tomar las decisiones.
Efectivamente 2/3 de los encuestados afirma que Scrum le permite mejorar su capacidad de influencia bastante o mucho en los proyectos, es relevante que más del 40% eleva este grado de participación a “mucho”.
P2.4. A dar más voz al equipo durante el seguimiento del proyecto.
Total
1. Nada
2
2. Poco
2
3. Bastante
3
4. Mucho
5
Respuestas
12
 
 

Conclusiones

Las conclusiones principales, en cuanto a las ventajas, parecen centrarse en la mayor capacidad de autogestión y a la planificación más acertada de los proyectos.
Por contra, las ventajas generalmente afirmadas de mejorar la comunicación con los actores externos al equipo y a estabilizar las jornadas de trabajo parecen no observarse. Podrían ser relevantes respecto a este punto, la experiencia limitada de los equipos y el limitado soporte de la organización.
En el siguiente post nos centaremos explícitament en los problemas que se observan respecto a la adopción de Scrum.

Para leer más

Sendas encuestas sobre esta materia realizadas por el Software Engineering Institute [1] y por James Brett de ScrumMaster.com.au [2], se han realizado sobre bases más amplias de usuarios de Scrum y aportan otros aspectos de interés.

martes, 10 de enero de 2012

Software Engineering for Software as a Service

Los profesores Armando Fox y David Patterson, de la UC de Berkeley organizan este curso online que muestra como desarrollar software para el cloud con una metodología ágil.

http://www.saas-class.org/

Yo voy a inscribirme para ver en acción herramientas que me suenan pero que no conozco en detalle, como Github, Cucumber, RSpec, SimpleCov, Pivotal Tracker y Heroku.

El curso online dura 6 semanas y requiere una dedicación aproximada de 3h semanales. Comienza el 20 de febrero.

Habitualmente trabajo ayudando a mejorar procesos en empresas que desarrollan software, muchas de ellas con metodologías ágiles como SCRUM. Este curso me será útil para practicar con estas herramientas y aprender algo de Ruby.


martes, 22 de noviembre de 2011

Participación en Bcn Dev Conference 2011

El pasado jueves 17 participé en la Bcn Dev Conference 2011, un evento para desarrolladores con más de 1000 asistentes, celebrado en el Museu Maritim de Barcelona.


El título de la ponencia era Mejorando la gestión de los equipos de desarrollo, y en ella hablaba de la experiencia de los proyectos de mejora de procesos IT con CMMI, coordinados por Bdigital, dentro del marco del Plan Avanza.


La presentación, que llenó la sala principal, tuvo una buena acogida y me permitió el contacto con muchos desarrolladores.


Los puntos más importantes de la presentación fueron:
  • Qué es CMMI
  • Cuales son los problemas habituales de una PIME que produce software y cuales fueron las soluciones propuestas
  • Ejemplos de integración entre CMMI y SCRUM
  • Ejemplos de herramientas implementadas
  • Ejemplos de prácticas realizadas ágilmente
La verdad es que fue un gusto poder compartir mis experiencias con los demás desarrolladores y espero volver el año que viene.


También quería felicitar a la organización, pues fue su primer evento y les salió muy bien.


Existe más información en la página de Mejora de procesos, CMMI y SCRUM en la Web de Cynertia.

















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