CAMINANDO HACIA LA

AGILIDAD CON VISUAL

STUDIO 2010

Rodrigo CorralALM Team Lead & Software Architect

CSM / CSP / PSDT

http://geeks.ms/blogs/rcorral

rcorral@plainconcepts.com

Twitter: r_corralAgile

¿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

EL MANIFIESTO ÁGIL

Individuos e iteraciones sobre Procesos y Herramientas

Sofware que funciona sobre documentación exhaustiva

Colaboración con el cliente sobre negociación de contratos

Responder al cambio sobre seguir un plan

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”

PRINCIPIOS ÁGILES

Satisfacer al cliente.

Los cambios son bienvenidos.

Las entregas son frecuentes.

Trabajamos en equipo.

Motivamos a la gente.

Nos gusta la comunicación cara a cara.

Medida de progreso: Software que funciona.

Mantenemos un ritmo sostenido y sostenible.

La calidad no es opcional.

Primamos la simplicidad.

Evolucionamos nuestros diseños.

Reflexionamos con regularidad.

¿POR QUÉ QUEREMOS SER ÁGILES?

La aproximación ágil al desarrollo de software a

demostrado ser mejor para lograr:

Reaccionar frente a cambios (en los requisitos, en el mercado, en las

prioridades, en la arquitectura…)

Priorizar el desarrollo para logra maximzar el retorno de la inversión

Controlar en tiempo real el progreso del desarrollo, la calidad y los

impedimentos.

Involucrar y motivar a los desarrolladores.

SCRUM

2.

3.

4.

5.

1.

7.

8.

9.

10.

6.

Product Backlog

TeamProduct Owner

Sprint Planning Meeting

Daily Scrum Meeting

Sprint Review

Incremento de

funcionalidad

Sprint Retrospective

Scrum Master

Sprint

Sin cambios

(ni en duración, ni en

alcance)

¿QUIÉN USA SCRUM?

Fuente: TFS Adoption within EMEA – A Process Perspective

http://processmentor.com/Community/blogs/carl_rogers/archive/2008/02/29/481.aspx

¿QUIÉN USA SCRUM?

Fuente: Scrum Alliance – Firms using Scrum

http://scrumcommunity.pbworks.com/Firms+Using+Scrum

¿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

EN ADELANTE… BUENAS PRÁCTICAS

Dificultades

Acciones

Resultados

A VECES LAS COSAS FUNCIONAN POR QUE SÍ…

… PERO EL CAOS TIENE LÍMITES

SIEMPRE SE PUEDEN DEJAR PARA EL FINAL…

SCRUM

Crear un producto backlog

Entender y formar el equipo multidisciplinar

Crear el product backlog

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

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

Pruebas unitarias

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

Integración frecuente y construcciones automatizadas

SIEMPRE PODEMOS INTEGRAR AL FINAL…

Exigen burocracia

Exigen seguimiento

Exigen control

Seleccionar métricas suficientes pero no excesivas

Vigilarlas a diario en el Daily Scrum

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 fundamentos las actividades paralelas al desarrollo

Hacer visible el progreso, la velocidad de desarrollo

Mejorar la gestión de recursos y personal

Métricas

Métricas

O PUEDES IGNORAR A QUE TE ENFRENTAS…

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

Calidad, 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

PRODUCT BACKLOG

LA ‘BUROCRACIA’ FACILITADA

Elige tu interfaz

favorita:

VS, WEB, Excel, Proje

ct…

MÉTRICAS DE PROGRESO

Burndown: trabajo

hecho y trabajo por

hacer

MÉTRICAS DEPROGRESO

TRACKING PROGRESS

MÉTRICAS DE PROGRESOEl portal proporciona

una vista ingrada:

métricas y

documentación

RESUMIENDO

• No es fácil

• Es posible

• Equipo

• Metodología

• Buenas prácticas

• Herramientas adecuadas

• Equivocaciones o conocimiento

• Los resultados son espectaculares

¿QUIERES EMPEZAR? ¡SCRUM WEEK!

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 Scrum Developer .NET

(lunes-viernes, día completo), por Rodrigo Corral y Jose Luis Soria

AZURE

SCRUM, ALM & TFS

USER EXPERIENCE, SILVERLIGHT, WINDOWS PHONE 7

DEBUGGING & OPTIMIZATION

.NET DEVELOPMENT