Gestión ágil con TFS, SCRUM y buenas prácticas
-
Upload
gillespie-hehir -
Category
Documents
-
view
70 -
download
0
description
Transcript of Gestión ágil con TFS, SCRUM y buenas prácticas
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
¡Gracias!