El presente documento tiene como objetivo principal validar los requerimientos del cliente desde una perspectiva ágil. Se abordará esta temática en dos partes, siendo esta la primera entrega. En esta sección se analizarán las ventajas de aplicar la metodología ágil en el proceso de validación de los requerimientos del cliente. Asimismo, se presentarán las diferentes técnicas y herramientas que se pueden emplear para llevar a cabo esta validación de manera efectiva. Al finalizar el documento, se espera tener un panorama claro sobre cómo la perspectiva ágil puede contribuir a optimizar el proceso de validación de los requerimientos del cliente.
El problema
“Cuando nosotros nos acercamos al cliente, asumimos que él sabe exactamente qué quiere hacer y nosotros le damos el cómo. Sin embargo, esto no es así y nuestro trabajo se convierte en algo así como adivinar el futuro con una bola de cristal.”.
¿Cómo enfrentar desde la perspectiva ágil el hecho de que sigue siendo importante poder obtener con antelación una validación de los requerimientos del cliente antes de que el producto salga al mercado? teniendo en mente que el objetivo es evitar por todos los frentes posibles que nos transformemos en verdaderos adivinos con una bola de cristal.
Sabemos por ejemplo que de acuerdo a SCRUM, la validación que hace el cliente (product owner) de la pila de requisitos (backlog desde ahora en adelante) no la podrá obtener sino hasta que se construya el primer incremento (potentially shippable product), es decir, hasta que pueda obtener una versión funcional del producto (testeable). Sin embargo también sabemos que el Product Owner (PO desde ahora en adelante) es un agente partícipe activo del Sprint Planning, área que puede usarse para obtener con antelación una validación de este mismo stakeholder (involucrado).
Desde las primeras etapas del proceso de SCRUM cuando se comienza a recopilar la pila del producto (backlog), la única inferencia que el PO tiene en dicha pila es: para ordenar las historias de usuario.
Luego de armar las características de las historias especificadas con el comportamiento deseado desde la perspectiva del usuario, el PO no tiene inferencia hasta la etapa de planificación del sprint, donde básicamente se define:
- el What?
- el How?
y con lo anterior se genera el Sprint Backlog.
Luego durante 10 o 15 días (configurable de acuerdo al proyecto y las necesidades del PO), se comienza el desarrollo del primer sprint, y ya nos desconectamos completamente de la validación que podría hacer el PO sino hasta la entrega del incremento funcional. De acuerdo a mi perspectiva la pregunta planteada a modo de hipótesis es:
¿Cómo enfrentar desde la perspectiva ágil el hecho de que sigue siendo importante poder obtener con antelación una validación de los requerimientos del cliente (PO) antes de que el producto salga al mercado?
Para poner más claro el problema me gustaría compartir con ustedes una discusión entre Zach Bonaker, agile coach de Willis Towers Watson y Jaya Shrivastava, coach de AGILE++ Engineering. Obviamente personas que saben mucho más que yo.
La traducción es:
Zack:
Un equipo que desarrolla historias que resultan en un software que no se puede usar o que no tiene utilidad no es un fallo de una “definición de característica comercial mínima” (MMF). Es debido a un backlog muy pobre, probablemente el resultado de prácticas ágiles fallidas en las etapas iniciales donde el equipo planeó realmente el sprint.
Jaya:
Sí, cada iteración produce algo valioso, pero ¿los clientes lo usan?
En el mundo real, la respuesta es un rotundo NO. Los clientes no están dispuestos a asignar recursos para probar o liberar lo que se produce al final de los sprints.
En su lugar, los clientes están dispuestos a tomar incrementos que creen que pueden ser liberados al mercado.
Esto falta ya que no trabajamos lo necesario para poder liberar una característica mínima que sea comercializable.
Vaya problema…
El asunto importante es que si llegásemos a poder tener una validación inicial antes de la entrega del incremento funcional, podríamos disminuir un riesgo importante: que es justamente que el producto llegue defectuoso al mercado.
En una próxima entrega iré detallando algunas técnicas que buscan ir en apoyo de una definición más concreta y sencilla de requerimientos antes de entrar a las etapas de construcción.
Cualquier aporte es siempre bienvenido, sobre todo para corregir algunos temas principalmente relacionados con el mundo ágil.
Para abordar este problema, es crucial tener una validación temprana de los requisitos antes de entregar el incremento funcional. Esto nos ayudaría a reducir el riesgo de lanzar un producto defectuoso al mercado. En futuras entregas, exploraré técnicas que respalden una definición más clara y sencilla de los requisitos antes de entrar en la fase de construcción. Aprecio cualquier aporte para corregir aspectos relacionados con el ámbito ágil. ¡Nos encontramos en el próximo artículo y disfruten de la lectura!MMF: Características Mínimas Comercializables
