Vida de Programador I - Como explicar agiles a los Gerentes

El problema es justamente ese: Como explicamos lo que hacemos al Gran-Jefe-Quiero-Que-Cumplan-con-La-Fecha?.

Estas un día tranquilo en tu cubículo, esperando mientras la máquina cachaza que te dieron arranque y levante el IDE superperfomante gratuito que te bajaste por izquierda, cuando recibís la siguiente llamada:

"Juancito, te llama el Gran-Jefe-Quiero-Que-Cumplan-con-La-Fecha, que quiere hablar con vos, pasa a su oficina."

Con una cierta inquietud en tus entrañas te vas para la oficina como quien camina sobre piedras descalzo. Te vas pensando de que vendrá el tema, si tu cv está actualizado en Linkedin o si te sera posible pagar la siguiente cuota del televisor LCD sin trabajo. En síntesis, vida del programador que le dicen.

"Pero Si, hombre, como andas?, pasa pasa, siéntate en esa silla", dice, señalandote una sillita de juguete, bajita, mientras se apoya en el Gran-sillón-De-Cuero-2-metros-de-Alto, para preguntarte:

"Hombre, que te he llamao porque un Gerente amigo, cuando estaba jugando al Golf, me ha hablado de no se que rollo de unas metodologías ágiles, escram(sic) o cosillas por el estilo, no se bien. Creo que hablaba de algo así como focalizarse en la entrega al usuario, en lo que quiere, que el cambio es un rollo normal y no recuerdo pero algo sobre la importancia de las personas por sobre no se que coño."

"Punto numero 1:", pensas, "Este cabron no sabe ni como me llamo". "Punto numero 2: Dios no existe, mierda."

"En sintesis, joder, que me gustaría que me explicaras este follón, porque me ha picao el bichito de la curiosidad, no sea que puedo salir en la gran magasine "MANAGEMENTO" y me estoy perdiendo una oportunidad de la Ostia!!."

"Es definitivo", seguis pensando mientras lo miras con cara de sesudo, "Si, Dios existe pero es un sádico o bien, en la reencarnación anterior debo haber sido muy mala persona....".

Pero bueno... repitiendote pavadas como "en la cancha se ven los pingos" (hmm pero no soy caballo ni galgo)... o "los cobardes no hacen historia" (pero todos murieron de viejo)... te pones a pensar como explicarle al Gran-Jefe-plin plin plin, lo que te pide....

Como explicar que la calidad si importa. Que no hacerlo bien es justamente no llegar a tiempo porque los intereses de la deuda tecnica te comerán vivo como si tu acreedor fuera la mafia misma (bah o algún banco...) .

Piensa piensa piensa...

Del PMI y Waterfall a Scrum

La diferencia fundamental que uno ve al pasar de trabajar de la manera tradicional PMI-Waterfallistica a Scrum es que uno se va chequeando durante el proyecto que esta construyendo lo que el usuario quiere.

El gran problema con la manera "tradicional" es que la forma en que plantea encarar los proyectos es, engañosamente, muy razonable y atractiva: Hagamos un proyecto dividiéndolo en etapas bien marcadas adonde en cada etapa nos aseguramos de hacer bien una y solo una tarea. Hagamoslo en cascada de manera que la actividad de la etapa siguiente se apoye en lo que se hizo en la etapa anterior, como construir un puente, que joder, relevamos, armamos una maqueta, los planos y a construir, todo muy ingenieril, si, si. Pero si hasta parece una receta, un poquito de harina por acá, levadura por allá, 10 minutitos de horno y Voila! la Torta del proyecto esta cocinada, no? No.

Comienzo de un proyecto a-la-tradicional

Es la primera etapa, Gran Relevamiento, el primer paso de la Receta Torta-A-la-Waterfall: Tomémonos todito TOODO el tiempo necesario para entender lo que quiere el usuario, hagamos casos de usos, diagramas de realización, armamos minutas de reunion de todo lo que se hablo en infinidad de reuniones con los usuarios, hagamos prototipos, maquetas, y documentemos en un gran Documento de documentación (valga la redundancia) hasta el más mínimo detalle de lo que el usuario quiere, no sea cosa que después nos pida algo que no mencionó antes. Y si se olvidó de algo...., jah! al banquillo de los acusados!

Tipica reunion de Relevamiento

El funcional, canchero, pregunta:
"Che, A ver, es esta pantalla, en el menu 48, item 256, fijate en el caso de USO de UML2, en Rational: Agregando informacion a la solicitud XRF-3456, te parece que si queres especificar la lista de boxitracios te pongamos un listbox sincronizado con este checkbox o lo hacemos igual que la lista de parafernoles que te mostramos en la maqueta del caso de Uso UJ323 hace 8 días? ".

El usuario nos mira con una sonrisa tímida y balbucea alguna respuesta al azar mientras piensa:
"Merda!, que catzo estará diciendo este tipo por dios?! porque no pueden hablar en castellano?. No voy a decir que "si" ni en pedo, no se a que me estoy comprometiendo."

Despues de eso deberias explicarle al Gran-Jefe-Quiero-Que-Cumplan-con-La-Fecha:

Que ventaja tenemos si usamos Scrum o alguna otra metodología ágil?

El beneficio mas importante de aplicar una metodología ágil en un proyecto es que nos permite instalar dentro del grupo una forma de trabajar en la cual es mucho mas probable que logremos entender y desarrollar el sistema que el usuario realmente necesita. El secreto es simple: Feedback Feedback y mas Feedback.
Feedback constante durante muchas iteraciones para mostrarle una y otra vez lo que entendimos que el usuario pidió y corregir una y otra vez el rumbo en base a su revisión.

Agiles es más que feedback constante y un proceso de mejora iterativa

Claro, el tema es que vamos a pemitir que el usuario en cada iteración nos diga en que difiere lo que hicimos de lo que ahora ve que El necesita. Notar el "ahora", porque es justamente cuando lo ve funcionando que se da cuenta que lo que pidio no es exactamente lo que necesita. O bien, se da cuenta que puede accederlo de alguna manera distinta o entiende lo que le dijimos cuando le deciamos que probablemente la pantalla se vea un poco...saturada de informacion, es decir, confusa.

Y, como vamos a permitir eso; perdón, no solo a permitirlo, como vamos a alentar para que lo hagan, TENEMOS QUE poder cambiar el software, cambiarlo a veces de una manera radical, rapida . Cambiarlo, generalmente, de una forma no prevista en el momento de hacerlo.

Por eso, para que esto sea posible, en un tiempo razonable y que no genere un código fuente inmantenible es que se necesita desarrollar código de calidad.Y para ello se necesitan buenas prácticas de desarrollo.

Cuales? y bueno, por lo menos una malla de seguridad de tests de unidad con un cubrimiento alto del código del proyecto, si es posible hacer TDD, aplicar refactoring constantemente para mantener la calidad y no generar deuda técnica, integración continua, aplicar diseño incremental y evolutivo, técnicas de programación de a pares, Tests de aceptación....etc...

Con tu metabolismo acelerado pensastes todo esto en una fracción de un segundo. Tu jefe, el Gran-Jefe-plin plin plin esta esperando la respuesta, repechado en su Gran-Sillon, te mira desde las alturas y ya se impacienta.

Pensas todo lo que tenes que decirle, pensas en lo difícil que es que lo entienda porque no sabe del tema ni por lejos, de como inventar metáforas simples y futboleras, de lo peligroso que lo malinterprete, sopesas pros y contras, hasta que llegas a la única conclusión lógica posible...

"Pues entonces Juancito? "

"Entonces nada Gran Jefe, son unas metodologias de desarrollo poco serias, chorradas no importantes para un gran Jefe como usted, el camino mas serio e importante es seguir el pinbuk del Gran Libro del Management, PMI, el curso que hizo usted durante 2 años, jefe, ese que le salio lo que yo gano en 5 años. "

"Pero, estas seguro ? mi amigo parecía al tanto de que esto era poco menos que un filón de oro."

"Seguro, Jefe, fijese que tiene nombres raros como Scrum, Extreme Programming, tests de unidad, diseño emergente, metaforas, People over Process" y cosas así, suenan poco serio, no?

En lontananza se escucha el canto de un gallo...

Liderazgo (I)

Hace tiempo, más tiempo del que me gustaría, en uno de mis primeros trabajos, se me acercó mi jefe de ese momento y sin más preambulo que una aclaración de garganta, en un tono seco y muy cortante me informó:

"La empresa necesita destruir unos papeles. Te vas mañana por la mañana a una planta de desechos en Loma-del-Ortis."
Y se dio la vuelta para Irse. Mi respuesta fue casi automática, visceral e inmediata:
"No", le dije.
La espalda se detuvo, y juro que percibí como se contracturaba todo antes de volverse con cara de pocos, poquísimos amigos:
"Como? que no vas a ir?"
"No, porque no me pagan para eso, soy programador."

La discusión que siguió fue bastante fea, con acusaciones de "Sos un principista", "no estas alineado con la empresa", etc.

La discusión fue doblemente fea porque podría haberse evitado totalmente. Que les parece que hubieran contestado si lo planteaba de la siguiente manera:

"La empresa tiene que mandar a destruir unos papeles. El que quiera ir tiene que levantarse un poco mas temprano, lo pasan a buscar en remise, el desayuno lo paga la empresa y a las 15 horas esta libre y se puede tomar el resto del dia libre. Quien quiere ir?" Porque realmente esas eran las condiciones.

Hace poco Martin Alaimo preguntó en la lista de foros-agiles que rol de Scrum era mejor para "reciclar" a un PM de la escuela PMI-stica, si era mejor que se transformara en un Product Owner (PO) o en un Scrum Master (SM).

Mas allá de la parte metodológica de la discusión que siguió: que en general se los asocia mas como Scrum Master, que los Analistas Funcional hacen mejor de PO, incluso mejor que los propios clientes , que depende del PM, que mejor continua fuera de Scrum llenando planillas o projects, etc., mas allá de todo esto, decia, de manera subyacente se estaba discutiendo el tema del Liderazgo y de que características deben tener un buen líder para ser efectivo (tanto si se hablaba del rol como PO, SM u otro).

Pueden ver la discusion original aqui, pero para resumir hubo excelentes aportes de Ingrid Astiz, Jose Manuel Beas, Pablo Rodriguez Facal y varios otros que fueron desgranando características (a veces por la negativa) entre las que rescato:

• Un líder debe poner de costado su "propio ego"
• Debe tener humildad y poner lo menos posible de su propio ruido
• Aportar herramientas practicas y dejar que el equipo descubra su potencial.
• Renunciar a la ilusión de importancia personal
• No ser burócrata
• Sentirse incomodo con forma de Gestionar de "Comando y Control"
• Ayudar al equipo a triunfar
• Escuchar a la gente
• No adjudicarse el merito de los demás
• No crear conflictos
• No manipular
• No caer en la inercia y tratar siempre de mejorar
• No caer en la ilusión del control
• No culpar al equipo por los fracasos
• No tiene que estar encima de todos
• debe confiar en las personas del equipo

¿Que les parece eh?! Pavada de listita!! Interesante para chequear a nuestro alrededor, verdad?

El camino del Conocimiento: de Aprendiz a Maestro

El problema en cuestión es: Como encarar la adopción de una metodología ágil?

Artes Marciales y un poco de historia

Como siempre, la cultura milenaria Japonesa viene en nuestra ayuda. Existe un concepto dentro del arte marcial japonés llamado ShuHaRi, que describe, dentro del camino hacia el conocimiento, 3 etapas necesarias para volverse un maestro:

ShuHaRi

Es la composición de tres palabras: Shu - Ha - Ri

Shu significa "proteger" y "obedecer", con significado de obedecer el "conocimiento tradicional". El aprendiz debe aprender las técnicas y conocimientos fundamentales, bajo la supervisión de un maestro. Todavía no esta listo para explorar y comparar diferentes caminos.

Ha significa "desprenderse", "desamarrar", "derivar". Es romper con la tradición. De una manera controlada el "Practicante" comienza a explorar diferentes caminos.

Ri es "dejar", "separarse", "trascender". Ya no hay un seguimiento de reglas o técnicas porque todo movimiento es natural y fluido. El conocimiento forma ya parte indivisible con la persona que se ha transformado finalmente en un Maestro.

Toda persona que comienza a aprender este arte marcial debe pasar por estas tres etapas que lo llevan desde aprendiz a Maestro.

En la cultura occidental , durante la edad media los aspirantes a determinados oficios (herrero, carpintero, etc.), recorrían un camino similar a ShuHaRi, adonde cada aprendiz empezaba a trabajar con un Maestro, con el tiempo se convertía en un profesional, practicante de su oficio y luego de muchos años y una mejora constante llegaba a tomar el lugar de Maestro y completaba el ciclo teniendo sus propios aprendices.

Adopción de metodologías ágiles

Desde la irrupción masiva de las metodologías ágiles en el mundo del desarrollo de software y su llegada a nuestro país hemos presenciado varias veces el momento en el cual una empresa comienza a aplicar ágiles.

Ignoramos si solo es una característica de nuestro país, o es general pero observamos la misma falla una y otra vez:

Se define el cambio a una nueva metodología, tomemos con ejemplo a Scrum, se capacitan a las personas, se contrata a coachs, se eligen equipos, etc., pero se comienza a aplicarlo con modificaciones a la esencia de la metodología. Es decir, se saltean la etapa imprescindible del aprendizaje, la de Aprendiz (Shu) y pasan directamente a Ha.

Por supuesto, estas modificacione se producen esgrimiendo variadas y al parecer muy validas razones, respaldadas por las excusas más variadas, como por ejemplo:

• "En esta empresa hacemos las cosas diferentes".
• "No podemos seguir la metodología al detalle, acá somos muy especiales".
• "El de Product Owner es un concepto de lo más interesante pero... acá los usuarios son difíciles. No va a servir."
• Aca los usuarios están muy ocupados.
• No, aquí esto va a traer problemas (así, de una manera difusa, en voz baja, con miradas nerviosas por sobre el hombro).
• No se adapta a la cultura de la empresa.
• Este principio no aplica a nuestro entorno porque va en contra de nuestra politica X.
• etc.

Se plantean así desde el primer momento "adaptaciones" a la metodología. Adaptaciones estas que son cambios encubiertos, que de una u otra manera van en contra de los principios por los cuales la metodología funciona.

Es decir, se busca la excusa que sea necesaria para cambiar para no cambiar. Se hace cualquier modificación de la forma de trabajar que no implique un cambio real en la forma de trabajar.

Porque justamente todo cambio Real implica entrar en una zona de incomodidad, de no confort y eso generalmente cuesta, cuesta mucho.

Vale una aclaración importante, no estamos proponiendo no hacer ninguna adaptación a la realidad en la que nos movemos, a la cultura adonde estamos inmersos y ser talibanes al imponer rigurosamente cada punto y coma de la metodología en cuestión. Cuestiones acerca de si entrar de lleno con todas las prácticas o el grado de profundidad que aplicará desde entrada, si incluir hasta la ultima práctica recomendada de entrada o ir haciendolo de manera progresiva, la forma o detalles de implementación de las prácticas técnicas, etc, son todos puntos a pensar y adaptar de la mejor manera para el contexto y proyecto en cuestión.

Pero, el punto esencial es que si uno eligió una metodología ágil no puede proponer cambios que vayan en contra de los principios y valores sobre los cuales esta basados esa metodología. Así de sencillo.

El camino del aprendizaje

Miremos, por otra parte, como propone encarar la adopción de una metodología ágil, James Shore, un muy conocido evangelizador de metodologías ágiles, fundamentalmente de XP, y autor del libro "The Art of Agile Development".

En su "Camino del aprendizaje" justamente basado en ShuHaRi propone encarar el estudio de un método nuevo, como es, adoptar una nueva metodología de desarrollo, de la siguiente manera:

1 - Seguir las reglas: Esta es la etapa inicial durante la cual se elige un metodo y se lo sigue tan rigurosa y detalladamente como sea posible. Durante esta etapa uno esta aprendiendo del tema en cuestion, asi que debe estudiar, debe seguir el metodo, reflexionar sobre la experiencia y volver a estudiar. Es importante justamente seguir las reglas fielmente, en su espiritu al menos, para poder evaluar si nos sirve o no. En lo que respecta a este tema uno es un aprendiz.

2 - Romper las reglas: En esta etapa, habiendo uno realmente aprendido el metodo (sin modificaciones "tempranas") y haberlo practicado durante un cierto tiempo se plantea una etapa de mejora basada en pequeños cambios controlados. Uno debe evaluar los resultados obtenidos, plantear un solo cambio y volver a prácticar el metodo completo, para poder medir la diferencia del cambio realizado. Durante esta etapa uno ya ha pasado la etapa de aprendiz y sabe tanto del método como para poder ajustar determinadas partes sin ir en contra de los principios que lo hacen funcionar. Es ya un Practicante del método.

3 - Ignorar las reglas: Por último en esta etapa el conocimiento se incorporó completamente y las acciones a realizar surgen naturalmente respetando fielmente los principios y valores subyacentes. Uno no debe pensar ni recordar ya en las reglas de manera individual porque las tiene internalizadas de manera que se aplican constantemente pero adaptandolas instantaneamente al problema en cuestión. Se hace lo que le parece correcto basándose en su amplia experiencia y el conocimiento del método que absorbió y luego se observa y actúa en base al resultado.

El Practicante se ha convertido en Maestro.

Nota de los autores: Queremos agradecer a James Shore por su permiso para traducir, publicar y discutir su poster "camino del conocimiento, así como también su excelente predisposición para ayudarnos. Recomendamos fuertemente cualquier libro o artículo proveniente de Él.

Author's note: We would like to thanks James Shore for his permission to translate, post and discuss his poster "The Road to Mastery" and for his help and feedback. We strongly recomend any of his books or articles.

Flexibilidad ante el cambio

Inmaginense la siguiente situación: Comienzo de un proyecto, el Gran-Gerente de proyecto, Gran-Jefe-Saco-Agua-De-Las-Piedras reune a todo el equipo y anuncia "El equipo de funcionales va a comenzar con la (Gran)Etapa de relevamiento, durará unos 10 meses. Queremos lograr entender completamente lo que quiere el usuario asi no vamos a tener ningún cambio y vamos a saber todo para cuando entremos en la etapa de desarrollo, que durará unos 3 meses.". Esta es una situacion real, números de meses incluidos. Me sucedió a mi.

Una y otra vez todos hemos estado en proyectos adonde pasa mas o menos lo mismo: Una Gran Etapa De Relevamiento al principio del mismo para "evitar" tener que realizar Cambios y para aprender TODO lo que hay que aprender. Una y otra vez hemos llegado a la mitad o al final del proyecto, con varios meses de retraso respecto de la fecha original, cuando, al mostrarsele el sistema a los usuarios comienzan a aparecer estos "cambios-que-se-suponian-que-no-tenian-que-existir".

Porqué pasa esto? Son los usuarios una fraternidad de sádicos a los que les gusta torturarnos? Son los funcionales, los desarrolladores personas altamente perturbadas y disfuncionales (eh... mejor no contestemos esto) que no pueden entender lo que el usuario les pide? Existe el destino y se empeña en ponernos piedras en el camino?

O será que el cambio es una parte normal de todo proyecto?

Hasta el surgimiento de las metodologías ágiles el cambio se trataba (se sigue tratando) como una anomalía, como un error del usuario o como un síntoma de que alguien se equivocó y no relevó lo suficiente. Cuando hablamos de cambio lo hacemos en todo sentido pero particularmente de los requerimientos y necesidades del usuario.

Por este motivo es que Waterfall indica que debe realizarse una Gran Etapa de Relevamiento al Principio (en inglés, BRUF, Big Requirements Up Front), seguido de escritura de casos de uso (indicado por el DR. RUP) y terminando con requerimientos firmados por usuarios temerosos (de meterse en camisas de once varas y de estar firmando los "10 mandamientos del sistema" tallados en Mármol!).

PMI lo trata con un proceso de "gestión de cambio" o "Control de Cambio" adonde en base a un pedido de cambio del relevamiento inicial se realiza un "cambio de alcance", lo cual implica reestimar costos, chequear asignación de recursos, reestimar tiempos, replanificar y obtener la autorización del sponsor / Gerentes del proyecto para proceder con el cambio. Cualquier parecido con la tortuga de Mafalda es pura coincidencia (La tortuga se llamaba Burocracia).

Justamente uno de los principios comúnes a todas las metodologías ágiles es: El cambio es parte de la realidad!

No es un hecho excepcional, no es causado por usuarios viles y sádicos que quieren hacer un infierno de nuestras vida. No es causado por analistas funcionales perezosos (bah, vagos) o que no saben como escribir un caso de uso (que los hay, los hay) ni por malos programadores que malinterpretan lo que esta escrito en la lista de requerimientos (de estos también hay). Sencillamente es que no importa cuanto tiempo le dediquemos al relevamiento, no importa cuantas Maquetas, prototipos o casos de uso hagamos para mostrarle al usuario, no importa cuanto esfuerzo le dediquemos a reuniones de validación, siempre siempre siempre va a haber cambios a partir del relevamiento inicial (por favor, vuelvan atras y lean de nuevo esta frase).

Porqué? bueno, los principales motivos son :

1. El usuario ve el sistema funcionando y ahí se da cuenta lo que realmente quería .
2. El usuario descubrió a lo largo de todo el tiempo de trabajo en conjunto con analistas y desarrolladores lo que necesita.
3. Funcionales y Programadores aprendieron del dominio del problema y son capaces finalmente de entender lo que el negocio necesita ahora que el usuario finalmente aprendió.
4. El negocio simple y sencillamente cambió.
5. La legislación cambió.
6. El/Los usuarios cambiaron (y usuarios distintos quieren soluciones distintas).

Es decir, simple y sencillamente porque es NORMAL que la realidad cambie (un cambio en alguna regulación, etc, el mercado cambia, aparece un nuevo producto, etc). Y es NORMAL que el conocimiento cambie a medida que uno va teniendo más información y aprendiendo. Esta información solo se puede obtener a través de la experiencia. Esto es así porque al ser un sistema un modelo abstracto de la realidad el usuario sólo se da cuenta de las consecuencias de lo que pidió cuando lo ve funcionando, cuando lo "toca".

Que mente perversa nos metió en la cabeza la idea de que podemos preveer de entrada la forma en que se va a comportar la realidad!? Que cambios se van a producir en el mercado? que leyes saldrán? que va a querer el nuevo usuario o de que se va a dar cuenta el usuario que tenemos cuando le mostremos el comportamiento de las reglas de negocio que relevamos en casos concretos? seria como predecir el clima, pero de aca a un año!.

Una simple muestra para ver el lugar que ocupa el cambio en las metodologías ágiles, en el primer libro de XP, llamado "XP Explained", de Kent Beck, tenia como subtitulo "Embrace Change", abracemos el cambio!

Escuchemos de nuevo finalmente a Kent Beck, en un fragmento de su libro "Implementations Patterns" :

"Nuestra industria parece adicta a la idea de que solo si diseñamos el software bien de entrada no tendremos que cambiar luego el sistema.

Recientemente lei una lista de razones por las que el software cambia. En la lista estaban los programadores que no hacen bien su trabajo al entender los requerimientos, sponsors y usuarios que cambian de parecer y otros motivos mas. El unico factor que faltaba en la lista era justamente el cambio legítimo. La lista asumía que el cambio es siempre un error.

¿Porque no sirve un pronostico del tiempo para todos los dias? Porque el tiempo cambia de manera impredecible. ¿Porque no podemos listar de una sola vez todas las formas en las que necesitaremos que el sistema sea flexible? Porque los requerimientos y la tecnología cambian de manera impredecible.

Esto no nos releva de nuestra responsabilidad de hacer lo mejor que podamos para desarrollar el sistema que el usuario necesita ahora pero sugiere que hay límites al valor de hacer sistemas a prueba-de-cambios-futuros, a través de la especulación.

Poniendo todos estos factores juntos, la necesidad para que el sistema sea flexible ante el cambio, el costo de esa flexibilidad, la impredecibilidad de adonde será necesaria, me lleva a creer que el momento para introducir esa flexibilidad es sólo cuando la misma es absolutamente necesaria".

Con Scrum no alcanza

Empezando un poco con el tema de metodologías ágiles en general quiero pasar a este blog, de alguna manera repitiendo su publicación, un post que habia escrito respecto a una conversación dentro del marco de la lista sobre metodologías agiles en habla hispana, foro-agiles@yahoogroups.com. De paso la idea es "aggiornalo" o mejor dicho, ponerlo un poco mas en contexto dentro de este blog.

Como ya contamos comenzamos a interesarnos en las metodologías ágiles allá por los años 2002/2003, cuando leímos un par de libros sobre eXtreme Programming (XP), "XP Explained" de Kent Beck y "XP Installed", de Ron Reffries que llegaron en el momento justo, cuando estabamos en crisis, en la búsqueda de ciertas respuestas. LLevabamos en ese momento casi 10 años de trabajo profesional y estabamos seguros de que tenía que haber otras formas, mejores, de encarar el desarrollo de software. Ni Waterfall ni RUP, ni la utilización de una gran etapa de relevamiento con UML habian cambiado en lo mas mínimo la mala situación de la mayoría de los proyectos en los que participabamos. Al final sucedia siempre lo mismo: El grupo de desarrollo, realizando una marcha forzada contra reloj, se esforzaba heroica pero inútilmente en terminar un sistema que al usuario luego no le servía.

En los años siguientes, las metodologías ágiles comenzaron a ser cada vez más populares, y se ensanchó grandemente su audiencia. Esto sucedió básicamente a través de la difusión masiva de Scrum y sus certificaciones, por encima de XP (y su relacionada Industrial-XP ) y Cristal Clear (de Alistair Cockburn) , que han quedado mucho mas relegadas. Creo que en parte ganó la noción que estas otras metodologías, particularmente XP, solo se ocupaban de la programación y no de la gestión y organización del proyecto. Esta idea es totalmente errónea pero es un tema que trataremos en otro momento.

LLendo al titulo del post, aclaramos por si las dudas: Estamos a favor de Scrum. Personalmente creo que es una buena metodología/ framework / conj. de buenas prácticas/ comoseaqueunolodefina, de lo mejor que hay dando vuelta por el ala ágil del arco de desarrollo (es la mas difundida, seguro).
Lo que desafío es la noción de que con Scrum sólo alcanza para obtener excelentes resultados en un proyecto de desarrollo de software. Más bien me juego por lo contrario, con Scrum solo solo (valga la redundancia) alcanza para fracasar. Lo digo en serio. Cuando mucho será un fracaso menor o más rápido que con una metodología tradicional, de las monumentales, con más participación del usuario, pero fracaso al fin.

A ver, en teoría es suficiente con hacer muchos Sprints, muchas retrospectivas, cierta transpiración y luego de un cierto numero de iteraciones....voila! van a ir surgiendo en el grupo un conjunto de buenas práacticas de desarrollo, se van a ir corrigiendo errores, eliminando impedimentos y llegaremos a tener un proceso aceitado que permite conseguir un producto de alta calidad deleitando a nuestros usuarios, verdad?

FALSO (IMHO) porque:

1. Muchos proyectos no duran tanto para lograr mejorar la calidad del producto a través de retrospectivas y permitir que surjan buenas practicas de desarrollo, en parte por "culpa" del mismo Scrum. El hecho de realizar reviews cada 2 o 3 semanas del Sprint implica una Alta Exposición ante el usuario (claro que estoy a favor del feedback constante), el hecho es que si estamos construyendo...crap, es decir, porquerías vamos a estar mostrando porquerías... y los usuarios suelen tener poca paciencia... (y ni hablar de nuestros "ágiles" gerentes...).


2. Los equipos de desarrollo no suelen estar juntos y evolucionar juntos en distintos proyectos (algo que mejoraría el punto anterior porque no tiene que producirse la evolución en el proyecto presente sino que puede venir de proyectos anteriores) por la altísima rotación producto (bendita sea) del mercado dinámico y de ciertas condiciones de contratación precarias. Es la realidad en que vivimos por lo menos aquí en Argentina, y me atrevería a arriesgar en muchos lugares del mundo incluso a pesar del impacto de la crisis mundial.


3. Un grupo de desarrolladores (Programadores) no aprende de la nada a ser bueno, de la noche a la mañana, no se aprende a realizar buenos Diseños Simples de manera evolutiva e incremental. Lleva mucho tiempo y trabajo aprender a realizar tests de unidad efectivos y mantenibles en variados ambientes tecnológicos y tipos de proyectos. Cuesta y mucho aprender a Programar Orientado a Objetos, pero en serio, de manera profunda no solo aplicando patrones de diseño a diestra y siniestra. Requiere estudio, requiere mucha práctica, mucho esfuerzo y cierta habilidad o capacidad mínima.


4. Cuesta tiempo aprender a coordinar al grupo, Desarrolladores, Testers, Analistas Funcionales, Usuarios, tiempo este que crece exponencialmente con el tamaño del mismo.


5. Nos enfocamos mucho en el proceso.... Planning Meeting - Sprint - Review - Retrospectiva y nos estamos olvidando de la calidad de la gente.... People over Processes , no se si les suena. Y es la gente la que siempre termina dando la solución.


6. Hay un proceso.... dudo en llamarlo... de pauperización o deterioro de calidad de la programación y desarrollo de software que me preocupa, cada vez mas los programadores solo se centran en dominar el siguiente framework X-Y-J, llamese Enterprise Library, WCF, Spring security-MVC-Whatever, Hibernate, Seam, el siguiente "juguete" o arma que les promete la famosa "bala de plata" en lugar de buscar mejorar activamente la calidad del desarrollo y su capacidad de concepción de un desarrollo de más alto nivel, de practicar y adoptar buenas practicas que permitan pensar en algo mas estratégico en lugar de la táctica de corto alcance...


7. Gran parte del mercado de desarrollo se dirige a una complejización cada vez mayor de la tecnología, lo que nos lleva a estructuras de aplicaciones y ambientes cada vez mas complejos e interdependientes.

Todos estos puntos hacen que los problemas de mala gestión, falta de empiriscmo, falta de autogestion y de feedback que vienen a solucionar Scrum sean males "menores" comparados con no empezar a trabajar bien desde un punto de vista técnico desde el primer dia, utilizando buenas prácticas de desarrollo.

En síntesis es poco realista pretender que aplicando Scrum "a la Talibana" y después de unas pocas iteraciones o muchas el grupo vaya evolucionando y mejorando (ojo, que lo hace peroo no) a una velocidad tal que permita desarrollar un producto de muy buena calidad, sin deuda técnica, con alta cobertura de tests de unidad y con un Diseño de objetos solido y extensible, en pocas palabras, un sistema Mantenible (asi con "M" Mayuscula).

Es como pretender realizar un viaje en barco y comenzar el viaje sabiendo que el barco esta lleno de agujeros y se comienzan a tapar en medio del viaje. Lo mas probable es que cuando lleguemos a mitad del camino, en aguas profundas, el barco tenga tanta agua (léase Deuda Técnica) que ,aunque seamos cada vez mejores y mas rápidos en tapar agujeros, el barco (léase Proyecto) se hunda irremediablemente y sin necesidad de chocar contra algún tempano.