Scrum, Team System y el mundo real{ …si yo he podido tu puedes}Rodrigo Corralrcorral@plainconcepts.com

Software ArchitectPlain Concepts

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}

¿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…

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

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

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

Buenas prácticasPruebas unitarias

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

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

Problemas de comunicación habituales

Obsolescencia de la documentaciónCambios no informados

Asegurar un extraordinario ROIUtilizar extensivamente las capacidades de WSS

Mantener la documentación estrictamente necesaria

Usar otras formas de documentaciónCompartir información a diario

Informar ‘hacia afuera’ y promocionar el feedback

Extraordinario lead time de los proyectosExtraordinario ROI

Clientes satisfechosBajo riesgo por rotación

Confianza en la documentación

Buenas prácticasFacilitar la comunicación

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

Resumiendo

No es fácilEs posible

EquipoMetodologíaBuenas prácticasHerramientas adecuadasEquivocaciones o conocimiento

Los resultados son espectaculares

¡Haced algo! {

}! … os podemos ayudar

Recursos

Mi blog: http://geeks.ms/blogs/rcorralwww.scrumforteamsystem.comrcorral@plainconcepts.com

¡Gracias!