El valor de lo pequeño: construir calidad en base a incrementos frecuentes

Hoy en día, la inmensa mayoría de productos de software que son desarrollados y puestos en producción son un compendio de multitud de elementos con una arquitectura compleja. No obstante, es muy común que cada uno de nosotros, como usuarios domésticos o profesionales de este software, hayamos sufrido las consecuencias de errores subyacentes en estos sistemas, y de que estos puedan aparecer en el momento más insospechado.

¿A qué podemos achacar estos defectos? Muy posiblemente, la respuesta a esta pregunta nos daría para una amplia literatura, pero en este artículo vamos a centrarnos en un motivo muy concreto: la baja granularidad en la construcción de muchos de estos sistemas afectan decididamente a su calidad. O lo que es lo mismo, cuanto más grande es el incremento que añadimos, más difícil es controlar el correcto funcionamiento (acorde a los requerimientos) del mismo, y de los elementos que pueden verse afectados (es decir, controlar las posibles regresiones del sistema).

Para vencer este inconveniente, las metodologías ágiles hacen virtud de lo pequeño, que consiste en entregar piezas de software funcionales construidas en ciclos cortos de desarrollo, llamadas iteraciones (timeboxed development).

¿Cómo Agile estructura la construcción en pequeños incrementos? Es aquí donde es esencial el concepto de historia de usuario (también llamada caso de uso o característica, dependiendo de la metodología con la que tratemos), que es el actor principal en el contenedor de tareas que deben formar el producto (Product Backlog).

Una historia de usuario contiene una pequeña parte de funcionalidad a ser construida. Si esta es muy compleja, se conoce como épica. Las épicas se dividen más tarde en User Stories, que a su vez son divididas de nuevo en tareas, que representan unidades de trabajo indivisibles. Como vemos, Agile pretende llevar a cabo un amplio nivel de granularidad sobre el desarrollo a realizar.

¿Qué beneficios tiene dividir las historias de usuario en pequeñas unidades de trabajo? A continuación mencionaremos las principales ganancias:

• La estimación temporal es más simple cuanto más pequeña es la tarea a analizar
  • La visibilidad del progreso de tareas amplias es más compleja que en actividades más simples.
• Construimos calidad desde el inicio del desarrollo
  • La comprensión del trabajo a realizar es más sencilla con una tarea más pequeña. Al mismo tiempo, es más fácil acordar que debe cumplir la actividad para ser considerada como hecha (criterios de aceptación). Esto facilitará enormemente la labor de verificación de QA.
  • Cuanta más grande es la tarea a realizar, más posibilidades de que el desarrollo se alargue en el tiempo. Esto hace que los tests de aceptación sean lanzados en una fase tardía, lo que aumenta sustancialmente los riesgos de que la funcionalidad sea lanzada a producción conteniendo defectos relevantes.
  • La entrega de software funcional en cada ciclo permite hacer una mejor selección de la estrategia de tests de regresión a ser ejecutados. Cabe recordar que cuanto más grande es la modificación añadida al software, más posibilidad hay de introducir defectos de regresión, debido a la cantidad de elementos afectados por el cambio.
  • Como hemos mencionado anteriormente, construir con pequeños incrementos hace que los riesgos claves presentes en el desarrollo sean cubiertos en una fase temprana del proyecto.

• Dividir el trabajo en pequeñas unidades, hace las tareas factibles
  • Los proyectos de desarrollo tradicional de software no permiten a los miembros del equipo ver el sistema hasta que el proyecto está en una fase avanzada. Esto dificulta la introducción de modificaciones respecto a lo inicialmente establecido, al mismo tiempo de que el riesgo de no entregar lo acordado (tanto por no cumplir con los requisitos, ya que estos son más complejos de entender, así como de hacerlo con defectos) es sustancialmente mayor.
  • El desarrollo en pequeñas porciones de trabajo da una oportunidad al equipo de ver casi constantemente el progreso de su trabajo, así como de recibir y dar feedback acerca de cambios en el producto, ya que los responsables de negocio empiezan a ver el producto en una fase más temprana, y no cuando el sistema está completamente desarrollado.

La conjunción de estas ventajas del desarrollo en pequeños incrementos facilita entregas frecuentes y de calidad, lo que permite adecuarse a un mercado cambiante y ávido de cambios que permitan acercarnos con mayor precisión a las necesidades de los clientes.

Conoce nuestras soluciones de Agile Testing!

Isaac Álvarez Diz
QA Manager | SOGETI ESPAÑA