Downloading content…

Hace tiempo empecé a trabajar en una “agile shop” (una empresa de desarrollo de software usando metodologías ágiles), bueno en realidad no es la primera vez que veo algo así, cuando fuí a Estados Unidos me tocó trabajar en un ambiente ágil pero a pesar de que eran muy agiles y todo no le ponian nombre a su metodología. Aqui tiene nombre y ese es… pom pom pooom… SCRUM.

SCRUM es un sabor de las afamadas metodologias ágiles, de que se trata todo esto? bueno es relativamente “fácil” de explicar, y digo “fácil” por que creanme que es mucho mas sencillo que CMMI o RUP (metodologias no agiles)

Pongamos una pequeña pausa, ¿ok?

¿Qué es una metodología ágil?

Metodología: Forma de hacer algo, es un proceso o una guía de pasos a seguir.

Ágil: Adaptable, rápido, flexible, etc.

Metodología ágil: Es una forma adaptable, rápida y flexible de hacer las cosas. En el desarrollo de software se le conoce por que es una forma de desarrollar sistemas adaptandote rápidamente a los cambios y entregando continuamente un producto funcional.

OYEEEEE… espera… entonces ¿como hacian las cosas antes? ¿Como era el mundo “no ágil”?

Bueno. De entrada la mayor parte del mundo sigue sin ser ágil, así que en vez de decir como era el mundo es un como es el mundo.

El mundo es horrible. (pero eso ya lo sabian)

Hace tiempo para garantizar la seguridad (y por seguridad me refiero mas a “certeza”) en el desarrollo de software se crearon procesos que permitian a la gente entender como se hacia un sistema.

• Se hacian consultas y propuestas de lo que se queria hacer. normalmente en juntas de minutos, horas o dias.
• Se hacian negociaciones sobre los requerimentos que podian tomar dias, semanas o meses.
• Se sacaba una bola de cristal (bueno no tanto así) y se planeaba cuanto tiempo iba a tomar hacer algo, esto tambien puede tomar dias, semanas o meses.
• Se les entregaba un machote de documentos a los desarrolladores (ahora si trabajen) y se les decia cuanto tiempo se podian tardar en cada tarea (si, se les decia, te vas a tardar X tiempo en hacer esto), normalmente en este paso las estimaciones siempre decian que el sistema era realizable en menos tiempo de lo que realmente se tarda uno asi que resultaba en dias, semanas o meses de ir los sabados y domingos a trabajar.
• Una vez terminado se hacian pruebas.estas tardaban horas minutos o segundos para compensar el retraso de los inutiles desarrolladores.
• Se implementaba la solución en los sistemas finales que tomaban horas o dias de estar rezando.

¿Dudas?

Yo tambien tengo muchas.

Sobre todo una: ¿Como es que alguien mas sabe cuanto me tardo en hacer algo? son gurus? shamanes? brujos?

Bueno no, son CONSULTORES CAPACITADOS CERTIFICADOS, RESPALDADOS POR FAMA INTERNACIONAL Y QUE GANAN 10 VECES LO QUE CUALQUIER DESARROLLADOR MORTAL. woooooooooooooooooooooooooooooooooow

En fin, el proceso funciona, creanlo o no.

Y funciona por que lo hemos hecho funcionar, ya sabemos que esperar, que vamos a tener que trabajar de más, que van a estimar de menos, que si firmamos que vamos a hacer algo, solo vamos a hacer eso, y si queda mal, si no es lo que el cliente queria, ni modo, por que el firma que se va a seguir ese proceso y está de acuerdo con el. Este proceso le da certeza al desarrollo a cambio de hacerlo inflexible ya que si el cliente necesita algo extra, ni modo, tendrá que ser hasta el final, por que hay un plan y hay que hay que seguirlo.

Es un mundo horrible (y ahora lo acaban de comprobar)

Bueno bueno bueno. ¿Pero que propones?

Las metodologias agiles por supuesto, de eso se trata este post (bueno la segunda mitad del mismo)

Las metodologias agiles proponen algo distinto y mucho mas arriesgado (por eso no son tan populares) pero mucho mas eficientes cuando se quiere hacer algo nuevo.

La idea principal es.

• Juntarse con el cliente y preguntarle mas o menos que quiere y hacer una sesion de lluvia de ideas, que pida hasta las perlas de la virgen si eso es lo que el quiere.
• Ahora con esa listotototototota de cosas le preguntamos: Que de todo esto es lo más importante.
• El cliente responde: TODOOOO,
• y tu le dices, va. ok todo, pero solo podemos hacer mas o menos esto en 15 dias.
• El cliente sacado de onda se responde “15 dias??? pero en 15 dias no alcanzarias a hacer nada”
• Tu respondes “si y no, podemos hacer algo, y lo vas a ver funcionando en 15 dias, solo elige una cosa de todo lo que me dijiste”
• El cliente incredulo elige algo, no muy grande no muy chico. mas o menos bien.

Y aqui empieza la diversión. Ahora ya tenemos algo de prioridad suprema. vamos con los desarrolladores y les decimos que es lo que el cliente quiere, todo mundo sabe que eso no es TOOOODO lo que el cliente quiere y que esa petición es solo un pedacito de un todo que asusta a cualquiera, pero. El objetivo a corto plazo es: Hacer lo que el cliente pide ahora.

Aqui es realmente cuando el proceso inicia:

• El equipo de desarrollo empieza a desarrollar, planear y hacer el sistema de inmediato basandose en solo esa pequeña parte que el cliente eligio.
• Lo que el cliente pide se divide en tareas que puedan hacer personas simultaneamente, tareas pequeñitas y que sepamos mas o menos que tan dificil son.
• Mientras tanto le preguntamos al cliente que es lo siguiente que le gustaria ver.
• El cliente elige y se prepara el camino para la siguiente iteración
• El equipo termina lo que pueda en esos 15 dias, dejando algo FUNCIONANDO al final.

No se si ven la diferencia? En una metodologia agil no se adivina cuanto tarda en hacerse un sistema, eso se sabe siempre, lo que se adivina es que tanto se puede hacer en X tiempo y una vez que algo se termina se valida se implementa y se entrega bonito y acabado.

Suena como un mundo ideal ¿noooooo? pues no lo es. “not quite” es mejor pero no es ideal.

Requiere de mucho control para el descontrol y de muchas prácticas de programación locas que puede que no a todos les guste. Test Driven Development (Con este excelente libro: Test Driven By Example), Pair programming, Continous Integration (chequen hudson por ejemplo), etc.

Ahora vamos a un ejemplo real, ¿va?

Un ejemplo de metodología con nombre y apellido: SCRUM

La idea escencialmente es la misma de arriba, todos los requerimentos del usuario son escritos en historias de usuario que son los pequeños bloques de principio a fin que hacen algun tipo de funcionalidad, por ejemplo, el usuario quiere logearse al sistema, el usuario quiere poder agregar otro usuario, el usuario quiere poder borrar un usuario. Ahi vieron 3 historias distintas, todas son una funcionalidad especifica.

Ahora esas historias se estiman, la estimación no la hace un gurú la hace el equipo. Como? simple: primero se le muestran las historias y el equipo por concenso dice cual es la más fácil de hacer. Esa será nuestra historia de dificultad 1. ahora se va por las historias y se pregunta: Esta historia, ¿Cuantas veces más dificil es que la historia de dificultad 1?. Si es el doble tiene una dificultad de 2, si es 4 veces mas complicada es un 4, etc… lo que se recomienda es que se usen valores de 1,2,4 y 8… si algo es más grande que eso tal vez valga la pena dividir la historia en pedazos mas pequeños.

Entre los bloques sean mas pequeños no solo son más fáciles de desarrollar sino que tambien son más fáciles de estimar.

Ahora el equipo empieza a trabajar…

Toman un estimado “a la macha” de cuanto pueden hacer y empiezan…

Dia a dia, se hace una micro junta (Que se le conoce como SCRUM) de maximo 10 minutos donde todos los desarrolladores dicen:

• Que hice ayer?
• Que voy a hacer hoy?
• Hay algo que me impida hacer eso?

De esa manera todo mundo está enterado de lo que está pasando.

Al final de los 15 dias lo que haya terminado el equipo se suma. y se obtiene un numero de historias terminadas, pero sobre todo de puntos de dificultad terminados. a eso se le llama: VELOCIDAD.

Asi que digamos que un equipo logra hacer 50 puntos. entonces podemos deducir que mas o menos haran eso consistentemente cada 15 dias.
Si un sistema tiene 1500 puntos en total tomaria: 30 iteraciones de 15 dias para terminarse o bien: 450 dias.

Eso si no cambiara nada PEEEERO

Aqui empieza lo mágico de las metodologías agiles.

Cada vez que se termina un “sprint” (periodo de 15 dias, aunque algunos equipos usan 20 o 10 dias) se presenta el producto “terminado” y se pregunta si es lo que se esperaba, si no, se agregan los cambios al siguiente sprint, si si lo es entonces continuamos, PEEERO, continuamos con lo que nos diga el cliente, y como va a tener estimados de las historias de su sistema el cliente ahora va a elegir los siguientes 50 puntos que quiere que se hagan, obviamente es una desición consensual ya que el equipo ayuda al cliente a elegir aquello que le de valor a su negocio y que le permita al equipo desarrollar más rápido el sistema.

Y si el cliente cambia de opinion o algo no le gusta no se pierde mas que 15 dias de trabajo. Digamos que al cliente le gustaria mejor que se puedan hacer compras online a que se puedan registrar a una mailing list, no problem, eso se agrega en el siguiente sprint. Si eso implica dejar fuera unas historias pues así será, si requiere crear nuevas pues se hace y se estiman las nuevas historias.

En si eso son las metodologias agiles, y en el ejemplo anterior SCRUM.

Ahora bien, yo creo que no son tan usadas no por que sean malas o no funcionen, estas metodologias realmente funcionan, las grandes empresas van migrando poco a poco a estas metodologias por que saben que entregan resultados, sin embargo aun no se adoptan completamente. Por que?

Yo creo sinceramente que la industria detras de las “no agiles” es muy fuerte y hay inversiones muy fuertes en ellas, se crean certificaciones millonarias para que las empresas cumplan con standares que les permitan minimizar riesgos y darles un titulo de  “empresa certificada con CMMI level 3” que te asegura cierto control.

Eso aun falta un poco aqui. ADEMAS de que la cultura agil desmotiva los esfuerzos de certificar a la gente ya que no deberia ser un requerimento, o se sabe o no se sabe, (pero eso lo veré en otro post lo prometo, por que este ya está muy largo)

En fin, yo les digo por experiencia. Funcionan, y funcionan muy bien. (como la sección amarilla :p)

Espero les sea útil para ver que no todo son procesos labrados en piedra, rigidos y pesados.

Download Complete