Ser Ágil en España: Un caso real con equipos de trabajo en remoto

Conferencias Agile Spain CAS2010 Ser Ágil en España: Un caso real con equipos de trabajo en remoto

Antonio David Fernández. Responsable Centro de desarrollo de Cádiz adfernandez@atsistemas.com Enrique J. Amodeo Rubio. Arquitecto Jefe y Responsable Técnico eamodeorubio@atsistemas.com http://eamodeorubio.wordpress.com

Agenda 1. La llegada del agilismo 2. Búsqueda de herramientas 3. Nuesto primer intento 4. Problemas: Stop & Fix 5. Segundo intento: mejoras 6. Los problemas crecen 7. Mejoras para el futuro

Mayo 2007: La llegada del Agilismo

1.0 Érase una vez ... He pensado que vamos a montar una Software Factory, y va a estar en Cádiz. El jefe ¿Y cómo lo hacemos? ¿Cómo vamos a trabajar?¿Qué infraestructura empleamos? ¿Y el seguimiento? ¿Cómo vamos a reportar los avances a la Dirección? …. Antonio “AD9” Podemos hacer un framework para que el desarrollo sea más sencillo y no tendremos problemas Enrique

1.1 ¿Qué metodología usamos? Dos enfoques, ninguno le gustaba a la dirección: • Metodología pesada. Preventa decía: “CMMI 5 con RUP y hagamos las estimaciones basadas en puntos función … que eso vende mucho” • El sector comercial era de otra opinión: “No usemos nada, que es más barato y al final las cosas salen bien, total, siempre podremos hacer horas extras!” Con lo que se decidió algo más razonable… Usemos una metodología Ágil, he leído “Scrum from the trenches”, y en Arquitectura lo hemos estado investigando y tiene buena pinta. Y no nos olvidemos del TDD! Vale, la metodología Ágil parece un buen punto de compromiso, apliquémosla.

1.2 Con qué contábamos ... Lo primero, era mucha ilusión AD9, te nombro Scrum Emplearemos nuestra infraestructura actual: Master y Product Owner - CVS central en Madrid - Nuestros frameworks. - Conexión ADSL ¡ Estoy apañado ! - Chat - Portátiles - Correo Electrónico. - Servidor de Integración para pruebas manuales - Hoja Excel para seguimiento y planificación

1.3 Por qué Scrum Porque ya teníamos pequeñas experiencias previas. Porque permitía al equipo participar e involucrarse en las planificación del proyecto. Porque el equipo está en remoto, y esa participación hace al equipo más responsable y entusiasta. Porque es sencillo: o De explicar. Son conceptos claros. o Las herramientas no son complejas. o Eso permite crear y alimentar el control de proyecto de forma ágil. o Se puede adoptar sobre la marcha (experimentar) con un coste de o adopción incial bajo Recapitulando, la agilidad y sencillez, se alineaban con la forma de Pensar de la Dirección

1.4 Viviendo en el CAOS ... La hoja Excel da demasiado trabajo! Es necesario actualizar diariamente el trabajo de TODO el equipo! El equipo es remoto, y no podemos emplear técnicas como el Planning Poker, las reuniones las tenemos que hacer por webcam. Además no podemos tener tablón de tareas. Tenemos que mejorar la gestión de código, las integraciones son manuales y hay demasiados conflictos cuando queremos subir una versión al servidor de integración!

Búsqueda de Herramientas

2.0 Búsqueda de Herramientas La hoja Excel como herramienta no era eficiente. No era fácilmente accesible por el equipo, ni tenía en cuenta automáticamente ciertos parámetros básicos como el trabajo disponible dado un equipo. El equipo es remoto, esto es un problema: • El tablón de tareas no era posible, burndown no visible por todos, imputación por mail, etc… • Visibilidad del estado del proyecto para el equipo y los gerentes: burndown, velocity, asignaciones, desviaciones, estimaciones, etc... • La herramienta debía permitir, imputar de forma sencilla el trabajo diario.. Conclusión: Necesitamos una aplicación Web

2.1 Herramientas: XPlanner Proyecto creado con el único objetivo de cubrir las necesidades de una Metodología basada en Scrum. Desarrollada como aplicación J2EE de código abierto. Permite gestionar múltiples proyectos, definiendo para cada uno, miembros Del equipo, e iteraciones. Descomposición del trabajo en historias y tareas, donde los usuarios Pueden imputar el trabajo realizado y el trabajo restante. Burndown generado a las 23:59 de cada día, según las imputaciones Realizadas ese día.

2.2 Herramientas: xPlanner (2)

2.3 Herramientas: Trac Trac es una herramienta Open Source basado en Python, que permite: - Wiki integrada - Gestión de tickets, para representar tareas, bugs, etc.. - Extensible mediante plugins. - Con integración directa con el repositorio de código: CVS, SVN, … - Comunidad muy activa. - Con integración mediante scripts de pre y post-commit de SVN, para implementar trazabilidad de cambios. - Integrado con Mylyn (Eclipse), para acceso integrado desde el entorno de desarrollo. Desventajas: No estaba pensado para soportar una metodología Ágil. Sólo adecuado para gestión de tickets.

2.4 Herramientas: Trac + Agilo (1) Agilo es un plugin de Trac, que lo habilita para gestionar proyectos con Scrum: - Permite disponer de distintos Backlogs, destacando el Product Backlog, Sprint Backlog y Bug Backlog. - Permite clasificar los tickets en tipos: Requisitos, Historias de Usuario, Tareas y Defectos. - Calendario por miembro del equipo.

2.5 Herramientas: Trac + Agilo (2) - Gráfico de Burndown generado dinámicamente en el momento de su consulta. - Asignaciones, y estado actual de cada tarea por cada Sprint.

2.6 Herramientas: Trac + Agilo (3) - Configurable en cuanto a información de las tareas y workflow de las mismas. - Generación automática de métricas por equipo y Sprint. - Permitiendo su acceso bajo los tres perfiles Scrum: PO, SM y TM.

2.7 Trac + Agilo: Desventajas - Entorno desconectado por proyecto  No permite de forma sencilla acceder a información conjunta de forma global: - El objetivo es dar informes sobre la SF a la Dirección. - ¡ No es RIA ! ;-) - No tiene histórico de iteraciones, ya que cambios en las sucesivas iteraciones alteran el estado final de las iteraciones anteriores (ej: composición de un equipo): ¡ Necesitamos datos objetivos para experimentar y mejorar ! ¡ La dirección también espera un informe global del proyecto !

Primer intento

3.0 El Equipo La organización era la siguiente:

3.1 Sprint Planning (1) - Todo el equipo participa - Usamos una arquitectura homogénea que nos permitía partir las historias en tareas de forma mecánica: - El SM entra en la reunión con todas las historias partidas en tareas previamente (agiliza la reunión) - Facilita aprender de estimaciones anteriores - La unidad de medida de esfuerzo es el “kiko”  4 horas un miembro del equipo - La estimación la hacía el equipo votando a mano alzada indicando con los dedos el numero de kikos. SM vota el último para no influir en el resto del equipo.

3.2 Sprint Planning (2) - Capacidad del SPRINT = JORNADAS * 2 * PERSONAS (en kikos)  EJ: Capacidad = 15 jornadas * 2 * 5 TM = 150 kikos - Normalmente usamos 3 semanas - Se van incluyendo historias desglosadas en tareas hasta cubrir la capacidad máxima disponible para el sprint - Las historias se eligen por orden de prioridad según diga el PO - Suele quedar algo de capacidad libre  Margen de maniobra  Necesario ya que la productividad de un humano no es constante - Factor de productividad: - Junior: 50% (necesita aprender) - Senior: 90%

3.3 Daily Meeting! - SM y TMs - Cada uno en su puesto: - Evita tentación de alargar reunión - No hay que andar moviéndose de sitio - Concentrados - Consultando documentos y código si es necesario - Multiconferencia con voz (skype) y chat - Si no hay problemas 2 min por persona - Si hay problemas: - Local  Stop&fix sólo con la persona que tiene el problema - Globales al equipo  Genera discusión entre todos para buscar solución

3.4 Incidencias! En los sprints “No iniciales” de un proyecto, se reserva lo que denominamos “Tiempo de contingencia”, para trabajo que no se puede planificar en el tiempo. Este tiempo de contingencia se resta de la capacidad máxima del equipo en el Sprint Planning. Cuando llega una incidencia, el PO evalúa su criticidad: • URGENTE: Se planifica y estima como una tarea más del sprint actual. Consumimos “tiempo de contingecia” • NORMAL: Se añade al product backlog. El PO podrá planificar en que sprint sucesivo se corrige ¿Y si no queda tiempo de contingencia disponible y es urgente? …mmm… La meto en el sprint y aumento la duración de éste: FAIL !

3.5 Un dia en la vida del SM

FAIL: 3.6 ¡ Los sprints no se respetan ! • Muchas incidencias URGENTES  Se agotaba el tiempo de contingencia  Se “violaba” el sprint al aumentar su duración  No se cumple el plan  Desmoralización • No existía DoD (Definition of Done)  Se producían malentendidos respecto a cuando una historia estaba terminada, algunas interpretaciones: • Funcionando en producción (según el SM) • Sin incidencias en producción (según el PO) • “En mi máquina funciona” (TM) • Compila (TM agobiado) • Pases entre entornos eran infernales: • Problemas de integración • Dependencias del entorno gestionadas manualmente • Build manual • Gestión de dependencias manual • Administración Infraestructura • Tentación de recurrir a malas prácticas en caso de agobio

Enero 2009: Stop & Fix Parar para mejorar

4.0 Stop & Fix (1) No podemos seguir así, mejor paramos y vemos que causa nuestros problemas y como solucionarlos Muchas incidencias, pienso que tenemos un problema con la calidad del código Es que tendríamos que haber acogido el TDD, hagámoslo ahora. Pongamos un SM adicional on-site en Cádiz que te ayude, a veces los problemas se solucionan mejor en directo Ok, el SM en Cádiz puede TDD: pues vamos a ir mirar que la gente use aprendiendo buenas prácticas y no caigan en la tentación

4.1 Stop & Fix (2) Lo de los builds y gestión de dependencias: usemos MAVEN Lo voy a investigar para usarlo de forma eficaz ….. (¿Cómo se enganchará esto con eclipse?) Ahora que tenemos MAVEN y TDD podemos hacer Integración Continua Genial, usaremos Hudson y SONAR Je,je, a instalar y Asi de paso el estado del configurar….. proyecto es mucho más (qué gráficas más visible bonitas!)

4.2 Stop & Fix (3) Los SPRINTS no deben cambiar de tamaño: hay que respetar la cadencia de trabajo Pero, ¿y si resulta que no me queda tiempo de contingencia disponible? El PO debe involucrarse más, si él dice que un bug es urgente que se moje y quite una historia de usuario no tan urgente del sprint para abrir hueco Suena muy bien, pero mejor convences tu al PO, ¿vale? (y asi de paso este trabaja un poco, je,je…)

4.3 Stop & Fix (4) Oye, hemos tardado mucho en darnos cuenta de estos problemas, ¿no? Sí, la presión bajo nuestra disciplina y en los momentos de pico de trabajo hemos dejado de hacer retrospectivas Claro, ahora lo entiendo, que nos sirva todo esto de lección. No podemos dejar de hacer retrospectivas A partir de ahora no nos saltaremos más retrospectivas, asi nos enteraremos de los problemas antes

Mejoras

5.0 Nuevo Equipo

Mejorando: 5.1 MAVEN al rescate La gestión del ciclo de construcción de un proyecto software, para tener en cuenta de forma automática todas las dependencias entre proyectos y con librerías externas, es lo que nos permite Maven. Su ventajas: • Habilita un ciclo de vida repetible: Construcción, pruebas, empaquetado, despliegue, etc.. • Independiente del IDE de desarrollo empleado. • Mejora la carga de los entornos de desarrollo locales y reduce el tiempo de creación inicial y configuración de dichos entornos. • Habilita la creación de repositorios corporativos de dependencias y artefactos, mejorando la organización interna. • Habilita la aplicación de Integración continua de forma sencilla.

Mejorando: 5.2 TDD Requisito Escribir Ejecutar / Tarea / Test Test Bug Unitario N O ¿Pasa Escribir / Arreglar Test? Código Aplicación SI SI ¿Necesita Refactor Refactor? NO Luces Verdes! Supone el fin del miedo a cambiar código por posibles efectos colaterales, al ser detectados en el caso de que ocurran.

Mejorando: 5.3 Integrar MAVEN+Eclipse Para evitar un cambio en la forma de trabajar, se adaptó el uso de Maven desde eclipse, empleando para ello m2eclipse. Sin embargo, se decidió seguir empleando la estructura de proyectos establecida por Maven (src para fuentes, WebContent para contenido web, etc.) en vez de adoptar la de Maven. Del mismo modo, en proyectos multimódulo, no se adoptó el anidamiento de los proyectos físicamente en el repositorio de versiones. Ello implica un mayor esfuerzo de configuración en los POM de los proyectos, y algunas dificultades a la hora de usar algunos plugins muy útiles de Maven, como maven-release-plugin, que son más difíciles de manejar y en ocasiones no están preparados.

Mejorando: 5.4 Integracion continua

Mejorando: 5.5 Integracion continua (2) Configurado en cada proyecto: - Para ejecutar un build completo (compilación, pruebas unitarias y pruebas de integración) cada vez que se detecta un cambio en el repositorio de código. - Ejecutar otro build nocturno periódicamente, para ampliar el build con otras tareas de mayor duración, como pruebas de rendimiento, análisis estático de código, etc.. Nos permite que el desarrollador al entregar un cambio, tenga mayor confianza en que si su cambio afecta al resto del sistema, le será notificado la causa del error en un tiempo muy cercano a la entrega de ese código, con lo que su resolución será mucho más rápida. Nos asegura que el esfuerzo invertido en TDD, va a ser empleado durante toda la vida del proyecto de forma automática.

Mejorando: 5.6 Hudson Hudson: elegido internamente como Servidor de Integración Continua. Permite su configuración e instalación de manera muy sencilla. Uno de sus puntos fuertes es la claridad a la hora de presentar la información de las construcciones de cada proyecto. Extensible mediante plugines que pueden ser descargados e instalados automáticamente desde su consola de administración web. Estos plugines nos permiten trabajar con cualquier VCS (SVN, CVS, GIT, …) así como establecer cualquier post-acción ante un build correcto: - Etiquetado de código - Despliegue automático de artefactos Maven. - Despliegue automático de versiones a entornos de prueba.

Mejorando: 5.7 Sonar Sonar, acumula una serie de frameworks de análisis estático de código (PMD, checkstyle, cobertura, clover, …) que nos permite detectar de forma automática: o Nomenclaturas requeridas por arquitectura y metodología. o Buenas prácticas. o Código repetido. o % de código cubierto por pruebas. o Parámetros de complejidad de clases y métodos. o % de código comentado. Permite realizar seguimiento entre otras cosas, de las buenas prácticas, nomenclaturas, y en particular, de la aplicación de TDD en el desarrollo (% código cubierto > 65%).

Diciembre 2009: Los problemas crecen.

Nuevos Problemas: 6.0 Más recursos A medida que los beneficios de estas nuevas prácticas se extienden entre más proyectos, cada vez hay más necesidades de compilación y entornos de integración  + Hardware Surgen nuevos conceptos: - Agentes de compilación distribuidos. - Integración continua incremental: En proyectos grandes, es necesario abordar la integración en varios pasos. - Mejora de hardware para soportar múltiples entornos de preproducción de los distintos proyectos.

Scrum y la dura realidad: 6.1 Bugs Funcionales (1) Un bug funcional ocurre cuando la especificación de un requisito o historia de usuario no refleja la realidad. Posibles causas: •El analista funcional comete un error en el análisis de requisitos •El cliente haya cambiado los requisitos sin que nosotros nos demos cuenta a tiempo (falta de agilidad). Durante un SPRINT esto puede causar que una o más tareas que están en desarrollo dejen de tener sentido al no reflejar la historia de usuario lo que quiere el cliente ¿Qué hacemos?

Scrum y la dura realidad: 6.2 Bugs Funcionales (2) Posibles planes de acción: • Opción 1: Acortar el sprint y eliminar la historia de usuario que está mal -> FAIL -> Rompe la cadencia • Opción 2: Eliminar la historia que está mal y aprovechar la capacidad que queda libre para incorporar trabajo al sprint desde el product backlog -> sprint planning de emergencia. • Opción 3: Si es una historia muy importante se rehace desde cero y eliminamos historias menos importantes del sprint -> sprint planning de emergencia.

Scrum y la dura realidad: 6.3 Negocio de cliente es muy ágil En algunos clientes los time to market deben ser muy cortos. Es crucial entregar en fecha que mantener a largo plazo el código. Incluso muchos desarrollos pueden ser de usar y tirar (campañas) Acciones posibles: • Ganar agilidad  sprints cortos • Usar un framework muy especializado  mayor productividad • Más automatismo, por ejemplo IC. Si los desarrollos son de usar y tirar: • Simplificar la infraestructura (lenguajes dinámicos, servidores sencillos…) • Eliminar documentación técnica • Bajar el esfuerzo encaminado al mantenimiento (QA, refactoring) • Nunca abandonar TDD  Al fin y al cabo la aplicación debe funcionar, aunque no la vayamos a mantener.

Scrum y la dura realidad: 6.4 Mantenimientos correctivos Cuando un proyecto entra en la fase de mantenimiento, aparece un gran problema. • Las incidencias a resolver aparecen a intervalos no predecibles, muchas veces en rachas. • Se suele tener un equipo dedicado al mantenimiento • No se puede planificar el trabajo en Sprints • Las incidencias de deben arreglar ASAP pero sin sobrecargar al equipo ¿Cómo gestionar todo esto? KANBAN

Scrum y la dura realidad: 6.5 Proyectos cerrados Tiempo de entrega Recursos Alcance Los proyectos cerrados no existen. Los clientes lo saben y por eso normalmente: • Cierran en alcance y dinero  Se protegen • Esperan cierto retraso en la entrega  Por tradición • Se protegen del retraso con clausulas de penalización. Coste estimado = Tamaño del equipo (cerrado) x Tiempo (estimado) Oferta cerrada económicamente = Coste estimado + margen beneficio Hay que mejorar mucho las estimaciones para hacer una oferta competitiva y a la vez ganar dinero  KANBAN

Problemas de Infraestructura: 6.6 Conectividad Uno de los principales problemas, es que al estar el equipo distribuido la pérdida de conectividad o su falta de rapidez, incide en la productividad del equipo, ya que están centralizados: • el repositorio de código. • el entorno de integración continua y el entorno de pruebas. • la herramienta de control y planificación. Además, supone una pérdida de comunicación: • chat, videoconferencia, mail, …

Scrum y la dura realidad: 6.7 Merging • Sprint de 3 semanas. • Al comenzar un sprint, se crea una rama de mantenimiento, usando la última release. • El trabajo para el sprint se continua en el trunk • Si durante el sprint, hay que arreglar los bugs, se hace sobre la rama de mantenimiento • Al final del sprint se hace un merge de las dos ramas PROBLEMA  Merge muy costoso (cada 3 semanas) CAUSA  No existe IC entre la rama de mantenimiento y el trunk

Scrum y la dura realidad: 6.8 Fake TDD • Cuando hay mucha presión existe tendencia a hacer tests no efectivos (baja cobertura). • Son detectables por la herramienta “Cobertura” en el proceso de IC • El SM suele hacer revisiones de tests para asegurarse que son aceptables • Pero el SM puede estar también bajo presión Lo ideal es conseguir un feedback más rápido para la calidad de los tests. A veces el proceso de IC es demasiado lento para esto.

Mejoras futuras (no paramos)

7.0 Mejoras en progreso • No implantadas todavía, en estudio • Tecnología I+D • Aclarando las ideas • Primero PoC

Mejoras en progreso: 7.1 Kanban (muyyy rapido) 1 • Aceptar tareas ASAP (cuando hay capacidad de trabajo libre) • Pero sin saturar al equipo  Limitar cantidad de trabajo en progreso (WIP) • Y seguir priorizando por valor para el cliente  El PO sigue ordenando la cola de entrada (Product Backlog) • Importante: PO debe dividir los requisitos entrantes historias del mismo tamaño  Menos variabilidad • No es necesario abrir sprint  Tender al flujo • Pero podemos seguir teniendo sprints • Conservar Dailys y retrospectivas  Control • Pero no se planifica por sprint  No Sprint Planning • Cada historia se planifica en el último momento, antes de implementarla. • La velocity del equipo se actualiza cada vez que se acaba una historia  Mayor agilidad para mejorar estimaciones

Mejoras en progreso: 7.2 Kanban (muyyy rapido) 2 • Optimizar el tiempo de entrega, no uso de recursos  Se ajusta el WIP • Release ASAP: • Cuando se han completado todos los PBI planeados (construcción) • En cuanto se arregle el bug (mantenimiento) • Ventajas: • Tiende al flujo  Mayor adaptabilidad • Ideal para entornos muy cambiantes o impredecibles  Mantenimientos • El tiempo de entrega por PBI es fácil de medir  Mejores estimaciones • La velocity se actualiza al finalizar cada historia  La estimación se mejora más rápidamente • El error absoluto de la estimación es menor por cada historia que por cada Sprint completo

Mejoras en progreso: 7.3 Kanban: Ejemplo

Mejoras en progreso: 7.4 DVCS: ¿Qué es? •Se tienen N repositorios que se pueden sincronizar • Traer cambios de un repositorio al mio (pull) • Enviar cambios de mi repositorio a otro (push) •El código se ramifica, hay branches implícitas • Optimizados para merge • ¡ IC es más importante aun ! •Trabajo offline: • Tolera fallos de red • Esencial en equipos distribuidos •Mayor autogestión • Ágil • Cada equipo define sus políticas •Menos requisitos de máquinas centrales •Topologia mimetiza: • Estructura de proyecto • Colocación física de equipos

Mejoras en progreso: 7.5 DVCS: ¿Nuestro caso?

Mejoras en progreso: 7.6 IC incremental distribuido • Adaptar IC a DVCS • No existe repositorio central donde hacer IC • ¡Hacer IC en cada repositorio! • Cuando haces commit • Cuando haces pull (traes cambios) • Cuando recibes un push (recibes cambios) • Y no hay conflictos o el merge está ok • Si tu build pasa un estándar de calidad: • Compila y test unitarios • Mejora el nivel de test de aceptación • Tu código promociona al siguiente nivel de repositorio: • Enviar solicitud de pull al repositorio “padre” • El padre entra en IC • Recursivo • Equivalente a un IC incremental o por etapas (staging)

Mejoras en progreso: 7.7 Pair Programming • No se implementa ahora: • A evangelizar y experimentar • Difícil de convencer a la dirección • Ventajas: • Transmisión de información  Aprendizaje  Multidisciplinar • Aprendizaje  Nuevos miembros productivos más rápido • No hay cuellos de botella • QA Continua  Eliminar Fake TDD • Lazos de equipo • Formar parejas: • Los “novatos” eligen historia de usuario a completar • A cada “novato” le toca el especialista en ese tipo de historia • Al finalizar se vuelve al principio  Rotar parejas • Planificar teniendo en cuenta una historia dos personas

Mejoras en progreso: 7.8 Mejores herramientas •De nuevo necesidad de offline •Funcionalidad básica en teléfono móvil •En desktop, usar RIA •Si es open source mejor •Soporte a: • Pair programming • Scrum • Kanban • Multiproyecto • Métricas • Estimación • Funcionalidad integrada VS. Múltiples herramientas • ¡No existe! (qué sepamos) • ¿La tendremos que hacer? HTML5+AJAX

Mejoras en progreso: 7.9 Lecciones aprendidas (Pifias) • Errores cometidos en un principio ¡FAIL! • Stop & Fix  Te dejas llevar por el día a día y no mejoras • Retrospectivas  No hacerlas, tarda en aflorar los problemas • TDD  ¿Test antes de desarrollar, es una locura? • IC  Si no hacíamos TDD, menos IC • Pair Programming  ¿Pero eso no baja la productividad al 50%? • SPRINT Flexible (!qué novatos éramos!) no es Sprint ni es nada • ¿Por qué cometimos estos fallos? • Inexperiencia  Nos lleva a subestimar algunas buenas prácticas • Proyectos cerrados  Mayor dificultad • Equipo distribuido  Mayor dificultad

Mejoras en progreso: 7.10 Lecciones aprendidas • Lo que hicimos bien: • ¡Queremos mejorar!  Terminamos mejorando • Experimentamos y empezamos sencillo • Lo importante es la gente  Equipo • Responsabilidad compartida  Equipo • Terminamos haciendo Stop&Fix en dos ocasiones • Involucrar a la dirección  Tienen más visión de lo que uno espera • Tener éxito rápidamente  La dirección necesita resultados • Equivocarnos  Aprender Si escondes los problemas no puedes mejorar

Gracias por su atención Antonio David Fernández. adfernandez@atsistemas.com Enrique J. Amodeo Rubio. eamodeorubio@atsistemas.com http://eamodeorubio.wordpress.com

Ser Ágil en España: Un caso real con equipos de trabajo en remoto

by Enrique Amodeo on Jun 14, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 14

Statistics

Ser Ágil en España: Un caso real con equipos de trabajo en remoto — Presentation Transcript