Categoría: calidad

Agile White Book de AXA liberado

AXA (EMEA-LATAM Emerging Markets) ha liberado su Agile White Book, descargable en el siguiente enlace : http://www.slideshare.net/AXAEMEALA/documents

awb-axa-emeala

Este libro es una guía de Agile que cubre los conceptos fundamentales y proporciona una terminología común para los diferentes países de la región EMEA-LATAM (aspecto importante dados sus diferentes niveles de madurez en Agile). Sirve como punto de entrada para futuros Scrum Masters que van a empezar a trabajar en Agile en AXA y esperamos que pueda servir también a otras organizaciones que están comenzando en este camino basado en personas y trabajo en equipo“.

Algunos ejemplos de contenido:

readiness-criteria

metrics-balanced-scorecard

También cuenta con varios checklists que puede ser útil consultar:

PBL-Refinement-checklist.jpg

The importance of early testing and automation

See below some slides of presentation “The importance of early testing and automation” in order to create better solutions, increase predictability and being more productive. Topics as concurrent engineering, acceptance criteria and testing automation criteria are explained in this presentation.

Full slide deck can be found here.

/early-testing-01-waterfall-model

early-testing-02-waterfall-problems

early-testing-03-waterfall-latency

 early-testing-04-waterfall-problems-by-design

/early-testing-05-what-is-agile

early-testing-06-concurrent-engineering

early-testing-07-quick-feedback

early-testing-08-fix-asap

early-testing-09-acceptance-criteria.jpg

early-testing-10-kiss-yagni.jpg

early-testing-11-testing-automation.jpg

early-testing-12-automation-investment.jpg

early-testing-13-automation-criteria.jpg

early-testing-14-summary

 slideshare

See the full presentation (including last updates) in Slideshare: here.

Related presentations

 Related articles

Mejorar la productividad

 

Breve definición de productividad

La productividad es la relación entre valor de negocio obtenido respecto a recursos utilizados, por unidad de tiempo.

 

Cómo medir la productividad

Métricas posibles (por unidad de tiempo):

  • Valor de negocio desarrollado.
  • Complejidad desarrollada (velocidad).

Otras métricas relacionadas:

  • Satisfacción del cliente.
  • Esperas, colas.
  • Defectos.
  • Calidad interna del producto.
  • Motivación del equipo.

 

 

Cómo mejorar la productividad

 

Gestión de producto

  • Disponer de un roadmap de producto priorizado por valor de negocio.
  • Minimizar el tiempo entre la concepción de un objetivo de negocio hasta su entrega al usuario/consumidor, visualizando esperas y cuellos de botella en la cadena de valor y analizando sus causas.

 

Gestión de proyecto

  • Reducción del trabajo en curso (WIP):
    • Minimizar el número de objetivos en curso.
    • Evitar la multitarea.
  • Objetivos a corto plazo.
  • Mejorar planteamientos:

Mejora continua

  • Reflexionar de manera regular y quitar impedimentos.

 

Calidad

  • Cumplir con las expectativas del cliente (evitar retrabajo).
    • Faseado intenso con:
      • Explicación verbal del cliente hacia el equipo del producto al inicio de cada fase.
      • Revisión y feedback del cliente al final de cada fase.
      • Flexibilidad a cambios.
    • Mapa del producto mostrando el avance en el alcance.
  • Reducir los defectos del producto (evitar retrabajo).
    • Ciclos cortos de pruebas.
    • Pruebas de regresión automáticas para la detección temprana de defectos.
  • Mejorar la calidad interna para poder crecer a ritmo sostenido.

 

Tecnología y herramientas

  • Automatización de tareas manuales.
  • Automatización de pruebas.
  • Frameworks de desarrollo.
  • Herramientas de control de calidad.

 

Metodologías y prácticas

  • Estándares de codificación.
  • BDD, TDD.
  • Refactorización (simplificación del diseño).
  • Patrones de diseño evitando sobreingeniería (evitando más complejidad de la necesaria).
  • Peer reviews, Pair programming.

 

 

Comunicación y gestión del conocimiento

  • Minimizar el número de traspasos de información y su volumen.
    • Orientación a resolver objetivos de negocio uno a uno.
    • Personas co-localizadas para fomentar la comunicación cara a cara.
  • Comunicación regular de avance e impedimentos, cara a cara entre todos los participantes.
  • Sistemas colaborativos: wikis, gestión documental, microblogging.
  • Repositorio de componentes.

 

Personas implicadas

  • Mejorar la adecuación, formación y experiencia de todos los participantes en el proyecto.
  • Aumentar la motivación.

 

Artículos relacionados

 

¿Quién es responsable de la calidad?

(Este artículo parte de los comentarios realizados en un hilo del foro de Agile Spain)




El equipo es el responsable de proporcionar un producto de calidad, no se puede escudar en etapas posteriores de verificación de calidad o en las pruebas de aceptación del cliente (Product Owner) para no garantizar la calidad del producto que ha construido.

Profundizando en base a la terminología de la ISO9126 de calidad de producto en ingeniería del software:

  • La calidad en uso (satisfacción del usuario, efectividad, productividad, seguridad) es un aspecto a verificar por el Product Owner que, además de ser representante de los usuarios finales, también debe asegurar que el producto cumpla con las necesidades del negocio y estratégicas de los stakeholders del proyecto.
  • La calidad externa (funcionalidad, usabilidad, eficiencia, mantenibilidad, fiabilidad, portabilidad) en algunos aspectos es más difícil de verificar  por el Product Owner.
  • La calidad interna no suele poder ser verificable directamente por el Product Owner.

Como comenta Xavier Quesada en el mencionado hilo, “[allí donde la calidad externa e interna no es observable] el equipo tiene una obligación básica de desarrollar un producto, un software, de calidad, o sea el Product Owner no debe convertirse en el Tester/QA del equipo”.

Si es necesario, el Product Owner se puede servir de diversos mecanismos de apoyo para verificar la calidad externa e interna del producto como, por ejemplo, una auditoría experta. En el caso de desarrollo de software, se trataría de una auditoría del código fuente, patrones arquitectónicos utilizados, trazabilidad entre requisitos (o historias de usuario) respecto a los casos de prueba de aceptación (condiciones de satisfacción) y otros modelos o entregables, etc.

Según se indica en la guía oficial de Scrum, “el Scrum Master entrena y guía al equipo para que sea más productivo y entregue productos de mayor calidad”. Al ser el responsable de la calidad en el proceso, el Scrum  Master guía al Product Owner y al equipo para conseguir que:

  • El Product Owner (re)priorice en función del valor aportado al negocio (y el coste de implementación).
  • El equipo cumpla con la definición  de hecho que ha sido consensuada con el cliente.
  • El Product Owner revise el producto al final de cada iteración, en la reunión de Demostración de los requisitos completados.
  • El equipo tome consciencia del producto que está entregando (si cumple con las expectativas del Product Owner, si se está degradando la calidad externa e interna y se está introduciendo “deuda técnica” que dificulte su crecimiento sostenido) y guiarlo para que reaccione si hay problemas (como menciona Xavier Quesada), especialmente en las reuniones de retrospectiva al final de cada iteración.
  • Similarmente, el Scrum Master debe hacer recapacitar al Product Owner si quiere rebajar la calidad a cambio de conseguir objetivos en fechas determinadas (lo cual produciría defectos en el producto una vez entregado, ralentizaría después la velocidad del equipo y tiene el riesgo de mala imagen respecto a los consumidores/clientes/usuarios). Si finalmente es necesario hacer esto, el Scrum Master tiene que hacer que esta decisión se tome al nivel más alto posible y que sea visible. Con posterioridad a la toma de esta decisión, el Scrum Master debe ser capaz de demostrar, si es necesario, las consecuencias de haber rebajado la calidad mediante gráficos de tendencias de velocidad y defectos, así como explicar sus causas objetivas (menos testing, menos refactoring, …) [1].

Agilidad es reaccionar ante los impedimentos, problemas, equivocaciones o errores y tomar acciones correctoras, no “mirar a otro lado”, como diría Ángel Medinilla.

 

Enlaces relacionados

Referencias

 [1] Succeeding with Agile: Software Development Using Scrum – Mike Cohn.

 

Agilidad es calidad y competitividad

Este artículo se tomó como base para el mini keynote de apertura del Agile Open Spain 2009.

Agilidad es calidad

 

La agilidad es mayor satisfacción para TODOS los que participan en un proyecto:

    • Nuestros clientes, que reciben un mejor servicio.
  • Los trabajadores (nosotros), que podemos realizarnos profesionalmente en nuestro trabajo y que disfrutamos más.

Esto es lo que venden muchas las metodologías, pero con diferencias fundamentales en cómo entendemos y conseguimos esa calidad:

  1. Calidad es satisfacer las expectativas de nuestros clientes, y para ello no hay nada mejor que priorizar los objetivos del proyecto en función de los que aportan más valor al cliente, enseñarle de manera regular el producto final (una aplicación funcionando) y siendo flexibles a cambios (control empí­rico en contraposición al control predictivo de metodologías más tradicionales, que suponen que es posible conocer desde el principio todos los detalles del sistema a construir y que, por tanto, estos no van a cambiar durante el desarrollo).
  2. Calidad es que lo que nuestros productos puedan crecer de manera sostenible, que estos cambios tengan un impacto controlado, de manera que estos cambios sean baratos. Para ello:
    1. Utilizamos prácticas de ingeniería (patrones de diseño, peer reviews, pair programming, coding standards) y cuidamos la calidad interna de nuestros productos empezando primero por las pruebas (TDD, refactoring).
    2. Mientras construimos nuestros productos, comprobamos de manera continua que se comportan de  manera adecuada. Para que esas comprobaciones sean baratas (dado que hay que repetirla infinidad de veces) automatizamos integraciones y pruebas.
  3. Las metodologías ágiles no se olvidan del capital humano que lo hace posible. Nosotros creemos que la calidad de un proyecto depende de la calidad de TODAS las personas que trabajan en él y de cómo colaboran, mucho más que de tener procesos bien definidos y documentados.

 

Agilidad es competitividad

 

Por otro lado, nunca podremos competir con India o China en precio. La agilidad nos puede ayudar a tener un país más competitivo, es decir, a ser más innovadores, a proporcionar mayor calidad y a ser más productivos. Necesitamos adoptar modelos de gestión que nos permitan adaptarnos de manera continua a un entorno de incertidumbre, en continua evolución, y ser muy ágiles en el desarrollo de iniciativas. La clave vuelve a ser:

  • Modelos dirigidos por valor.
  • Flexibilidad a cambios.
  • Potenciación del equipo, multidisciplinar y autogestionado, para que aporte creatividad en el producto y que sus sinergias y la mejora continua le hagan más eficiente a través de la colaboración de sus miembros.

 

¿Qué se necesita para que una empresa sea ágil?

 

Para que una empresa empiece a ser ágil es conveniente realizar los siguientes requisitos:

  • Un cambio de cultura profundo en individuos y organizaciones, y especialmente en las direcciones y los gestores de las empresas. En lugar del ordeno y mando, para poder crear este tipo de equipos superproductivos y motivados se necesita cambiar a un modelo de gestión basado en la facilitación de la colaboración entre las personas que participan en los proyectos, así como el coaching del equipo, para que adquiera conocimiento de forma colaborativa, que desaprenda, se equivoque y que vuelva a aprender.
  • En esta misma lí­nea, hay que transformar las relaciones de cliente/proveedor en relaciones de socios de proyecto en que todos tenemos que colaborar y todos  tenemos que ganar.
  • A nivel de ingeniería, facilidad para realizar cambios.
  • Enfocarnos en proporcionar valor en todas las tareas que hacemos, desde que aparece la idea del producto hasta que el usuario final o consumidor lo reciben.
     

Todo esto acabamos de ver es, esencialmente, el Manifiesto Ágil, Scrum, eXtreme Programming y Lean Software Development.

 

¿Quien hace Agile?

 

Hoy dí­a, las metodologí­as ágiles se están extendiendo en paí­ses punteros en tecnología (EEUU y su área de influencia, países del norte de Europa y potencias emergentes como India o China).

 
Entre las empresas que han realizado este cambio de paradigma para ser más competitivas y atraer talento podemos encontrar a Google, Amazon, Nokia, British Telecom, Microsoft, SAP, IBM, Bank of America, General Dinamics, Blizzard, Ubisoft, etc. y españolas como Telefónica I+D, Double You, Plain Concepts, Proyectalis, Biko2, Gailén, Autentia, etc.

De cualquier manera, en España las metodologías ágiles todavía son poco conocidas. En poco tiempo, nuestros profesionales y empresas pueden no ser competitivos y ni siquiera colaborar con empresas extranjeras porque no nos habremos adaptado a estas nuevas formas de trabajar.
 

En resumen

 

La agilidad es una gran oportunidad para tener empresas más competitivas y a la vez disfrutar más de nuestros trabajos, oportunidad que no deberí­amos perder para no quedarnos atrás como país.

 
 

Para saber más

 

 

Calidad y agilidad – Resultados del cuarto encuentro ágil en Barcelona

En este encuentro se compartieron experiencias sobre los siguientes temas:

  • La manera en que las metodologías ágiles permiten hacer proyectos con un alto nivel de calidad, entendida como (1) la satisfacción de las expectativas del cliente, usuarios finales o consumidores, (2) el comportamiento correcto del producto y (3) la garantía de su mantenibilidad. Todo ello gracias a los principios de Lean (análisis del valor desde la concepción del producto hasta su venta), a que Scrum en sí mismo es un proceso de mejora continua y a que XP (eXtreme Programming) consta de prácticas de ingeniería enfocadas a mantener una alta calidad interna que permite una velocidad de desarrollo sostenible.

Calidad y agilidad

  • Hasta qué punto la calidad es negociable y cómo, gracias a priorizar los objetivos del proyecto por valor, las metodologías ágiles permiten prescindir de requisitos de baja prioridad antes que tener que degradar la calidad.
  • El proceso de Scrum se puede certificar casi directamente en nivel 3 de CMMI y existen empresas certificadas en nivel 5 que al adoptar Scrum han reducido mucho esfuerzo innecesario. La dificultad de certificar CMMI es la falta de conocimiento de los certificadores sobre metodologías ágiles, aunque el SEI está empezando a tener en cuenta estas metodologías.
  • El objetivo de Q/A en metodologías ágiles es evitar que se produzcan errores más que encontrarlos (con lo cual deben formar parte del propio equipo de desarrollo y participar desde la definición de los objetivos del proyecto) así como colaborar en la mejora de los procesos de trabajo para ser más productivos.
A continuación se detallan las ideas que se trataron respecto a estos temas.
 

 
Conceptos de calidad
 
El ciclo de mejora continua de Deming (PDCA)
En el ciclo de mejora continua de Deming tiene las siguientes actividades [1]:
  • [Plan] Planificar cómo conseguir unos objetivos.
  • [Do] Ejecutar esta planificación.
  • [Check] Verificar los resultados conseguidos.
  • [Act] Definir acciones correctoras a realizar en el siguiente ciclo para mejorar los resultados.
Las dimensiones de la calidad
Simplificando el modelo de calidad ISO 9126 [3], podríamos considerar que la calidad tiene las siguientes dimensiones:

1-     Cumplimiento de expectativas del Cliente (Product Owner).

Yendo un poco más lejos y utilizando el concepto de Lean de mejorar el proceso de producción de valor (analizar desde la concepción de la idea hasta que alguien la utiliza o paga por ella, cuando se recupera la inversión realizada), más que cumplir con las expectativas del cliente, hay que cumplir con las expectativas del consumidor o usuario final de producto, que es quien va a comprarlo o verse beneficiado en su utilización. Por ello, para no crear un producto que nadie va a comprar o una aplicación que nadie va a utilizar, el cliente debería conocer quién es y qué necesita el consumidor o usuario final, hacer participar a personas representativas, investigar el modelo de negocio (cómo va a ganar dinero) y contar con las ideas y aportaciones del equipo.

2-     Calidad externa, funcionamiento correcto. El producto debe comportarse de la manera esperada, tanto a nivel funcional como no funcional (rendimiento, usabilidad, etc.).

3-     Calidad interna. El producto debe ser mantenible, debe poder evolucionar a un ritmo sostenido.

En el encuentro se añadió, desde una perspectiva ágil, una cuarta dimensión:
4-     Satisfacción del equipo, que esté orgulloso de su trabajo, para mantener su motivación, su compromiso con el proyecto y con la empresa.
 
Agilidad, calidad y mejora continua
Scrum [2] es un proceso que en bloques temporales cortos y fijos (entre 2 y 4 semanas) entrega un incremento de producto final. En cada iteración de Scrum se ejecuta el ciclo de mejora continua de Deming en los siguientes ámbitos:
  • Las expectativas del cliente, a las cuales se va acercando iteración a iteración mediante las siguientes actividades:
    • La planificación al inicio de la iteración, en que el equipo se reúne con el cliente, quien ha expresado su expectativas mediante la lista priorizada de objetivos del proyecto (product backlog). El equipo coge tantos objetivos como se vea capaz de cumplir en la iteración, los refina con preguntas al cliente y hace una primera descomposición en las tareas necesarias para completar cada uno de ellos, creando la definición de completado y la lista de tareas de la iteración (sprint backlog). [Es importante que el cliente haya preparado las iteraciones para que tengan una meta clara, que no sean un conjunto de objetivos poco cohesionados que produzcan pocas sinergias].
    • La iteración se desarrolla orientada a objetivos, minimizando el “número de objetivos en curso” (WIP, Work In Progress), para tener alguno completado cuando acabe la iteración y no muchos iniciados o a punto de finalizar.
    • La demostración de los resultados completados que el equipo realiza al cliente al final de la iteración. El feedback recibido del cliente permite ir acercándose a sus expectativas mediante ajustes a realizar en siguientes iteraciones, bien por que el equipo no consiguió entender correctamente sus necesidades, bien por que es el cliente quien ahora entiende mejor el producto, bien por que la velocidad de desarrollo no es la esperada o bien por cambios externos al proyecto que obligan a cambiar objetivos. Estos ajustes se incorporan al product backlog y el cliente lo reprioriza.
Notar que dentro de la propia iteración hay otro ciclo de Deming: la reunión diaria de sincronización del equipo, que le permite inspeccionar lo que está sucediendo y realizar las adaptaciones necesarias para poder conseguir los objetivos de la iteración, añadiendo o quitando tareas del sprint backlog durante la iteración.
Se puede observar que uno de los principales beneficios de Scrum es la flexibilidad frente a cambios en el contexto, el hecho de poder modificar y repriorizar los objetivos del proyecto iteración a iteración, así como las de tareas para poder conseguir un objetivo (se pueden llegar a cambiar todas las tareas si el planteamiento inicial ya no es aplicable).
 
  • Los procesos de trabajo del equipo, mediante:
    • La replanificación de las tareas a ejecutar.
    • La retrospectiva de cómo fue su ejecución, qué cree que hay que mantener, mejorar o probar hacer de manera diferente, con lo que se generar objetivos y tareas de ajuste de los procesos a ejecutar en las siguientes iteraciones.
  • La satisfacción del equipo se consigue mediante:
    • El hecho de poder entregar resultados finales de forma regular, de forma que el cliente los pueda utilizar o entregar a los usuarios/consumidores finales.
    • El mejor entendimiento de las expectativas del cliente, que permitirá dar mejores resultados en las siguientes iteraciones.
    • La mejora continua del proceso de trabajo entre el equipo y con terceros, cosa que le permite ser más productivo, reducir re-trabajo y tareas de poco valor.
calidad-lean-scrum-xp 
 
Agilidad y calidad interna
Es necesario construir el producto con calidad interna para poder tener una velocidad de desarrollo sostenible y crecer de manera iterativa e incremental. Ya desde la segunda iteración se debe construir sobre la parte del producto final ya existente sin poner parches que al final se transformen en “deuda técnica” (Technical Debt). Si la deuda técnica fuese creciendo, al final el coste de ir incrementando la funcionalidad se haría enorme. Para ello, eXtreme Programming utiliza las siguientes prácticas de ingeniería:
  • Estándares de codificación, incluyendo código bien comentado, para facilitar la propiedad colectiva.
  • Pair programming y/o peer review, para conseguir un código más simple, fácil de mantener y revisado por otra persona, con lo que la probabilidad de errores se reduce (arquitectónicos, de diseño o de funcionamiento).
  • Arquitecturas flexibles tanto en interfaz de usuario como en patrones de diseño como en información, de manera que en el futuro se puedan introducir cambios minimizando el impacto sobre el resto del sistema / los objetivos ya completados. Esto no debe implicar preparar la arquitectura o el código para requisitos futuribles (que puede que no lleguen nunca), si no simplemente cubrir cada objetivo conforme se va desarrollando intentando no hacer demasiado en contra de los futuribles.
  • TDD (Test Driven Development) para desde el inicio conseguir un código se puede probar así como su simplicidad. Para ello se escribe primero las pruebas (funcionales, de integración o unitarias) y después se escribe el mínimo código necesario para pasarlas.
  • Refactorización, para simplificar y mejorar el código una vez la prueba ha pasado, con la garantía de que sus pruebas asociadas actuarán como regresión protegiendo de la introducción de errores.
  • Ejecutar pruebas automatizadas en un sistema de integración continua para poder realizar cambios controlados. De esta manera, si algún componente que ya existía deja de funcionar, las pruebas asociadas inmediatamente detectan el fallo tan pronto se integra. Dado que estos errores colaterales no tardan en ser detectados, su corrección es más rápida ya que el desarrollador todavía tiene en mente el código que los produjo.
Es importante contar con métricas para ir evaluando de manera objetiva si cómo se están produciendo las mejoras [8].
 
¿La calidad es negociable?
El cumplimiento de las expectativas del usuario es lo más importante: sin esto el proyecto no puede ser un éxito. Por ello, en metodologías tradicionales, el cliente puede llegar a negociar bajar la calidad funcional e interna con el objeto de cumplir en fechas (ver el concepto del triangulo de hierro). Al cliente no le sirve tener algo perfecto, sino tener lo que necesita a tiempo.
 
Para no tener qué llegar a bajar la calidad, las metodologías ágiles priorizan los objetivos del proyecto en función del valor que aportan al cliente. De esta manera, para llegar en fechas se prescinde de algún objetivo poco relevante, en lugar de bajar la calidad. Esto también permite que el equipo se sienta orgulloso de la calidad de su trabajo.
 
Reducción de riesgos de calidad y retrabajo
  • Se puede utilizar una iteración (para poner un timeboxing a la no producción de resultados), llamada “iteración cero”,donde hacer la lista priorizada de objetivos del proyecto y pruebas de concepto muy ligeras de:
    • La arquitectura del proyecto, con una prueba extremo a extremo de la introducción/recuperación de información a través de distintas capas y tecnologías.
    • La usabilidad y el diseño e interacción del usuario con la aplicación, mediante wireframes o prototipos de baja fidelidad. Este modelo, un diagrama de procesos y otro de entidad/relación (todos a alto nivel) permiten complementar el modelo de historias de usuario (texto escrito e interpretable) y reducir la incertidumbre sobre las expectativas del cliente (“para el usuario, las pantallas son la aplicación”).
  • Estas pruebas de concepto se irán refinando y adaptando iteración a iteración, según se desarrollen los objetivos por orden de prioridad, por ejemplo construyendo maquetas navegables a partir de los wireframes, como acompañamiento al backlog en la planificación de cada iteración.
 
CMMI vs agilidad
  • CMMI define unos niveles de madurez de una empresa que permiten tener un orden mejora/implantación de procesos. Por ejemplo, si no tienes nada (Nivel 1 de madurez), una de las primeras cosas que deberías hacer es un control de versiones (Nivel 2).
  • Algunas de las principales diferencias entre CMMI y Scrum son que CMMI se orienta a procesos y su institucionalización en la empresa, con la idea de que los procesos serán los que permitirán conseguir los objetivos del cliente y mejorar la predictibilidad de los proyectos, mientras que Scrum se orienta directamente a conseguir los objetivos del cliente en un proyecto mediante el trabajo en equipo, el cual puede mejorar sus procesos según sea el contexto del proyecto.
  • Dado que la base de Scrum es la gestión de proyectos y el trabajo en equipo, CMMI y PMBOK se pueden utilizar para complementar Scrum cuando sea necesario en las áreas que Scrum no aborda por que están fuera de su alcance como, por ejemplo, la gestión de riesgos (que en Scrum son más reducidos por hacer iteraciones cortas con feedback tanto del cliente como del equipo y por limitar la complejidad que cabe en una iteración), la institucionalización en la empresa de los procesos ágiles, la gestión de proveedores, etc.
  • Respecto a la certificación de procesos ágiles, es más fácil certificar ISO que CMMI, ya que ISO certifica lo que dices que haces. El proceso de Scrum se puede certificar casi directamente en nivel 3 de CMMI y existen empresas certificadas en nivel 5 que al adoptar Scrum han reducido mucho esfuerzo innecesario. El problema de certificar CMMI es que los certificadores exijan que se implemente y se registre la ejecución de un proceso de una determinada manera, normalmente siguiendo metodologías tradicionales (en cascada o waterfall). Sin embargo, el propio SEI (que como el PMI está empezando a tener en cuenta la agilidad) lo desmiente [5]: lo importante son los objetivos del proceso, no la manera cómo se implementa (que puede ser ágil) [6].
 
El objetivo de Q/A en metodologías ágiles
  • Evitar que se produzcan errores. Utilizando el pensamiento Lean de evitar el desperdicio como el re-trabajo en búsqueda y corrección de errores, es necesario impedir que aparezcan los errores que se deban a malas interpretaciones. Por ello, las personas que se encargan de las pruebas funcionales deben hacen TDD a nivel de requisitos:
    • Para ayudar a que tanto el cliente como el equipo compartan la misma visión, los testers participan en la toma de objetivos/requisitos (creación/modificación [fuera de la iteración] y detalle del backlog [en la planificación de la iteración]), asociando a cada objetivo sus condiciones de satisfacción, normalmente en forma de pruebas de aceptación (por ejemplo en el reverso de las tarjetas de historias de usuario). De esta manera el equipo y el cliente desambiguan el objetivo, le dan el detalle que consideran necesario e impiden la aparición de errores por falta de entendimiento de los objetivos.
    • Notar que la búsqueda de errores después de la programación sigue siendo necesaria (un programador programa e introduce errores al mismo tiempo). Mediante las prácticas de eXtreme Programming enumeradas anteriormente se puede reducir la tasa de errores por línea de código.
    • Los testers deben estar dentro del propio equipo, para conseguir que el equipo tenga la responsabilidad de entregar objetivos completados (probados) y no sea necesario hacer un trabajo adicional sobre ellos. De esta manera cuando el equipo haga una demostración, el cliente podrá tomar decisiones contando con que puede disponer de los resultados que se le han mostrado.
    • Las pruebas de aceptación por parte del cliente o con usuarios beta sigue siendo necesaria, dado que las pruebas realizadas por el propio equipo (unitarias, funcionales, etc.) no lo pueden cubrir todo. La perspectiva del producto del cliente o del usuario final o consumidor puede ser diferente de la del equipo de desarrollo y llevar a cabo acciones no previstas: pueden esperar un comportamiento del sistema que daban por sobreentendido pero no fue explicitado en su momento, o bien no cayeron en su necesidad cuando se planteó el objetivo y al probar el producto se dan cuenta de algo adicional que es necesario.
    • En ciertos proyectos pueden ser necesarias iteraciones específicas cada vez que se haga una entrega de producto (por ejemplo de la mitad de duración de una iteración de desarrollo) para incluir las últimas modificaciones/errores detectados por el feedback del cliente en la última demostración.
    • Si el proyecto es muy grande y participan varios equipos, puede ser necesario un equipo de integración que recoja el trabajo de todos los equipos y se encargue de que todo funcione correctamente. Para mejorar la comunicación, las personas de este equipo pueden llegar a trabajar la mitad de su tiempo en cada equipo de desarrollo y el resto en el propio equipo de integración, de manera que se asegure que en cada iteración todo el producto funciona.
  • Colaborar en la mejora de los procesos de trabajo, buscar maneras de reducir esfuerzos innecesarios.
 
Video del encuentro

 

 
encuentro-calidad-agilidad
 
El encuentro fue transmitido en directo. La grabación se realizó en dos partes y está disponible en:
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, la transmisión en directo del encuentro, los snacks y las bebidas.
 
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
 
Para saber más