El término Mongolian Horde proviene de
las hordas mongolas de Genghis Khan y sus hijos que conquistaron gran parte de Asia y Europa durante los siglos 13 y 14. La estrategia que seguían en sus combates era lanzar miles y miles de soldados contra sus enemigos sobrepasándolos en número y consiguiendo victorias sencillas.
Mongolian Horde es un término que se utiliza en la actualidad en el mundo de los negocios al tratar de resolver un problema a base de asignar más y más personas a la resolución del mismo, pensando (muchas veces inocentemente) que el disponer de más personas asignadas a una tarea hará que ésta llegue satisfactoriamente a su fin. En el mundo del software este término toma relevancia especial por lo habitual que han llegado a ser este tipo de situaciones. George Stepanek lo explica muy bien
en su libro "
Why software projects fail":
A naive project manager who saw developers as equivalent to each other would be tempted to use the so-called "Mongolian Horde" approach, which uses a large number of cheap and inexperienced developers. Just as with the original Horde, the end result is chaos. Even allowing for their limited design and programming skills, the developers just don't have the experience to organize and deliver a system of this scale.
Some developers can even bring negative productivity to a team. They may not understand the sophistication of the team's code, and will introduce bugs that require lots of rework. They may demand so much help that their own work fails to compensate for the lost productivity of the other team members...
En uno de los últimos proyectos en los que he trabajado me encontré con algo muy similar, pero en un campo en el que nunca lo había experimentado, que es el del testing de programas. Tener testers no es algo demasiado habitual en España, salvo en grandes empresas, mientras que en Irlanda era el pan nuestro de cada día. En todos los proyectos en los que participé había un departamento separado de pruebas. No sólo eso, los testers no tenían idea de programación, ni siquiera eran informáticos. La idea es en este caso tener personas con experiencia en el negocio que aunque no esan informáticos sepan realmente como debe funcionar la aplicación, y no tenga ideas preconcebidas sobre desarrollo de software sino que se comporten como meros usuarios. No es mala idea, pero eso es otro tema.
El caso es que en uno de estos proyectos estaban unos ocho testers. Pero había un problema, nuestro software, que básicamente era una conversión entre formatos de ficheros para entornos bancarios, tenía miles y miles de posibles entradas y salidas. El equipo de testers era muy tradicional, y su lider se negaba a recibir cualquier tipo de ayuda de automatización. Esto hacía que cada vez que lanzábamos una release, que era tras tres semanas porque en desarrollo seguíamos el dictamen Agile, tenían que probar todas esas combinaciones manualmente. Algo totalmente imposible. Nunca llegaban al 20% de pruebas, así que poco a poco el producto iba ganando más y más bugs lo que nos afectaba a desarrollo.
La solución ideada por los managers fue crear una
Horda de testers. Contrataron más personas e incluso una agencia externa de testing. Llegó a haber un equipo de 38 testers!!! ¿Os lo podéis imaginar en una empresa que no llega a los 100 empleados? Ni que decir tiene que la iniciativa fue un fracaso. Ellos mismos se dieron cuenta de que tener más testers no significa probar más y mejor la aplicación. De hecho el número de errores aumentó y el número de pruebas realizada disminuyó. Era simplemente demasiado complejo el controlar y formar a tanta gente en tan poco tiempo como necesitaban.
¿Cuál fue la solución? En este caso el marrón me tocó a mi, pero desde desarrollo conseguimos convencerlos de que la única opción es que nos dejasen proporcionarles herramientas para automatizar su trabajo. Lo que hicimos fue separar un grupo de swats (desarrolladores kamikaze jejeje) que creamos un sistema para que ellos pudiesen diseñar tests automatizables. Muy simple y en lenguaje natural. De modo que ellos definian los tests y por detrás nosotros lanzábamos sin que se diesen cuenta acciones de HTMLUnit que iban probrando las páginas webs. Imaginaros, un test podría ser:
- upload /tmp/Test1.xml
- Login:username=martin,password=martin
- click "Results"
- assertExists "Upload Test1.xml successful"
- Validate /results/Test1.xml
Esto es algo totalmente inventado, el lenguaje era incluso más sencillo que esto. Pero os da una idea. Además, los testers podían reutilizar los tests, para crear sus propias cadenas de tests más complejos. En un principio recibieron la herramienta con escepticismo. Ya sabeis, "Aquí vienen estos con más trabajo con lo ocupados que estamos". Pero en cuanto vieron que ahora podían repetir los tests cuando quisieran, que no tenían que andar continuamente haciendo el mismo setup manual, y que un test que les llevaba media hora hacerlo pasaba a llevarles un minuto, la historia cambio. En unas pocas semanas tenían automatizado el 30% del trabajo, mucho más de lo que habían conseguido nunca. Y lo más importante para nosotros, los desarrolladores, al incluir los tests en la build, teníamos garantía de que todo funcionaba.
No sé si alguno de vosotros habéis vivido una experiencia similar, pero os animo a compartirla. Espero que os haya interesado mi historieta.
Hace casi un año, Chad Dickerson dio una charla en la RailsConf 2011 que vale la pena leer. Se trata de una presentación de poco más de 20 minutos donde el que es el CEO de Etsy explica las claves para conseguir un equipo de desarrollo feliz. 
