En Ingeniería de software, la inspección se relaciona con la Revisión por pares de cualquier producto de trabajo por personas capacitadas que buscan defectos mediante un proceso bien definido. La inspección de software es conocida también como -Fagan inspection- en homenaje a Michael Fagan, el creador de este popular método de inspección de software.
wikipedia
Parece que la inspección se ha coronado como la forma más habitual de trabajo en el desarrollo del software. Básicamente un desarrollador selecciona una tarea, la implementa en solitario y a continuación, solicita una revisión a otra persona para que valide el trabajo realizado.
Esto no sólo ocurre cuando se escribe el código del programa, en general la aproximación a cualquier tarea que se deba hacer para el equipo de desarrollo sigue este mismo patrón.
En mi opinión la inpección se utiliza porque es la manera más fácil de introducir feedback en un proceso en cascada.
Un ejemplo de lo que un equipo Agile hace para poner una historia en producción:
- El Product Owner/Product Manager/Business Analyst o el nombre que sea, escribe las historias de usuario solo.
- El UX trabaja en el diseño de la solución tras hablar con los interesados/clientes sin hablar con nadie más.
- Product Owner y UX tienen una reunión para combinar ambos trabajos, cualquier feedback sirve para volver a trabajar solos y mejorar ambas partes. (Punto de unión)
- El PO presenta en un Refinement al resto del equipo el trabajo que se ha analizado. Los profesionales de Calidad (QA) y los Developers pueden dar algún feedback nuevo, que se tratará de la misma manera, cada uno por su lado.
- Los QA’s crearán sus test-cases, test executions y el resto de cosas solos.
- Los desarrolladores partirán las historias según consideren y empezarán el desarrollo.
- Cuando un desarrollador termine una tarea, pedirá una revisión de código. (Punto de unión)
- Si hay comentarios intentará solventarlos.
- Cuando todas las tareas estén terminadas, se mergeará el código y se probará que funciona. (Punto de unión)
- QA también pedirá feedback a otros QA para mejorar. (Punto de unión)
- Cuando todo lo anterior esté hecho, se probará la nueva característica en un entorno y si se encuentra algún bug o defecto o hay algún nuevo feedback volveremos a empezar. (Punto de unión)
- Si el feedback es relacionado con la genésis de la historia entonces nos vamos al principio otra vez (Punto de unión)
¿Y no os suena esto a una especie de proceso en cascada con retroalimentación?.
Cada uno de esos puntos de unión están ahí para incrementar la calidad de la pequeña tarea que se ha ido haciendo, parece como un parche para seguir manteniendo la misma aproximación. Es como que hemos cambiado de tener feedback muy de vez en cuando a tenerlo solo de vez en cuando.
Feedback loops largos
El efecto de un feedback loop muy largo es que tiende a aumentar el WIP (work in progress). Los puntos donde nos damos feedback no son inmediatamente después de que se haya terminado el trabajo de esa pequeña tarea (porque debemos esperar a la revisión), con lo que eso provoca que la gente se dedique a otra y aumente de forma natural el WIP. Básicamente somos muy ineficientes trabajando de esta manera, estamos siempre ocupados, pero las tareas no hacen más que esperar por las reuniones que debemos tener para recibir o dar feedback.
Un ejemplo claro de esto son las “pull requests“, para tener feedback tras implementar la tarea necesitamos a otra persona que revise la historia. Esto no se hará inmediatamente, ni en minutos en la mayoría de los casos, sino en horas o días, eso provocará que cojamos otra historia para seguir estando ocupados. 100% de utilización y ¿qué es una carretera con el 100% de utilización?:
Correcto un parking, algo totalmente bloqueado que no hace la función para la que estaba diseñada.
Feedback loops cortos
En realidad ¿qué pasa si llevamos la idea de que más y más puntos de unión para revisar el trabajo hecho conlleva añadir más calidad?. Pues nos daremos cuenta de que esos puntos de unión representan en realidad una restricción del sistema, convertimos la carretera en un parking porque debemos esperar a tener esas reuniones o que otra persona tenga tiempo para de forma asíncrona echar un ojo a nuestro trabajo.
Entonces la respuesta parece obvia, eliminemos los puntos de revisión y hagámosla constantemente. Pongamos a más de una persona trabajando en la misma subtarea de forma síncrona. Cambiemos la inspección por colaboración, entonces no necesitaremos tantos puntos de verificación para poder seguir trabajando, reduciéndolos reduciremos el WIP.
Algunos técnicas de colaboración:
- Mob programming (ensemble programming, swarming), el WIP será uno, todo el equipo trabajará en la misma historia hasta que termine y todos aportarán en todos los pasos del desarrollo.
- Programación en parejas (recordemos que la rotación frecuente de las parejas es fundamental).
- Trunk based development las ramas introducen siempre delays en el desarrollo.
- Shift Left testing.
- Escribir las historias de usuario entre los representantes de cada rol del equipo
La inspección no mejora la calidad ni garantiza la calidad. La inspección es demasiado tarde. La calidad, buena o mala, ya está en el producto. Como dijo Harold F. Dodge, “No se puede inspeccionar la calidad de un producto”.
Principios de gestión de la calidad total de Demmings
