Ver el todo de un proyecto es algo que puede parecer simple, pero que necesita de sus herramientas y recursos para poder hacerlo de manera controlada y efectiva.
Hasta aquí, hemos estado hablando mucho sobre agilidad y sus bondades. Sin embargo, aparece el siguiente efecto colateral: perdemos de vista "el todo" del proyecto. Es decir, ¿estamos haciendo lo que realmente debemos hacer?, ¿hacia dónde vamos? ¿dónde estamos parados actualmente luego de finalizar determinadas tareas? Si lo trasladamos a un proyecto de testing, ¿todas las funcionalidades están cubiertas por nuestras pruebas? ¿dónde nos está faltando testing? ¿cómo está el semáforo del proyecto?
Gojko Adzic, en su libro "Impact Mapping: Making a big impact with software product and projects", se encarga de tratar este tema usando los mapas mentales. Adzic, nota que una causa común de la desconexión entre el negocio y el delivery es que los equipos que trabajan en un esquema iterativo, lo hacen sobre pequeñas funcionalidades que tienden a ir por un pipeline sin tener en cuenta su valor para el negocio. Con el foco puesto principalmente en el delivery, los mapas de impacto facilitan esta vista tanto para el negocio como para el equipo técnico y se adaptan bien a los modelos iterativos. Usando mapas de impacto podemos reportar progreso, comprometernos sobre impactos a ser logrados, dar visibilidad y permitir una implementación más flexible.
Para Janet Gregory y Lisa Crispin, "look at the big picture" es uno de los factores claves de éxito según definen en su libro "Agile Testing: A Practical Guide for Testers and Agile Teams". Para ellas, todos los software makers deben mirar el todo del proyecto y usualmente desde el punto de vista del cliente. ¿Qué sucede si una nueva funcionalidad causa que otras no relacionadas rompan? Es necesario considerar el impacto sobre el sistema completo y llamar la atención del equipo sobre esto. Enfocándose puntualmente en testing, Crispin y Gregory proponen evaluar cómo las actuales stories se insertan en el esquema del negocio y preguntarnos a nosotros mismos cómo podemos hacer un mejor trabajo para poder entregar valor real. Usar el cuadrante de testing agile, guiar el desarrollo con tests, hacer testing exploratorio para aprender sobre el negocio, hacer un ambiente de pruebas tan similar al productivo como sea posible, usando datos reales y recrear situaciones en producción, tales como el testing de carga, son algunas de las herramientas que se proponen en el libro.
Personalmente, he puesto en práctica varias de estas herramientas y consejos en mis proyectos. Algunas ya las hemos charlado en el blog y otras las vamos a ir desarrollando en entradas posteriores. Sin embargo, antes de seguir avanzando, creo que es necesario ponernos a pensar si estamos viendo el todo de nuestros proyectos.
Germán
[1] Frase extraída del libro "Impact Mapping: Making a big impact with software product and projects"
[2] Imagen de http://blog.pablojimeno.com/blog/2013/03/13/london-2013-experience-part-i-impact-mapping-with-gojko-adzic/
