Jose alberto. Product Assurance in agile developmentss. A Team-Based Approach

PARTE1 GMV: UNA BREVE PRESENTACIÓN
MITOS DE LA GESTIÓN DE PROYECTOS
EL MANIFIESTO AGILE: VALORES INICIALES Y VALORES
REVISADOS
LA PROPUESTA DE VALOR AGILE
EL ENFOQUE AGILE
METODOLOGÍAS Y PRÁCTICAS AGILE
EL TRIÁNGULO INVERTIDO DE LAS RESTRICCIONES EN
AGILE
TIMEBOXING Y PRIORIZACIÓN
VISIÓN DE CONJUNTO DE AGILE
EL MANIFIESTO AGILE: PRINCIPIOS

GMV: UN GRUPO TECNOLÓGICO
GLOBAL
PARTE 1
Grupo
multinacional
tecnológico
Fundado en
1984
Capital
privado
Sede principal
en España
(Madrid)
Oficinas en 10 países
Más de 1.100
empleados
Origen
vinculado
al sector
espacial
Aeronáutica, Espacio, Defensa,
Seguridad, Sanidad, Transporte,
Banca y finanzas, y Tecnologías de la
Información y la Comunicación
Ingeniería, desarrollo
e integración de
sistemas, software,
hardware, servicios y
productos
especializados

GMV: COMPROMISO CON LA
CALIDAD
PARTE 1
GMV Aerospace
and Defence
S.A.U.
GMV Soluciones
Globales
Internet S.A.U.
GMV Sistemas S.A.U GMVIS Skysoft S.A.
GMV Innovating
Solutions Pvt. Ltd.
GMV NA
CMMI Level 5 ✓ ✓ ✓ ✓
CMMI Level 3 ✓
AQAP/PECAL 2110 ✓
AQAP/PECAL 2210 ✓
UNE-EN ISO 14001:2004 ✓ ✓ ✓
UNE-EN IS0 9001:2008 ✓ ✓ ✓ ✓ ✓
UNE-EN ISO 9100:2010 ✓ ✓ ✓
ISO 13485:2003 ✓
ISO 27001:2005 ✓
ISO 20000-1:2011 ✓
ISO 22301:2012 ✓
UNE 166002 ✓
Madrid Excelente ✓

MITOS DE LA GESTIÓN DE
PROYECTOS
PARTE 1
Nada va a cambiar a lo largo
del proceso de construcción.
Los Desarrolladores saben
exactamente cómo
construirlo.
El Cliente sabe exactamente
lo que quiere.
Muchas cosas cambian a lo
largo del proceso de
contrucción.
Los Desarrolladores
descubren cómo construirlo
al tiempo que lo van
construyendo.
El Cliente descubre lo que
quiere según va viendo o
experimentando.
LOS MITOS
LA REALIDAD

PARTE 1
EL MANIFIESTO AGILE:
VALORES INICIALES
Individuos e interacciones
Software funcionando
Colaboración del cliente
Responder al cambio
Procesos y herramientas
Documentación extensiva
Negociación contractual
Seguir un plan
Agile, reconociendo valor en los elementos tradicionales, surge para enfrentar a ellos nuevos valores.
Frente a
Frente a
Frente a
Frente a

PARTE 1
VALORES REVISADOS
Individuos e interacciones Procesos y herramientas
Software funcionando Documentación extensiva
Colaboración del cliente Negociación contractual
Responder al cambio Seguir un plan
Hoy en día, debido a múltiples factores (la tecnología cambiante, la omnipresencia del software, el
incremento en su complejidad y la existencia aún notable de proyectos fallidos), conviene revisar estos
valores de manera que coexistan con los tradicionales.
Combinado con
Equilibrado con
Combinado con
Combinado con

GENERAL PRESENTATION
06/02/20
13
LA PROPUESTA DE VALOR
AGILE
PARTE 1

06/02/20
13
EL ENFOQUE AGILE
PARTE 1
 Agile es una manera de pensar, una filosofía
basada en los valores, los principios y las
prácticas Agile.
 Agile no es un proceso o un marco de trabajo o
una herramienta específicos.
 El pensamiento Agile puede materializarse en
varias prácticas diferentes.
Enfoque
Agile
4
Valores
12
Principios
Varias
Prácticas

METODOLOGÍAS Y
PRÁCTICAS AGILE
PARTE 1
Scrum Kanban
Crystal
Clear
Extreme
Programming
XP
Lean Software
Development
Dynamic Systems
Development
Method
DSDM
Feature Driven
Development
FDD
Rational
Unified
Process
RUP
Refactoring
Test Driven
Development
Continuous
Integration
Story-Driven
Modeling
Velocity
Tracking
Pair
Programming
Retrospectives

EL TRIÁNGULO INVERTIDO DE
LAS RESTRICCIONES EN AGILE
PARTE 1
 Enfoque Agile: Alcance emergente (variable). Tiempo y Coste fijos; si hay flexibilidad en las
prioridades de los temas que están bajo ese Alcance.
Alcance
Coste Tiempo
Restricciones en un
Proyecto Agile
 Enfoque Tradicional: Alcance conocido (fijo). Tiempo y Coste estimados para ese Alcance; es un
hecho que es difícil “cuadrar” el Alcance por adelantado.
Alcance
Coste Tiempo
Restricciones en un
Proyecto Tradicional
Variable
Fijo

06/02/20
13
TIMEBOXING Y PRIORIZACIÓN
PARTE 1
 Se establecen períodos de duración fija y relativamente corta (timeboxes) en los que realizar un
trabajo o un conjunto de actividades definido de antemano.
New Must have
Could have
Alcance
Coste Tiempo
TABLA DE
PRIORIDAD
Must
have
Should have
Could have

06/02/20
13
VISIÓN DE CONJUNTO DE AGILE
PARTE 1

06/02/20
13
PRINCIPIOS
PARTE 1
Satisfacer al
cliente mediante
la entrega
temprana y
continua de
software con
valor
Aceptar que los
requisitos
cambien, incluso
en etapas
tardías del
desarrollo
Entregar
software que
funciona
frecuentemente,
entre dos
semanas y dos
meses
Los responsables
de negocio y los
desarrolladores
trabajan juntos
de forma
cotidiana
Los proyectos se
desarrollan en
torno a individuos
motivados a
quienes se confía
la ejecución del
trabajo
El método más
eficiente y
efectivo de
comunicarse es la
conversación cara
a cara
El software que
funciona es la
principal medida
del progreso
Se promueve un
desarrollo
sostenible,
manteniendo un
ritmo constante
de forma
indefinida
Atención
continua a la
excelencia
técnica y al buen
diseño
Equipos auto-
organizados como
fuente de las
mejores
arquitecturas,
requisitos y
diseños
Reflexiones
periódicas de
todo el equipo
para ajustar y
mejorar su
efectividad
Simplicidad como
arte de
maximizar la
cantidad de
trabajo que no se
hace

PARTE2 RETOS Y OPORTUNIDADES DE AGILE SW QA
IMPLICACIONES SOBRE SW QA
TAREAS CLAVE DE AGILE SW QA
PUNTOS DE CONTROL EN AGILE SW QA
DIFERENCIAS EN LAS ACTIVIDADES DE V+V
IMPLICACIONES SOBRE ECSS Y REVISIONES FORMALES
(MILESTONES)
IMPLICACIONES SOBRE CMMI
CONCLUSIONES E IDEAS FINALES

06/02/20
13
RETOS Y OPORTUNIDADES DE
AGILE SW QA
PARTE 2
Proceso de seguimiento y control
Pocas revisiones principales (hitos)
Control del cambio
Documentar como evidencia
Cultura de confianza Frente a
Muchas pequeñas evaluaciones Frente a
Bienvenida al cambio Frente a
Documentar por valor Frente a
LAS OPORTUNIDADES
Respuesta rápida a los problemas
Mejora del proceso como parte del
propio proceso de desarrollo
Métricas inmediatas sobre el
producto
Promover mejores prácticas

06/02/20
13
IMPLICACIONES SOBRE SW QA
PARTE 2
 Las pocas revisiones principales (hitos) se convierten en muchas revisiones pequeñas.
 V+V continua.
 Aceptación iterativa.
 Participación activa y frecuente del Cliente.
 Apoyo a los equipos en la medición y análisis.
 Supervisión de los puntos de control automáticos de SW QA.

06/02/20
13
TAREAS CLAVE DE AGILE SW QA
PARTE 2
 Supervisión de la priorización de los requisitos.
 Supervisión de las iteraciones.
 Puntos de control automáticos de SW QA en integración continua.
 QA proactivo, integración en el equipo.
 Transparencia, debido a la medición y análisis continuo.
 Aceptación y V+V continua.

PUNTOS DE CONTROL EN AGILE SW QA
PARTE 2

DIFERENCIAS EN LAS ACTIVIDADES
DE V+V
PARTE 2

06/02/20
13
IMPLICACIONES SOBRE ECSS Y
REVISIONES FORMALES (MILESTONES)
PARTE 2
ECSS - European Cooperation for Space Standardization
 ECSS es una iniciativa para desarrollar un conjunto
único y coherente de estándares user-friendly para uso
en todas las actividades de Espacio en Europa.
 ECSS se origina oficialmente en otoño de 1993.

06/02/20
13
PARTE 2
 ECSS se despliega en tres ramas y
varias disciplinas por rama.

06/02/20
13
PARTE 2
Acquisition
Supply
Primary life cycle processes
Development
Operation
Maintenance
Documentation
Configuration Management
Supporting life cycle processes
Quality Assurance
Verification
Validation
Joint Review
Audit
Problem resolution
Improvement
Management Infrastructure
Training
Organizational life cycle processes
Other ECSS
E-ST-40C
Q-ST-80C
Details for SPA
and/or SW-
Engineering
 ECSS cubre los procesos del estándar ISO 12207 de Ingeniería del Software.

06/02/20
13
PARTE 2
 Ciclo de vida del software ECSS
basado en fases y revisiones.

06/02/20
13
PARTE 2

06/02/20
13
PARTE 2
 CMMI es una colección de prácticas que las
organizaciones (SW, HW e IT) pueden adoptar
para mejorar su desempeño. CMMI se puede
adoptar en dos modos: por etapas (hoja de
ruta) o continuo (“a la carta”).
 CMMI es un modelo de 5 niveles:
 El Nivel 1 (Inicial) representa el nivel inicial caracterizado por la falta de estabilidad y
de planificación, en que el éxito de los proyectos se basa en el esfuerzo personal y a
menudo se producen fracasos, retrasos y sobrecostes.
 El Nivel 2 (Repetible) se enfoca en la gestión básica de proyectos y cambios.
 El Nivel 3 (Definido) se enfoca en las habilidades de ingeniería, la gestión avanzada y el
aprendizaje de la organización.
 Los Niveles 4 (Gestionado) y 5 (Optimizado) se enfocan en el uso de la estadística para
mejorar el desempeño de la organización, controlando estadísticamente procesos
seleccionados y reduciendo la variación.

06/02/20
13
PARTE 2
 Scrum es una metodología de desarrollo Agile
que sigue un ciclo de vida predefinido.
 Scrum se basa en tres roles principales:
 El Product Owner comunica la visión del producto al equipo de desarrollo. Esto incluye
representar los intereses del cliente por medio de requisitos y prioridades.
 El Scrum Master actúa como intermediario entre el Product Owner y el equipo. No
gestiona al equipo sino que trabaja para ayudar al equipo a alcanzar los objetivos de
cada Sprint eliminando obstáculos. Verifica que se sigue el método Scrum.
 Los miembros del equipo realizan el trabajo del proyecto. Normalmente el equipo se
compone de ingenieros software diversos: arquitectos, analistas, programadores,
testers, etc.

PARTE 2
CMMI Scrum
Nivel 2
Repetible
 Scrum representa una buena implementación de algunas de las prácticas de este nivel, sin más que el equipo
conserve las artefactos de trabajo como evidencia.
 Generic Practices. Aproximadamente la mitad de las prácticas genéricas de las Áreas de Proceso REQM
(Requirements Management), PP (Project Planning) y PMC (Project Monitoring and Control) están
implementadas por Scrum (www.processgroup.com/scrum-cmmi-mapping-ma-gp-v1.pdf).
 Scrum implementa también todas las prácticas específicas de PP y PMC.
 Respecto a otras Áreas de Proceso:
 Configuration Management (CM) no está establecida como tal, pero se puede adoptar fácilmente
conservando y versionando los artefactos de trabajo.
 Process and Product Quality Assurance (PPQA) no está establecida como tal, pero algunas de sus
actividades se hacen de manera natural cuando el Scrum Master chequea que se sigue el proceso
Scrum, cuando elimina barreras e ineficiencias, y cuando el equipo realiza inspecciones de código,
revisiones de documentos y pruebas. Por tanto, con refinamientos también se puede implementar.
 Measurement and Analysis (MA). No hay prácticas en Scrum que establezcan un programa de medida
similar a las expectativas de MA, pero se pueden usar las medidas de Scrum para implementar MA
(www.processgroup.com/scrum-cmmi-mapping-ma-gp-v1.pdf).
 Supplier Agreement Management (SAM). No hay prácticas en Scrum que traten la selección y gestión
de suministradores.

PARTE 2
CMMI Scrum
Nivel 3
Definido
 Hay dos áreas principales en las que Scrum presenta huecos en este nivel:
 Una es en la expectativa de que datos y lecciones de proyecto se compartan entre proyectos por
medio de una librería o repositorio común de activos.
 Otra es que las fases de ingeniería (requisitos, diseño, implementación, verificación, integración y
validación) estén bien definidas.
 Estos conceptos pueden ser realizados en Scrum, pero no están definidos en Scrum.
 Scrum sí sugiere implementar Communities of Practice y Retrospectives para compartir lecciones aprendidas
dentro de un equipo. Estas ideas se podrían usar ciertamente para poblar un repositorio de activos y por
consiguiente definir mejores prácticas y guías de adaptación.
 Los siguientes componentes de Nivel 3 de CMMI no pueden ser implementados en Scrum sin trabajo
adicional:
 Organizational Process Focus, Organizational Process Definition, Organizational Training
 Integrated Project Management, Risk Management, Decision Analysis and Resolution
 Algunas prácticas específicas de ingeniería (requirements V+V data analysis)
 Objetivo Genérico 3 (utilizar un proceso de adaptación y de amplitud la organización con medidas)
En resumen  Scrum es una buena implementación de algunas de las prácticas de Nivel 2 de CMMI. Las restantes prácticas
de Niveles 2 y 3 se pueden implementar sobre Scrum. Por consiguiente, se puede utilizar Scrum y CMMI a la
vez.

06/02/20
13
CONCLUSIONES E IDEAS
FINALES
PARTE 2
GENERALES
 Agile está aquí para quedarse.
 Existen muchas metodologías y prácticas Agile diferentes.
 No hay una receta única: hay que saber indagar, adoptar y adaptar.
 Se necesita un cambio mental para conseguir involucrar al cliente: participación,
revisiones.
 Implicaciones en la medida del progreso: mayor transparencia, línea de referencia
flotante.
 Las necesidades del usuario son el hilo conductor.
 Se incrementa la satisfacción del cliente a través de la frecuente retroalimentación.
 Seguir las métricas y usarlas como una fuente de entrada más en cada iteración.

FINALES
PARTE 2
PROJECT MANAGEMENT (PM)
 Mantener ambos paradigmas ECSS y Agile simultáneamente requiere una mayor dedicación. Es preferible
usar solo Agile frente a usar ambos paradigmas o solo ECSS.
 Mantener ambos paradigmas ECSS y Agile simultáneamente puede conducir a una mayor conflictividad con el
Cliente sobre lo que está incluido y lo que no en el presupuesto.
 Se necesita asegurar la involucración del cliente; que el Project Manager asuma el rol del Cliente va en contra
de la filosofía Scrum y puede ser contraproducente.
 Se pueden producir puntos de bloqueo o cuellos de botella si el Cliente no proporciona retroalimentación a
tiempo.
 Aunque se recomienda reducir el número de revisiones formales ECSS (por ejemplo combinando varias en
una), se deben mantener los documentos mínimos que sean necesarios a lo largo del ciclo de vida, para que
estén listos para su revisión y aprobación en la revisión final.
 Se recomienda idear y montar mecanismos para generar los documentos mínimos que sean necesarios de
manera automática (y válida) por medio de herramientas y a partir de otros artefactos del desarrollo como
son el diseño, el código fuente y las pruebas.
 Se recomienda usar herramientas flexibles de ticketing con visibilidad externa para el reporting y la
trazabilidad de los principales elementos de gestión del proyecto (tareas, acciones, riesgos, RID, SPR, etc.),
en lugar de realizar informes.

FINALES
PARTE 2
V+V, CM, QA
 Las prácticas de V+V pueden ser dependientes de la definición de DONE (en particular en el caso de user
stories) que se acuerde con el Cliente.
 La Validación realizada durante las iteraciones no conlleva la generación de informes de pruebas. Los
problemas detectados pueden ser recogidos en herramientas de ticketing.
 La aplicación de un proceso Agile no es suficientemente transparente ni de grano fino en relación a la
verificación del cumplimiento de los requisitos, según se requiere en ECSS.
 En Agile, la trazabilidad de los cambios en los elementos de configuración (en particular documentos) no se
suele estar contenida en los elementos mismos, sino que se encuentra distribuida y dispersa en el product
backlog, wikis, MOM, documentos informales o emails. Ello puede dificultar la verificación.
 En Agile, el Responsable de QA puede compartir algunas tareas con el Scrum Master, como son:
 Asegurar que el equipo sigue los procedimientos y estándares aplicables al proyecto, durante todo el proyecto
pero especialmente en las primeras etapas.
 Asegurar que todos los miembros del equipo usan el mismo entorno de desarrollo (incluyendo conjunto de
reglas, métricas, configuración, etc.) , durante todo el proyecto pero especialmente en las primeras etapas.
 Participar en los review meetings, una vez por Sprint.
 En la entrega final, asegurar que los productos a entregar al Cliente son correctos, completos y poseen la
calidad esperada.

www.gmv.com
GRACIAS
jagonzalez@gmv.com

Jose alberto. Product Assurance in agile developmentss. A Team-Based Approach

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (10)

Similar a Jose alberto. Product Assurance in agile developmentss. A Team-Based Approach

Similar a Jose alberto. Product Assurance in agile developmentss. A Team-Based Approach (20)

Más de 233 Grados de TI

Más de 233 Grados de TI (15)

Último

Último (20)

Jose alberto. Product Assurance in agile developmentss. A Team-Based Approach