Capítulo 11: Collective Code Ownership
Capítulo 11: Collective Code Ownership
Miércoles de la segunda semana. Elena necesita cambiar algo en el backend. Diego necesita cambiar algo en el frontend. Ninguno de los dos escribió originalmente ese código. En muchos equipos esto sería un problema de territorio. En XP, es lo normal.
Anterior: Refactoring y Courage | Siguiente: El cliente cambia de opinión
Elena toca el backend
Elena está trabajando en la story de asignar personas a tarjetas. Necesita que la API devuelva información sobre quién está asignado a cada tarjeta. El endpoint existe pero no incluye ese dato.
Elena (Dev): “Necesito modificar el endpoint que Diego escribió la semana pasada. ¿Le pido permiso?”
Carlos (TL): “No. En XP no hay permisos. El código es del equipo, no de la persona que lo escribió. Si necesitas cambiar algo, lo cambias. Los tests te dirán si rompiste algo.”
Elena (Dev): “Pero Diego conoce ese código mejor que yo.”
Carlos (TL): “Hoy. Después de que lo modifiques, lo conocerás tú también. Eso es Collective Code Ownership: todos conocen todo, todos pueden modificar todo.”
Elena abre el archivo. Los nombres siguen la metáfora del sistema. Los tests describen el comportamiento. Puede entender qué hace cada parte sin preguntarle a Diego.
Elena (Dev): “Ok. Los tests me dicen qué se espera. Voy a agregar el campo de persona asignada al response y escribir un test nuevo para eso.”
Elena escribe el test. Rojo. Modifica la API. Verde. Empuja. CI verde.
Diego toca el frontend
Mientras tanto, Diego necesita agregar un selector de persona en la pantalla de tarjetas. Esa pantalla la construyó Elena.
Diego (Dev): “Elena, voy a tocar la pantalla de tarjetas.”
Elena (Dev): “Adelante. Si tienes dudas sobre cómo organicé los componentes, pregunta.”
Diego (Dev): “¿Cómo sé dónde agregar el selector?”
Elena (Dev): “Mira la estructura. Cada componente tiene una sola responsabilidad. La tarjeta muestra datos. Si necesitas agregar algo a la tarjeta, ahí es donde va.”
Diego navega el código del frontend. Tarda un poco más de lo que tardaría Elena, pero lo entiende. Agrega el selector de personas y escribe un test para verificar que aparece.
El conflicto
A media mañana, Diego descubre que Elena hizo un cambio en la API que no esperaba.
Diego (Dev): “Elena, cambiaste la estructura de respuesta de la API. Mi frontend espera un formato diferente.”
Elena (Dev): “Necesitaba agregar el campo de persona. Era la forma más limpia.”
Diego (Dev): “Pero ahora tengo que cambiar cómo el frontend lee los datos. No me avisaste.”
Elena (Dev): “No sabía que te afectaba. Lo siento.”
Hay un momento de tensión. Diego está frustrado porque tiene que rehacer parte de su trabajo. Elena se siente mal por no haber comunicado el cambio.
Carlos interviene.
Carlos (TL): “Paren. Esto es exactamente el tipo de situación donde los valores de XP nos salvan. Communication: Elena debió comunicar el cambio antes de hacerlo. Respect: Diego, Elena no lo hizo a propósito. El código es de los dos.”
Diego (Dev): “Lo sé. No estoy enojado con Elena. Estoy frustrado con la situación.”
Carlos (TL): “Perfecto. La frustración con la situación se resuelve. Resuélvanlo juntos.”
Resolución en pair
Diego y Elena se sientan juntos. En diez minutos acuerdan la estructura de datos que funciona para ambos. Elena ajusta la API, Diego ajusta el frontend. Corren todos los tests. Verde.
Elena (Dev): “Deberíamos haber hecho esto juntos desde el principio.”
Diego (Dev): “Tienes razón. La próxima vez que toque algo compartido, aviso antes.”
Carlos (TL): “O mejor: hagan pair cuando el cambio toca la frontera entre backend y frontend. Es justo ahí donde los conflictos nacen.”
Lo que aprendieron
Al final del día, el equipo reflexiona brevemente.
Diego (Dev): “Fue incómodo, pero resolvimos un conflicto real en diez minutos. En mi equipo anterior, eso habría sido un ticket de Jira, tres reuniones y una semana.”
Elena (Dev): “Aprendí que Collective Code Ownership no significa ‘cambia lo que quieras sin decir nada’. Significa ‘puedes cambiar lo que sea necesario, pero comunícalo’.”
Carlos (TL): “Kent Beck dice que la propiedad colectiva del código requiere que existan coding standards y tests. Sin convenciones, el caos. Sin tests, el miedo. Con ambos, la libertad.”
Ana (PO): “Desde fuera, lo que vi fue un equipo que tuvo un problema a las 10 y lo resolvió a las 10:15. Eso es impresionante.”
Práctica XP del capítulo
Collective Code Ownership: En XP, cualquier persona del equipo puede modificar cualquier parte del código. No hay “mi código” ni “tu código”. Kent Beck argumenta que esto distribuye el conocimiento, elimina cuellos de botella y aumenta la resiliencia del equipo. Si solo una persona conoce el backend y se enferma, el proyecto se detiene. Si todos conocen todo, el equipo sigue funcionando. La propiedad colectiva funciona gracias a dos pilares: coding standards (todos escriben igual) y tests (cambiar es seguro).
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Observa la resolución rápida del conflicto |
| Carlos | Media en el conflicto, enseña propiedad colectiva |
| Diego | Modifica frontend de Elena, expresa frustración con respeto |
| Elena | Modifica backend de Diego, acepta responsabilidad por no comunicar |
Anterior: Refactoring y Courage | Siguiente: El cliente cambia de opinión