Todos los procesos de ingeniería de software ágiles o no tienen una etapa, fase o labor en la que el Product Owner conoce y analiza los requerimientos. Estos requerimientos son expresiones en lenguaje de negocio sobre las necesidades y problemas que se espera que el producto deba resolver o solucionar. Este esfuerzo marca el éxito o fracaso del producto, ya que una incorrecta identificación de estos requerimientos ocasiona que el producto no resuelva necesidad alguna o no lo hará de la forma más efectiva.
Scrum como proceso no identifica una fase en la que esto ocurra como parte de un proceso de ingeniería de software. El evento o ceremonia más cercana es el Refinamiento del Product Backlog, que es el acto de descomponer y definir aún más los elementos de Product Backlog en elementos más pequeños y precisos.
Dado lo anterior, cuando se realiza el Refinamiento del Product Backlog el Product Owner ya debió de haber hecho las actividades de identificación de requerimientos, analizando los procesos de negocio, las necesidades de los usuarios. Así como la identificación de los requerimientos no funcionales.
Pero… ¿Y si este trabajo no está correctamente realizado?
En mi experiencia he visto que en el 100% de los casos, el Product Owner termina siendo el Sponsor (el que paga, financia o gestionó los recursos financieros del proyecto) o alguien de su confianza. Cuando el PO es el mismo Sponsor habitualmente este nunca está disponible o no tiene la intensión de pensar y detallar, vaya, no tiene la intensión de realmente ejecutar el rol en su más mínimo sentido. Y no es muy diferente cuando es alguien de su confianza.
Cuando estamos en una circunstancia así pueden pasar dos cosas, tener un equipo que tenga la iniciativa para hacer las preguntas necesarias al Product Owner cuando este esté con nosotros durante el Sprint Planning, Sprint Review o en cualquier momento del Sprint; o tener un equipo que esté tomando una actitud pasiva y siendo sujeto de las circunstancias. Lo segundo llevará al título de este post.
¿A dónde nos llevará una mala definición de los requerimientos?
Creo que hay muchas respuestas a esta pregunta, pero todas inciden en el mismo punto: al caos. Cuando un PO no está haciendo bien su trabajo, sumado a un equipo de developers con actitud pasiva llevará a un estado en donde cada miembro del equipo construye un «pedazo» del producto como su mejor interpretación le dio a entender.
Este estado se vuelve caótico cuando incorporamos a este proceso actividades de Testing.
El Testing, pero el verdadero Testing.
Para entender correctamente lo que hace un Tester debemos entender primero lo que son las Especificaciones de Requerimientos.
El desarrollo de un documento de Especificación de Requerimientos de Software es esencial para el ciclo de vida del desarrollo de software, ya que este contiene, entre otras cosas, la descripción completa de lo que el sistema debe hacer sin describir cómo lo va a hacer. Su importancia reside en que son el artefacto que alberga las especificaciones de requerimientos funcionales y no funcionales y los casos de uso.
Los testers utilizan la Especificación de Requerimientos de Software desarrollar estrategias y casos de prueba para validar que el sistema se comporte de la manera en la que se indica en la ERS, con el objetivo de garantizar que los requerimientos descritos en dicha ERS están siendo cumplidos o no.
¿Cómo probar sin Especificación de Requerimientos?
Como comentaba en el punto anterior este artefacto es un insumo básico en un proceso de pruebas eficiente, cuando se carece de este resulta difícil conocer los comportamientos esperados del sistema.
Cuando esto ocurre lo común es esperar a que los desarrolladores terminen de codificar las funcionalidades supuestas de las historias de usuario, una vez liberado a un ambiente de pruebas los testers se dedican a entender cómo y qué necesidad se espera que resuelva.
A partir de este punto los comportamientos inesperados, evidentemente fallos, deberán ser reportados. Otros comportamientos por lo general son aclarados con el Product Owner para conocer si dicho comportamiento puede o no resolver una necesidad o soportar un proceso de negocio.
En esta situación muchos comportamientos del sistema pueden no estar terminados o llegar al ambiente de pruebas con demasiados errores lo que repercutirá en una sobrecarga de esfuerzo que pudo evitarse.
Los casos de pruebas solo podrán ser documentados hasta que la funcionalidad desarrollada haya sido corregida y los smoke test puedan ejecutarse. La desventaja de este proceso es que no se conoce lo que se espera del sistema, como andar de noche sin los faros del coche encendidos.
Conclusiones
En ambientes startups se da mucho énfasis a hacer software directamente escribiendo código con la esperanza de así colocar lo más rápido posible un producto en el mercado.
Siempre debe existir una planificación adecuada, priorizando e identificando problemas y necesidades que deban ser atacados y a partir de esto tener un buen diseño de software acompañado de su adecuada estrategia de aseguramiento de la calidad.
La agilidad nunca deberá abandonar procesos vitales de la ingeniería de software como el análisis de requerimientos, priorización y aseguramiento de la calidad.