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

2. 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

3. 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

4. Mayo 2007:
La llegada del
Agilismo

5. 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

6. 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.

7. 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

8. 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

9. 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!

10. Búsqueda de
Herramientas

11. 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

12. 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.

13. 2.2 Herramientas: xPlanner (2)

14. 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.

15. 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.

16. 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.

17. 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.

18. 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 !

19. Primer intento

20. 3.0 El Equipo
La organización era la siguiente:

21. 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.

22. 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%

23. 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

24. 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 !

25. 3.5 Un dia en la vida del SM

26. 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

27. Enero 2009:
Stop & Fix
Parar para mejorar

28. 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

29. 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!)

30. 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…)

31. 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

32. Mejoras

33. 5.0 Nuevo Equipo

34. 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.

35. 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.

36. 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.

37. Mejorando:
5.4
Integracion continua

38. 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.

39. 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.

40. 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%).

41. Diciembre 2009:
Los problemas
crecen.

42. 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.

43. 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?

44. 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.

45. 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.

46. 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

47. 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

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

49. 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

50. 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.

51. Mejoras futuras
(no paramos)

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

53. 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

54. 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

55. Mejoras en progreso:
7.3
Kanban: Ejemplo

56. 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

57. Mejoras en progreso:
7.5
DVCS: ¿Nuestro caso?

58. 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)

59. 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

60. 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

61. 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

62. 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

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