En esta sesión veremos, en base a escenarios reales, como TFS facilita la adopción de una metodología ágil de desarrollo de software y lleva a los equipos de desarrollo buenas prácticas de ingeniería del software que proporcionan un claro retorno de la inversión y una ventaja competitiva basada en el control explícito de los proyectos y la detección temprana de las fugas de rendimiento por problemas de calidad, evitando la burocracia y facilitando las tareas que el desarrollador realiza.

1. Caminandohacia la agilidad con Visual studio 2010 Rodrigo Corral ALM Team Lead & Software Architect CSM / CSP / PSDT http://geeks.ms/blogs/rcorral rcorral@plainconcepts.com Twitter: r_corral Agile

2. ¿Por qué una metodología? Evitar reinventar la rueda Establecer un marco de trabajo claro Incorporar a nuestra gestión buenas prácticas

3. ¿Qué metodología? Simple, de menos a más Natural para el desarrollador Ágil SCRUM

4. El manifiesto ágil Aunque hay valor en los elementos de la derecha , valoramos más los elementos de la izquierda. “La agilidad es un marco común, las metodologías implementaciones”

5. Principios ágiles

6. ¿Por qué queremos ser ágiles? La aproximación ágil al desarrollo de software a demostrado ser mejor para lograr:

7. Scrum Scrum Master Daily Scrum Meeting Sprint Team Sprint Review Product Owner 1. Sprint Planning Meeting 2. 3. Incremento de funcionalidad Sin cambios (ni en duración, ni en alcance) 4. 5. 6. 7. 8. 9. 10. Sprint Retrospective Product Backlog

8. ¿Quién usa Scrum? Fuente: TFS Adoptionwithin EMEA – A ProcessPerspective http://processmentor.com/Community/blogs/carl_rogers/archive/2008/02/29/481.aspx

9. ¿Quién usa Scrum? Fuente: Scrum Alliance – Firms using Scrum http://scrumcommunity.pbworks.com/Firms+Using+Scrum

10. ¿Por qué una herramienta? Soportar la metodología y buenas prácticas en el día a día Facilitar la vida de los implicados en el proyecto Recolectar y explotar información sin burocrácia

11. ¿Qué herramienta? Agnósticarespecto a la metodología Con soporteparatodaslasbuenasprácticascomunes Integrada en el día al día del desarrollador

12. En adelante… Buenas prácticas Dificultades Acciones Resultados

13. A veces las cosas funcionan por que sí…

14. … pero el caos tiene límites

15. Siempre se pueden dejar para el final…

16. Scrum Crear un producto backlog Entender y formar el equipo multidisciplinar Crear el productbacklog Estimación Seguir la reglas de Scrum Implementar buenas prácticas Aprender a estimar Trabajamos metódicamente continuamente Nuestra velocidad de desarrollo mejora contínuamente Hemos conseguido los objetivos marcados La calidad del producto a mejorado enormemente La rotación en el equipo es nula

17. BuenasprácticasPruebasunitarias Falta de comprensión de las ventajas Falta de pericia al escribir pruebas Pereza al escribir pruebas Problemas de rendimiento de las pruebas Las pruebas unitarias no son opcionales Pragmatismo: cobertura suficiente = pruebas suficientes Mantenimiento contínuo de las pruebas Capacidad de mejorar la base de código con libertad Percepción general de mejora de la calidad de desarrollo Flexibilidad para implementar cambios con rapidez Código más mantenible Mejor diseño Pruebas “sin esfuerzo” Ya nadie discute la utilidad

18. BuenasprácticasIntegraciónfrecuente y construccionesautomatizadas Difícil Muy ambiciosos La complejidad de la construcción crece más que la complejidad del proyecto Utilizar una figura de Release Manager Mantenimiento continuo de los scripts de construcción Reutilización de tareas de terceros Todo componente tiene su instalador El despliegue ha dejado de ser un dolor Podemos hacer test de humo Detección muy temprana de problemas Muchas menos incidencias

19. Siempre podemos integrar al final…

20. BuenasprácticasMétricas Exigen burocracia Exigen seguimiento Exigen control Seleccionar métricas suficientes pero no excesivas Vigilarlas a diario en el DailyScrum Hacerlas pieza central de la gestión del proyecto Analizarlas con visión de medio plazo Mantener la burocracia bajo control Gestionar en base a datos Guiar en base a fundamentoslasactividadesparalelas al desarrollo Hacer visible el progreso, la velocidad de desarrollo Mejorar la gestión de recursos y personal

21. BuenasprácticasMétricas ¡Hasta mi jefe lo entiende! La velocidad es la métrica clave

22. O puedes ignorar a que te enfrentas…

23. Buenas prácticasCalidad, calidad y… calidad La calidad no es importante La falta de calidad daña la agilidad y la velocidad Nosotros no elegimos la calidad Dejar la calidad para el final Pruebas de aceptación y de humo Test de carga puntualmente Sprint Reviews: vigilar la calidad percibida Betas públicas: automatización del despliegue Mantener el nivel de calidad es más barato que alcanzarlo Agilidad ante cambios Tiempo de despliegue minimizado Detección temprana de problemas

24. Política de gestión de fuentes Nada de lo anterior es posible sin: Una política adecuada de gestión de fuentes

25. Desarrollo concurrente y en equipo $ PROJECT DEV - FEATURES + DEV-401 + Estructura de ramas Estructura de carpetas DEV-402 + DEV-401 Antes de comenzar a trabajar en una historia de usuario creamos una rama sobre la que realizamos el desarrollo DEV-402 RI RI Branch Branch DEV Concluido el desarrollo de la historia de usuario, integramos el código en la rama principal de desarrollo

26. Estructura de ramas ‘Aislar’ el entorno de pruebas Estructura de carpetas DEV-401 $ PROJECT + DEV-402 DEV RI - FEATURES Branch RI Branch + DEV-401 DEV + DEV-402 RI Branch + MAIN MAIN 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 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

27. Estructura de ramas Incrementos de funcionalidad potencialmente entregables Estructura de carpetas DEV-401 $ PROJECT + DEV-402 DEV RI - FEATURES Branch RI Branch + DEV-401 DEV + DEV-402 Fin de Sprint RI Branch + MAIN MAIN 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 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

28. Estructura de ramas Corrección de errores 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 Estructura de carpetas DEV-401 $ PROJECT + DEV-402 DEV RI - FEATURES Branch RI Branch + DEV-401 DEV + DEV-402 RI RI FI Branch + MAIN MAIN Branch RI FI V1.0.1 + RELEASE RELEASE 1.0 + 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 RELEASE x.y.z V1.0 (hotfix)

29. Product Backlog

30. La ‘burocracia’ facilitada Eligetuinterfazfavorita: VS, WEB, Excel, Project…

31. Métricas de progreso Burndown: trabajohecho y trabajoporhacer

32. Métricasdeprogreso

33. Tracking Progress

34. Métricasde progreso El portal proporcionauna vista ingrada: métricas y documentación

35. Resumiendo No es fácil Es posible Equipo Metodología Buenas prácticas Herramientas adecuadas Equivocaciones o conocimiento Los resultados son espectaculares

36. ¿quieres empezar? ¡scrumweek!www.scrumweek.com Cursos Curso de Scrum (iniciación a intermedio), por Rodrigo Corral y Jose Luis Soria (lunes-martes, día completo) Coaching de equipos Ágiles, por Ángel Medinilla (lunes-miércoles, 9 a 15) Arquitectura Ágil, por Unai Zorrilla (miércoles-jueves, 9 a 15) Seminarios y talleres en profundidad Gerencia Ágil, por Ángel Medinilla (jueves, 9 a 18) Taller de pruebas unitarias, por Ibon Landa (viernes, 9 a 15) Visual Studio Ágil, por Ibon Landa (jueves-viernes, 16 a 18) Scrum Clinic, por Ángel Medinilla y Rodrigo Corral (viernes, 9 a 15) Curso oficial de certificación Professional ScrumDeveloper .NET (lunes-viernes, día completo), por Rodrigo Corral y Jose Luis Soria

37. aZUREsCRUM, ALM & TFSUser Experience, Silverlight, Windows Phone 7Debugging & Optimization.NET Development