Del valor de la comunicación en el desarrollo de software
[ visto aquà ]
On numerous occasions, I have spent time reading hundreds if not thousands of pages of requirements specs, prepared over the course of several months, which don’t define any sort of useable product. I had product backlogs with tens and hundreds of user stories, all properly prioritized and thought over. Yet – this backlog didn’t last more than a couple of months before the original ordering and feature list fell apart and became irrelevant.
And you know what? This is normal, expected and you should be prepared for it every single time you sit down to start a new project.
Conversations with my daughter before preparing breakfast in the morning, usually goes somewhat like this: “What do you want for breakfast honey?” “Well, I would like scrambled eggs. No, make it boiled. No, make it an omlette. You now what dad? I will have whatever you get me, just make it yummy”. This is the key point – “make it yummy”. Make it awesome, make them love it and make them come back to you for more good stuff.
How do you “make it awesome” then? Well, this is where it is important to remember that software development is an act of creation rather than manufacturing. You have to become a bit of an artist to make great software. Good taste and critical eye are important. User stories are not everything, they don’t give you the full picture – despite the name, they don’t tell “the whole story”.
(…)
Being profficient in communication is much more important than being a guru programmer, master-level Java-wrangler whose neurons run on CRL and who has written his first Lisp program at the young age of 6. More important even than having Six-Sigma Black-Belt, CMMI 10 Certified ScrumTrainer certifications.
11 comments
Realmente bueno… gran consejo, “cuento a aplicarse” o reflexión.
¡Make it yummy!
Totalmente de acuerdo. Dentro del mundo de la programación, la mayorÃa de errores son por falta de comunicación, incluso entre compañeros de la misma empresa, que hay muchos que no saben expresarse…
@Deepbane: making life yummy… such a hard task…
@Nesta: en mi opinión lo que falta son reuniones de grupos de trabajo, control y monitorización de objetivos de cada uno, repositorios de documentación comunes, etc… pero cada empresa y cada proyecto es un mundo.
Not a task, but a way of life. Es cuestión de querer… y de creer 😉
@banyuken muchas veces tanta reunion es una perdida de tiempo
Y muchas otras como se pierde tiempo es dejando a la gente a su libre albedrÃo, sin pedir cuentas, o sin compartir el conocimiento y los avances del dÃa a dÃa con el resto del equipo.
Como ya digo, cada empresa y cada proyecto es un mundo, pero lo que sà tengo claro es que poner unos objetivos y sentarse a programar como autómatas hasta dentro de quince dÃas es un buen comienzo para obtener un producto con un mantenimiento retorcido y tedioso donde los haya, en el mejor de los casos.
No por no hacer reuniones se deja de compartir conocimiento. Pero ese tipo de práctica, que ahora no recuerdo el nombre técnico, creo que son un sinsetido. La dos primeras reuniones de “intercambio” de conocimientos pueden ser fructiferas, al final se acaban convirtiendo en horas perdidas escuchando o explicando por qué pusiste un for y no un while, por poner un ejemplo.
Tal vez la experiencia que he tenido no haya sido positiva, pero creo que una reunión en el reparto de tareas es más que suficiente.
PD. Me gustan este tipo de debates jeje
Saludos!
Repito: depende del proyecto, el número de personas implicadas, y mil factores más. Pero para eso están los jefes de proyecto, para coordinarlos y regular que su interacción sea lo más exitosa posible. Escuchará a todos y hará que se hablen entre ellos, lo justo y necesario.
Por seguir un poco con el tema, la metodologÃa esta es la extreme programming?
Un saludo 🙂
No está hablando de ninguna metodologÃa concreta, está tratando un problema general del desarrollo software.
En el blog del que proviene se defienden las prácticas de desarrollo ágil.
No hablan de ninguna en concreta pero defienden el desarrollo ágil, en su caso, el extreme programming…
Tsss no sé, si en el desarrollo de software todo fuera maravillosamente perfecto tal vez le encontrarÃa algo de sentido, pero fuera de los toboganes y pizarras de Google Zurich acaba siendo inutil, al menos desde mi punto de vista.
Por curiosidad, ¿usáis esta metodologÃa en tu equipo de desarrollo?
Saludos y no seas tan serio que pareces enfadao! 😉