Date post: | 24-Jun-2015 |
Category: |
Technology |
Upload: | globallogic-latinoamerica |
View: | 235 times |
Download: | 1 times |
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?
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: