Embed Size (px)
Citation preview
AGILE SW QA GMV
PA
RTE
1
AG
ILE
PA
RTE
1
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 Aerospaceand DefenceS.A.U.
GMV Soluciones Globales Internet S.A.U.
GMV Sistemas S.A.U GMVIS Skysoft S.A. GMV InnovatingSolutions 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
EL MANIFIESTO AGILE: 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
Page 9 GENERAL PRESENTATION
06/02/2013
LA PROPUESTA DE VALOR AGILE
PARTE 1
Page 10 GENERAL PRESENTATION
06/02/2013
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
Page 13 GENERAL PRESENTATION
06/02/2013
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
Page 14 GENERAL PRESENTATION
06/02/2013
VISIÓN DE CONJUNTO DE AGILE PARTE 1
Page 15 GENERAL PRESENTATION
06/02/2013
EL MANIFIESTO AGILE: 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
PA
RTE
2
AG
ILE
SW
QA
PA
RTE
2
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
Page 18 GENERAL PRESENTATION
06/02/2013
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
Page 19 GENERAL PRESENTATION
06/02/2013
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.
Page 20 GENERAL PRESENTATION
06/02/2013
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.
GENERAL PRESENTATION
PUNTOS DE CONTROL EN AGILE SW QA PARTE 2
DIFERENCIAS EN LAS ACTIVIDADES DE V+V
PARTE 2
Page 23 GENERAL PRESENTATION
06/02/2013
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.
Page 24 GENERAL PRESENTATION
06/02/2013
IMPLICACIONES SOBRE ECSS Y REVISIONES FORMALES (MILESTONES)
PARTE 2
ECSS se despliega en tres ramas y varias disciplinas por rama.
Page 25 GENERAL PRESENTATION
06/02/2013
IMPLICACIONES SOBRE ECSS Y REVISIONES FORMALES (MILESTONES)
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.
Page 26 GENERAL PRESENTATION
06/02/2013
IMPLICACIONES SOBRE ECSS Y REVISIONES FORMALES (MILESTONES)
PARTE 2
Ciclo de vida del software ECSS basado en fases y revisiones.
Page 27 GENERAL PRESENTATION
06/02/2013
IMPLICACIONES SOBRE ECSS Y REVISIONES FORMALES (MILESTONES)
PARTE 2
Page 28 GENERAL PRESENTATION
06/02/2013
IMPLICACIONES SOBRE CMMI 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.
Page 29 GENERAL PRESENTATION
06/02/2013
IMPLICACIONES SOBRE CMMI 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.
IMPLICACIONES SOBRE CMMI 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.
IMPLICACIONES SOBRE CMMI 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.
Page 32 GENERAL PRESENTATION
06/02/2013
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.
CONCLUSIONES E IDEAS 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.
CONCLUSIONES E IDEAS 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.
