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/
Muy interesante.
ResponderEliminarCreo que, en el tema de metodología ágiles, estamos llegando a una segunda etapa de uso, con mayor maduración y problemas más interesantes.
Igual que en OOP, la primera etapa fue de pelear por la adopción, discutir si sirve o no, si es mejor que lo anterior, etc. Ahora, ya tenemos proyectos, empresas y comunidades con años de uso, mucha variedad, muchos practicantes, y ya podemos empezar a toamr perspectiva.
¡Gracias Carlos por leer y comentar!
ResponderEliminarTe cuento que el otro día volví a ver un keynote de Alan Cyment (de 2012, hice una entrada al respecto también en http://germanbraun.blogspot.com.ar/2013/03/responsabilidad-cambios-y-motivacion-mi.html) en el que hace una comparación similar a la tuya (OOP y Agile).
La frase que me gusta es "Estamos bien pero vamos mal!" Quizás deberíamos tener esto en mente para lograr superarse en el mundo ágil (como se logró imponer el paradigma OO)
Abrazo,
Germán