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.

¿Por qué funciona Pair Programming?

Cuando se presentan las prácticas de Extreme Programming hay una que inmediatamente genera un rechazo especial: Pair Programming. Ese rechazo es completamente comprensible, ya que estamos poniendo a dos personas a hacer el trabajo que antes hacía uno. ¡El proyecto va a llevar el doble de esfuerzo! - grita el lider del proyecto, y al doble de Costo!! - corea desde su oficina el gerente de proyectos, estos programadores vagos que no quieren trabajar!!

Sin embargo, hay bastante evidencia de que trabajar de a pares nos hace más productivos. ¿Cómo puede ser?

La principal explicación es que programar no es una tarea mecánica. La única parte más o menos mecánica es el tipeo del código y es una tarea que no consume mucho tiempo. En un proyecto en el que participé medí la cantidad de código que habíamos generado y la dividí por la cantidad de horas de desarrollo. El resultado fue que habíamos escrito algo así como unas 15 líneas de código por hora (y esto en un proyecto que fue completado exitosamente en el tiempo estimado).

Las tareas que verdaderamente se llevan el tiempo de desarrollo son otras, como descubrir lo que el usuario quiere que desarrollemos, entender el código existente para ver a donde nos conviene agregar las partes nuevas, diseñar la implementación, entender como usar nuestras herramientas y corregir bugs.

Pair programming funciona porque todas esas tareas se hacen en forma más eficiente en pares. Es más facil entender requerimientos o código o herramientas cuando discutimos con un par (y además es probable que uno de los integrantes del plan ya tenga experiencia al respecto) y es mucho más productivo hacer sesiones de brainstorming de a pares para pensar alternativas de diseño.

En cuanto a la corrección de bugs, trabajando de a pares disminuye, y mucho, la cantidad de errores introducidos debido a la constante revisión del código por dos personas. La búsqueda de los pocos errores que se producen también es más eficiente, simplemente por la necesidad de comunicación dentro del par. El efecto es parecido al que se da cuando nos rompemos la cabeza durante horas tratando de solucionar un problema y cuando finalmente pedimos ayuda y tratamos de explicar el problema a alguien, se nos ocurre la solución, antes de que la otra persona tenga tiempo de decir una palabra.

La productividad además aumenta porque disminuyen las distracciones y aumenta la focalización en los problemas. Esto a primera vista parece paradójico porque con dos personas uno pensaría que crece la posibilidad de divagar o distraerse. Sin embargo no es así, y la necesidad de concentrarse no solo en solucionar el problema sino, además, en comunicar con el par lo que uno cree que debe hacerse y discutir sobre la solución, todo esto evita que uno se distraiga con ruidos externos o con llamadas o la llegada contínua de mails molestos.

Por ultimo el compartir entre dos desarrolladores de diferentes niveles de skill y conocimiento constituye la mejor y más rapida forma para poner al dia a un nuevo programador que se incorpora al equipo. Y ademas, el más experimentado recibe una dosis frescas de dudas y cuestionamientos a ciertos temas que "siempre han sido asi" pero que no tienen porque serlos.

En definitiva, los programadores no trabajamos levantando paredes ni en una línea de montaje de una fábrica, por mencionar dos metáforas conocidas en nuestra profesión ("factorias de desarrollo") . Trabajamos pensando y ese tipo de trabajo se hace en forma más eficiente en equipo.

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".

Estás realmente haciendo desarrollo ágil?(Traducido con permiso de Jake Scruggs)

Hace tiempo que los que escribimos este post venimos viendo como ha ido quedando de lado y, casi diría, en el olvido la metodología de desarrollo Extreme Programming, conocida como XP, que no trata solamente de prácticas de programación, una creencia bastante extendida. Lo que sigue es la traducción de un post interesante que escribió recientemente Jake Scruggs, Are you really doing agile development?, y que aquí publicamos con su permiso.

Recientemente en el trabajo me pidieron que ayudara a hacer a la compañia más "ágil". Bueno, como primero soy un desarrollador y segundo, un fanático estudioso de procesos, respondí con mi usual "Cuantas, de las 12 prácticas están realmente siguiendo?". Mi pregunta fue recibida con muchos ojos grandes y bocas abiertas. Parece que las 12 prácticas de XP clásicas no son fáciles de ubicar estos días en internet. Tambien parece que la palabra "ágil" (de las metodologías ágiles) ha sido tan exitosa en su difusión que muy poca gente parece recordar que XP significa Extreme Programming. Ahora bien, soy el primero en admitir que "Extreme Programming" es un nombre colosalmente estúpido, pero lo que me gusta de XP y sus 12 prácticas originales es que fueron controversiales y fáciles de evaluar: O bien las estabas siguiendo o no lo hacias.

Lo que no me gusta de la palabra "ágil" es que es tan amplia y definida de una manera tan difusa que casi cualquiera puede autoengañarse y creer que ya es completamente ágil.

Asi que, para solucionar esto, y ayudar a mi compañia a comenzar a medir mejor su "agilidad" , decidi listar las 12 prácticas de XP clásicas (A través del tiempo cambiaron...pero no para mi. Y mantenganse afuera de mi jardin!) y mi altamente subjetiva opinión sobre cada una de ellas. Al final les diré como calcular su índice de "agilidad".

* Planning Game o juego de planificación Obtener requirimientos del usuario, armar historias de usuario (cortas), estimar el tiempo que llevará hacerlas, hacerlas, medir velocidad, examinar estimaciones erradas para pistas acerca de como estimar mejor y repetir. Una historia es una promesa de conversación -- esto solo funciona si el usuario (o representante) está altamente disponible para los desarrolladores y los desarrolladores aprovechan esa disponibilidad chequeando constantemente dudas y presunciones durante el proceso de desarrollo. Nota: Historias que toman más de un dia para completarse reducen el éxito de otras prácticas de XP.

* Small Releases o versiones pequeñas LAs iteraciones deben ser de 1 o 2 semanas (dependiendo de cuan doloroso/caro sea organizar una iteración). Despues de cada iteración se debe implementar una versión en productivo si la aplicación es fácil de desplegar (como por ejemplo una aplicación web).

* Metaphor - Metáfora Nadie sigue esta práctica, puntos extras si tu lo haces.

* Simple Design - Diseño Simple Esto significa distintas cosas en distintos niveles. Cuando se esta empezando un proyecto desde cero, una semana de relevamiento de requerimientos y diseño esta bien. Para una historia individual, diseñar desde unos minutos hasta una hora está bien. Después uno comienza a programar. Importante: Se diseña a medida que uno desarrolla. Para para pasar unas horas en frente de un pizarrón está permitido, e incluso, alentado. Hacer la cosa más simple que pueda funcionar hasta que se vuelva obvio que no funciona. Entonces se rediseña. La idea es que el comienzo de un proyecto es el momento que uno sabe menos del mismo-- por eso hay que distribuir el esfuerzo de diseño a lo largo de la vida del proyecto de manera de poder tomar decisiones cuando uno tiene más conocimiento.

* Testing Testear antes de programar. Cubrimiento del 80% para Java, 90% para Ruby (menos chequeo de exepciones en ruby hace más fácil aumentar el porcentaje de código cubierto). Tests Robustos, atómicos, rápidos. (los Test de unidad deben correr en menos de 5 minutos, todos, en realidad es mejor si es menos de un minuto pero la mayoria cree que es imposible (Les adelanto la respuesta: ES posible )

* Refactoring - Refactorización de código En breve: Rojo, verde, refactorizar!, respuesta larga: Escribir un test que falle, hacerlo pasar, refactorizar el código. Tambien significa que cuando estás pasando por un lugar (de código) desordenado lo dejas un poco mejor de lo que lo encontrastes.

* Pair Programming - Programación de a pares

Más del 80% del tiempo. En serio. Tareas en las que parece que no se puede programar de a pares a menudo significan que no estas usando las técnicas de pair programming correctas. Programar de a pares es una habilidad sobre la que se trabajar. Practiquen para ser mejores en ella.

* Collective Code Ownership - Compartición de código colectiva

Cualquiera puede cambiar cualquier parte del código. Si, deben consultar al que conozca más acerca del código a modificar pero no hay ninguna parte del codigo que sólo el desarrollador X puede tocar.

* Continuous Integration - Integración contínua

Cada check-in en el repositorio remoto dispara un set extensivo de tests de unidad. Los programadores deben ocuparse si el build falla. Por ejemplo, cuando el build falla nadie hace más check-ins hasta que se soluciona. También debe haber algúna penalización social para el que rompe el build (Debe usar un sombrero estúpido por el resto del dia, un deshonroso trofeo "Rompedor del build" que se ubique en el escritorio del susodicho, debe comprar donas o algo para todo el equipo, etc.). Todo esto se basa en la presunción de que el build es confiable y que una falla significa un problema real.

* 40-hour Week - Semana de 40 horas

Ahora es llamada "Paso sostenible" porque "semana de 40 horas" tendía a asustar a los gerentes y corridas de final del proyecto son a veces necesarias incluso en XP. Esto no debe durar por más de 2 semanas, tener un punto claro y definido a partir del cual las horas de más se terminan y no debe suceder más de dos veces en el año. En verdad, si sucede dos veces en el año significa que se deben mejorar las habilidades de estimación.

* On-site Customer - Usuario in-situ

No sucede a menudo para proyectos internos. Se usan en general representanes de Usuarios (o proxies). Estos representantes necesitan tomarse el trabajo de hablar con los usuarios reales constantemente (no solo con los gerentes de los usuarios) y estar totalmente disponibles para contestar preguntas y dudas de los programadores.

* Coding Standards - Estandares de desarrollo

No importan cuales sean pero los programadores necesitan llegar a un consenso y mantenerlo. El consenso no significa que todos digan "si" en la reunión y luego ignoren los estandars cuando les conviene.

Asi que, como obtenemos el índice de agilidad? Tomen la cantidad de prácticas que realmente siguen, dividanlo por 12 y multipliquenlo por 100-- este es el porcentaje de ágiles que están haciendo. No se den un punto si no implementan real y completamente la práctica. Tienen integración continua pero algunos de los tests fallan de manera aleatoria? ningún punto. Programan de a pares "cuando es necesario" lo cual termina siendo el 40% del tiempo? ningún punto! Hacen iteraciones pero no estiman las historias? ningún punto!!

Este es un momento para mirarse objetiva y seriamente ante un espejo, no una fiesta de amor hippie, i.e, la Hippie-Love Fest.