MetodologíaMetodologíaPlanificaciónPlanificación Gestión del cambio EstimaciónEstimaciónDocumentaciónDocumentaciónHerramientasHerramientasProcesosProcesosROIROIEquipoEquipoComunicaciónComunicación.

Presentación del tema: "MetodologíaMetodologíaPlanificaciónPlanificación Gestión del cambio EstimaciónEstimaciónDocumentaciónDocumentaciónHerramientasHerramientasProcesosProcesosROIROIEquipoEquipoComunicaciónComunicación."— Transcripción de la presentación:

1

2 MetodologíaMetodologíaPlanificaciónPlanificación Gestión del cambio EstimaciónEstimaciónDocumentaciónDocumentaciónHerramientasHerramientasProcesosProcesosROIROIEquipoEquipoComunicaciónComunicación Involucrar al cliente Testeo Unitario CalidadCalidad Gestión de la configuración Construcción automatizada ContratosContratos Gestión de requisitos

3 SOCORRO ! Gestionar proyectos es dificil Gestionar proyectos ES POSIBLE Vengo a animaros a hacerlo… y comentar mi experiencia

4 Evitar reinventar la rueda Establecer un marco de trabajo claro Incorporar a nuestra gestión buenas prácticas

5 Simple, de menos a más Natural para el desarrollador ÁgilÁgilSCRUMSCRUM

6

7 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

8 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

9

10

11 AutoorganizadoAutoorganizadoAutogestionadoAutogestionadoMultifuncionalMultifuncional

12 Dificultades AccionesAccionesResultadosResultados

13 Crear un producto backlog Entender y formar el equipo multidisciplinar Crear el product backlog Estimación 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 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 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

14

15

16 Falta de comprensión de las ventajas Falta de pericia al escribir pruebas Pereza al escribir pruebas Problemas de rendimiento de las pruebas 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 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 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

17

18 Difícil Muy ambiciosos La complejidad de la construcción crece más que la complejidad del proyecto 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 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 El despliegue ha dejado de ser un dolor Podemos hacer test de humo Detección muy temprana de problemas Muchas menos incidencias

19

20 Exigen burocracia Exigen seguimiento Exigen control 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 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 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

21

22

23 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 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 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 Mantener el nivel de calidad es más barato que alcanzarlo Agilidad ante cambios Tiempo de despliegue minimizado Detección temprana de problemas

24

25 Estructura de ramas DEV Branch DEV-402 RI Branch 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

26 Estructura de ramas DEV Branch RI Branch DEV-401 RI Estructura de carpetas DEV-402 RI Branch 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

27 Estructura de ramas DEV Branch RI Branch DEV-401 RI Estructura de carpetas DEV-402 RI Branch 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

28 + Estructura de ramas DEV Branch RI Branch DEV-401 RI Estructura de carpetas DEV-402 RI Branch MAIN DEV-401 DEV-402 - PROJECT DEV FEATURES + $$ + + + MAIN RELEASE 1.0 V1.0.1 V1.0 (hotfix) Branch 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 RELEASE RI FI 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

29

30 Product Backlog Item Bug Report Failed By Tested By Acceptance Test Tested By

31

32

33 ¡Haced algo! … os podemos ayudar

34 Gestión de proyectos de software con Team System y Team Foundation 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

35

36 ¡Gracias!