Embed Size (px)
DESCRIPTION
Presentación que realicé en el ALM Sessions'09 de España
Citation preview
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
automatizada
Contratos
Gestión de
requisitos
SOCORRO !Gestionar proyectos es dificil
Gestionar proyectos ES POSIBLE
Vengo a animaros a hacerlo… y
comentar mi experiencia
Evitar reinventar la rueda
Establecer un marco de trabajo claro
Incorporar a nuestra gestión buenas prácticas
Simple, de menos a más
Natural para el desarrollador
Ágil
SCRUM
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
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
Autoorganizado
Autogestionado
Multifuncional
Dificultades
Acciones
Resultados
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
+ 2600 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
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
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
Estructura de ramas
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
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
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
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
Item
Bug
ReportFailed By
Tested ByAcceptance
Test
Acceptance
TestTested By
¡Haced algo!
… os podemos ayudar
¡Gracias!
