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

ALM09 - Scrum, Visual Studio y Buenas Prácticas

on

  • 2,802 views

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

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

Statistics

Views

Total Views
2,802
Views on SlideShare
2,641
Embed Views
161

Actions

Likes
0
Downloads
71
Comments
0

5 Embeds 161

http://geeks.ms 145
http://www.slideshare.net 10
http://www.linkedin.com 3
https://www.linkedin.com 2
http://plantecnologico.gpm.int 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

ALM09 - Scrum, Visual Studio y Buenas Prácticas ALM09 - Scrum, Visual Studio y Buenas Prácticas Presentation Transcript

  • 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
  • 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
  • SOCORRO !
    Gestionar proyectos es dificil
    Gestionar proyectos ES POSIBLE
    Vengo a animaros a hacerlo… y comentar mi experiencia
  • ¿Por qué una metodología?
    Evitar reinventar la rueda
    Establecer un marco de trabajo claro
    Incorporar a nuestra gestión buenas prácticas
  • ¿Qué metodología?
    Simple, de menos a más
    Natural para el desarrollador
    Ágil
    SCRUM
  • ¿Qué está usando el mundo?
  • ¿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
  • ¿Qué herramienta?
    Agnósticarespecto a la metodología
    Con soporteparatodaslasbuenasprácticascomunes
    Integrada en el día al día del desarrollador
  • 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.
  • Scrum
  • El equipo
    Autoorganizado
    Autogestionado
    Multifuncional
  • En adelante… Buenas prácticas
    Dificultades
    Acciones
    Resultados
  • 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
  • A veces las funcionan por que sí…
  • … pero el caos tiene límites
  • 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
  • Siempre se pueden dejar para el final…
  • 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
  • Siempre podemos integrar al final…
  • 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
  • BuenasprácticasMétricas
    ¡Hasta mi jefe lo entiende!
    La velocidad es la métrica clave
  • O puedes ignorar a que te enfrentas…
  • 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
  • Política de gestión de fuentes
    Nada de lo anterior es posible sin:
    Una política adecuada de gestión de fuentes
  • 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
  • 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
  • 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
  • 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)
  • ¿Cómo nos ayuda VS 2010?
    Soporte para desarrollo guiado por la aceptación
  • ATDD en la práctica
    Failed By
    Tested By
    AcceptanceTest
    ProductBacklogItem
    BugReport
    Tested By
    AcceptanceTest
  • ¿Cómo nos ayuda VS 2010?
    Soporte para multiples equipos
  • Resumiendo
    No es fácil
    Es posible
    Equipo
    Metodología
    Buenas prácticas
    Herramientas adecuadas
    Equivocaciones o conocimiento
    Los resultados son espectaculares
  • ¡Haced algo!
    … os podemos ayudar
  • “Gestión de proyectos de software con TeamSystem y TeamFoundation Server”
    • A partir del 15 de Junio (duración: 2 meses)
    • Curso online ( con tutorías y diploma acreditativo)
    • Más de 15 horas de vídeos prácticos.
    • Curso bonificable
    • Precio: 495€ (valor --> ∞) Descuentos por volumen.
    Más información en shop.campusmvp.com
  • Recursos
    Mi blog: http://geeks.ms/blogs/rcorral
    rcorral@plainconcepts.com
    www.scrumforteamsystem.com
  • ¡Gracias!