Enseñar competencias clave para desarrollar proyectos TIC en un mercado global, con equipos dispersados en distintos países, es el objetivo del proyecto GSD de la Univerisidad de Pace de Nueva York.

Cada año pone en marcha, en colaboración con otras universidades (Tailandia, India, Camboya, Senegal...) el desarrollo de un proyecto de software con equipos distribuidos.

Son proyectos que sirven de aprendizaje para los estudiantes y profesionales que participan, y de material de análisis con el que están construyendo y depurando un fondo de conocimiento específico para desarrollo global de software.

En 2009 decidieron por primera vez emplear un marco ágil (Scrum) para gestionar el desarrollo de una aplicación para dispositivos móviles, con equipos separados  (Universidad de Pace - Universidad de Delhi y Escuela Superior Politécnica de Dakar).

El mes pasado de publicó el informe del proyecto: "Some Management Principles Learned from Scrum Practices within a Global Software Development Project " que incluye las

6 lecciones aprendidas para la gestión de Scrum distribuido:

Lección 1: Se empieza con mucha voluntad...

Pero es dífícil mantener la motivación y el compromiso con los rituales ágiles previstos.
Sugerencia de gestión: Escribir las motivaciones y compromisos individuales para tenerlos presentes y visibles como banderas a lo largo del proyecto.

Lección 2: No caer en el principio de pareto

Trabajar por separado acentúa la tendencia a enfatizar y consumir mucho esfuerzo en tareas de preparación, aplicando esfuerzo ineficiente (80% de esfuerzo en un 20% del resultado).
Sugerencia de gestión: Conocimiento previo de los conceptos de Scrum, y aplicar pautas y artefactos de gestión simples.

Lección 3: Asignatura difícil: Gestión individual del tiempo

El trabajo distribuido reduce la visibilidad de problemas en miembros del equipo por una mala autogestión del tiempo. Los miembros de equipos separados deben conocer y aplicar de forma disciplinada los principios para la buena gestión del tiempo. Las prácticas de Scrum  para priorizar y estimar las tareas y seguir su evolución de forma cercana y con compromiso de equipo, son especialmente útiles, pero más difíciles de poner en práctica entre personas geográficamente dispersas.
Prácticas aconsejadas:
1.- Periodo de práctica y aprendizaje previo para poner a prueba las habilidades de gestión del tiempo, realizando prácticas de estimación y ejecución de tareas.
2.- Asesoramiento en el análisis y priorización de las tareas pendientes.
3.- Mostrar a los "perfeccionistas" que la perfección es imposible e innecesaria.
4.- Recordar que el tiempo es un recurso valioso.

Lección 4: Ser impasible... ¡mantener un ritmo de trabajo constante!

No olvidar el principio ágil de mantener una velocidad equilibrada, sin fluctuaciones. Sin momentos de estres que queman y desmotivan, ni periodos de procrastinación.

Lección 5: El fin justifica los medios.

El foco del trabajo no es la eficacia o la estética de la codificación. Son puntos técnicos que no deben consumir más foco que el necesario para garantizar el objetivo real: entregar una aplicación operativa.

Lección 6: La capacidad del barril depende de su tabla más corta.

Cada miembro tiene sus debilidades, o tablas más cortas, y sus fortalezas, o tablas largas. La organización del equipo debe conseguir la distribución del trabajo y el resultado combinando y sumando las fortalezas, no las debilidades.


Otros informes del proyecto GSD.

GSD 2007 GSD 2008 GSD 2009 GSD 2010

¡Feliz Navidad amigos, y los mejores deseos para 2012!

El 24% de los usuarios de redes sociales en España se consideran saturados mientras que el 30% dice que le sabe a poco y que quiere participar más; y el 20% afirma que se dio de alta alta por seguir la moda o probar la novedad pero no se ha "enganchado".

A Facebook la prefieren más ellas que ellos (81% frente a 75%) mientras pasa lo contrario con Twitter (11% frente a 17%).

Estos datos y otros más serios ;-)  están en el estudio sobre conocimiento y uso de las redes sociales , que acaba de publicar el Obserbatorio Nacional de las Telecomunicaciones (red.es). 173 páginas con mucho grano y poca paja para los interesados en las redes sociales, acompañadas además de una presentación-resumen.

• Página de información y descarga del esutio y la presentación.

Esta presentación muestra un ejemplo de la teoría del post anterior, con el que comparto mi experiencia en dos proyectos reales y los patrones de entrega de valor al cliente de cada uno: uno desarrollado en 2000 cuando dirigía el área de proyectos y programación de iA Soft: la versión 1.0 de espublico.com  (gestión tradicional) y el otro, el que dirijo actualmente (gestión ágil): Safe Creative, comenzado en 2007.

Para un gestor de proyectos tradicional, espublico fué un éxito: se entregó al cliente todo lo que pidió con una calidad técnica intachable, en las fechas previstas y por el presupuesto estimado.

Para el cliente fue necesario especificar el 100% de los requisitos desde el principio y esperar un año a tener todo el producto completo. Cuando se le entregó muchas funcionalidades ya no tenían sentido.

Desde el punto de vista de la gestión de proyectos tradicional "la operción fué un éxito". Desde la perspectiva del cliente: "el paciente casi se muere".  Tuvo exactamente lo que pidió, aunque no era lo que realmente necesitaba, y en un 80% no le servía, pero no se pudo dar cuenta hasta que no estuvo todo terminado, ni pudo cambiar de estrategia a mitad de desarrollo. (Afortunadamente, tras pasar el bache de la "operación exitosa" el cliente se repuso y hoy espublico es el líder de su sector.)

El objetivo de la gestión predictiva es construir el producto planificado en el tiempo y con los costes previstos. El de la gestión ágil, entregar el mayor valor posible en el menor tiempo, e incrementarlo de forma continua.

Pasar de desarrollo secuencial y planificación global con requisitos cerrados, a un marco iterativo e incremental con requisitos abiertos no es agilidad. Agilidad también supone preferir la pericia y el criterio de las personas al conocimiento estuchado en los procesos y la tecnología.

Trabajar sin procesos ni gestión predictiva, pero sin conocer tampoco ni principios ni prácticas prácticas ágiles tampoco es agilidad.

Si falta alguna de estas piezas el ecosistema para un Campo de Scrum estará cojo. Cuando más evidente es más rozamiento produce, e incluso lo puede hacer inviable.

Cambalache: Trueque, considerado con desprecio, jactancia, satisfacción, pesar u otro movimiento del ánimo que se expresa por el tono y el contexto. Trueque hecho con afán de ganancia. (RAE)

Que el mundo fue y sera una porqueria, ya lo sé,
en el quinientos seis y en el dos mil también;
que siempre ha habido chorros,
maquiavelos y estafaos,
contentos y amargaos, valores y dublé.
Pero que el siglo veinte es un despliegue
de maldá insolente ya no hay quien lo niegue,
vivimos revolcaos en un merengue
y en el mismo lodo todos manoseaos.

Hoy resulta que es lo mismo ser derecho que traidor,
ignorante, sabio, chorro, generoso, estafador.
¡Todo es igual, nada es mejor,
lo mismo un burro que un gran profesor!
No hay aplazaos ni escalafón,
los inmorales nos han igualao...
Si uno vive en la impostura
y otro roba en su ambición,
da lo mismo que sea cura,
colchonero, rey de bastos,
caradura o polizón.

¡Qué falta de respeto, qué atropello a la razón!
¡Cualquiera es un señor, cualquiera es un ladrón!
Mezclaos con Stavisky van don Bosco y la Mignon,
don Chicho y Napoleón, Carnera y San Martin.
Igual que en la vidriera irrespetuosa
de los cambalaches se ha mezclao la vida,
y herida por un sable sin remache
ves llorar la Biblia contra un calefón.

Siglo veinte, cambalache, problemático y febril,
el que no llora no mama y el que no afana es un gil.
¡Dale nomas, dale que va,
que alla en el horno te vamo a encontrar!
¡No pienses mas, tirate a un lao,
que a nadie importa si naciste honrao!
Si es lo mismo el que labura
noche y dia como un buey
que el que vive de las minas,
que el que mata o el que cura
o esta fuera de la ley.

vía  @Mavalvanera

No es fácil trabajar en un marco de Scrum con un equipo distribuido y es precisamente el tema que analiza Sergio Yazyi en su trabajo de Fin de Master en las TIC en Educación de la Universidad de Salamanca "Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido ".

El trabajo emplea para su análisis el taller de Open Knowledge Scrum de Scrum Manager en el que participó el año pasado, que fué dirigido por Claudia Ruata.

El documento compone una visión general y análisis, objetivo y riguroso tanto del aprendizaje basado en proyectos como de los retos del trabajo con equipos distribuidos.

"El aprendizaje basado en proyectos se presenta en varias disciplinas como una estrategia pedagógica óptima para ejercitar conocimientos a la vez que desarrollar habilidades, afrontando situaciones similares a las del mundo real no sólo en términos individuales sino también en la acción coordinada, al mismo tiempo que ofrece un escenario para facilitar la incorporación transparente de la tecnología dentro del proceso de trabajo, por sus virtudes para alcanzar el logro de los objetivos."

"En contextos donde los requisitos son estables, esto ha funcionado bien. Sin embargo, con la aceleración en el ritmo de evolución tecnológica de las últimas décadas, la aplicación de este enfoque en escenarios donde los cambios frecuentes no sólo son inevitables sino incluso deseables, y donde la capacidad de predecir el resultado y el momento es menos importante que garantizar la producción de valor genuino en el
proceso, el modelo tradicional en cascada, predictivo, se ha revelado insuficiente. En particular, en la industria del software se ha vuelto evidente que cuando las definiciones de los requisitos son más dinámicas, inciertas o inestables, este modo de desarrollar produce sistemáticamente  retrasos, altos costos para los proyectos e insatisfacción en el cliente"

Entre las conclusiones del trabajo una particularmente interesante, que apunta una nueva dimensión de Scrum: en la formación.

"Se podría incluso considerar Scrum dentro del aprendizaje basado en proyectos como un verdadero patrón pedagógico, que sintetiza en un conjunto de reglas simples, los principios y buenas prácticas para permitir a un grupo de trabajo transformarse en un verdadero equipo de alto rendimiento, en contextos de incertidumbre e interdisciplinariedad."

... continúa en: "Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido" 

• Página de información del trabajo.
• Enlace de descarga.

La agilidad es lo fácil y la ingeniería de procesos (ISO 12207, ISO 15504, CMMI...) lo difícil.

El marco de trabajo Scrum se explica en media docena de páginas y para conocer las veintitantas áreas de procesos, objetivos y prácticas, específicas y genéricas de un modelo como CMMI,  hacen falta cientos.

Hace unos años, cuando CMMI hablaba sin miedo a perder mercado por la competencia de la agilidad, una implantación para un nivel 2 de madurez, entre pitos y flautas se te iba a más de un año de trabajo y bastantes miles de euros en formación al grupo de evaluación y en minutas de expertos consultores encorbatados. Aparecieron entonces unos chicos que tras años intentando hacer software con esos procesos los habían mandado a la porra, y descubierto otras formas que funcionaban mejor; y tras ellos otros que andaban buscando en qué podían decir que eran expertos, y esto parecía fácil.

Así que teniamos lo difícil y caro: CMMI y lo fácil y barato: Agilidad.... ¿o no?

CMMI es complejo, pero no es difícil. La Agilidad es simple, pero no es fácil.

Para tornear figuras con un torno de control numérico hay que conocer y aplicar sin cambiar una coma el manual de operación, y al final las piezas salen perfectas. Puede ser complejo, pero no difícil. Quien lo hace es un operador.

Podría parecer que es más fácil tallarlas porque sólo hace falta un martillo y un cincel, y además asesorar de cuáles son los mejores martillos, y cinceles. Los mejores materiales, técnicas para coger el cincel... y es que cuando se trata de agilidad y confias el resultado no a los procesos y la tecnología, sino a las personas, como dice mi amigo Luis, la cuestión no son las flechas, sino los indios ;-)