Por la mañana, después de una taza de café, tenemos la llamada reunión diaria de pie. Cada uno de nosotros cuenta su historia: "Ayer completé esta herramienta, así que siéntanse libres de usarla", "Hice algunos cambios en el pipeline de CI, debería funcionar más rápido, pero si experimentan problemas pónganse en contacto conmigo", "Tuve una reunión con un cliente, así que realmente necesitamos cumplir con la fecha límite esta vez, pero podemos posponer una implementación de la característica X hasta el otoño", "Estoy bloqueado debido a... Por lo tanto estoy haciendo Y en lugar de Z". Así, cualquiera es responsable de dar a conocer el estado de su trabajo a los compañeros de equipo (no sólo a la dirección). En realidad, el stand-up diario no es la única manera de hacerlo, pero a veces funciona.
Mi compañero de equipo terminó una tarea la noche anterior, y me invitan a hacer una revisión para el pull request. Ejecuto el código y - ooops - se lanza una NullReferenceException. Parece que el desarrollador no probó el código a fondo, y se perdió algunos casos de borde. Escribo un comentario con mis conclusiones para que el desarrollador pueda corregir el error y añadir las pruebas unitarias/de integración que faltan. Hacer revisiones por pares, probar nuestro propio código y hacer todo lo posible para hacer un producto de buena calidad también es parte de nuestras responsabilidades.
Luego hay una larga y aburrida reunión de todos con muchos números. Las reuniones apestan.
Después del all-hands hay una buena oportunidad para trabajar en el diseño de una nueva característica y finalmente hacer algo de codificación. En realidad esta es la parte favorita del trabajo.
Entonces un ingeniero de automatización de pruebas viene a discutir las posibles opciones para probar un nuevo conjunto de características. Trabajamos juntos en el concepto que permite que las pruebas sean menos frágiles y vemos cómo los desarrolladores pueden ayudar al equipo de automatización de pruebas. La interacción entre los diferentes equipos también forma parte de las responsabilidades.
Entonces tenemos que discutir los nuevos requisitos con el propietario del producto. La nueva característica sexy puede comprometer la seguridad del sistema, y probablemente no es lo que los clientes realmente necesitan. Tratar de averiguar los requisitos reales es parte de nuestro trabajo, y no el más fácil. Y después tenemos un pequeño póker de planificación para estimar un par de tareas en el backlog que probablemente se tomarán para la próxima primavera. ¿Quién sino los desarrolladores pueden estimar los esfuerzos? (Honestamente, los desarrolladores apestan en las estimaciones, pregunte a cualquier director de proyecto)
El día está casi terminado, tengo algo de tiempo para aprender la tecnología que vamos a utilizar pronto, y para finalizar la tarea de codificación de hoy. Oh no, todos los build pipelines están en rojo. Revisando los logs veo que las versiones de los artefactos están totalmente desordenadas. Ese nuevo sistema casero de versionado automático que utilizamos ha resultado ser una eterna fuente de frustración. Tenemos que reunirnos de nuevo para discutir qué vamos a hacer con él (aplicar un nuevo fix probablemente y esperar un mes hasta que vuelva a romper nuestros pipelines).
Básicamente, esto es lo que hacemos. Ok, ok, voy a ser honesto. Esto es lo que nuestro jefe de proyecto cree que hacemos. Lo que hay en la realidad puede ser otra historia a contar en otra ocasión.