RS: enfocados hacia la calidad

Este post de retrospectiva vale por las últimas semanas. Desde el último post de retrospectiva hasta ahora, estamos notando una evolución espectacular en el equipo, tanto en el compromiso que cada uno demuestra escribiendo código de calidad como en la responsabilidad de completar las releases semanales. En la pizarra que usamos en la última reunión de retrospectiva aparecieron más anotaciones positivas que anotaciones de mejora 🙂  Sin embargo en este post voy a resaltar lo que queremos lograr.

La cuestión es no parar aquí porque sigue quedando muchisimo camino por recorrer. Simplemente seguir trabajando duro con ayuda de esta sensación de progreso que va calando en el equipo.

Lo que queremos hacer:

  • Los commits aún más cortos y legibles (tengo pendiente un artículo sobre esto que saldrá en la proxima tirada de agilerecord.com). Evitar que los commits lleven diferencias en tabulaciones y espacios para que no se registren cambios que no son de verdad en código sino en configuración del editor de texto.
  • Un branch por feature: tenemos que quitarnos de encima el agobio de que el dia de la subida de versión el branch principal no acaba de estar fino para mezclarlo con estable. Al empezar una nueva funcionalidad iniciaremos un nuevo branch. Cuando se toca código cómun se mezclará con la rama principal y se compartirá para que los demás tengan el cambio disponible lo antes posible.
  • Acelerar la velocidad de nuestras máquinas. En compilar el proyecto (.sln) y lanzar los tests se iba un minuto en cada maquina. Insoportable e impracticable para hacer TDD. Hemos cambiado dos máquinas comprando todo el hardware nuevo, doblando la memoria RAM, y poniendo discos duros nuevos. También hemos optimizado la configuración de la compilación. Ahora se tardan 3 segundos en compilar y otros 3 en pasar los tests. Con eso recuperamos más que de sobra la inversión en hardware. Pero aún quedan varios compañeros con equipos lentos. Es muy importante resolverlo cuanto antes.
  • No hacer cambios en base de datos sin hablarlo primero con los demás y sin que sea totalmente inevitable. Nuestro objetivo es que la BD sea lo último que se toque, tratando de modelar primero el comportamiento en el código.
  • No olvidar pasar todos los tests despues de hacer "merge" y dar la voz de alarma cuando alguno se ha roto.
  • Mejorar el tiempo de respuesta de las incidencias.
  • Seguir formándonos, leyendo libros y practicando ejercicios. En la sesión formativa de los viernes y en casa.
  • Conocer más el código que hacen los demás y la funcionalidad para evitar duplicarla. Tener aún más cuidado en la code review de las mañanas.
  • Automatizar la generación de bases de datos de quita y pon, para pruebas de integración.
  • Cuando el código legado es abrumador, nos trazamos un mini "backlog" de los cambios que queremos conseguir hacerle y una estimacion de tiempos para irlo haciendo (ej: en 15 minutos, cambiar este método para que en lugar de recibir 7 parametros reciba un objeto).

Logros:

  • Aumento de lo concienciado que está el equipo para escribir código más legible y mantenible para los compañeros.
  • Despliegues automáticos. Yeah!!
  • Estamos priorizando mejor. Nadie ha tenido que hacer ni una hora extra porque hemos afrontado a tiempo todas dificultades y la comunicación va mejorando.
  • El número de incidencias va descenciendo.
  • Se están haciendo más commits y más pushes (nos acercamos a la media de 3 commits por hora).
  • Se hace pair programming cuando es productivo y se programa por individual cuando la pareja se da cuenta que no se está aprovechando bien.
Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.