Embed Size (px)
Citation preview
Experiencias de Implementación Ágil en Equipos Tradicionales
Jersson Dongo
@jersson
Octubre 2009
Whos that?
• Consultor en TI
• Arquitecto de Software
• 9 años en Desarrollo e Implementación de Sistemas de Información
• Coordinador AgilePeru
• Jefe de Arquitectura Gesfor Perú
– +1.5 años (oficiales) en Iniciativaságiles a nivel de proyectosinternos/externos y procesos.
Agenda
• Por qué se implementó?
• Mitos a evitar
• Errores cometidos
• Qué realizar?
• Lo realizado hasta el momento
Por qué se implementó?
• Recomendado por nosotros
– A los jefes
– Bondades de técnicas versus Problemas comunes
– Demostraciones de orden y mejoras a corto plazos
– Mas que promesa un compromisofactible
Por qué 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
Por qué se implementó?
• La mejor: La combinación
– Un plan de evagelización interna
– Apertura hacia los jefes y desde los jefes
– Equipos comprometidos / Jefescomprometidos
Mitos a evitar
• Resolverá tus problemas
– No puedes prometerlo!
– Mejor que resolver a demanda esidentificar
– Luego sigue el plan de solución
– «bala de plata»?
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!
Mitos a evitar
• Cero documentos
– Son los documentos que necesitas!
– Los mínimos para trabajar sin problemas.
Mitos a evitar
• Usar TDD es ser ágil
– Não!
– No solo TDD
– IC, Pruebas unitarias…
– Procesos <> Herramientas
Mitos a evitar
• Somos agiles pues...
– Iteramos!
– Usamos este Framework
– Personalizamos esta metodología
Errores cometidos
• 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
Errores cometidos
• Seguir la norma establecida
– Como la biblia!
– TDD desde el primer proyecto
– Sin haber pasado por PU
• Falta de apertura
– Ser agil = puertas abiertas
Qué realizar?
• Conversar con el equipo
– Mostrar compromiso y apertura desdetodos los niveles
– Presentar conceptos básicos
– Proponer y esperar propuestas
Qué realizar?
• Comprender conceptos básicos (proceso)
– Iteración
– Retrospectiva / Mejora continua
• Descubrir las bondades en conjunto
– Revisar propuestas de manera abierta
Qué realizar?
• Encontrar las falencias colectivas
– Mea culpa / Feedback
– Todo “sin animo de ofender a nadie”
Realizado hasta 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
Realizado hasta el momento
• Retrospectivas– Lo bueno/lo malo/lo ideal
– Inicialmente reuniones “que podemosmejorar?”
• Desarrollos con mas iteraciones
– Con interaciones
– Hagamos un alcance justo y presentable en el tiempo que queda.
Realizado hasta el momento
• Definición de procesos con mas iteraciones
– Pilotajes desde el borrador!
– En muchos casos el cierre de lasespecificaciones generaban un bloqueo.
Realizado hasta el momento
• Productos realizados
– Framework de Desarrollo
– Metodología de Construcción
• Primeras iteraciones se utilizaron en la construccion del FW
• Pilotajes sobre Proyecto
• Pilotajes sobre Fase
• Conceto de “Paquete mínimonecesario”
Realizado hasta 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íade Construcción
Referencias
• A pesar de que
– La experiencia y el sentido comunson escenciales
– Siempre se requiere una base
• Scrum desde las trincheras (mínimo)
• InfoQ / Navegapolis / Blogs
• Code Leader / Code Complete
• Experiencias e Iniciativas del Equipo!
• www.agile-peru.net
