Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agiles 2009 - Propuestas / Recomendaciones para Equipos "Tradicionales" - Jersson Dongo

977 views

Published on

Propuesta de puestas en práctica de implementación de tendencias /herramientas ágiles en proyectos con equipos “tradicionales”, es decir con fundamentos y experiencias del tipo escalonado, waterfall o RUP.
El concepto o idea principal de la sesión es compartir recomendaciones que permitirán incrementar la velocidad de implementación de un framework ágil.
Se mostrarán herramientas y recomendaciones partiendo de conceptos tradicionales a tendencias y recomendaciones ágiles. Teniendo en cuenta los riesgos y beneficios principales de estas implementaciones.
Se mencionarán a manera de ejemplo 3 casos reales de la puesta en práctica de estas propuestas.

Published in: Technology, Business, Travel
  • Be the first to comment

  • Be the first to like this

Agiles 2009 - Propuestas / Recomendaciones para Equipos "Tradicionales" - Jersson Dongo

  1. 1. Experiencias de Implementación Ágil en Equipos Tradicionales<br />Jersson Dongo<br />@jersson<br />Octubre 2009<br />
  2. 2. Whosthat?<br />Consultor en TI<br />Arquitecto de Software<br />9 años en Desarrollo e Implementación de Sistemas de Información<br />CoordinadorAgilePeru<br />Jefe de Arquitectura GesforPerú<br />+1.5 años (oficiales) en Iniciativaságiles a nivel de proyectosinternos/externos y procesos.<br />
  3. 3. Agenda<br />Porqué se implementó?<br />Mitos a evitar<br />Errorescometidos<br />Quérealizar?<br />Lo realizado hasta el momento<br />
  4. 4. Porqué se implementó? <br />Recomendadopornosotros<br />A los jefes<br />Bondades de técnicas versus Problemascomunes<br />Demostraciones de orden y mejoras a corto plazos<br />Mas quepromesa un compromisofactible<br />
  5. 5. Porqué se implementó? <br />Recomendado por los jefes<br />Acabo de verlo en...<br />Deberíamos ahorrar usando...<br />La mejor: La combinación<br />Pero que nazca de los jefes gracias a nuestra recomendación o complemento a sus dudas/aportes<br />
  6. 6. Porqué se implementó? <br />La mejor: La combinación<br />Un plan de evagelizacióninterna<br />Aperturahacia los jefes y desde los jefes<br />Equiposcomprometidos / Jefescomprometidos<br />
  7. 7. Mitos a evitar<br />Resolverá tus problemas<br />No puedesprometerlo!<br />Mejorque resolver a demandaesidentificar<br />Luego sigue el plan de solución<br />«bala de plata»? <br />
  8. 8. Mitos a evitar<br />El manifesto lo es todo<br />Cuántos lo conocen?<br />Primero queda el sentido común<br />Mejor que memorizar, comprender y aplicar de manera incremental<br />Cuidado!<br />
  9. 9. Mitos a evitar<br />Cero documentos<br />Son los documentos que necesitas!<br />Los mínimosparatrabajar sin problemas.<br />
  10. 10. Mitos a evitar<br />Usar TDD es ser ágil<br />Não!<br />No solo TDD<br />IC, Pruebasunitarias…<br />Procesos &lt;&gt; Herramientas<br />
  11. 11. Mitos a evitar<br />Somos agiles pues...<br />Iteramos!<br />Usamoseste Framework<br />Personalizamosestametodología<br />
  12. 12. Errorescometidos<br />Confiar al 100% en<br />Un framework / metodología / técnica<br />Recordemos el manifesto…<br />Personalizar/ponerle nombre a<br />La metodología/técnica/framework<br />La reunión<br />
  13. 13. Errorescometidos<br />Seguir la norma establecida<br />Como la biblia!<br />TDD desde el primer proyecto<br />Sin haberpasadopor PU<br />Falta de apertura<br />Seragil = puertasabiertas<br />
  14. 14. Quérealizar?<br />Conversar con el equipo<br />Mostrarcompromiso y aperturadesdetodos los niveles<br />Presentarconceptosbásicos<br />Proponer y esperarpropuestas<br />
  15. 15. Quérealizar?<br />Comprender conceptos básicos (proceso)<br /><ul><li>Iteración
  16. 16. Retrospectiva / Mejora continua</li></ul>Descubrir las bondades en conjunto<br />Revisarpropuestas de maneraabierta<br />
  17. 17. Quérealizar?<br />Encontrar las falencias colectivas<br />Mea culpa / Feedback<br />Todo “sin animo de ofender a nadie”<br />
  18. 18. Realizadohasta el momento<br />Reuniones mas «agiles»<br />Cualquier miembro del equipo puede definir la agenda o agendar la reunión<br />El problema encontrado es que a veces la experiencia puede «intimidar»<br />Planeamientos mas «agiles»<br />Apertura y revisiones mas periódicas<br />Iteracion y revision del alcance<br />
  19. 19. Realizadohasta el momento<br />Retrospectivas<br />Lo bueno/lo malo/lo ideal<br />Inicialmentereuniones “quepodemosmejorar?”<br />Desarrollos con mas iteraciones<br />Con interaciones<br />Hagamos un alcancejusto y presentable en el tiempoquequeda.<br />
  20. 20. Realizadohasta el momento<br />Definición de procesos con mas iteraciones<br />Pilotajesdesde el borrador!<br />En muchoscasos el cierre de lasespecificacionesgeneraban un bloqueo.<br />
  21. 21. Realizadohasta el momento<br />Productos realizados<br />Framework de Desarrollo<br />Metodología de Construcción<br />Primeras iteraciones se utilizaron en la construccion del FW<br />PilotajessobreProyecto<br />PilotajessobreFase<br />Concetode “Paquetemínimonecesario”<br />
  22. 22. Realizadohasta el momento<br />Productos realizados<br />Simplificación de Metodología de Gestión de Proyectos<br />Documentación (secciones y documentos)<br />Procesos<br />En base a experiencias de Metodología de Construcción<br />
  23. 23. Referencias<br />A pesar de que<br />La experiencia y el sentidocomun son escenciales<br />Siempre se requiereuna base<br />Scrum desdelastrincheras (mínimo)<br />InfoQ / Navegapolis / Blogs<br />Code Leader / Code Complete<br />Experiencias e Iniciativas del Equipo!<br />www.agile-peru.net<br />

×