Así como está el “inbox zero” como práctica de gestión de emails, también está la “zero tolerance on open defects” (sin tolerancia a defectos abiertos) buscando tener cero defectos conocidos. No conozco ningún equipo que lo practique, así que no tengo información de primera mano sobre los resultados, pero leyendo esto me pareció interesante los resultados teóricos esperados.
La idea es que si uno prioriza en resolver los defectos apenas aparecen, se evita lo siguiente:
- esfuerzo en gestionar muchos incidentes abiertos
- esfuerzo en priorizar (para lo cual lo mejor es hacerlo basado en riesgo)
- demorar el aprendizaje que sucede al corregir un defecto (y así evitar que se vuelva a cometer el mismo error)
- esfuerzo extra para corregir por el cambio de contexto y por recordar lo que se estaba haciendo y cómo se hizo lo que se va a corregir
Lo más parecido que he visto a esta política es que en un sprint, si el tester encuentra defectos no los reporta, sino que los comenta en la misma historia de usuario y esa historia no se termina hasta que se solucionen todos los defectos. Si aparece un error en producción, esto será puesto en el backlog y priorizado como un cambio, comparando con el resto de funcionalidades. Si es un issue que tiene impacto, supongo que tomará una prioridad mayor que cualquier nueva funcionalidad y se corregiría de inmediato (siguiente sprint).
¿Tenés alguna experiencia sobre esta práctica de cero defectos como para compartir? Me interesaría saber si alguien la lleva adelante y cómo le va.
