Calidad en Agile - EducacionIT

Post on 24-Jun-2015

235 views 1 download

description

Calidad en Agile - EducacionIT

Transcript of Calidad en Agile - EducacionIT

Calidad de Productoen Agile

W. Edwards Deming

“La Calidad es responsabilidad de todos.”

Algunas ideas que desarrollaremos...

Qué es Calidad?

Principios y prácticas que mejoran la

Calidad del Producto

Algunas ideas que desarrollaremos......

Org

aniz

ació

n de

equ

ipo

ágile

s

Automatización

Delivery contínuo

Calidad Integrada

Documentación vivaDinamica de desarrollo

ágil

Mejora contínua

Qué es Calidad?

Si vamos a comprar un auto, qué pretendemos que tenga?

Lexus GS350

Lexus GS350

Algunos datos sobre Lexus

Qué pasaba si queríamos comprar un auto

en 1910?

Ford T

Algunos datos sobre el Ford T

Principios y prácticas que mejoran

la Calidad del Producto

Qué pasa cuando el Cliente presiona cada vez más por productos de calidad

superlativa?

http://en.wikipedia.org/wiki/Kano_model

Cómo podemos extrapolar esta cuestión al campo de la Ingeniería de Software?

Manifiesto Ágil

http://agilemanifesto.org/iso/es/

Principios del Manifiesto Agil

http://agilemanifesto.org/iso/es/principles.html

Prácticas que mejoran la calidad del producto Implementamos diversas prácticas

organizacionales que siguen los principios antedichos:

Equipos multidisciplinarios. Desarrollo iterativo e incremental/Flujo

contínuo. Foco en la mejora contínua durante el ciclo de

desarrollo.

Jeff Sutherland’s Scrum HandbookKen Schwaber & Jeff.Sutherland, The Scrum

Guide

Prácticas que mejoran la calidad del producto Adicionalmente, aplicamos prácticas de índole

técnica: Automatización y Delivery contínuo de cada

incremento del producto. Software construído con documentación viva.

Software con Calidad integrada.

Gojko Adzic, Bridging the Communication Gap Jez Humble, David Farley - Continuous Delivery

Ron Jeffries, Extreme Programming InstalledJames Shore, The art of Agile Development

Estos principios y prácticas promueven que el foco de todo el equipo esté en la Calidad

del Producto.

Equipos Multidisciplinarios

Scrum prescribe:

El Product Owner

Equipo: Programadores y Testers.

El Scrum Master

Scrum Primer, 2nd Edition

Contexto

El Desarrollo Ágil busca prevenir errores en etapas tempranas del ciclo de desarrollo.

Lisa Crispin, Janet Gregory: Agile Testing – Traditional vs Agile Testing

ACTIVIDADES RELACIONADAS

Los programadores construyen artefactos que son “error proof”.

Ken Beck, TDD by Example

ACTIVIDADES RELACIONADAS

Los testers colaboran activamente con el cliente en la definición de las condiciones de satisfacción de cada nueva funcionalidad.

Lisa Crispin, Janet Gregory: Agile Testing - Ten Principles for Agile Testers

ACTIVIDADES RELACIONADAS

Aseguramos la Calidad colaborando colectivamente en la implementación de tests que:

Guían el desarrollo de artefactos de Software.

Están orientados al Negocio.

Critican el Producto.

ACTIVIDADES RELACIONADAS

MATRIZ DE TESTING AGILE

Atributos de un equipo ágil

➤ Libertad para el cambio: Debemos ser flexibles en lo metodológico y en

lo técnico para permitir cambios de modo sustentable.

Agile in a Flash – Agile success factors

Atributos de un equipo ágil

➤ Equipos motivados: Debemos ser un equipo ansioso por entregar

un producto de Calidad del cual sentirnos orgullosos.

Agile in a Flash – Agile success factors

Atributos de un equipo ágil

➤ Comunicación con el Cliente: Dedemos fomentar el diálogo hacia un

entusiasmado, exclusivo y dedicado Cliente que pueda comunicarnos la visión del Producto

de manera efectiva.

Agile in a Flash – Agile success factors

Atributos de un equipo ágil

➤ Colaboración: Debemos colaborar activamente con el Cliente.

Asistir pasivamente a una reunión no es un buen ejemplo.

Agile in a Flash – Agile success factors

Atributos de un equipo ágil

➤ Foco en la Calidad: Sin esto no podremos mantener un ritmo sustentable de Delivery del Producto. Pronto no podremos cumplir con las demandas del

Cliente.

Agile in a Flash – Agile success factors

Atributos de un equipo ágil

➤ Incrementalismo: I.N.V.E.S.T en User Stories y S.M.A.R.T

Tasks. Retrospectiva.

Agile in a Flash – Agile success factors

Atributos de un equipo ágil

➤ Automatización: En un ciclo de Desarrollo reducido, es

necesario aminorar tantas tareas repetitivas como se pueda.

Agile in a Flash – Agile success factors

Desarrollo iterativo e incrementalFlujo contínuo

Desarrollo iterativo e incremental/Flujo contínuo

Agile prescribe iteraciones time-boxed.

Henrik Kniberg – Kanban and Scrum

Desarrollo iterativo e incremental/Flujo contínuo

Estas etapas acotadas promueven el feedback sobre la marcha del desarrollo.

Henrik Kniberg – Kanban and Scrum

Desarrollo iterativo e incremental/Flujo contínuo

Estas etapas acotadas promueven el flujo contínuo (velocidad y predictibilidad) de

artefactos de software.

Jeffrey Liker – The Toyota Way cap. 8

Desarrollo iterativo e incremental/Flujo contínuo

Radiadores de información típicos en Scrum pueden ser un taskboard o un burn-up/down

chart.

Jonathan Rasmusson - The Agile Samurai cap. 8

Desarrollo iterativo e incremental/Flujo contínuo

En este sentido Kanban provee un mecanismo para:

Visualizar el workflow.

Henrik Kniberg – Kanban and Scrum

Desarrollo iterativo e incremental/Flujo contínuo

En este sentido Kanban provee un mecanismo para:

Limitar los procesos abiertos (WIP).

Henrik Kniberg – Kanban and Scrum

Desarrollo iterativo e incremental/Flujo contínuo

En este sentido Kanban provee un mecanismo para:

Identificar impedimentos.

Henrik Kniberg – Kanban and Scrum

Desarrollo iterativo e incremental/Flujo contínuo

En este sentido Kanban provee un mecanismo para:

Medir la cadencia o Lead Time de la implementación del producto.

Henrik Kniberg – Kanban and Scrum

Foco en la mejora continua durante el ciclo de desarrollo

Mejora contínua

“A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación

ajustar y perfeccionar su comportamiento en consecuencia.”

http://agilemanifesto.org/iso/es/principles.html

Mejora contínua

Los equipos ágiles realizan reuniones de Retrospectivas.

Esther Derby, Diana Larsen – Agile Restrospectives

Mejora contínua Los equipos ágiles atacan la causa raíz de los

problemas aplicando la técnica de 5 Whys.

Poppendieck – Lean Software Development An Agile Toolkit, cap 7 “See the Whole”

Mejora contínua

Los equipo ágiles buscan minimizar la deuda técnica.

Mejora contínua Hay relación directa entre la Calidad del producto, la productividad y la deuda técnica

acumulada.

Mejora contínua Para controlar la deuda técnica podemos:

Implementar Tests de Unidad y de Sistema.

Automatizar procesos. Tener etapas de refactoring

regularmente. Evidenciar acciones y

resultados al Cliente.

Mejora contínua

Aplicar JIT a nuestro proceso de Desarrollo.

Craig Larman and Bas Vodde – Lean Primer

Mejora contínua

Just In Time es una filosofía de management que promueve las siguientes prácticas:

Promover un sistema de pull a través del proceso de desarrollo.

Atender sólo los problemas fundamentales. Excluir cualquier cuestión que no agregue

valor al producto. Promover la simplicidad de procesos.

Craig Larman and Bas Vodde – Lean Primerhttp://www.ifm.eng.cam.ac.uk/research/dstools/jit-just-in-time-manufacturing/

Mejora contínua

Just In Time es una filosofía de management que promueve las siguientes prácticas:

Propiciar la proximidad de todos los elementos, e involucrados, en el proceso de creación del

producto. Reducir el nivel de inventario:

La menor cantidad de artefactos posibles. Procesar en pequeños lotes.

Crear conciencia en la Calidad con la cultura 'Stop the Line'.

Craig Larman and Bas Vodde – Lean Primerhttp://www.ifm.eng.cam.ac.uk/research/dstools/jit-just-in-time-manufacturing/

Automatización

Es muy difícil pensar en practicar Agile con madurez sin automatizar ningún proceso crítico:

Testing en sus distintas dimensiones. Precarga de Datos y Deployment.

Automatización

Es indispensable, para la mejora contínua, poder liberarnos de las tareas que consumen más

tiempo.

VS

Software construído con “documentación viva”

Software construído con “documentación viva”

Es una fuente de información, colectivamente consensuada, acerca de la funcionalidad del Sistema; resultado de desarrollar mediante

Tests de Aceptación.

http://specificationbyexample.com/key_ideas.html

Software construído con “documentación viva”

Colectivamente consensuada.

Gojko Adzic – Specification by Example cap. 6 “Specifying Collaborativelly”

Software construído con “documentación viva”

Desarrollada con Tests de Aceptación.

Lasse Koskela – TDD and ATDD for Java. Developers

Software construído con “documentación viva”

Características de los Tests de Aceptación.

Software construído con “documentación viva”

Se ilustran mediante ejemplos.

Gojko Adzic – Specification by Example cap. 7 “Illustrating with Examples”

Software construído con “documentación viva”

Se emplea un lenguaje oblícuo.

Eric Evans – Domain Driven Design cap. 2 “Communication and the Use of Language”

Software construído con “documentación viva”

El lenguaje oblícuo se compone de abstracciones naturales del dominio del

negocio.

http://www.solutionsiq.com/Portals/93486/docs/Domain-Specific-Testing-Languages-Huso-Phoenix-Agile-2008.ppt

Software construído con “documentación viva”

Su verificación es automatizada.

Gojko Adzic – Specification by Example cap. 9 “Automating validation without changing specifications”

Automatización

Automatización

“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y

usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.”

Automatización

“La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.”

Automatización

Automatizar procesos nos provee de: Un método de prevención de Bugs.

Una red de contención que incrementa la seguridad del equipo y la calidad del producto. Un mecanismo de feedback muy eficiente.

Automatización Lean/Agile

Existen artefactos de Software modulares. Cuentan con responsabilidades concretas.

Poppendieck – Implementing Lean From Concept to Cash

Automatización Lean/Agile

Ejemplos: Servidor de Integración Contínua.

http://jenkins-ci.org/https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin

Automatización Lean/Agile

Ejemplos: Framework de Tests Unitarios.

Poppendieck – Implementing Lean From Concept to Cash

Automatización Lean/Agile

Ejemplos: Framework de Tests Funcionales.

Runner de Especificaciones ejecutables. Framework de interacción con el Front-End,

API, etc.

http://cukes.info/install-cucumber-jvm.html

http://www.masterthought.net/section/cucumber-reporting

Automatización Lean/Agile

Ejemplos: Framework de Tests No Funcionales.

Seguridad Performance

Etc.

http://www.sonarqube.org/

Automatización Lean/Agile

Los distintos niveles de automatización nos permiten construir productos con Calidad

Integrada.

Jeffrey K. Liker – The Toyota Way

Automatización Lean/Agile

Ejemplos: Las piezas de Software que son construidas

con Test-First (usando TDD o ATDD) son Error-Proof.

Ken Beck, TDD by Example

Automatización Lean/Agile

Para que la automatización sea eficiente es necesario que respete la cultura de trabajo Stop

The Line.

Jeffrey K. Liker – The Toyota Way

Automatización Lean/Agile

Artefactos como los Tests Unitarios se detienen automáticamente al encontrar una falla.

Si están conectados a un CI Server interrumpen,

a la vez, un deploy a otro ambiente.

Automatización Lean/Agile

Artefactos como los Tests de Aceptación ejecutan la suite entera y, de existir, informan

fallas al final. Cuentan con mecanismos de reversión de estado, dejando la SUT en un estadío previo a

la ejecución.

Automatización Lean/Agile

Los artefactos de Automatización son mantenidos por todos los integrantes del equipo:

¡Actividad!

Delivery contínuo

Delivery Contínuo

“Es una disciplina de desarrollo de Software que permite la construcción del mismo de forma tal de

poder desplegarlo a producción en cualquier momento.”

http://martinfowler.com/bliki/ContinuousDelivery.html

Diagrama de procesos

http://en.wikipedia.org/wiki/Continuous_delivery

Development Pipeline

Es un patrón de Implementación automatizada de un proceso de build, test y release de

aplicaciones.

Continuous Delivery – cap. 5 “Anatomy of the Deployment Pipeline”

Continuous Delivery – cap. 5 “Anatomy of the Deployment Pipeline”

Automatización del testing

En la Commit Stage encontramos: Tests Unitarios.

Tests de Integración. En la Acceptance Stage encontramos:

Test Funcionales. Test de Aceptación.

Smoke Tests. En la UAT Stage y Equivalentes encontramos:

Test Manuales.

Continuous Delivery – cap. 4 “Implementing a Testing Strategy”.

Pirámide de Automatización

http://martinfowler.com/bliki/TestPyramid.html

Commit Stage

Aut. Acceptance Stage M

anual Acceptance

Stage

Capacity Stage

Beneficios

Cada instancia provee distintos tipos de Feedback:

A nivel de unidad/integración una falla detiene la ejecución de la suite, completamente.

A nivel de aceptación una falla no detiene la ejecución de la suite.

Nos da un pantallazo del criterio de done.

Beneficios

Los Tests Funcionales automatizados, en particular los Tests de Aceptación, tienen los

atributos de: Liberan a los Testers para que exploten su creatividad en la búsqueda de escenarios de

borde y errores no detectados.

Conclusiones:¿Qué fue lo más importante que

aprendiste hoy?

Gracias!Marcelo Corpucci

QC Practice Lead - CTOconsultas:

m.corpucci@globallogic.com