Gestión de proyectos. Metodología Involucrar al cliente Planificación. Herramientas. Contratos. Procesos. Estimación requisitos

Transcripción

1 Gestión ágil de proyectos: experiencias prácticas y resultados obtenidos Rodrigo Corral rcorral@plainconcepts.com Twitter: r_corral

2 Gestión de proyectos Metodología Involucrar al cliente Planificación Estimación Gestión n de requisitos ROI Equipo Herramientas Procesos Contratos Documentación Testeo Unitario Calidad Comunicación Construcción Gestión n de la automatizada configuración Gestión n del cambio

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 n buenas prácticas

5 Qué metodología? Simple, de menos a másm Natural para el desarrollador Ágil SCRUM

6 El manifiesto ágil 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

7 Principios ágiles

8 Scrum Scrum Master Daily Scrum Meeting Product Owner Team Sprint Sprint Review Sprint Planning Meeting Sin cambios (ni en duración, ni en alcance) Incremento de funcionalidad Sprint Retrospective Product Backlog

9 Quién usa Scrum? Fuente: TFS Adoption within EMEA A Process Perspective

10 Quién usa Scrum? Fuente: Scrum Alliance Firms using Scrum

11 El equipo Autoorganizado Autogestionado Multifuncional

12 En adelante Buenas prácticas Dificultades Acciones Resultados

13 A veces las cosas funcionan por que sí

14 pero el caos tiene límites

15 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 nuamente Hemos conseguido los objetivos marcados La calidad del producto a mejorado enormemente La rotación n en el equipo es nula

16 Pruebas unitarias 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 nuo de las pruebas Capacidad de mejorar la base de código c con libertad Percepción n general de mejora de la calidad de desarrollo Flexibilidad para implementar cambios con rapidez Código más m s mantenible Mejor diseño pruebas sin esfuerzo Ya nadie discute la utilidad

17 Siempre se pueden dejar para el final

18 Integración n frecuente y construcciones automatizadas 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 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 n muy temprana de problemas Muchas menos incidencias

19 Siempre podemos integrar al final

20 Métricas Exigen burocracia Exigen seguimiento Exigen control Seleccionar métricas m suficientes pero no excesivas Vigilarlas a diario en el Daily Scrum Hacerlas pieza central de la gestión n del proyecto Analizarlas con visión 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 n de recursos y personal

21 Flujo acumulado de proyecto Cuánto han cambiado los requisitos? Cuándo terminaremos?

22 Sprint burndown chart Cuánto retraso tenemos acumulado?

23 O puedes ignorar a que te enfrentas

24

25 Calidad, calidad y 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 n y de humo Test de carga puntualmente Sprint Reviews: vigilar la calidad percibida Betas públicas: p automatización n del despliegue Mantener el nivel de calidad es más m s barato que alcanzarlo Agilidad ante cambios Tiempo de despliegue minimizado Detección n temprana de problemas

26 Siempre se pueden dejar para el final

27 Resumiendo No es fácil Es posible Equipo Metodología Buenas prácticas Herramientas adecuadas Equivocaciones o conocimiento Los resultados son espectaculares

28 Call to action Haced algo! os podemos ayudar

29 Recursos Mi blog: Twitter: r_corral

30 Gracias!