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.
- 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 hecho 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.
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
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 saber más
Proyectos Ágiles 