ser ágil en españa, un caso real con equipos de trabajo en remoto

Ser Ágil en España: Un caso

real con equipos de

trabajo en remoto

Conferencias Agile Spain CAS2010

Antonio David Fernández.

Responsable Centro de desarrollo de Cádiz

[email protected]

Enrique J. Amodeo Rubio.

Arquitecto Jefe y Responsable Técnico

[email protected]

http://eamodeorubio.wordpress.com

mailto:[email protected]


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.

¿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? ….

Podemos hacer un framework para que el desarrollo sea más

sencillo y no tendremos problemas

El jefe

Antonio “AD9”

Enrique

1.1 ¿Qué metodología usamos?

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.

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…

1.2 Con qué contábamos ...

Lo primero, era mucha ilusión

Emplearemos nuestra infraestructura actual:

- CVS central en Madrid

- Nuestros frameworks.

- Conexión ADSL

- Chat

- Portátiles

- Correo Electrónico.

- Servidor de Integración para pruebas manuales

- Hoja Excel para seguimiento y planificación

AD9, te nombro Scrum

Master y Product Owner

¡ Estoy apañado !

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!

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!

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.

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.


- Gráfico de Burndown generado dinámicamente en el momento de su

consulta.

- Asignaciones, y estado actual de cada tarea por cada Sprint.


- 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

3.6FAIL:

¡ 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

mirar que la gente use

buenas prácticas y no caigan

en la tentación

TDD: pues vamos a ir

aprendiendo

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

Asi de paso el estado del

proyecto es mucho más

visible

Je,je, a instalar y

configurar…..

(qué gráficas más

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

5.1Mejorando:

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.

5.2Mejorando:

TDD

Supone el fin del miedo a cambiar código por posibles efectos colaterales,

al ser detectados en el caso de que ocurran.

Requisito / Tarea /

Bug

Escribir Test

Unitario

¿Pasa Test?

Refactor¿Necesita Refactor?

Luces Verdes!

SI

NO

SI

Escribir / Arreglar Código

Aplicación

Ejecutar Test

NO

5.3Mejorando:

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.

5.4Mejorando:

Integracion continua

5.5Mejorando:

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.

5.6Mejorando:

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.

5.7Mejorando:

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.

6.0Nuevos Problemas:

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.

6.1Scrum y la dura realidad:

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?


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.


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.


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


Proyectos cerrados

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

Tiempo de entrega

AlcanceRecursos

6.6Problemas de Infraestructura:

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, …


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


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

7.1Mejoras en progreso:

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


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


Kanban: Ejemplo


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


DVCS: ¿Nuestro caso?


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)


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


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


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


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.

[email protected]

Enrique J. Amodeo Rubio.

[email protected]

http://eamodeorubio.wordpress.com



ser ágil en españa, un caso real con equipos de trabajo en remoto

Documents