Gestión ágil con TFS, SCRUM y buenas prácticasRodrigo CorralALM Team Lead, Plain ConceptsMVP Team System Certified Scrum Master y Certified Scrum Practicioner

Gestión de proyectos

Metodología

Planificación

Gestión del cambio

Estimación Documentación

Herramientas

Procesos

ROI

Equipo

Comunicación

Involucrar al cliente

Testeo Unitario

Calidad

Gestión de la configuració

n

Construcción automatizad

a

Contratos

Gestión de requisitos

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óstica respecto a la metodología

Con soporte para todas las buenas prácticas comunes

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

ScrumCrear un producto backlog

Entender y formar el equipo multidisciplinar

Crear el product backlogEstimación

Seguir la reglas de ScrumImplementar buenas prácticas

Aprender a estimar

Trabajamos metódicamente continuamenteNuestra velocidad de desarrollo mejora

contínuamenteHemos conseguido los objetivos marcados

La calidad del producto a mejorado enormementeLa rotación en el equipo es nula

A veces las funcionan por que sí…

… pero el caos tiene límites

Falta de comprensión de las ventajasFalta de pericia al escribir pruebas

Pereza al escribir pruebasProblemas de rendimiento de las

pruebasLas pruebas unitarias no son opcionales

Pragmatismo: cobertura suficiente = pruebas suficientes

Mantenimiento contínuo de las pruebasCapacidad de mejorar la base de código con

libertadPercepción general de mejora de la calidad de

desarrolloFlexibilidad para implementar cambios con rapidez

Código más mantenibleMejor diseño

+ 2600 pruebas “sin esfuerzo”Ya nadie discute la utilidad

Buenas prácticasPruebas unitarias

Siempre se pueden dejar para el final…

DifícilMuy ambiciosos

La complejidad de la construcción crece más que la complejidad del proyecto

Utilizar una figura de Release ManagerMantenimiento continuo de los scripts de

construcciónReutilización de tareas de terceros

Todo componente tiene su instalador

El despliegue ha dejado de ser un dolorPodemos hacer test de humo

Detección muy temprana de problemasMuchas menos incidencias

Buenas prácticasIntegración frecuente y construcciones automatizadas

Siempre podemos integrar al final…

Exigen burocraciaExigen seguimiento

Exigen controlSeleccionar métricas suficientes pero no

excesivasVigilarlas a diario en el Daily Scrum

Hacerlas pieza central de la gestión del proyecto

Analizarlas con visión de medio plazoMantener la burocracia bajo control

Gestionar en base a datosGuiar en base a fundamentos las actividades paralelas al

desarrolloHacer visible el progreso, la velocidad de desarrollo

Mejorar la gestión de recursos y personal

Buenas prácticasMétricas

Logo Partner

Buenas prácticasMétricas

¡Hasta mi jefe lo entiende!La velocidad es la métrica clave

O puedes ignorar a que te enfrentas…

La calidad no es importanteLa falta de calidad daña la agilidad y la velocidad

Nosotros no elegimos la calidadDejar la calidad para el final

Pruebas de aceptación y de humoTest de carga puntualmente

Sprint Reviews: vigilar la calidad percibidaBetas públicas: automatización del despliegue

Mantener el nivel de calidad es más barato que alcanzarlo

Agilidad ante cambiosTiempo de despliegue minimizadoDetección temprana de problemas

Buenas prácticasCalidad, calidad y… calidad

Política de gestión de fuentes

−Nada de lo anterior es posible sin:−Una política adecuada de gestión de

fuentes

Estructura de ramas

Desarrollo concurrente y en equipo

DEV

Bra

nch

DEV-402

RI

Bra

nch

DEV-401

RI

Antes de comenzar a trabajar en una

historia de usuario creamos una rama

sobre la que realizamos el

desarrollo

-

PROJECT

DEV

FEATURES

+ DEV-401

$

+ DEV-402

+

Estructura de carpetas

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

DEV

Bra

nch

RI

Bra

nch

DEV-401

RI

Estructura de carpetas

DEV-402

RI

Bra

nch

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

-

PROJECT

DEV

FEATURES

+ DEV-401

$

+ DEV-402

+

+ 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

Estructura de ramas

Incrementos de funcionalidad potencialmente entregables

DEV

Bra

nch

RI

Bra

nch

DEV-401

RI

Estructura de carpetas

DEV-402

RI

Bra

nch

MAIN

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

DEV-401

DEV-402

-

PROJECT

DEV

FEATURES

+

$

+

+

+ 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

Fin de Sprint

+

Estructura de ramas

Corrección de errores

DEV

Bra

nch

RI

Bra

nch

DEV-401

RI

Estructura de carpetas

DEV-402

RI

Bra

nch

MAIN

DEV-401

DEV-402

-

PROJECT

DEV

FEATURES

+

$

+

+

+ MAIN

RELEASE 1.0

V1.0.1

V1.0 (hotfix)

Bra

nch

RI

FI

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

RELEASER

IF

I

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

+ RELEASE x.y.z

¿Cómo nos ayuda VS 2010?Soporte para desarrollo guiado por la aceptación

ATDD en la práctica

ProductBacklogItem

BugReportFailed By

Tested ByAcceptanceTest

AcceptanceTestTested By

¿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

Recursos

Mi blog: http://geeks.ms/blogs/rcorralrcorral@plainconcepts.com

www.scrumforteamsystem.com

¡Gracias!