The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
–Principles behind the Agile Manifesto
(Es lo que dice el manifiesto ágil, nos mole más o menos, es lo que ahí pone…)
Gran, amplia, mayoritaria parte, de lo que hoy entendemos «por ágil» viene esencialmente de dos modelos de trabajo: Scrum y eXtreme Programming. Hay muchos más modelos de trabajo «ágiles» pre-manifiesto, pero, sin duda, estos dos son los que más influencia han tenido hasta día de hoy.
Si quieres de verdad profundizar y tener un pensamiento formado de qué es lo que pretende, pretendía, pretendió, al aparecer el concepto ágil en el mundo del software, adoptado luego por otras áreas (pero que apareció en software), tienes que entender y estudiar Scrum y eXtreme Programming.
Sí, también podrías interiorizar el manifiesto, sus valores, sus principios y otras no sé cuantas cosas más, pero no puedes dejarte Scrum y eXtreme Programming. De hecho ambos modelos de trabajo son previos al manifiesto y en él hay, obviamente, mucha esencia de ellos.
De hecho, aunque Scrum hoy es más popular creo que eXtreme Programming debiera darte más trabajo a la hora de estudiar. Quizá por que tuvo una muy fuerte comunidad, te va a llevar a más áreas, no sé, pero hay mucha idea profunda a interiorizar.
Dejando por ahora Scrum a un lado, si interiorizás eXtreme Programming (XP) entenderás mucho de lo que la agilidad busca, y entenderás mucho por qué mucha gente de peso en el mundo ágil gente es crítica con ciertos nuevos modelos de trabajo (¿escalado?) bajo el paraguas ágil y que muchos no consideran ágiles.
Jez Humble, autor del libro Continuous Delivery decía, lo dijo públicamente cuando este verano estuve en Orlando, que mucho de la inspiración de su trabajo vino de XP (más sobre Continuous Delivery y unos apuntes gráficos). Y podríamos elaborar una larga lista de «cosas ágiles», populares hoy, cuyo origen es XP (o que XP las popularizó): las historias de usuario de hoy vienen de XP, XP popularizó la Integración Continua, el Testing automatizado, etc.
Y de todas esas aportaciones de XP, quería hoy quedarme con una: XP fue diseñado para la comunicación cara a cara por encima de la comunicación vía documentos (no lo digo yo, lo dice uno de los creadores). Supongo que mucho de lo anterior influenció la creación del principio del manifiesto ágil con el que empecé el post.
La comunicación cara a cara es la mejor manera de comunicarse, la más efectiva y eficiente. Que la separación física impida, o ponga difícil, la comunicación cara cara, no hace que esto cambie. Y si no hay separación física menos justificación hay para sustituir comunicación cara a cara por comunicación vía documentos (o mails, o tickets de jira, o páginas Confluence, etc.)
Te dejo algunas ideas en unos dibujos súper rápidos
La comunicación cara a cara es base de la agilidad, es cómo se diseñó XP, es un principio del manifiesto ágil, autores del manifiesto ágil han escrito sobre ello, debemos saber que, aunque no pueda evitarse, la separación física, que merma la interacción cara a cara, impacta en el rendimiento, etc.
En XP la comunicación verbal y los test automatizados reducían la necesidad de documentar requisitos. Eso sin que hubiera una negación tajante a documentar, pero sí con un claro orden de prioridades: más hablar y menos escribir.
Si quieres leer más sobre esto, este post puedes complementarlo con aquello de cuidado con «escribir HU» .
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Es cierto que como el cara a cara no hay nada, pero creo que decir que el 100% de las veces es mejor hablar que cualquier otro medio, es generalizar demasiado.
Hay un factor en contra de hablar cara a cara, hay que coincidir en la disponibilidad de todas las partes implicadas A LA VEZ!. Y esto puede implicar: interrumpir situaciones de flujo del programador, hacer perder tiempo a posibles interlocutores, caer en el vicio de la reunionitis,…
¿Estamos diciendo que cuando hay una incidencia nos la tienen que comunicar hablando y no puede comunicarse por escrito (un mail, un slack, un JIRA, …)?
Yo concluiria con ¨Escribir después de hablar¨. Una vez que hemos discutido y decidido algo, debemos escribir nuestras decisiones. No tiene porque ser un gran parrafo, puede ser una foto con un diagrama y un par de frases.