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

Transcripción

1 Calidad en Agile

2 Temario Qué es Calidad? Principios y prácticas para incrementar la calidad del producto. Construcción de artefactos con 'Calidad Integrada'. Procesos, Cultura y problemática de Agile. Dicotomía entre los roles tradicionales y los roles en Agile. Automatización Tradicional vs Lean/Agile.

3 Qué es Calidad?

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

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

6 Qué pasaba si queríamos comprar un auto en 1910? Ford T

7 Definición Existen muchas definiciones de Calidad. Por ejemplo: El grado con el cual las características inherentes de un producto cumplen con los requerimientos del cliente. Adaptación de la definición de Calidad de ISO.

8 Definición Para nosotros, Calidad es: Cumplir con las espectativas del cliente: Brindándole un producto de Valor, de forma transparente y colaborativa. Teniendo la prioridad de entregar un PSI al final de cada iteración. Demostrando confiabilidad, a través de métricas objetivas y subjetivas. Siendo flexibles ante los cambios, sin resignar ninguno de los ítems anteriores.

9 Cómo lograr estos objetivos?

10 Principios y prácticas para incrementar la calidad del producto Seguimos el Manifiesto de Desarrollo Ágil: Individuos e interacciones sobre procesos y herramientas. Software funcionando sobre documentación extensiva. Colaboración con el cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un plan.

11 Principios y prácticas para incrementar la calidad del producto Tomamos una definición de Valor, desde la visión del cliente: Resolver mi problema por completo. "Proveerme exactamente lo que necesito." "Del modo en que lo necesito." "Cuando lo necesito. Implementing Lean Software Development: From Concept to Cash Capítulo 3: Value

12 Principios y prácticas para incrementar la calidad del producto Implementamos diversas prácticas que siguen los principios antedichos: Equipos multifuncionales. Etapas acotadas de desarrollo. Participación activa del cliente durante todo el ciclo de desarrollo. Scrum Handbook The Scrum Guide

13 Principios y prácticas para incrementar la calidad del producto Adicionalmente, aplicamos prácticas de índole técnica: Desarrollo guiado por pruebas. Refactoring. Integración contínua de los artefactos. Automatización. Extreme Programming Installed The art of Agile Development

14 Construcción de artefactos con 'Calidad Integrada'

15 Decimos que una pieza de software contiene 'Calidad Integrada' cuando: La definición de sus requerimientos es 'on demand'. La definición de sus requerimientos es realizada colaborativamente. Dicha definición es especificada con ejemplos. Dicha definición es implementada con procesos automatizados. Bridging the communication gap

16 Decimos que una pieza de software NO contiene 'Calidad Integrada' cuando: La definición de sus requerimientos ocurre en una etapa específica. La definición de sus requerimientos es realizada por especialistas del negocio. Dicha definición es especificada en lenguaje abstracto. Dicha definición es implementada con documentación estática. Bridging the communication gap

17 Características de una pieza de software con 'Calidad Integrada' en Agile En Agile la construcción del software es iterativa e incremental.

18 Características de una pieza de software con 'Calidad Integrada' en Agile Decimos que el output de la iteración, la pieza de software construída, es un PSI. PSI son la iniciales de Potentially Shippable Increment.

19 Características de una pieza de software con 'Calidad Integrada' en Agile Un PSI reune las condiciones de ser: Diseñado. Construído. Testeado. Aceptado. En condiciones de ser desplegado a Producción.

20 Requisitos del equipo para integrar Calidad en un PSI La madurez de un equipo ágil puede medirse, entre otras cosas, por su capacidad para construir eficientemente un PSI.

21 Requisitos del equipo para integrar Calidad en un PSI Esto requiere: Colaboración activa del equipo en todas las tareas. No especializaciones, sino skills. 'Three amigos'.

22 Requisitos del equipo para integrar Calidad en un PSI Esto requiere: Cultura 'zero defects'. Prácticas test-first.

23 Requisitos del equipo para integrar Calidad en un PSI Esto requiere: Automatización de procesos. De los tests. Del despliegue. Cultura 'Stop the line'.

24 Desafíos en la integración de Calidad en un PSI Los equipos ágiles pueden encontrarse con: Diversidad de lenguajes propios de un equipo multidisciplinario. Documentos funcionales abstractos. Reducción del tiempo de ejecución del ciclo de pruebas.

25 Desafíos y propuestas Podemos proponer: La construcción de un Lenguaje Oblicuo. La definición de especificaciones con ejemplos. La implementación de las especificaciones para transformarlas en ejecutables.

26 Concepto de ATDD Iniciales de Acceptance Test Driven Development.

27 Concepto de ATDD Es un conjunto de principios y prácticas que nos permiten construir Software que posee: 'Calidad integrada': Empleando Tests/Ejemplos que guian el desarrollo de las funcionalidades.

28 Concepto de ATDD Es un conjunto de principios y prácticas que nos permiten construir Software que posee: 'Documentación Viva': Atributo de las especificaciones ejecutables.

29

30 Concepto de ATDD Es un conjunto de principios y prácticas que nos permiten construir Software que posee: Ciclos de feedback más cortos y efectivos: Empleando procesos de ejecución automatizados.

31 Ventajas de ATDD La integración del Cliente al proceso de desarrollo. Durante la planning/fase de Verificación. Durante la iteración/fase de Validación.

32 Ventajas de ATDD El mecanismo de especificar mediante ejemplos reduce drásticamente: Las cuestiones poco claras durante la construcción. Los malos entendidos con el Cliente en la fase de UAT.

33 Ventajas de ATDD El atributo de 'Calidad integrada' nos permite reducir drásticamente la cantidad de defectos. Los tests automatizados funcionan como una 'red de contención': Incrementan la confianza del equipo y la calidad del código. Permiten refactors más seguros.

34 Ventajas de ATDD La construcción de artefactos de Software guiada por Tests de Aceptación permite construir únicamente las funcionalidades requeridas: Deriva del desarrollo Just-in-Time.

35 Ventajas de ATDD La construcción de artefactos de Software guiada por Tests de Aceptación minimiza diseños complejos: En combinación con Kanban, facilita la eliminación de los 7 tipos de desperdicios: Trabajo parcialmente concluído. Funcionalidades extra. 'Reinventar la rueda' (Relearning) 'Conocimiento Tácito' (Handoff) Switcheo de tareas. Demoras. Defectos.

36 Ventajas de ATDD La construcción de artefactos de Software guiada por Tests de Aceptación minimiza diseños complejos: Ayuda a prevenir el 'sobrediseño' (overdesign).

37 Ventajas de ATDD La construcción de artefactos de Software guiada por Tests de Aceptación minimiza diseños complejos: Ayuda a prevenir el antipatrón Analisys Paralisys.

38 Cambios positivos en ATDD En el Analista de Negocios: Los desarrolladores leen las especificaciones, sin saltarse ninguna parte. Los desarrolladores entienden las especificaciones correctamente. Se pueden identificar contradicciones entre las reglas de negocio con más facilidad.

39 Desafíos en ATDD En el Analista de Negocios: Rechazo a canalizar requerimientos de negocio a través de ejemplos. Yo no escribos Tests. Entender a las especificaciones ejecutables como un retrabajo. No tengo suficiente tiempo.

40 Cambios positivos en ATDD En el Analista de QA: Colaboran con los programadores a evitar errores frecuentes. Los escenarios son una red de contención. Se puede delegar la plomería de la automatización a los programadores. Se puede construir artefactos con Calidad integrada desde el 1er momento. Se gana más tiempo para tareas donde la creatividad del tester es muy valiosa.

41 Desafíos en ATDD En el Analista de QA: Rechazo a perder el control sobre el testing. Perder el status de Guardián de la Calidad. Rechazo a perder la posición en el equipo. Los tests de aceptación no encuentran todos los errores.

42 Cambios positivos en ATDD En el Programador: Cualquier brecha en materia funcional es cubierta antes de comenzar a programar. El código se vuelve más fácil de mantener y compartir.

43 Desafíos en ATDD En el Programador: Rechazo a mantener la implementación de las specs. Desconfianza de estos tests como mecanismo de feedback. Los tests unitarios nos dan feedback más rápido.

44 Procesos, Cultura y Problemática de Agile

45 Procesos, Cultura y Problemática de Agile Agile es un conjunto de metodologías. Una metodología es un marco de procesos o Framework. Pero es peligroso cuando se transforma en un Producto. Sin embargo, el verdadero valor de Agile está en emplearlo como un canalizador de Cambio Cultural. Agile survival guide, part 1.

46 Procesos, Cultura y Problemática de Agile En cualquier tipo de Compañía distinguimos cuatro tipos de culturas. Agile survival guide, part 2.

47

48 Procesos, Cultura y Problemática de Agile No hay cultura 'mejor' que otra. En una Compañía suele haber una cultura dominante con elementos del resto. La cultura en Agile es acerca de Cultivación y Colaboración.

49

50 Factores de éxito en la Cultura de Agile Freedom to change: Debemos ser flexibles en lo metodológico y en lo técnico para permitir cambios de modo sustentable. Energized team: Debemos ser un equipo ansioso por entregar un producto de Calidad del cual sentirnos orgullosos. Communication with customer: 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 - Pag.14

51 Factores de éxito en la Cultura de Agile Collaboration: Debemos colaborar activamente con el Cliente. Asistir pasivamente a una reunión no es un buen ejemplo. Attention to quality: Sin esto no podremos mantener un ritmo sustentable de Delivery del Producto. Pronto no podremos cumplir con las demandas del Cliente. Incrementalism: I.N.V.E.S.T en User Stories y S.M.A.R.T Tasks. Retrospectiva. Automation: En un ciclo de Desarrollo reducido, es necesario aminorar tantas tareas repetitivas como se pueda.

52 Problemáticas

53 Adopción de Agile El Cliente suele buscar en el Control la Cultura dominante. Como profesionales debemos proponer diversas prácticas dentro del contexto en el que estemos.

54 Adopción de Agile

55 Niveles de complejidad en los proyectos

56 Niveles de complejidad en los proyectos Como Trabajadores del Conocimiento debemos encontrar el equilibrio entre la complejidad y el caos. Las Metodologías Ágiles nos ayudan a encausar nuestra creatividad.

57 No Silver Bullet Los proyectos caóticos suelen presionarnos a buscar 'balas de plata' que solucionen nuestros problemas. En la actualidad las Metodologías Ágiles puede ser tomadas como una bala de plata. Pero Agile no sólo no es una bala de plata, sino que no hace nada por sí misma.

58 Triángulo de Acero Surge con las llamadas metodologías 'Predictivas'.

59 Triángulo de Acero En esta clase de proyectos los requerimientos son fijos, mientras el costo y el calendario corresponden a un plan.

60 Triángulo de Acero Las metodologías Ágiles proponen invertir el Triangulo de Acero.

61 Triángulo de Acero La Calidad deja de ser una variable de ajuste para pasar a ser el Basamento del Producto.

62 Dicotomía entre roles tradicionales y roles en el contexto de Agile

63 Roles tradicionales

64 Contexto Los roles tradicionales existen en el ámbito de un proyecto tradicional.

65 Contexto En un proyecto tradicional encontramos los siguientes elementos: Procesos Predictivos (en algunos casos iterativos). Instancias de desarrollo desacopladas. Silos de especialización.

66 Contexto Los roles tradicionales heredan varias características de los proyectos tradicionales: Los artefactos que cada uno genera están desacoplados de las instancias previas y posteriores de desarrollo. Se considera que la Calidad es cuestión de ciertos especialistas exclusivamente.

67 Roles en Agile

68 Contexto En Agile existen los equipos multidisciplinarios, donde todos hacen un poco de todo.

69 Contexto Scrum prescribe: El Cliente El Product Owner El Scrum Master Desarrolladores: Programadores y Testers.

70 Contexto La Calidad es un asunto preponderante en todos los roles.

71 Contexto El Desarrollo Ágil busca prevenir errores en etapas tempranas del ciclo de desarrollo. Los programadores construyen artefactos que son error proof. Los testers colaboran activamente con el cliente en la definición de las condiciones de satisfacción de cada nueva funcionalidad.

72 Contexto 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.

73 Matriz de Testing Ágile Agile Testing Part III Agile Testing Quadrants.

74 Desarrollo Tradicional El tratamiento de bugs ocurre en lotes de trabajo. Se basa en el uso intensivo de documentación 'estricta'. Especialistas diseñan los tests. Una pieza de software está 'terminada' cuando se finalizó de codear. Desarrollo Ágil Se busca no acumular bugs. Se prioriza el tiempo de pruebas por sobre el tiempo de documentación. Todos los integrantes del equipo colaboran. Una pieza de software está 'terminada' cuando está terminada de probar.

75 Técnicas para encontrar la causa raíz de los problemas y alternativas para reducirlos.

76 Técnicas Propuestas Utilizar los elementos que nos provee Agile: Retrospectivas. 5 Whys.

77 Alternativas para reducir los defectos Minimizar la Deuda Técnica. Blanquear los Bugs en el Product Backlog. Aplicar JIT a nuestro proceso de Desarrollo. Implementar Testing Automatizado.

78 Elementos de Agile Las Retrospectivas son una buena oportunidad para plantear problemas y proponer acciones de mejora. Un método para llegar a la causa raíz de un problema es aplicar 5 Whys.

79 Bugs y Deuda Técnica Frecuentemente los bugs estan relacionados a la Deuda Técnica acumulada en el código. Generamos Deuda Técnica cuando ante un defecto, generamos un fix en lugar de un refactor. Cuando no aplicamos correctamente principios de desarrollo como SRP y OCP. Cuando no tenemos Test Automatizados que actúen como una red de contención ante los frecuentes cambios de alcance.

80 Bugs y Deuda Técnica La Deuda Técnica es un disparador de Bugs: La introducción de una nueva feature puede dañar las features existentes de manera imprevista. El resultado del Testing se ralentiza. Más y más esfuerzo es necesario en el relevamiento de Bugs.

81 Bugs y Deuda Técnica Es necesario tener bajo control la Deuda Técnica. Y tomar todos los recaudos posibles. Implementar Tests de Unidad y de Sistema. Tener etapas de refactoring regularmente. Evidenciar acciones y resultados al Cliente.

82 Lidiar con los Bugs Algunos equipos emplean un DTS (Defect Tracking System). Los Bugs son trackeados, priorizados, y cerrados por los Testers en un sistema dedicado especialmente a tal fin. Cada iteración los Testers actualizan un listado de Bugs pendientes de resolver. El Cliente suele participar en la administración del listado definiendo prioridades.

83 Lidiar con los Bugs Algunos equipos ven a las pilas de rework como un desperdicio. Practican 'Zero Bug Tolerance' Cuando un Bug es detectado se intenta solucionar de inmediato. Programadores y Testers colaboran activamente en la solución. El objetivo es cerrar la iteración sin Bugs abiertos. Una alternativa para equipos que no alcanzaron este nivel de madurez es setear un 'nivel de tolerancia'.

84 Blanquear los Bugs en el Product Backlog Es útil que, como Equipo, pensemos en los Bugs como: Features inconclusas: Tener un criterio de done que no permita dar por finalizada una tarea si existen defectos. Nuevos escenarios de una Feature: No todo Bug es un error. Puede suceder que se trate de un escenario no contemplado en la definición de la Feature.

85 Blanquear los Bugs en el Product Backlog En concecuencia, es importante que tratemos a los Bugs como Features en nuestro Backlog. Tener un solo Backlog que incluya todo. Bugs y Features tratados por igual. El Equipo debe de asegurarse de procesar un Bug del mismo modo que una Feature: De no existir definir condiciones de satisfacción, escenarios, tests automatizados, etc.

86 Blanquear los Bugs en el Product Backlog Esta acción implica transparencia hacia el Cliente y disciplina. Somos transparentes y no 'manipulamos' datos. Tenemos disciplina en el tratamiento de los defectos. Aprendemos de ellos y generamos mecanimos para impedir que no vuelvan a suceder: Refactors, automatización de los escenarios, etc.

87 Aplicar JIT a nuestro proceso de Desarrollo Por naturaleza tendemos a la complejización de todas las tareas. También tenemos la tendencia natural a agregar mecanismos 'por las dudas'.

88 Aplicar JIT a nuestro proceso de Desarrollo Just In Time es una familia de procesos que promueve las siguientes prácticas: Implementar un Pull System: Un Sistema que genera un flujo donde cada instancia es solicitada por otra. Visualizar el Workflow mediante Kanban.

89 Aplicar JIT a nuestro proceso de Desarrollo Just In Time es una familia de procesos que promueve las siguientes prácticas: 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'.

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

91 Automatización Automatizar, en este contexto, provee: Un método de prevención de Bugs. Una red de contención indispensable para solucionar la causa raíz de un problema. Un eficiente mecanismo de feedback.

92 Automatización Ejemplos: Implementar una regresión funcional del los escenarios críticos. Definir una cobertura unitaria basada en los escenarios críticos. Automatizar las tareas más propensas a error: Deployment del SUT del ambiente de desarrollo al de UAT. Preparación de Ambiente: Scripts de DB, limpieza del File System, etc.