[#ALM] SCRUM no implica que tengas que hacer TDD (lo se, titulo amarillista)

Hola!

Hace unos años el comienzo de este post sería una frase del estilo

El mundo del desarrollo de software no termina de sorprenderme…

Sin embargo, cada vez más me estoy dando cuenta de que

Intentar mejorar la forma de trabajo de un equipo es lo importante

Y todo esto porqué? Pues hace unos días, tuve una especie de discusión en twitter donde afirmé que TDD no es necesario para el desarrollo del software. Ya lo sé, bomba incendiaria; como en el thread estaban personajes del calibre de @elbruno @jc_quijano @ialcazar @juanmagomer @lfraile @r_corral; decidí bajar el nivel con mis aportaciones y terminar con el post de Rodrigo que me abrió la cabeza hace casi 9 años “la calidad no es opcional”.

@elbruno @ialcazar @jc_quijano @lfraile eso da para unas buenas cervezas 😀

— Juanma Gómez (@JuanmaGomeR) marzo 28, 2014

@jc_quijano @ialcazar @juanmagomer @lfraile y en nada se cumplen 9 años del post de Rodrigo http://t.co/hYVI5JiJW7 @r_corral

— Bruno Capuano (@elbruno) marzo 28, 2014

 

Aunque claro, quedó abierta la cuestión de porqué yo dije que no había que hacer TDD. Personalmente no tengo ni una pizca de honor y mi palabra vale menos que una licencia de Windows Vista, suelo dejar mis puntos de vista en el blog y aquí va el mio.

SCRUM es genial, no? en eso estamos todos de acuerdo. Cuando comienzas a creer en SCRUM te das cuenta de que es un marco empírico; todo se basa en aprender de la experiencia. A partir de allí es necesaria la confianza en el equipo, eso implica transparencia y cuando tienes estos 2 pilares apuntalados; ya puedes comenzar con la inspección y luego la adaptación basada en lo que has aprendido de la experiencia.

Yo hace poco tiempo estuve hablando de sobre como mejorar la forma de trabajo de un equipo de Marketing; y luego de conocer el contexto y sugerir SCRUM como un marco para que puedan organizar su trabajo; me dió mucha satisfacción ver que este grupo de personas comenzaro a desarrollar su propio esquema de trabajo. Eso sí, se respetaban los roles y artefactos de SCRUM, y a partir de la experiencia y del conocimiento compartido de todo el grupo, el mismo comenzó a autogestionarse para llegar a un objetivo común.

Esta es la experiencia que pensaba compartir para poner un brutal y asertivo

DONDE HAY TDD EN UN EQUIPO DE MARKETING? EHHHH DONDE?

Así todo en mayúsculas y con una arrogancia superior a la del Doctor House. Pero como siempre la realidad me puso en mi sitio poco después.

Esta semana mientras unos tenían la suerte de estar en el BUILD, yo me fuí a aprender sobre el mundo de Health y a comentar sobre como algunos aspectos de mobilidad e innovación van a cambiar la forma en la que se trabaja en el mundo de la salud en pocos años.

Y en ese contexto, hablando con una persona responsible de un hospital, me deja caer la siguiente frase: “Nosotros tenemos los mejores profesionales del mundo, y tal vez las mejores herramientas para los mismos. Deberíamos ser un equipo 100% efectivo y sin embargo la mayoría de los errores que tenemos son ocasionados por personas”.

Cuantas veces escuchamos esto ? muchísimas y en el mundo del desarrollo del software lo que hacemos es  … TDD !!! (bueno es una opción, la otra es no cagarla y punto). Como esta persona era muy receptiva y con un perfil muy abierto, le comenté sobre las bases sobre las que se soporta TDD. En poco tiempo, esta persona llevó los conceptos de TDD al día a día de trabajo de un hospital.

Nota: Sabías que los primeros que usaron un enfoque de Test before, fue la NASA en los 50 y 60, para asegurar que los materiales que recibían de fabricantes externos cumplían con las normas que ellos definían?

Me quedé asombrado !!! Y me dí cuenta que inclusive SCRUM nace de un concepto que no tiene nada que ver con el desarrollo de software, viene de la formación en RUGBY, donde una parte del equipo hace fuerza y apunta a una misma dirección.

Así que, después de darle vuelta al asunto, creo que tal vez el título del post debería ser algo como

SCRUM no implica que hagas TDD; implica que un equipo defina la mejor forma de trabajar.

Seguramente en el desarrollo de software, esto implicará TDD; en otras disciplinas … pues ve tu a saber.

PD: Si alguno no se había dado cuenta, la palabra TEAM es una de las más importantes en Team Foundation Server, no ?

Saludos @ Home

El Bruno

Google