Your SlideShare is downloading. ×
ALM09 - Scrum, Visual Studio y Buenas Prácticas
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

ALM09 - Scrum, Visual Studio y Buenas Prácticas

1,919
views

Published on

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

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

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,919
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
72
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Gestión ágil con TFS, SCRUM y buenas prácticas
    Rodrigo Corral
    ALM Team Lead, Plain Concepts
    MVP Team System
    Certified Scrum Master y CertifiedScrum Practicioner
  • 2. Gestión de proyectos
    Metodología
    Herramientas
    Involucrar al cliente
    Contratos
    Planificación
    Procesos
    Estimación
    Documentación
    Gestión de requisitos
    TesteoUnitario
    Calidad
    Comunicación
    ROI
    Construcción automatizada
    Gestión de la configuración
    Gestión del cambio
    Equipo
  • 3. SOCORRO !
    Gestionar proyectos es dificil
    Gestionar proyectos ES POSIBLE
    Vengo a animaros a hacerlo… y comentar mi experiencia
  • 4. ¿Por qué una metodología?
    Evitar reinventar la rueda
    Establecer un marco de trabajo claro
    Incorporar a nuestra gestión buenas prácticas
  • 5. ¿Qué metodología?
    Simple, de menos a más
    Natural para el desarrollador
    Ágil
    SCRUM
  • 6. ¿Qué está usando el mundo?
  • 7. ¿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
  • 8. ¿Qué herramienta?
    Agnósticarespecto a la metodología
    Con soporteparatodaslasbuenasprácticascomunes
    Integrada en el día al día del desarrollador
  • 9. Manifiesto ágil
    A los individuos y su interacción, por encima de los procesos y las herramientas.
    El software que funciona, por encima de la documentación exhaustiva.
    La colaboración con el cliente, por encima de la negociación contractual.
    La respuesta al cambio, por encima del seguimiento de un plan.
  • 10. Scrum
  • 11. El equipo
    Autoorganizado
    Autogestionado
    Multifuncional
  • 12. En adelante… Buenas prácticas
    Dificultades
    Acciones
    Resultados
  • 13. 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
  • 14. A veces las funcionan por que sí…
  • 15. … pero el caos tiene límites
  • 16. 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
    + 2600 pruebas “sin esfuerzo”
    Ya nadie discute la utilidad
  • 17. Siempre se pueden dejar para el final…
  • 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. ¿Cómo nos ayuda VS 2010?
    Soporte para desarrollo guiado por la aceptación
  • 30. ATDD en la práctica
    Failed By
    Tested By
    AcceptanceTest
    ProductBacklogItem
    BugReport
    Tested By
    AcceptanceTest
  • 31. ¿Cómo nos ayuda VS 2010?
    Soporte para multiples equipos
  • 32. Resumiendo
    No es fácil
    Es posible
    Equipo
    Metodología
    Buenas prácticas
    Herramientas adecuadas
    Equivocaciones o conocimiento
    Los resultados son espectaculares
  • 33. ¡Haced algo!
    … os podemos ayudar
  • 34. “Gestión de proyectos de software con TeamSystem y TeamFoundation Server”
    • A partir del 15 de Junio (duración: 2 meses)
    • 35. Curso online ( con tutorías y diploma acreditativo)
    • 36. Más de 15 horas de vídeos prácticos.
    • 37. Curso bonificable
    • 38. Precio: 495€ (valor --> ∞) Descuentos por volumen.
    Más información en shop.campusmvp.com
  • 39. Recursos
    Mi blog: http://geeks.ms/blogs/rcorral
    rcorral@plainconcepts.com
    www.scrumforteamsystem.com
  • 40. ¡Gracias!