Experiencias de Implementacion Agil en Equipos Tradicionales
•Descargar como PPTX, PDF•
0 recomendaciones•315 vistas
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 resolverá todos los problemas o que ser ágil significa no usar documentos. Finalmente, resume los primeros pasos dados como realizar reuniones y planificaciones más ágiles e iterativas y hacer retrospectivas para mejorar continuamente.
Más contenido relacionado
Destacado
Destacado (20)
Similar a Experiencias de Implementacion Agil en Equipos Tradicionales
Similar a Experiencias de Implementacion Agil en Equipos Tradicionales (20)
Experiencias de Implementacion Agil en Equipos Tradicionales
- 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
Notas del editor
- Bondades de técnicas versus ProblemascomunesAquidebemoshablar de problemasclasicos, alargamiento de requerimientos, el desborde del triangulo de calidad, controles de cambio al control de cambio y tecnicas, frameworks, metodologias, quepoco a polo limitanalargamientosDemostraciones de orden y mejoras a corto plazosEl ejemplo mas simple es el de lasiteracionessobre los prototipos, se ganaademas de confianza con el cliente, un menorriesgo de salir del requerimientoMas quepromesa un compromisofactibleNo hablar desolucion de problemasdesde cero, nada esposibleasi, todoes parte de un procesoqueincluye un movimientoportoda la lineaempresarial, cubriendoincluso al jefe (muchasveces el que mas identificadodeberiaestar), recordar y resaltarsiemprequelasbalas de plata no existen
- Recomendado por los jefesSeguirunadirectiva de estetipopuedesermuycontraproducente, mas aunsiesque el equipo no se encuentrapreparadopara un cambio de esetipo. El cambiomuchasveces genera temores mas quetododebido al desconocimiento, peroestoessolucionable con un plan informativo/evangelizador de lastecnicas/modelos a utilizar
- Si lo comienzas a tomarcomouna religion,puescuidado con los problemas!
- Aquídebeconsiderarse el casomencionadopor Linus Torvalds “menosdiseño, menosdocumentacion, sistemasengorrosos” y la respuesta de Joel Spolsky “no todoscontamos con la mismacapacidad”Porotrolado, En algunosproyectos los clientespidenexpresamentemenosdocumentosyaquerecargan los tiempos, en la negociación se considera el concepto de documentosminimos (sin estos no puedoavanzar)
- Comentarcasosrelacionados hasta con CRM o comoesque se vendenmuchasvecesherramientas e implementacionesporseparado (lo cualessabido inclusive desdeherramientastipo SAP)
- En estoscasosdebemossermuycuidadosos, yaquetanto XP/SCRUM (mencionadosporque son los mas utilizados) tienenaspectosminimos, que no solo van con el nombre o tecnica en particular, porejemplo:No solo se trata de iterar o usar un framework al pie de la letra.Iterartiene valor cuando en cadavueltaque le des al documento se agregar un valor funcional, algoque el usuarioconsidereque le da valor, quepuedeusar.La clave estenerclaro el proceso y queestevengadesdeadentro, no comonombre,Yasihablamos de maneras de comprobarsiestamosdentro o no del mito, pues, hay tests, checklists relacionados, como el de nokiaEsdecir, sihablamos de un framework, lo ideal estenerunamanera de demostrar el nivel del cumplimiento del mismoSi se ha personalizadounametodología, que % queda de la base? Aunrecuerdounaimplementacionbajo XP que no usaba Refactoring, user stories (entoncesqueusan?)