En un principio pensé que tendría yo algo que enseñar al equipo al cual me estaba integrando. Si bien, hemos tenido algunas pláticas por demás interesantes sobre algunas cuestiones de diseño, TDD, etc., de primera instancia este último par de meses han sido una incesante carrera por entender el negocio. No digo que no hay nada que mejorar –siempre hay algo– si no que en el punto donde se encuentra el equipo actualmente, son muy buenos en lo que hacen:
- Han integrado elementos a su proceso de desarrollo de aquí y de allá como apoyo al quehacer del día a día, sin seguir necesariamente una metodología fija.
- Cuando sucede un incidente que afecta al equipo, al negocio o a la capacidad del equipo de entregar valor, se dedica el tiempo necesario para entenderlo y tomar medidas para que no vuelva a pasar (o por lo menos que no nos vuelva a tomar desprevenidos).
- Tienen los problemas habituales cualquier equipo trabajando con código legacy, especialmente cuando se trata de desarrollar funcionalidad nueva sin caer en los mismos antipatrones anteriores… y a veces no lo logramos.
- Mientras que algunos jamás escriben una sola prueba unitaria (que en
ocasiones resulta prácticamente imposible por las características del
código), otros intentan hacer pruebas por lo menos para cada nueva característica y algunos incluso intentan hacer pruebas para el código legacy antes de intentar cambiarlo.
Pero nuevamente, a pesar de las limitaciones, existe una ventaja fundamental: el equipo sabe en dónde está la mayor parte de la deuda técnica y aprovecha cualquier oportunidad para reducirla. - Técnicamente es un equipo sólido, pero no hay rock stars. Y creo seriamente que la forma de trabajo del mismo de hecho previene el surgimiento de dichos personajes. Simplemente no son necesarios.
Pero quizás la característica más notable del equipo es su capacidad de comunicación (por supuesto, incluyendo a “producto”, pues todos somos un solo equipo). Algunos mientras que miembros del equipo se integran en sesiones impromptu de pair programming, otros trabajan la mayor parte del tiempo de esta forma, e incluso otros casi siempre trabajan solos. Pero sin importar cual sea su configuración favorita para trabajar, la mayor parte del tiempo todo el equipo sabe lo que están haciendo los demás, por qué e inclusive cómo. Nada pasa desapercibido. Ni una falla, ni un éxito. Todos están prestos a ofrecer ayuda cuando se necesita.
Me atrevo a opinar que esta es la característica que hace de este equipo un equipo efectivo, cohesivo y valioso para el negocio. Y es sin duda, el aspecto que debo aprender y dominar antes siquiera de hablar siquiera por primera vez de asuntos técnicos.
Así que no, lo que hacemos no es Scrum, ni Kanban, ni FDD, ni mucho menos XP. Solo hacemos agile y nada más.
