Conferencias Agile Spain CAS2010Ser Ágil en España: Un casoreal con equipos detrabajo en remoto
Antonio David Fernández.Responsable Centro de desarrollo de Cádizadfernandez@atsistemas.comEnrique J. Amodeo Rubio.Arquite...
Agenda1. La llegada del agilismo2. Búsqueda de herramientas3. Nuesto primer intento4. Problemas: Stop & Fix5. Segundo inte...
Mayo 2007:La llegada delAgilismo
1.0      Érase una vez ...                He pensado que vamos a montar una Software Factory, y va a                estar ...
1.1      ¿Qué metodología usamos?Dos enfoques, ninguno le gustaba a la dirección:• Metodología pesada. Preventa decía: “CM...
1.2      Con qué contábamos ...Lo primero, era mucha ilusión                                                AD9, te nombro...
1.3    Por qué ScrumPorque ya teníamos pequeñas experiencias previas.Porque permitía al equipo participar e involucrarse e...
1.4    Viviendo en el CAOS ...            La hoja Excel da demasiado trabajo! Es necesario actualizar            diariamen...
Búsqueda deHerramientas
2.0    Búsqueda de HerramientasLa hoja Excel como herramienta no era eficiente. No era fácilmenteaccesible por el equipo, ...
2.1    Herramientas: XPlannerProyecto creado con el único objetivo de cubrir las necesidades de unaMetodología basada en S...
2.2   Herramientas: xPlanner (2)
2.3    Herramientas: TracTrac es una herramienta Open Source basado en Python, que permite:- Wiki integrada- Gestión de ti...
2.4     Herramientas: Trac + Agilo (1)Agilo es un plugin de Trac, que lo habilita para gestionar proyectos conScrum:- Perm...
2.5    Herramientas: Trac + Agilo (2)- Gráfico de Burndown generado dinámicamente en el momento de su  consulta.- Asignaci...
2.6    Herramientas: Trac + Agilo (3)- Configurable en cuanto a información de las tareas y workflow de las  mismas.- Gene...
2.7      Trac + Agilo: Desventajas- Entorno desconectado por proyecto  No permite de forma sencilla  acceder a informació...
Primer intento
3.0      El EquipoLa 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  histo...
3.2    Sprint Planning (2)- Capacidad del SPRINT = JORNADAS * 2 * PERSONAS (en kikos)   EJ: Capacidad = 15 jornadas * 2 *...
3.3    Daily Meeting!- SM y TMs- Cada uno en su puesto:   - Evita tentación de alargar reunión   - No hay que andar movién...
3.4    Incidencias!En los sprints “No iniciales” de un proyecto, se reserva lo quedenominamos “Tiempo de contingencia”, pa...
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  S...
Enero 2009:Stop & FixParar para mejorar
4.0    Stop & Fix (1)               No podemos seguir así, mejor paramos y vemos que causa               nuestros problema...
4.1     Stop & Fix (2)                 Lo de los builds y gestión de dependencias: usemos MAVEN                           ...
4.2   Stop & Fix (3)           Los SPRINTS no deben cambiar de tamaño: hay que           respetar la cadencia de trabajo  ...
4.3   Stop & Fix (4)           Oye, hemos tardado mucho en darnos cuenta de estos           problemas, ¿no?               ...
Mejoras
5.0   Nuevo Equipo
Mejorando:5.1         MAVEN al rescateLa gestión del ciclo de construcción de un proyecto software, para teneren cuenta de...
Mejorando:5.2       TDD             Requisito     Escribir         Ejecutar             / Tarea /      Test              T...
Mejorando:5.3       Integrar MAVEN+EclipsePara evitar un cambio en la forma de trabajar, se adaptó el uso de Mavendesde ec...
Mejorando:5.4      Integracion continua
Mejorando:5.5        Integracion continua (2) Configurado en cada proyecto: - Para ejecutar un build completo (compilación...
Mejorando:5.6       HudsonHudson: elegido internamente como Servidor de Integración Continua.Permite su configuración e in...
Mejorando:5.7       SonarSonar, acumula una serie de frameworks de análisis estático de código(PMD, checkstyle, cobertura,...
Diciembre 2009:Los problemascrecen.
Nuevos Problemas:6.0      Más recursosA medida que los beneficios de estas nuevas prácticas se extiendenentre más proyecto...
Scrum y la dura realidad:6.1       Bugs Funcionales (1)Un bug funcional ocurre cuando la especificación de un requisito oh...
Scrum y la dura realidad:6.2       Bugs Funcionales (2)Posibles planes de acción:• Opción 1: Acortar el sprint y eliminar ...
Scrum y la dura realidad:6.3       Negocio de cliente es muy ágilEn algunos clientes los time to market deben ser muy cort...
Scrum y la dura realidad:6.4       Mantenimientos correctivosCuando un proyecto entra en la fase de mantenimiento, aparece...
Scrum y la dura realidad:6.5       Proyectos cerrados                              Tiempo de entrega                      ...
Problemas de Infraestructura:6.6       ConectividadUno de los principales problemas, es que al estar el equipo distribuido...
Scrum y la dura realidad:6.7       Merging• Sprint de 3 semanas.• Al comenzar un sprint, se crea una rama de mantenimiento...
Scrum y la dura realidad:6.8       Fake TDD• Cuando hay mucha presión existe tendencia a hacer tests no  efectivos (baja c...
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 ...
Mejoras en progreso: 7.2         Kanban (muyyy rapido) 2• Optimizar el tiempo de entrega, no uso de recursos  Se ajusta e...
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 r...
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•...
Mejoras en progreso:7.7       Pair Programming• No se implementa ahora:    • A evangelizar y experimentar    • Difícil de ...
Mejoras en progreso:7.8      Mejores herramientas•De nuevo necesidad de offline•Funcionalidad básica en teléfono móvil•En ...
Mejoras en progreso:7.9      Lecciones aprendidas (Pifias)• Errores cometidos en un principio ¡FAIL!   • Stop & Fix  Te d...
Mejoras en progreso:7.10        Lecciones aprendidas• Lo que hicimos bien:   • ¡Queremos mejorar!  Terminamos mejorando  ...
Gracias por su atenciónAntonio David Fernández.adfernandez@atsistemas.comEnrique J. Amodeo Rubio.eamodeorubio@atsistemas.c...
Upcoming SlideShare
Loading in …5
×

Ser ágil en España, un caso real con equipos de trabajo en remoto

824 views
733 views

Published on

Enrique J. Amodeo y Antonio David Fernández

1 Comment
0 Likes
Statistics
Notes
  • Me tome el tiempo para ver la presentación.
    La verdad me enriqueció mucho la forma en la que esta armada la misma, con un ejemplo real de implementación.
    Les agradezco el aporte, realmente muy valioso.

    Saludos desde Argentina!
    Diego
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
824
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Ser ágil en España, un caso real con equipos de trabajo en remoto

  1. 1. Conferencias Agile Spain CAS2010Ser Ágil en España: Un casoreal con equipos detrabajo en remoto
  2. 2. Antonio David Fernández.Responsable Centro de desarrollo de Cádizadfernandez@atsistemas.comEnrique J. Amodeo Rubio.Arquitecto Jefe y Responsable Técnicoeamodeorubio@atsistemas.comhttp://eamodeorubio.wordpress.com
  3. 3. Agenda1. La llegada del agilismo2. Búsqueda de herramientas3. Nuesto primer intento4. Problemas: Stop & Fix5. Segundo intento: mejoras6. Los problemas crecen7. Mejoras para el futuro
  4. 4. Mayo 2007:La llegada delAgilismo
  5. 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. 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. 7. 1.2 Con qué contábamos ...Lo primero, era mucha ilusión AD9, te nombro ScrumEmplearemos 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. 8. 1.3 Por qué ScrumPorque ya teníamos pequeñas experiencias previas.Porque permitía al equipo participar e involucrarse en las planificacióndel proyecto.Porque el equipo está en remoto, y esa participación hace al equipo másresponsable 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 deo adopción incial bajoRecapitulando, la agilidad y sencillez, se alineaban con la forma dePensar de la Dirección
  9. 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. 10. Búsqueda deHerramientas
  11. 11. 2.0 Búsqueda de HerramientasLa hoja Excel como herramienta no era eficiente. No era fácilmenteaccesible por el equipo, ni tenía en cuenta automáticamente ciertospará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. 12. 2.1 Herramientas: XPlannerProyecto creado con el único objetivo de cubrir las necesidades de unaMetodología basada en Scrum.Desarrollada como aplicación J2EE de código abierto.Permite gestionar múltiples proyectos, definiendo para cada uno, miembrosDel equipo, e iteraciones.Descomposición del trabajo en historias y tareas, donde los usuariosPueden imputar el trabajo realizado y el trabajo restante.Burndown generado a las 23:59 de cada día, según las imputacionesRealizadas ese día.
  13. 13. 2.2 Herramientas: xPlanner (2)
  14. 14. 2.3 Herramientas: TracTrac 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. 15. 2.4 Herramientas: Trac + Agilo (1)Agilo es un plugin de Trac, que lo habilita para gestionar proyectos conScrum:- 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. 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. 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. 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. 19. Primer intento
  20. 20. 3.0 El EquipoLa organización era la siguiente:
  21. 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. 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. 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. 24. 3.4 Incidencias!En los sprints “No iniciales” de un proyecto, se reserva lo quedenominamos “Tiempo de contingencia”, para trabajo que no se puedeplanificar en el tiempo.Este tiempo de contingencia se resta de la capacidad máxima del equipoen 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. 25. 3.5 Un dia en la vida del SM
  26. 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. 27. Enero 2009:Stop & FixParar para mejorar
  28. 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. 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 SONARJe,je, a instalar y Asi de paso el estado delconfigurar….. proyecto es mucho más(qué gráficas más visiblebonitas!)
  30. 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. 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. 32. Mejoras
  33. 33. 5.0 Nuevo Equipo
  34. 34. Mejorando:5.1 MAVEN al rescateLa gestión del ciclo de construcción de un proyecto software, para teneren cuenta de forma automática todas las dependencias entre proyectos ycon 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. 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. 36. Mejorando:5.3 Integrar MAVEN+EclipsePara evitar un cambio en la forma de trabajar, se adaptó el uso de Mavendesde eclipse, empleando para ello m2eclipse.Sin embargo, se decidió seguir empleando la estructura de proyectosestablecida por Maven (src para fuentes, WebContent para contenidoweb, etc.) en vez de adoptar la de Maven.Del mismo modo, en proyectos multimódulo, no se adoptó el anidamientode los proyectos físicamente en el repositorio de versiones.Ello implica un mayor esfuerzo de configuración en los POM de losproyectos, y algunas dificultades a la hora de usar algunos plugins muyútiles de Maven, como maven-release-plugin, que son más difíciles demanejar y en ocasiones no están preparados.
  37. 37. Mejorando:5.4 Integracion continua
  38. 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. 39. Mejorando:5.6 HudsonHudson: 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 lainformación de las construcciones de cada proyecto.Extensible mediante plugines que pueden ser descargados e instaladosautomá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. 40. Mejorando:5.7 SonarSonar, acumula una serie de frameworks de análisis estático de código(PMD, checkstyle, cobertura, clover, …) que nos permite detectar deforma 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. 41. Diciembre 2009:Los problemascrecen.
  42. 42. Nuevos Problemas:6.0 Más recursosA medida que los beneficios de estas nuevas prácticas se extiendenentre más proyectos, cada vez hay más necesidades de compilación yentornos de integración  + HardwareSurgen nuevos conceptos:- Agentes de compilación distribuidos.- Integración continua incremental: En proyectos grandes, esnecesario abordar la integración en varios pasos.- Mejora de hardware para soportar múltiples entornos depreproducción de los distintos proyectos.
  43. 43. Scrum y la dura realidad:6.1 Bugs Funcionales (1)Un bug funcional ocurre cuando la especificación de un requisito ohistoria 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 demoscuenta a tiempo (falta de agilidad).Durante un SPRINT esto puede causar que una o más tareas queestán en desarrollo dejen de tener sentido al no reflejar la historia deusuario lo que quiere el cliente ¿Qué hacemos?
  44. 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 capacidadque queda libre para incorporar trabajo al sprint desde el productbacklog -> sprint planning de emergencia.• Opción 3: Si es una historia muy importante se rehace desde cero yeliminamos historias menos importantes del sprint -> sprint planningde emergencia.
  45. 45. Scrum y la dura realidad:6.3 Negocio de cliente es muy ágilEn 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. 46. Scrum y la dura realidad:6.4 Mantenimientos correctivosCuando un proyecto entra en la fase de mantenimiento, aparece ungran 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. 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. 48. Problemas de Infraestructura:6.6 ConectividadUno de los principales problemas, es que al estar el equipo distribuidola pérdida de conectividad o su falta de rapidez, incide en laproductividad 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. 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 ramasPROBLEMA  Merge muy costoso (cada 3 semanas)CAUSA  No existe IC entre la rama de mantenimiento y el trunk
  50. 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ónLo ideal es conseguir un feedback más rápido para la calidad de lostests. A veces el proceso de IC es demasiado lento para esto.
  51. 51. Mejoras futuras(no paramos)
  52. 52. 7.0 Mejoras en progreso • No implantadas todavía, en estudio • Tecnología I+D • Aclarando las ideas • Primero PoC
  53. 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. 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. 55. Mejoras en progreso:7.3 Kanban: Ejemplo
  56. 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. 57. Mejoras en progreso:7.5 DVCS: ¿Nuestro caso?
  58. 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. 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. 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. 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. 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. 63. Gracias por su atenciónAntonio David Fernández.adfernandez@atsistemas.comEnrique J. Amodeo Rubio.eamodeorubio@atsistemas.comhttp://eamodeorubio.wordpress.com

×