Este documento describe las experiencias de implementar métodos ágiles en equipos tradicionales. Explica que es importante recomendar cambios a los jefes y demostrar beneficios concretos. También advierte sobre mitos como pensar que un marco o técnica solucionará todos los problemas o que ser ágil significa no usar documentación. Finalmente, resume los primeros pasos dados como realizar reuniones y planificaciones más ágiles e iterativas y hacer retrospectivas para mejorar continuamente.

1. Experiencias de Implementación Ágil en Equipos Tradicionales Jersson Dongo @jersson Octubre 2009

2. Whosthat? Consultor en TI Arquitecto de Software 9 años en Desarrollo e Implementación de Sistemas de Información CoordinadorAgilePeru Jefe de Arquitectura GesforPerú +1.5 años (oficiales) en Iniciativaságiles a nivel de proyectosinternos/externos y procesos.

3. Agenda Porqué se implementó? Mitos a evitar Errorescometidos Quérealizar? Lo realizado hasta el momento

4. Porqué se implementó? Recomendadopornosotros A los jefes Bondades de técnicas versus Problemascomunes Demostraciones de orden y mejoras a corto plazos Mas quepromesa un compromisofactible

5. Porqué se implementó? Recomendado por los jefes Acabo de verlo en... Deberíamos ahorrar usando... La mejor: La combinación Pero que nazca de los jefes gracias a nuestra recomendación o complemento a sus dudas/aportes

6. Porqué se implementó? La mejor: La combinación Un plan de evagelizacióninterna Aperturahacia los jefes y desde los jefes Equiposcomprometidos / Jefescomprometidos

7. Mitos a evitar Resolverá tus problemas No puedesprometerlo! Mejorque resolver a demandaesidentificar Luego sigue el plan de solución «bala de plata»?

8. Mitos a evitar El manifesto lo es todo Cuántos lo conocen? Primero queda el sentido común Mejor que memorizar, comprender y aplicar de manera incremental Cuidado!

9. Mitos a evitar Cero documentos Son los documentos que necesitas! Los mínimosparatrabajar sin problemas.

10. Mitos a evitar Usar TDD es ser ágil Não! No solo TDD IC, Pruebasunitarias… Procesos <> Herramientas

11. Mitos a evitar Somos agiles pues... Iteramos! Usamoseste Framework Personalizamosestametodología

12. Errorescometidos Confiar al 100% en Un framework / metodología / técnica Recordemos el manifesto… Personalizar/ponerle nombre a La metodología/técnica/framework La reunión

13. Errorescometidos Seguir la norma establecida Como la biblia! TDD desde el primer proyecto Sin haberpasadopor PU Falta de apertura Seragil = puertasabiertas

14. Quérealizar? Conversar con el equipo Mostrarcompromiso y aperturadesdetodos los niveles Presentarconceptosbásicos Proponer y esperarpropuestas

16. Retrospectiva / Mejora continuaDescubrir las bondades en conjunto Revisarpropuestas de maneraabierta

17. Quérealizar? Encontrar las falencias colectivas Mea culpa / Feedback Todo “sin animo de ofender a nadie”

18. Realizadohasta el momento Reuniones mas «agiles» Cualquier miembro del equipo puede definir la agenda o agendar la reunión El problema encontrado es que a veces la experiencia puede «intimidar» Planeamientos mas «agiles» Apertura y revisiones mas periódicas Iteracion y revision del alcance

19. Realizadohasta el momento Retrospectivas Lo bueno/lo malo/lo ideal Inicialmentereuniones “quepodemosmejorar?” Desarrollos con mas iteraciones Con interaciones Hagamos un alcancejusto y presentable en el tiempoquequeda.

20. Realizadohasta el momento Definición de procesos con mas iteraciones Pilotajesdesde el borrador! En muchoscasos el cierre de lasespecificacionesgeneraban un bloqueo.

21. Realizadohasta el momento Productos realizados Framework de Desarrollo Metodología de Construcción Primeras iteraciones se utilizaron en la construccion del FW PilotajessobreProyecto PilotajessobreFase Concetode “Paquetemínimonecesario”

22. Realizadohasta el momento Productos realizados Simplificación de Metodología de Gestión de Proyectos Documentación (secciones y documentos) Procesos En base a experiencias de Metodología de Construcción

23. Referencias A pesar de que La experiencia y el sentidocomun son escenciales Siempre se requiereuna base Scrum desdelastrincheras (mínimo) InfoQ / Navegapolis / Blogs Code Leader / Code Complete Experiencias e Iniciativas del Equipo! www.agile-peru.net