Gestión ágil con TFS, SCRUM y buenas prácticas<br />Rodrigo Corral<br />ALM Team Lead, Plain Concepts<br />MVP Team System...
Gestión de proyectos<br />Metodología<br />Herramientas<br />Involucrar al cliente<br />Contratos<br />Planificación<br />...
SOCORRO      !<br />Gestionar proyectos es dificil<br />Gestionar proyectos ES POSIBLE<br />Vengo a animaros a hacerlo… y ...
¿Por qué una metodología?<br />Evitar reinventar la rueda<br />Establecer un marco de trabajo claro<br />Incorporar a nues...
¿Qué metodología?<br />Simple, de menos a más<br />Natural para el desarrollador<br />Ágil<br />SCRUM<br />
¿Qué está usando el mundo?<br />
¿Por qué una herramienta?<br />Soportar la metodología y buenas prácticas en el día a día<br />Facilitar la vida de los im...
¿Qué herramienta?<br />Agnósticarespecto a la metodología<br />Con soporteparatodaslasbuenasprácticascomunes<br />Integrad...
Manifiesto ágil<br />A los individuos y su interacción, por encima de los procesos y las herramientas. <br />El software q...
Scrum<br />
El equipo<br />Autoorganizado<br />Autogestionado<br />Multifuncional<br />
En adelante… Buenas prácticas<br />Dificultades<br />Acciones<br />Resultados<br />
Scrum<br />Crear un producto backlog<br />Entender y formar el equipo multidisciplinar<br />Crear el productbacklog<br />E...
A veces las funcionan por que sí…<br />
… pero el caos tiene límites<br />
BuenasprácticasPruebasunitarias<br />Falta de comprensión de las ventajas<br />Falta de pericia al escribir pruebas<br />P...
Siempre se pueden dejar para el final…<br />
BuenasprácticasIntegraciónfrecuente y construccionesautomatizadas<br />Difícil<br />Muy ambiciosos<br />La complejidad de ...
Siempre podemos integrar al final…<br />
BuenasprácticasMétricas<br />Exigen burocracia<br />Exigen seguimiento<br />Exigen control<br />Seleccionar métricas sufic...
BuenasprácticasMétricas<br />¡Hasta mi jefe lo entiende!<br />La velocidad es la métrica clave<br />
O puedes ignorar a que te enfrentas…<br />
Buenas prácticasCalidad, calidad y… calidad<br />La calidad no es importante<br />La falta de calidad daña la agilidad y l...
Política de gestión de fuentes<br />Nada de lo anterior es posible sin:<br />Una política adecuada de gestión de fuentes<b...
Desarrollo concurrente y en equipo<br />$<br />PROJECT<br />DEV<br />-<br />FEATURES<br />+<br />DEV-401<br />+<br />Estru...
Estructura de ramas<br />‘Aislar’ el entorno de pruebas<br />Estructura de carpetas<br />DEV-401<br />$<br />PROJECT<br />...
Estructura de ramas<br />Incrementos de funcionalidad potencialmente entregables<br />Estructura de carpetas<br />DEV-401<...
Estructura de ramas<br />Corrección de errores<br />Los errores que no son urgentes se corrigen sobre la línea principal d...
¿Cómo nos ayuda VS 2010?<br />Soporte para desarrollo guiado por la aceptación<br />
ATDD en la práctica<br />Failed By<br />Tested By<br />AcceptanceTest<br />ProductBacklogItem<br />BugReport<br />Tested B...
¿Cómo nos ayuda VS 2010?<br />Soporte para multiples equipos<br />
Resumiendo<br />No es fácil<br />Es posible<br />Equipo<br />Metodología<br />Buenas prácticas<br />Herramientas adecuadas...
 ¡Haced algo!<br />… os podemos ayudar<br />
“Gestión de proyectos de software con TeamSystem y TeamFoundation Server”<br /><ul><li>A partir del 15 de Junio (duración:...
 Curso online ( con tutorías y diploma acreditativo)
Upcoming SlideShare
Loading in …5
×

ALM09 - Scrum, Visual Studio y Buenas Prácticas

2,355 views

Published on

Presentación que realicé en el ALM Sessions'09 de España

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,355
On SlideShare
0
From Embeds
0
Number of Embeds
170
Actions
Shares
0
Downloads
131
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

ALM09 - Scrum, Visual Studio y Buenas Prácticas

  1. 1. Gestión ágil con TFS, SCRUM y buenas prácticas<br />Rodrigo Corral<br />ALM Team Lead, Plain Concepts<br />MVP Team System <br />Certified Scrum Master y CertifiedScrum Practicioner<br />
  2. 2. Gestión de proyectos<br />Metodología<br />Herramientas<br />Involucrar al cliente<br />Contratos<br />Planificación<br />Procesos<br />Estimación<br />Documentación<br />Gestión de requisitos<br />TesteoUnitario<br />Calidad<br />Comunicación<br />ROI<br />Construcción automatizada<br />Gestión de la configuración<br />Gestión del cambio<br />Equipo<br />
  3. 3. SOCORRO !<br />Gestionar proyectos es dificil<br />Gestionar proyectos ES POSIBLE<br />Vengo a animaros a hacerlo… y comentar mi experiencia<br />
  4. 4. ¿Por qué una metodología?<br />Evitar reinventar la rueda<br />Establecer un marco de trabajo claro<br />Incorporar a nuestra gestión buenas prácticas<br />
  5. 5. ¿Qué metodología?<br />Simple, de menos a más<br />Natural para el desarrollador<br />Ágil<br />SCRUM<br />
  6. 6. ¿Qué está usando el mundo?<br />
  7. 7. ¿Por qué una herramienta?<br />Soportar la metodología y buenas prácticas en el día a día<br />Facilitar la vida de los implicados en el proyecto<br />Recolectar y explotar información sin burocrácia <br />
  8. 8. ¿Qué herramienta?<br />Agnósticarespecto a la metodología<br />Con soporteparatodaslasbuenasprácticascomunes<br />Integrada en el día al día del desarrollador<br />
  9. 9. Manifiesto ágil<br />A los individuos y su interacción, por encima de los procesos y las herramientas. <br />El software que funciona, por encima de la documentación exhaustiva. <br />La colaboración con el cliente, por encima de la negociación contractual. <br />La respuesta al cambio, por encima del seguimiento de un plan. <br />
  10. 10. Scrum<br />
  11. 11. El equipo<br />Autoorganizado<br />Autogestionado<br />Multifuncional<br />
  12. 12. En adelante… Buenas prácticas<br />Dificultades<br />Acciones<br />Resultados<br />
  13. 13. Scrum<br />Crear un producto backlog<br />Entender y formar el equipo multidisciplinar<br />Crear el productbacklog<br />Estimación<br />Seguir la reglas de Scrum<br />Implementar buenas prácticas<br />Aprender a estimar<br />Trabajamos metódicamente continuamente<br />Nuestra velocidad de desarrollo mejora contínuamente<br />Hemos conseguido los objetivos marcados<br />La calidad del producto a mejorado enormemente<br />La rotación en el equipo es nula<br />
  14. 14. A veces las funcionan por que sí…<br />
  15. 15. … pero el caos tiene límites<br />
  16. 16. BuenasprácticasPruebasunitarias<br />Falta de comprensión de las ventajas<br />Falta de pericia al escribir pruebas<br />Pereza al escribir pruebas<br />Problemas de rendimiento de las pruebas<br />Las pruebas unitarias no son opcionales<br />Pragmatismo: cobertura suficiente = pruebas suficientes<br />Mantenimiento contínuo de las pruebas<br />Capacidad de mejorar la base de código con libertad<br />Percepción general de mejora de la calidad de desarrollo<br />Flexibilidad para implementar cambios con rapidez<br />Código más mantenible<br />Mejor diseño<br />+ 2600 pruebas “sin esfuerzo”<br />Ya nadie discute la utilidad<br />
  17. 17. Siempre se pueden dejar para el final…<br />
  18. 18. BuenasprácticasIntegraciónfrecuente y construccionesautomatizadas<br />Difícil<br />Muy ambiciosos<br />La complejidad de la construcción crece más que la complejidad del proyecto<br />Utilizar una figura de Release Manager<br />Mantenimiento continuo de los scripts de construcción<br />Reutilización de tareas de terceros<br />Todo componente tiene su instalador<br />El despliegue ha dejado de ser un dolor<br />Podemos hacer test de humo<br />Detección muy temprana de problemas<br />Muchas menos incidencias<br />
  19. 19. Siempre podemos integrar al final…<br />
  20. 20. BuenasprácticasMétricas<br />Exigen burocracia<br />Exigen seguimiento<br />Exigen control<br />Seleccionar métricas suficientes pero no excesivas<br />Vigilarlas a diario en el DailyScrum<br />Hacerlas pieza central de la gestión del proyecto<br />Analizarlas con visión de medio plazo<br />Mantener la burocracia bajo control<br />Gestionar en base a datos<br />Guiar en base a fundamentoslasactividadesparalelas al desarrollo<br />Hacer visible el progreso, la velocidad de desarrollo<br />Mejorar la gestión de recursos y personal<br />
  21. 21. BuenasprácticasMétricas<br />¡Hasta mi jefe lo entiende!<br />La velocidad es la métrica clave<br />
  22. 22. O puedes ignorar a que te enfrentas…<br />
  23. 23. Buenas prácticasCalidad, calidad y… calidad<br />La calidad no es importante<br />La falta de calidad daña la agilidad y la velocidad<br />Nosotros no elegimos la calidad<br />Dejar la calidad para el final<br />Pruebas de aceptación y de humo<br />Test de carga puntualmente<br />Sprint Reviews: vigilar la calidad percibida<br />Betas públicas: automatización del despliegue<br />Mantener el nivel de calidad es más barato que alcanzarlo<br />Agilidad ante cambios<br />Tiempo de despliegue minimizado<br />Detección temprana de problemas<br />
  24. 24. Política de gestión de fuentes<br />Nada de lo anterior es posible sin:<br />Una política adecuada de gestión de fuentes<br />
  25. 25. Desarrollo concurrente y en equipo<br />$<br />PROJECT<br />DEV<br />-<br />FEATURES<br />+<br />DEV-401<br />+<br />Estructura de ramas<br />Estructura de carpetas<br />DEV-402<br />+<br />DEV-401<br />Antes de comenzar a trabajar en una historia de usuario creamos una rama sobre la que realizamos el desarrollo<br />DEV-402<br />RI<br />RI<br />Branch<br />Branch<br />DEV<br />Concluido el desarrollo de la historia de usuario, integramos el código en la rama principal de desarrollo<br />
  26. 26. Estructura de ramas<br />‘Aislar’ el entorno de pruebas<br />Estructura de carpetas<br />DEV-401<br />$<br />PROJECT<br />+<br />DEV-402<br />DEV<br />RI<br />-<br />FEATURES<br />Branch<br />RI<br />Branch<br />+<br />DEV-401<br />DEV<br />+<br />DEV-402<br />RI<br />Branch<br />+<br />MAIN<br />MAIN<br />Cuando se cumplen las condiciones de calidad el código en desarrollo se integra en la rama MAIN para que los testers comiencen el trabajo de estabilización<br />Cuando se cumplen las condiciones de calidad el código en desarrollo se integra en la rama MAIN para que los testers comiencen el trabajo de estabilización<br />
  27. 27. Estructura de ramas<br />Incrementos de funcionalidad potencialmente entregables<br />Estructura de carpetas<br />DEV-401<br />$<br />PROJECT<br />+<br />DEV-402<br />DEV<br />RI<br />-<br />FEATURES<br />Branch<br />RI<br />Branch<br />+<br />DEV-401<br />DEV<br />+<br />DEV-402<br />Fin de Sprint<br />RI<br />Branch<br />+<br />MAIN<br />MAIN<br />Usar ramas de característica garantiza que a la rama principal, sobre la que realizamos la estabilización del software, solo contendrá características completas y que han alcanzado un mínimo de calidad que permita que el trabajo de los testers sea productivo<br />Realizar el desarrollo de nuevas funcionalidades sobre ramas dedicadas permite que si una funcionalidad no se completa a tiempo para incluirla en el Sprint Review el resto de la base de código principal siga siendo coherente y no incluya características incompletas<br />
  28. 28. Estructura de ramas<br />Corrección de errores<br />Los errores que no son urgentes se corrigen sobre la línea principal de desarrollo y se llevan a las ramas de release, si es necesario, haciendo merge del changeset asociado a la corrección del error<br />Estructura de carpetas<br />DEV-401<br />$<br />PROJECT<br />+<br />DEV-402<br />DEV<br />RI<br />-<br />FEATURES<br />Branch<br />RI<br />Branch<br />+<br />DEV-401<br />DEV<br />+<br />DEV-402<br />RI<br />RI<br />FI<br />Branch<br />+<br />MAIN<br />MAIN<br />Branch<br />RI<br />FI<br />V1.0.1<br />+<br />RELEASE<br />RELEASE 1.0<br />+<br />Contar con una rama de RELEASE nos permite liberar parches de emergencia, para ‘showstopers’, minimizando los posibles impactos sobre el entorno de producción y minimizando las necesidades de validación por parte de los testers<br />RELEASE x.y.z<br />V1.0 (hotfix)<br />
  29. 29. ¿Cómo nos ayuda VS 2010?<br />Soporte para desarrollo guiado por la aceptación<br />
  30. 30. ATDD en la práctica<br />Failed By<br />Tested By<br />AcceptanceTest<br />ProductBacklogItem<br />BugReport<br />Tested By<br />AcceptanceTest<br />
  31. 31. ¿Cómo nos ayuda VS 2010?<br />Soporte para multiples equipos<br />
  32. 32. Resumiendo<br />No es fácil<br />Es posible<br />Equipo<br />Metodología<br />Buenas prácticas<br />Herramientas adecuadas<br />Equivocaciones o conocimiento<br />Los resultados son espectaculares<br />
  33. 33. ¡Haced algo!<br />… os podemos ayudar<br />
  34. 34. “Gestión de proyectos de software con TeamSystem y TeamFoundation Server”<br /><ul><li>A partir del 15 de Junio (duración: 2 meses)
  35. 35. Curso online ( con tutorías y diploma acreditativo)
  36. 36. Más de 15 horas de vídeos prácticos.
  37. 37. Curso bonificable
  38. 38. Precio: 495€ (valor --> ∞) Descuentos por volumen.</li></ul>Más información en shop.campusmvp.com<br />
  39. 39. Recursos<br />Mi blog: http://geeks.ms/blogs/rcorral<br />rcorral@plainconcepts.com<br />www.scrumforteamsystem.com<br />
  40. 40. ¡Gracias!<br />

×