Este documento trata sobre la calidad de producto en el desarrollo ágil. Explica conceptos como calidad, principios y prácticas ágiles que mejoran la calidad, tales como equipos multidisciplinarios, desarrollo iterativo e incremental, foco en la mejora continua, automatización, software con documentación viva y entrega continua. El objetivo general es promover que todo el equipo se enfoque en la calidad del producto.

1. Calidad de Producto
en Agile
“La Calidad es responsabilidad
de todos.”
W. Edwards Deming

2. Algunas ideas que desarrollaremos...
Qué es Calidad?
Principios y prácticas que mejoran la
Calidad del Producto

3. Algunas ideas que desarrollaremos......
Documentación viva Dinamica de desarrollo
Organización de equipo ágiles
Automatización
Delivery contínuo
Calidad Integrada
ágil
Mejora contínua

4. Qué es Calidad?

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

6. Lexus GS350

7. Lexus GS350

8. Algunos datos sobre Lexus

9. Qué pasaba
si queríamos comprar un auto
en 1910?

10. Ford T

11. Algunos datos sobre el Ford T

12. Principios y prácticas
que mejoran
la Calidad del Producto

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

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

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

16. Manifiesto Ágil
http://agilemanifesto.org/iso/es/

17. Principios del Manifiesto Agil
http://agilemanifesto.org/iso/es/principles.html

18. 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 Handbook
Ken Schwaber & Jeff.Sutherland, The Scrum
Guide

19. 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
Installed
James Shore, The art of Agile Development

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

21. Equipos Multidisciplinarios

22. Contexto
Scrum prescribe:
El Product Owner
Equipo: Programadores y Testers.
El Scrum Master
Scrum Primer, 2nd Edition

23. ACTIVIDADES RELACIONADAS
El Desarrollo Ágil busca prevenir errores en
etapas tempranas del ciclo de desarrollo.
Lisa Crispin, Janet Gregory: Agile Testing – Traditional vs Agile Testing

24. Los programadores construyen artefactos que
son “error proof”.
Ken Beck, TDD by Example
ACTIVIDADES RELACIONADAS

25. 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

26. 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.

27. MATRIZ DE TESTING AGILE

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. Desarrollo iterativo e incremental
Flujo contínuo

36. Desarrollo iterativo e incremental/Flujo contínuo
 Agile prescribe iteraciones time-boxed.
Henrik Kniberg – Kanban and Scrum

37. Desarrollo iterativo e incremental/Flujo contínuo
 Estas etapas acotadas promueven el feedback
sobre la marcha del desarrollo.
Henrik Kniberg – Kanban and Scrum

38. 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

39. 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

40. Desarrollo iterativo e incremental/Flujo contínuo
 En este sentido Kanban provee un mecanismo
para:
- Visualizar el workflow.
Henrik Kniberg – Kanban and Scrum

41. 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

42. Desarrollo iterativo e incremental/Flujo contínuo
 En este sentido Kanban provee un mecanismo
para:
- Identificar impedimentos.
Henrik Kniberg – Kanban and Scrum

43. 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

44. Foco en la mejora continua
durante el ciclo de desarrollo

45. 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

46. Mejora contínua
 Los equipos ágiles realizan reuniones de
Retrospectivas.
Esther Derby, Diana Larsen – Agile Restrospectives

47. 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”

48. Mejora contínua
 Los equipo ágiles buscan minimizar la deuda
técnica.

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

50. 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.

51. Mejora contínua
 Aplicar JIT a nuestro proceso de Desarrollo.
Craig Larman and Bas Vodde – Lean Primer

52. 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 Primer
http://www.ifm.eng.cam.ac.uk/research/dstools/jit-just-in-time-manufacturing/

53. 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 Primer
http://www.ifm.eng.cam.ac.uk/research/dstools/jit-just-in-time-manufacturing/

54. 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.

55. Automatización
 Es indispensable, para la mejora contínua, poder
liberarnos de las tareas que consumen más
tiempo.
VS

56. Software construído con
“documentación viva”

57. 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

58. Software construído con “documentación viva”
 Colectivamente consensuada.
Gojko Adzic – Specification by Example cap. 6 “Specifying Collaborativelly”

59. Software construído con “documentación viva”
 Desarrollada con Tests de Aceptación.
Lasse Koskela – TDD and ATDD for Java. Developers

60. Software construído con “documentación viva”
 Características de los Tests de Aceptación.

61. Software construído con “documentación viva”
 Se ilustran mediante ejemplos.
Gojko Adzic – Specification by Example cap. 7 “Illustrating with Examples”

62. 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”

63. 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

64. Software construído con “documentación viva”
 Su verificación es automatizada.
Gojko Adzic – Specification by Example cap. 9 “Automating validation without changing
specifications”

66. Automatización

67. 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.”

68. Automatización
 “La simplicidad, o el arte de maximizar la
cantidad de trabajo no realizado, es esencial.”

69. 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.

70. Automatización Lean/Agile
 Existen artefactos de Software modulares.
Cuentan con responsabilidades concretas.
Poppendieck – Implementing Lean From Concept to Cash

71. 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

72. Automatización Lean/Agile
 Ejemplos:
- Framework de Tests Unitarios.
Poppendieck – Implementing Lean From Concept to Cash

73. 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

74. Automatización Lean/Agile
 Ejemplos:
- Framework de Tests No Funcionales.
 Seguridad
 Performance
- Etc.
http://www.sonarqube.org/

75. Automatización Lean/Agile
 Los distintos niveles de automatización nos
permiten construir productos con Calidad
Integrada.
Jeffrey K. Liker – The Toyota Way

76. 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

77. 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

78. 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.

79. 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.

80. Automatización Lean/Agile
 Los artefactos de Automatización son
mantenidos por todos los integrantes del equipo:

81. ¡Actividad!

82. Delivery contínuo

83. 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

84. Diagrama de procesos
http://en.wikipedia.org/wiki/Continuous_delivery

85. 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”

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

87. 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”.

88. Pirámide de Automatización
http://martinfowler.com/bliki/TestPyramid.html

89. Aut. Acceptance Stage
Commit Stage
Manual Acceptance
Stage
Capacity Stage

90. 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.

91. 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.

92. Conclusiones:
¿Qué fue lo más importante que
aprendiste hoy?

93. Gracias!
Marcelo Corpucci
QC Practice Lead - CTO
consultas:
m.corpucci@globallogic.com