Hacer testing es también capturar conocimiento

Varias veces he escuchado la siguiente frase: "Los desarrolladores tiene un pensamiento constructivo y los testers tienen un pensamiento destructivo". Esta falacia se está derrumbando con el paso del tiempo (por suerte). Los testers también construyen, nada más ni nada menos que calidad. Ernesto Kiszkurno ya habló de esto en su blog.

En esta dirección, la dependencia de la gente en el software es cada vez mayor y, por lo tanto, este tiene que ser cada vez más confiable. Debe resolver el problema para el cual fue construido. Leandro Caniglia siempre me dice que para él, construir software es capturar conocimiento y que los testers son el complemento indispensable en la cadena de valor. Es decir, los testers también participan en la captura del conocimiento tan importante a la hora de modelar dominios reales y, por lo tanto, complejos.

En conclusión, es hora de integrar definitivamente a los testers y a los developers para que ambos colaboren desde las fases tempranas de un producto. El testing NO debe ser una etapa en el ciclo de construcción de software sino que debe ser una actividad parte del criterio de "Done".

"Tested is part of 'Done'"

[1] La imagen fue extraída del blog http://www.agilebuddha.com/

No revisaré mails al inicio del día

Aquí les dejo la justificación científica de por qué es interesante tratar de implementar el lema "Stop Starting, Start Finishing"

El video "La razón sobrevaluada", de Estanislao Bachrach en la TEDxRíoLimay del 2012 (en Septiembre de 2013 es la segunda edición), deja algunas perlitas:

1. Revisar mails al inicio del día consume mucha energía.
2. Dejar las actividades que nos consumen más energía para cuando estamos más descansados.
3. Priorizar
4. Visualizar
5. Escribir nuestros proyectos/ideas/compromisos para no tenerlos en nuestra cabeza constantemente.
6. Querer ser más productivos, nos hace improductivos.




Limitar nuestro WIP en pos de tomar mejores decisiones.

Mapas de Impacto

Estoy leyendo el libro de Gojko Adzic"Impact Mapping: Making a big impact with software product and projects". Me tiene bastante entretenido. Es un tema que está haciendo mucho ruido.

Personalmente, estoy intentando trabajar con mapas mentales desde hace un tiempito. Creo que es una herramienta potente que puede aplicarse a diversos dominios, tareas y/o problemas que tengamos que resolver. Sobre una aplicación puntual ya he escrito aquí.

Un mapa de impacto es un mapa mental que permite a los equipos y a las organizaciones visualizar alcance y asunciones relacionadas a algún objetivo que se intente lograr. Supongamos que, en nuestro contexto, es construir un producto software. Estos mapas son creados de manera colaborativa por todos los involucrados e interesados en lograr la meta que los convoca (obviamente, esto es una situación ideal). La gran ventaja de estos mapas: permiten tener controlada la big picture de nuestro proyecto, tener en claro a dónde queremos ir, cómo llegar y a quiénes debemos involucrar.

Durante la creación de una mapa es necesario responder a las siguientes preguntas:

  • WHY? Es el centro del mapa.  Es la meta que se está tratando de lograr. Una buena meta debería ser SMART (Specific, Measurable, Action-oriented, Realistic and Timely) y presentar el problema ha ser resuelto.
  • WHO? Este nivel indica quienes son los actores que pueden influenciar el resultado. Quién puede producir el efecto deseado, quién puede obstruirlo y quién será impactado. Debe ser lo más específico posible.
  • HOW? Explicita el impacto que se trata de crear. Cómo debe cambiar la conducta de los actores y cómo pueden ayudar a lograrlo. Especificar estos impactos permite priorizar e identificar riesgos. 
  • WHAT? El último nivel del mapa es el nivel de los entregables. Qué puede hacer el equipo o la organización para dar soporte al impacto. Puede contener varios niveles más y no necesariamente deben completarse desde el inicio. Puede ser refinado de manera iterativa.

A modo de ilustración, hice el siguiente mapa de impacto usando la herramienta MindMup. Espero que se animen a aplicarlo y a compartir la experiencia :) Voy a seguir escribiendo sobre el tema a medida que avance con el libro.


Tener +500 visitas en una entrada sobre Mapas de Impacto on MindMup

Stop Starting, Start Finishing


Hace tiempo que encontré este slide de Henrik Kniberg. Traté de implementarlo (y aún lo intento) pero algunas cuestiones son un poco más complejas. En el día a día, uno tiende mucho al multitasking y a salir corriendo atrás de las cosas que deberían haberse hecho para ayer. 


En fin, admiro a la gente que sabe decir NO y que puede tener su WIP controlado...