Scrum-team

Agilismo corporativo

Una de los principales obstáculos de la implantación de métodos ágiles en organizaciones tradicionales reside en el impacto que tiene una metodología como Scrum en el organigrama de una corporación. En este artículo sobre agilismo corporativo se aborda el papel de los ingenieros de Calidad desde distintos puntos de vista.

Scrum-team

Desde hace más de una década, prestigiosos metodólogos e ingenieros de software han apostado por un cambio de paradigma en la construcción de soluciones de tecnología que abunde en las interacciones entre los distintos roles. La formación de los impulsores de los métodos ágiles han condicionado la atribución de roles y responsabilidades en los equipos en los que algunos de los actores principales de los procesos más tradicionales no tienen cabida. En concreto me refiero a los siguientes:

  • QA: Ingenieros de calidad, sobre todo a nivel funcional
  • Project Manager.
  • Oficina de proyectos.

El reto fundamental para implantar una cultura ágil en empresas tradicionales (o con organigramas más resistentes al cambio) pasa por encontrar acomodo a éstas y otras figuras en los departamentos encargados del desarrollo de software. En este primer artículo de la serie sobre agilismo corporativo trataremos de proporcionar nuestra visión sobre el papel reservado a los responsabilidades de la calidad del software.

Calidad en métodos ágiles

En oposición a las metodologías más tradicionales, los procesos ágiles que han surgido en la última década parecen haber reservado un papel residual a los ingenieros de calidad. Apenas existe literatura sobre roles o responsabilidades específicas de los testers y la introducción de técnicas como el TDD o la Integración Continua a menudo se confunden con las tareas específicas de aseguramiento de la calidad.

En nuestra opinión, es imprescindible contar con personal especializado en determinar si un producto cumple con las características y niveles de calidad establecidos por el cliente.

Calidad como propietario de producto

El Product Backlog en Scrum es la lista de los requisitos funcionales del cliente ordenados en función del valor de negocio (o ROI). Cada elemento de la lista (Product Backlog Item) debe contener al menos la siguiente información para ser abordado por el equipo:

  • Funcionalidad: Descripción funcional del requisito (user story).
  • Valor de Negocio: Estimación relativa del valor que aporta al cliente.
  • Coste: Estimación relativa del esfuerzo necesario para implementar la funcionalidad.
  • Criterios de Aceptación: Definición de Hecho, pruebas de validación y/o regresión.

Dejando a un lado las estimaciones del valor de negocio (responsabilidad exclusiva del cliente) y de coste (responsabilidad exclusiva del equipo de desarrollo), el resto de los datos incluidos en cada historia de usuario forman parte del ámbito de responsabilidad habitual del equipo de Calidad funcional de producto!

Considera situar a un ingeniero de calidad (funcional) como propietario de producto para facilitar la comunicación de historias de usuario y asegurar la máxima calidad en cada Sprint.

Esta aproximación proporciona algunas ventajas:

  • Historias de usuario en lenguaje más cercano al desarrollo
  • Definición de Hecho (DoD)
  • Calidad en las entregas, lo que redunda en mayor confianza por parte de los stakeholders en el equipo y en el progreso del equipo.

Las empresas de producto en las que la calidad final sea un parámetro crítico o aquellos equipos de dirigidos por los ingenieros de desarrollo son entornos ideales para esta configuración.

Calidad como miembro del equipo de desarrollo

A menudo los actores que intervienen en el desarrollo de software están muy compartimentalizados y no permiten el grado de flexibilidad y auto-organización que requieren los equipos ágiles (ver el apartado dedicado a Ecosistemas Ágiles). En estos casos los grados de libertad se reducen por la presencia de áreas responsables de producto externas al equipo Scrum.

Cuando no sea posible disponer de un responsable de la calidad para el rol de Propietario de producto, se deberán asignar actividades de forma explícita al equipo de validación funcional con especial atención a 3 prácticas fundamentales:

  • Sesión de Planificación. En paralelo a la estimación y compromiso de funcionalidad para el Sprint que comienza, desde Calidad es imprescindible avanzar en el entendimiento de las historias de usuario y la Definición de Hecho ya que esta información podría tener impacto en el coste de ejecución.
  • Seguimiento. La integración continua (en los diversos entornos de despliegue) deberá ser coordinada con Calidad para que se puedan establecer sesiones de validación previas a la revisión del sprint.
  • Sesión de Revisión. Independientemente de la involucración de los responsables de producto, las sesiones de Revisión del sprint debería enfocarse en comprobar que los compromisos adoptados en el inicio del sprint se han entregado de forma integral (ver la definición de Sashimi en Scrum).

La credibilidad en el equipo (y por ende, en el nuevo paradigma de trabajo) depende en gran medida de la calidad de las entregas sostenidas en el tiempo por lo que la Calidad de producto debe ser una prioridad.

Ecosistemas ágiles

 La estructura de muchos de los departamentos de tecnología en empresas de ciertas dimensiones no facilitan un entorno colaborativo como el de Scrum. Estas dificultades se amplifican en organigramas donde la responsabilidad está distribuida: Responsable de Requisitos, Responsable de Arquitectura, Responsable de Desarrollo, Oficina de Proyectos…

Habitualmente la única alternativa para la implantación de métodos ágiles es la creación de un ecosistema ágil. Por si alguien tiene alguna duda seguimos hablando de metodologías ágiles…

Un ecosistema ágil es un entorno protegido para los equipos de desarrollo y calidad en el que se dan las condiciones para la auto-organización en una estructura más apta para modelos de crecimiento orgánico.

Ojo! Un ecosistema ágil tiene como objetivo implantar procesos iterativos e incrementales en organizaciones que no los soportan de forma explícita (mediante alcance o presupuestos cerrados). Aunque este modus operandi sea el único factible a corto plazo solamente podrán obtenerse resultados óptimos cuando la organización se adapte al nuevo paradigma.

Calidad en ecosistemas ágiles

El concepto de ecosistemas ágiles es difuso y no forma parte de ningún estándar de facto reconocido por las autoridades en la materia. Por lo tanto los siguientes consejos son el fruto de nuestra experiencia en la implantación de métodos ágiles mediante una aproximación pragmática en diferentes entornos:

  • Planificación. Calidad debe contribuir en la estimación de coste en función de los criterios de aceptación de cada historia de usuario. Para cada funcionalidad comprometida en el sprint, Calidad deberá realizar planes de prueba específicos que formarán la Definición de Hecho.
  • Integración Continua. La integración periódica del producto a lo largo del sprint debe ser utilizada para favorecer (en la medida de los posible) la automatización de los planes de pruebas funcionales. Es importante disponer de entornos de integración de pruebas y mecanismos de entrega continua en los mismos.
  • Herramientas de seguimiento. En las herramientas de seguimiento (burndown chart, kanban, etc.) debe considerarse la validación funcional como una etapa imprescindible sin la cual no se puede evaluar el progreso. De nuevo, una tarea solamente estará finalizada cuando se satisfagan los criterios de aceptación (y no solo la subida del código al gestor de versiones).
Kanban & Calidad en Greenhopper

Mediante herramientas como los tableros Kanban y los diagramas CFD deberá analizarse la optimización de recursos dedicados a desarrollo y calidad.

CFD en Greenhopper
  • Sesión de Revisión. La sesión de revisión deberá estar dirigida a comprobar el grado de cumplimiento de los compromisos adoptados en el Sprint. Por si no hemos insistido suficiente, el objetivo del proceso iterativo e incremental es producir credibilidad en el equipo (tanto internamente como hacia fuera) por lo que es importante tratar las causas de incumplimientos y retrasos en la retrospectiva.
  • Sesión Retrospectiva. En las primeras iteraciones es imprescindible realizar sesiones en las que tanto desarrollo como calidad analicen de forma colaborativa los impedimentos que están obstaculizando el avance así como los cambios organizativos y procedimentales que mejoren la productividad y fiabilidad del equipo.
  • Scrum Master. La implantación de ecosistemas ágiles debe estar guiada por grandes dosis de sentido común y, sobre todo en las primeras etapas, por la figura de un facilitador que permita obtener los mejores resultados dentro de las limitaciones que impone la organización. El grado de éxito (y el plazo para alcanzarlo) dependen en gran medida de la experiencia de este rol.

En siguientes artículos analizaremos otros aspectos que puedan servir de ayuda en la implantación de procesos y técnicas ágiles en entornos corporativos. Si no sabes por donde comenzar, te sugerimos que consultes nuestra guía.

Author: Eduardo Mayor

Eduardo Mayor is a software engineer with 20+ years of experience. He is also the founder of Novagenia Information Technologies, a company focused on introducing agile methods and tools to companies worldwide.

Visit us in: http://www.novagenia.com
Share this...

Un comentario en “Agilismo corporativo

  1. Un post muy interesante, aunque no estoy de acuerdo con algunas cosas.

    “los procesos ágiles que han surgido en la última década parecen haber reservado un papel residual a los ingenieros de calidad”

    Para nada! quizá en los inicios, pero a día de hoy por ejemplo, en Bridging the communication Gap, explican como el rol del equipo de calidad no solo se mantiene sino que se amplia para hacer que participe más en el proyecto.

    “Dejando a un lado las estimaciones del valor de negocio (responsabilidad exclusiva del cliente) y de coste (responsabilidad exclusiva del equipo de desarrollo), el resto de los datos incluidos en cada historia de usuario forman parte del ámbito de responsabilidad habitual del equipo de Calidad funcional de producto!”

    Que va! La elaboración de los criterios de aceptación de ser responsabilidad conjunta de cliente, equipo de desarrollo y equipo de calidad! Siendo el papel del equipo de calidad muy importante por su habilidad para buscar corner cases y ver rapidamente donde puede “romper” el sistema.

    De nuevo, te recomiendo Bridging the communication Gap que explica mucho mejor de lo que yo podría las responsabilidades de managers/developers/testers en la metodología agile acceptance testing (AKA ATDD)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>