El otro día, durante el desayuno de arquitectos que tuve la suerte de disfrutar, amén de cafés, medialunas y jugos, lo más interesante fue escuchar jugosos comentarios acerca de la implementación de scrum y otras metodologías ágiles en proyectos de software. Agradezco a Martín Salías y Juan Ladetto que me invitaron.
No esperes una "Bala de Plata"
En algún momento parecieron repetirse ciertos argumentos críticos acerca de scrum. En la mayoría de los casos, estos argumentos, basados en problemas, limitaciones, obstáculos, suelen darse en cualquier proyecto de software, más allá de la metodología de turno.
Y así fue cuando algunos de los que expusieron sus opiniones a favor de scrum, terminaron coincidiendo en esta idea "no esperes una bala de plata". Esto no resuelve todos los problemas... no es magia ni la panacea.
Scrum ofrece algunos beneficios, los cuales se producirán dependiendo del contexto, empresa, proyecto, integrantes del equipo, etc. No es aplicable a todos los casos; tampoco asegura el éxito.
Con esto quiero decir, que si tenemos la limitante X en un proyecto de software, esa limitante va a afectar al proyecto, más allá de si usamos Scrum, MSProject, CMMI, RUP o lo que sea. Seguramente algunas limitantes serán mejor absorbidas en alguna u otra metodología; pero ninguna es perfecta.
Por otro lado, tampoco podemos implementar "libremente" Scrum, y luego si el proyecto falla decir "Scrum falló en mi proyecto". Si no apliqué las reglas convencionales, y sólo usé las que más me gustaban o me parecían, pero sin usar todas las reglas... entonces no apliqué Scrum, sólo incorporé algunas prácticas de éste.
Disciplina: Agil no es relajarse
Un mito que existe, es que al ser àgil, no se documenta, o bien se relajan ciertos aspectos, basados en cierta "informalidad".
Pues parece que todo esto no es cierto. Aplicar metodologías ágiles significa utilizar una disciplina quizás aún mayor que en otras metodologías. Hablando de Scrum, hay reglas que deben cumplirse a rajatabla si queremos que el proyecto sea exitoso; habrá adaptaciones y atenuantes según el caso, pero se debe ser disciplinado. No podemos tener sprint de 1 semana, y luego otro de 2; no podemos aceptar modificaciones al sprint backlog en medio del sprint; no podemos, no podemos, no podemos.
Agil significa ser "livianos", no cargarse de más, focalizar todo nuestro esfuerzo en producir y llegar hasta la siguiente meta. La frase del "paso a paso" de Reynaldo Merlo, no podría aplicarse mejor que en este caso.
Bueno, seguiremos hablando de estos temas... hay mucha tela por cortar.
miércoles, 23 de julio de 2008
sábado, 19 de julio de 2008
Scrum, Scrum y más Scrum
Bien, después de una semana sumamente interesante, donde parecen haber concluído algunos procesos (como el conflicto con el campo, que espero se termine, y más allá de las diferencias y temas por resolver pendientes, el país "camine"), se dio particularmente una semana Scrum en mi caso, con un curso práctico -corolario de otro teórico que hiciera hace un par de semanas- más un encuentro con otros arquitectos, en el cual se compartieron experiencias, opiniones y se debatió sobre pros y contras de Scrum, hicieron que en mi cabeza se agolparan unas cuantas ideas que no tenía hasta la semana pasada.
El juego en acción
La práctica del curso de Scrum de Angel "Java" López fue muy interesante. Me vi jugando al scrum (decir esto me hace acordar al "Scramble") con un equipo que tenía consignas precisas, aunque no detalladas.
El objetivo del equipo era desarrollar, un juego que sirviera para enseñar los propósitos del scrum. Honestamente, cuando vi los objetivos, fue una total falta de fe en obtener algo concreto. Los primeros momentos fueron de confusión y debates más largos de lo esperado (aunque no muy extensos, en realidad), pero en eso Angel se puso firme en tratar de mantener el concepto de "timebox". Este es un concepto interesante, que usan las metodologías ágiles, y que buscan "poner en caja" el tiempo usado para cada tarea.
El tiempo en una caja
Si proponemos a un equipo que discuta sobre un problema a resolver, y lo dejamos un buen rato, y volvemos a verlos más tarde, es probable que al interrumpirlos y preguntarles a qué conclusión llegaron o que resolución tomarían, todavía no haya un acuerdo o bien se desviaron del tema original porque había otros "problemas laterales por resolver".
Si le dejamos a un desarrollador que desarrolle una tarea específica, pero con ciertas libertades o ambigüedades, y lo dejamos solo por un tiempo, al verlo nuevamente y revisar que hizo, es probable que lo haya terminado, pero que no haya hecho exactamente lo que se le pidio, o se trabó con algo y directamente abortó el desarrollo, o hizo lo que se pedía pero con una docena de adornos más que, en el mejor de los casos, ayuda sin obstruir al pedido inicial.
Estas dos situaciones, hipotéticas, no apuntan a desmerecer el valioso trabajo de un equipo o un desarrollador o cualquiera sea el caso; sino a que, ante la falta de un objetivo específico, o de un límite de tiempo, etc, cualquiera se distrae, o se traba, o se va por las ramas, teniendo en cuenta además de que hay otros factores en el medio (motivación, problemas de recursos, etc)
Y teniendo en cuenta que muchas veces, los requerimientos que podemos obtener tienen límites difusos o temas sin resolver o analizar... hace que los tiempos se disparen. Entonces, ¿qué mejor que poner en una caja el tiempo? Si cambiamos estos 2 planteos por "hay que resolver este problema, el tiempo disponible es 2 horas", estas personas sin dudas dirigirían todos sus esfuerzos y enfoque destinado a que al término de esas 2 horas, tengan algo, aunque sea erróneo.
¿Y si nos equivocamos?
Y aquí me detengo en otro punto. El miedo al error. Esto nos hace sobreanalizar muchos temas, nos hace adelantar varias jugadas como un jugador de ajedrez, lo que muchas veces nos hace olvidar el problema inmediato que tenemos enfrente. Tenemos miedo al error. Tenemos miedo de implementar algo que no sirva, o que sea de "mala calidad".
Ponernos un milestone rígido, atenta posiblemente contra la calidad de resultado, pero nos brinda otra cosa: la posibilidad de avanzar y revisar continuamente la dirección tomada. La consigna es "no hay mas tiempo para discutir, hagamos esto veamos que pasa". Total, el punto de control es pronto, y entonces, pronto nos daremos cuenta si sirve o no.
El problema es que seguimos pensando con un enfoque tradicional, prescriptivo, analizando previamente todas las alternativas, y creyendo que debemos evitar de antemano algo que, posiblemente termine 2 meses después.
Agiles como peces en el agua
Y aquí es donde se nota la mano de "ser ágil", o, si prefieren, seguir la movida ágil. Porque las prácticas de iteraciones continuas y con períodos cortos, nos dan la posibilidad de medir continuamente si tomamos la dirección correcta, pero nos fuerza a avanzar y no quedarnos inmovilizados con trabas o divagues.
Posiblemente estos conceptos, no sean aplicables en todos los casos. Habrá casos (y de esto he hablado en todo lo relacionado al movimiento "Slow") en que Scrum no sea aplicable, que metodologías ágiles no sean aplicables, aquí la cosa parece un espiral de velocidad. Pero no lo es tanto... En otras metodologías sufrimos presiones y debemos meter, no sólo tiempo en una caja. Debemos meter, tiempo, alcance y costos en una caja, que por lo general, alguna de las 3 variables, se escapa... y ni hablar cuando se escapa más de una, explota con caja y todo.
Aquí se trata de sacar el "alcance" de la caja. Pero dejemos dentro el costo y el tiempo, debemos saber administrar los recursos eficientemente.
Fin del juego
Bueno, para resumir, porque llegué a mi "fin de tiempo" para escribir este artículo :), el juego resultó muy interesante. En 2 sprint virtuales, de media hora de duración cada uno, armamos un juego con tablero, cartas, y reglamento escrito con todas la reglas.
Honestamente, no creí desde el principio que lo obtendríamos. Creí que nos íbamos en divagues y que a los sumo, tendríamos algunas reglas o ideas escritas nada más. Pero aplicamos los conceptos que comenté en este artículo y las cosas fluyeron. Se notó incluso, el esfuerzo del equipo y aceleramos cuando hubo que acelerar. Me sentí haciendo fuerza en la montonera del scrum de rugby ;)
El juego en acción
La práctica del curso de Scrum de Angel "Java" López fue muy interesante. Me vi jugando al scrum (decir esto me hace acordar al "Scramble") con un equipo que tenía consignas precisas, aunque no detalladas.
El objetivo del equipo era desarrollar, un juego que sirviera para enseñar los propósitos del scrum. Honestamente, cuando vi los objetivos, fue una total falta de fe en obtener algo concreto. Los primeros momentos fueron de confusión y debates más largos de lo esperado (aunque no muy extensos, en realidad), pero en eso Angel se puso firme en tratar de mantener el concepto de "timebox". Este es un concepto interesante, que usan las metodologías ágiles, y que buscan "poner en caja" el tiempo usado para cada tarea.
El tiempo en una caja
Si proponemos a un equipo que discuta sobre un problema a resolver, y lo dejamos un buen rato, y volvemos a verlos más tarde, es probable que al interrumpirlos y preguntarles a qué conclusión llegaron o que resolución tomarían, todavía no haya un acuerdo o bien se desviaron del tema original porque había otros "problemas laterales por resolver".
Si le dejamos a un desarrollador que desarrolle una tarea específica, pero con ciertas libertades o ambigüedades, y lo dejamos solo por un tiempo, al verlo nuevamente y revisar que hizo, es probable que lo haya terminado, pero que no haya hecho exactamente lo que se le pidio, o se trabó con algo y directamente abortó el desarrollo, o hizo lo que se pedía pero con una docena de adornos más que, en el mejor de los casos, ayuda sin obstruir al pedido inicial.
Estas dos situaciones, hipotéticas, no apuntan a desmerecer el valioso trabajo de un equipo o un desarrollador o cualquiera sea el caso; sino a que, ante la falta de un objetivo específico, o de un límite de tiempo, etc, cualquiera se distrae, o se traba, o se va por las ramas, teniendo en cuenta además de que hay otros factores en el medio (motivación, problemas de recursos, etc)
Y teniendo en cuenta que muchas veces, los requerimientos que podemos obtener tienen límites difusos o temas sin resolver o analizar... hace que los tiempos se disparen. Entonces, ¿qué mejor que poner en una caja el tiempo? Si cambiamos estos 2 planteos por "hay que resolver este problema, el tiempo disponible es 2 horas", estas personas sin dudas dirigirían todos sus esfuerzos y enfoque destinado a que al término de esas 2 horas, tengan algo, aunque sea erróneo.
¿Y si nos equivocamos?
Y aquí me detengo en otro punto. El miedo al error. Esto nos hace sobreanalizar muchos temas, nos hace adelantar varias jugadas como un jugador de ajedrez, lo que muchas veces nos hace olvidar el problema inmediato que tenemos enfrente. Tenemos miedo al error. Tenemos miedo de implementar algo que no sirva, o que sea de "mala calidad".
Ponernos un milestone rígido, atenta posiblemente contra la calidad de resultado, pero nos brinda otra cosa: la posibilidad de avanzar y revisar continuamente la dirección tomada. La consigna es "no hay mas tiempo para discutir, hagamos esto veamos que pasa". Total, el punto de control es pronto, y entonces, pronto nos daremos cuenta si sirve o no.
El problema es que seguimos pensando con un enfoque tradicional, prescriptivo, analizando previamente todas las alternativas, y creyendo que debemos evitar de antemano algo que, posiblemente termine 2 meses después.
Agiles como peces en el agua
Y aquí es donde se nota la mano de "ser ágil", o, si prefieren, seguir la movida ágil. Porque las prácticas de iteraciones continuas y con períodos cortos, nos dan la posibilidad de medir continuamente si tomamos la dirección correcta, pero nos fuerza a avanzar y no quedarnos inmovilizados con trabas o divagues.
Posiblemente estos conceptos, no sean aplicables en todos los casos. Habrá casos (y de esto he hablado en todo lo relacionado al movimiento "Slow") en que Scrum no sea aplicable, que metodologías ágiles no sean aplicables, aquí la cosa parece un espiral de velocidad. Pero no lo es tanto... En otras metodologías sufrimos presiones y debemos meter, no sólo tiempo en una caja. Debemos meter, tiempo, alcance y costos en una caja, que por lo general, alguna de las 3 variables, se escapa... y ni hablar cuando se escapa más de una, explota con caja y todo.
Aquí se trata de sacar el "alcance" de la caja. Pero dejemos dentro el costo y el tiempo, debemos saber administrar los recursos eficientemente.
Fin del juego
Bueno, para resumir, porque llegué a mi "fin de tiempo" para escribir este artículo :), el juego resultó muy interesante. En 2 sprint virtuales, de media hora de duración cada uno, armamos un juego con tablero, cartas, y reglamento escrito con todas la reglas.
Honestamente, no creí desde el principio que lo obtendríamos. Creí que nos íbamos en divagues y que a los sumo, tendríamos algunas reglas o ideas escritas nada más. Pero aplicamos los conceptos que comenté en este artículo y las cosas fluyeron. Se notó incluso, el esfuerzo del equipo y aceleramos cuando hubo que acelerar. Me sentí haciendo fuerza en la montonera del scrum de rugby ;)
martes, 15 de julio de 2008
1+1=3
Hace rato que no escribia. Tengo siempre temas, pero poco tiempo. Desde mi ultima entrada hasta hoy, tengo temas desde el curso de Liderazgo que hice, que termine el año pasado, pasando por cursos que hice este año, un poco más variados. Este año hice cursos de UML, Ajax, Scrum.
Y a propósito de Scrum, porque la cosa sigue esta semana con prácticas (mañana en el MUG, la parte práctica del curso de Scrum con Angel "Java" López, la continuación donde espero ver los "pingos" en la cancha), y al día siguiente, desayuno de arquitectos en Microsoft cuyo tema central será, casualmente, Scrum. Y allí participará Martín Salías quien hace rato trabaja en el tema, entre otros.
Pero lo que quería comentar, y que tiene que ver con el título, es la fuerza de la suma de las voluntades. Si hablamos de Scrum, de Agile, entre otras cosas, y hablando de las últimas tendencias, encontramos que de la suma de 2 voluntades, obtenemos un resultado mayor a 2; o al menos tenemos esa posibilidad.
También pensaba que difícil es lograr eso. Con sumar 2 personas no alcanza. En algunos casos, sumarlas nos puede dar -1! Para lograr que el resultado sea mayor a 2, que creo es el esperado... hay que trabajar, y de forma inteligente.
Pero cuando se logra... es asombroso. Pensaba en mis hijos. Cuando tenia sólo a mi hija, pensaba lo difícil que era criarla. Pero me daba muchas alegrías. Cuando nació mi segundo hijo... en cuanto a problemas por resolver, se cumplió 1+1=3; además de atender y criar a la mayor, y de atender y criar al menor, quien reclamaba atención a los gritos (como todo buen bebé), hubo que resolver las problemáticas nuevas; los celos de la mayor, explicarle la nueva situación, dejarla en la casa de alguien para darnos una mano; etc.
Ahora, esa complejidad va aumentando, pero vemos "beneficios". Ambos se enriquecen sólo de estar juntos, se entretienen y juegan juntos, lo cual requiere "menor" atención de nosotros los padres. Las comillas las pongo porque es relativo; pero es verdad que si bien hay que estar atentos, no requieren atención "presencial y permanente" como antes sólo con una.
Eso mismo, sucede con un equipo. Enseñarle reglas y ver como interactúan... y producen, debe ser una de las mejores satisfacciones que da el poder conducirlo, guiarlo.
Será hasta la próxima... cuando aprenda algo más del mundo Scrum.
Y a propósito de Scrum, porque la cosa sigue esta semana con prácticas (mañana en el MUG, la parte práctica del curso de Scrum con Angel "Java" López, la continuación donde espero ver los "pingos" en la cancha), y al día siguiente, desayuno de arquitectos en Microsoft cuyo tema central será, casualmente, Scrum. Y allí participará Martín Salías quien hace rato trabaja en el tema, entre otros.
Pero lo que quería comentar, y que tiene que ver con el título, es la fuerza de la suma de las voluntades. Si hablamos de Scrum, de Agile, entre otras cosas, y hablando de las últimas tendencias, encontramos que de la suma de 2 voluntades, obtenemos un resultado mayor a 2; o al menos tenemos esa posibilidad.
También pensaba que difícil es lograr eso. Con sumar 2 personas no alcanza. En algunos casos, sumarlas nos puede dar -1! Para lograr que el resultado sea mayor a 2, que creo es el esperado... hay que trabajar, y de forma inteligente.
Pero cuando se logra... es asombroso. Pensaba en mis hijos. Cuando tenia sólo a mi hija, pensaba lo difícil que era criarla. Pero me daba muchas alegrías. Cuando nació mi segundo hijo... en cuanto a problemas por resolver, se cumplió 1+1=3; además de atender y criar a la mayor, y de atender y criar al menor, quien reclamaba atención a los gritos (como todo buen bebé), hubo que resolver las problemáticas nuevas; los celos de la mayor, explicarle la nueva situación, dejarla en la casa de alguien para darnos una mano; etc.
Ahora, esa complejidad va aumentando, pero vemos "beneficios". Ambos se enriquecen sólo de estar juntos, se entretienen y juegan juntos, lo cual requiere "menor" atención de nosotros los padres. Las comillas las pongo porque es relativo; pero es verdad que si bien hay que estar atentos, no requieren atención "presencial y permanente" como antes sólo con una.
Eso mismo, sucede con un equipo. Enseñarle reglas y ver como interactúan... y producen, debe ser una de las mejores satisfacciones que da el poder conducirlo, guiarlo.
Será hasta la próxima... cuando aprenda algo más del mundo Scrum.
Suscribirse a:
Entradas (Atom)