Tocaré un tema que puede llegar a herir susceptibilidades en algunas personas, antes de juzgar por favor leer todo.

Alguna vez se han preguntado ¿es realmente necesario una persona de QA en nuestro equipo? ¿Necesitamos un Scrum master para que nos de ‘asistencia’? ¿Nos da valor tener un Agile Coach en nuestra empresa? Si la respuesta es sí a alguna de las preguntas anteriores déjame decirte que tienes un equipo/empresa aún con muchas oportunidades de mejora y te voy a explicar por qué.

Empecemos por el departamento de calidad la cual es un área creada por la incompetencia de los developers de garantizar calidad, son el fantasma de la navidad pasada creado por ellos mismos. He tenido la oportunidad en los últimos 10 años de encontrarme con excelentes tester y también de encontrarme con el que no entiende la misión de su cargo y su única objetivo/placer es de llenar de bugs al equipo (su misión es que el software funcione correctamente no llenar de bugs al equipo lo cual son dos cosas completamente diferente).

Sin embargo, a pesar de que existan excelentes profesionales encargados de garantizar la calidad, no anula la siguiente afirmación ‘Es un cargo que NO debería de existir y toca tenerlo por la incompetencia de los developers’ son los mismos developers quienes deben garantizar la calidad del software, ¿entonces qué sucede? ¿por qué no se logra?

Existen varias razones:

1. Se nos enseña desde la academia (universidad, cursos, bootcamps) que existe un rol encargado de garantizar la calidad. Esto genera una especie de bloqueo mental en los developers en que empiezan a creer que la calidad es responsabilidad de un equipo o personas diferentes a ellos, que ellos solo deben producir software y esta otra área encargarse de que no existan defectos, por supuesto que existen developers preocupados por la calidad y defensores número 1 de la calidad, pero ¿son todos así? esta pregunta la dejo para que se la respondan ustedes
2. La imposibilidad ver nuestros propios errores, la ceguera inconsciente de los developers haciendo más fácil ver los errores ajenos a sus propios y obvios errores, lo cual lo aludo a:
3. Orgullo que puede llegar a sentir un developer al ‘finalizar’ su trabajo, que aún no comprende que el final, no es terminar el código sino probarlo las veces y maneras necesarias hasta garantizar que esta correcto.
4. Tiempos de desarrollo apretados y la necesidad de sacar una versión al costo que sea, cayendo en la frase “Es mejor sacar algo (con errores) a no sacar nada”

Empezando a depender menos del cargo

Veamos una serie de pasos para lograrlo:

1. Lo primero es un cambio de mentalidad (sin esto no hay nada). El developer debe entender que la calidad del software es única y exclusiva responsabilidad de él. Olvidémonos del developer encargado de únicamente la etapa del COMO, él debe participar en el QUE apoyando y debatiendo las definiciones de negocio. (Más del 60% de los bugs nacen desde la etapa de definición. Adicionalmente siempre preguntarnos si todo lo que vamos hacer realmente sirve o le aporta al producto). Los developers deben estar llenos de coraje y no escuchar las definiciones del Product owner con obediencia.
2. Un buen proceso de CI en el que existan branch protegidos (véase gitflow) y para que un nuevo desarrollo llegue a la rama “develop” debe pasar por un proceso de revisión de PR. Lo anterior debe ir acompañado de una mentalidad de calidad, nada debe llegar a develop sin garantizar que está bien desarrollado (un developer que apruebe un PR sin hacer una revisión exhaustiva es un developer que no entiende aún su trabajo ).
3. Buenas pruebas unitarias y de integración, no pruebas para cumplir con el coverage que nos den un falso positivo y una sensación de falsa calidad.
4. Revisiones pares o en conjunto de la funcionalidad terminada y no por partes. A veces sucede que el ‘Developer A’ le hace una revisión par al ‘Developer B’ y todo funciona correctamente, pero al integrar los desarrollos no funcione y quedándose con la idea de que funciona porque ‘Developer A’ hizo una revisión. Por supuesto no estoy diciendo que no sirva las revisiones Par al finalizar un desarrollo individual, digo que se debe hacer una revisión completa una vez se tiene lista la versión por Sprint si es posible entre varios mejor.
   • Si se tiene un equipo digamos de 5 personas se puede dividir el equipo en dos, revisan de manera separada ambos grupos y luego verifican que bugs encontraron y cómo los encontraron, lo más probable que suceda es que el el ‘equipo A’ encontró algunos bugs diferente al ‘equipo B’ y viceversa, permitiendo generar retroalimentación de cómo generar las pruebas.
   • Rotar entre los developers el sombrero de “Capitán de la calidad”, como dije anteriormente la calidad es responsabilidad de todos, pero hacer responsable a 1 developer por sprint de la calidad ocasionará que tenga un doble sentido de responsabilidad debido a que será responsable de que el proceso de desarrollo se cumpla. Con el tiempo este sombrero de Capitán debe desaparecer.
5. Dejar de ver a los developers como productores de líneas de código para cumplir casos de uso y empezar a verlos como los productores totales del sistema. Ejecutar un plan de acción de mejora sobre un developer que produce decenas de linea de código por día y decenas de bugs por sprint es un paso que no puede faltar (cuántas veces hemos tenido que sobrevivir al “gran developer” que hace mucho código y poco software de calidad).

Apostando por alcanzar la utopía

Por la volatilidad de nuestra carrera evitar los bugs en el software al 100% es una utopía, lo que no deben de existir son errores obvios/fáciles de detectar, aquellos errores que lleguen a producción deben ser excepcionales o aquellos flujos difíciles de encontrar.

Pero existen casos donde apostar por un 100% de calidad es la meta (Banca, salud) podemos apostar por la figura del QC, aquella persona que no hace parte del equipo de desarrollo pero interviene en una etapa previa al final, esta persona debe tener un alto conocimiento de negocio o lo que pretende lograr el software.

¿Cómo trabajar con la persona QC?

• Su trabajo se ejecutará finalizado el sprint y trabajara sobre un ambiente de pre productivo, que solo cuenta con las versiones actuales de producción y los artefactos actualizados a instalar en producción (Staging), en gitflow el desarrollo a certificar calidad estará alojado en la rama Release (separado del nuevo trabajo que estarán haciendo los develops que estará en las ramas feature y develop) y los bugs que se presenten se solucionaran en ramas “Fix” que se deben reintegrar a la rama release.
• Contabilizar y revisar el porque se pasaron al equipo de software exhaustivamente cada uno de los issues que encuentran.
• Si el sprint tuvo una duración de dos semanas, su revisión deberá durar máximo 3 días (recordemos que esta persona garantiza que a nivel de negocio se cumplieron las expectativas, la calidad debió ya fue garantizada en el sprint inmediatamente anterior) y en un mundo ideal los issues encontrados deben ser solucionados por el “capitán calidad” del sprint inmediatamente anterior.
• ¿Debe ser Ingenier@? No necesariamente (si lo es bien, sino, también), esta persona debe conocer a detalle el propósito del sistema, los flujos a ejecutar, invariantes, necesidades a cumplir del negocio.
• Una vez la persona de QC garantiza que los artefactos a desplegar a producción cumple con lo requerido por negocio, esta versión queda cerrada y puede desplegarse a producción, otorgando el OK para hacer un merge hacia la rama master
• ¿Hace parte del Scrum team?, respondanse ustedes esta pregunta.

En el siguiente Post hablaremos del scrum master — agile coach. Lo que se debe esperar de su cargo y el poco valor que aportan muchos para ayudar a encontrar al verdadero y valioso scrum master.