Agiles 2008

Que placer ha sido ver un evento de estas características. Un evento bien organizado, con excelentes contenidos... y hecho a pulmón. Como escuché por ahí, hecho con "garra y sangre".

No dejo de felicitar a los organizadores, speakers, voluntarios, y todos los que estuvieron allí.

Me conmovió la emoción al final de Martín Salías, lo que refleja el nivel de compromiso, esfuerzo y expectativas que todo esto tenía para ellos.

Algunas impresiones

Tengo varias ideas dando vueltas en mi cabeza... todavía no he podido asentarlas, pero voy a tratar de volcar algo aquí.

Una impresión que tengo, es que esto no es una movida de unos pocos locos e improvisados. Realmente el nivel y solidez de lo expuesto, y cierta coherencia general en algunos temas, hace pensar que esto es más serio de lo que muchos piensan.

De nuevo: no hay modelo unificado

Otra impresión es que no hay tampoco una idea unificada en algunos temas... como todo hay ideas que confluyen, pero también distintas corrientes de pensamiento y puntos de vista. Esto se vio claramente en el panel final... donde entre los panelistas hubo algunas diferencias. De todos modos esto me parece que enriquece y además que nos recuerda ideas como "esto no es la solución final"... o de nuevo "no hay bala de plata"... y también "no hay nada escrito para lo que hay resolver, hay que buscar la solución".

Proceso de cambio

También observé que estamos en el medio de un proceso de cambio. Venimos de ciertas estructuras tradicionales, con recetas extraídas de otros contextos. El nuestro (Desarrollo de Software) es una especialidad que, a pesar de haber transcurrido medio siglo, es relativamente nueva (no podemos ni compararnos con la antigüedad en las profesiones de los médicos, abogados, ingenieros, artistas, etc), con lo cual es esperable pensar que aún tenemos mucho por madurar. Somos parte de una "profesión en vías de desarrollo". Al mismo tiempo, el mundo ha cambiado muchísimo, en particular en los últimos años.

No obstante, algunas cosas no han cambiado tanto. Somos humanos, y nuestra esencia se mantiene. Algunas de las ideas expuestas, nos recuerdan eso y lo importante que eso es.

Como en todo proceso de cambio, hay incertidumbre. Veo eso en muchos aspectos. Es difícil saber qué pasará, difícil saber que cosa es correcta y que no, difícil ubicar cada cosa en su lugar, todo esto cuesta trabajo, esfuerzo y una constante revisión de nuestra forma de pensar y actuar. Por lo tanto, es esperable que este proceso sea largo.

Esas raras ideas nuevas

De la charla inicial de Mary Poppendiek, vimos que estas nuevas ideas ágiles... en realidad no son tan nuevas, ni tan raras. En un brillante repaso de hitos y conceptos de la historia del desarrollo de software... vimos que muchas de las ideas que se están aplicando ahora... fueron aplicadas hace 10, 20, 30 años atras!!!

Debe ser por eso, que algunos conceptos... son tan naturales. Aunque hemos incorporado una cultura tan anti-natural, que nos cuesta despojarnos de ella para volver a ser "nosotros".

Para terminar, les dejo esta pregunta....

¿Estamos protagonizando el cambio?

Hasta la próxima.

Libros, Riesgos, etc

Libros riesgosos

Les cuento un poco en que ando respecto de la lectura. Gracias a la magia de Amazon, estoy leyendo los siguientes libros:

• Pro C# 2008 and .Net 3.5 Platform, Andrew Troelsen: Un librito de tapa dura, de 1370 páginas, ideal para llevar en el subte D a las 9 de la mañana. Debe pesar más de 1 kilo, pero bien vale su peso. Se puede leer de todo en él, aunque algunos temas como "Web Services", los pasa de largo (y tambien, no alcanza para meter todo en un solo libro). De algunos temas se los trata a nivel introductorio, especialmente los temas nuevos. Hay un capítulo acerca de WCF y supongo que por eso se pasaron de largo los Web Services.
• Waltzing with Bears, Tom DeMarco & Timothy Lister: Una joyita. Del escritor de PeopleWare (del cual comentan mucho y yo apenas lei sólo algunos capítulos hace algunos años... que mal). El tema del libro es: "Manejo de riesgos en proyectos de software". Después les comento más de este librito. Comparado con el bodoque de C#... este no llega a las 200 páginas, pero les aseguro que vale cada página que tiene. Este si lo podés llevar en el subte (y dale con el subte)
• Pragmatic Unit Testing, in C# with NUnit, Andrew Hunt y David Thomas with Matt Hargett: De este no puedo hablar mucho porque poco leí hasta el momento.. puedo decirles que es un tema que me tiene agarrado y no me suelta.. después les hablo un poco más.
• Tengo por ahí algunas lecturas, entre las más destacadas "Foundation of programming", un ebook que se puede bajar gratis (y legalmente gratis, digo) de la web. Interesante compendio de buenas prácticas de programación con C#. También un par de ebooks de Agile patterns y Adopción de Scrum.

¿Riesgos? Nooooo va a andar todo bien...

Bien, hablando de este librito de los riesgos, y cuando digo "librito" lo hago cariñosamente, le tengo aprecio. Son esos libros que te dan gusto leer y sentís que le sacás el jugo. Tiene algunos conceptos y frases memorables. Para citar alguna:

"Risk management is project management for adults".

De lo que habla es que, a esta altura, si estamos manejando un proyecto (y seguramente debe referirse a cualquier proyecto, no sólo de software), si no estamos haciendo algo con los riesgos.. entonces somos adolescentes jugando a manejar proyectos. No podemos ponernos una venda en los ojos y darle pa'frenchi como si no hubiera riesgos; los riesgos están, y hay que enfrentarlos. Nada de esconder la cabeza como un avestruz, sepamos dónde están los riesgos y definamos una estrategia ante ellos.

Hay una actitud muy positiva y valorada, que es la de "puedo hacerlo". El manejo de riesgos no va contra esa actitud, pero tomar un proyecto complejo, en circunstancias complicadas, y prometer que estará listo para una fecha que de antemano se sabe es imposible de cumplir, no nos va a llevar muy lejos.

La idea es conocer los riesgos, y tomar decisiones, en donde en algunos casos puede dar lugar a decir "ok, sé que tengo todo en contra pero apuesto a que esto funcione. Tengo confianza en tal y tal". Eso es distinto, en todo caso tendremos dentro nuestro a "un jugador empedernido" que se juega hasta la coronilla pero no un "cabeza de avestruz" que mete la cabeza en la boca del león... sin saber ni querer sabre donde se mete.

Sobre esto hay tela para cortar.... cuando avance más con el libro les cuento.

Architectum Forum en Microsoft

Este architectum forum fue hace un mes largo ya, pero aprovecho que comente algo de unit testing para repasar algunos temas.

Sólo pude presenciar un medio día, pero el que estuve fue muy interesante. Se hablaron de algunos productos de Microsoft, como son Visual Studio Team System, TFS (Team Foundation Server, si la memoria no me traiciona), y Rosario (el codename del próximo Team System).

Hicieron algunas demostraciones y la verdad que me llevé buenas impresiones.

• Testing: Sí, con VSTS se pueden crear unit test en forma automática. También mostraron test de carga y tomados de una fuente de datos.
• Code Analysis: Se puede saber el porcentaje de cobertura de los tests y analizar el código. Se validan reglas (las cuales se pueden configurar) y con eso se llega a un número, un indicador de calidad de código.
• Validaciones: Una facilidad que me pareció piola es que se puede validar esas reglas.. al hacer checkin del código. Es decir, si el fuente que subo, si bien compila y funciona, no cumple con alguna de las reglas que el team defina como excluyentes... no puedo subir el fuente. Es como si no compilara.
• Manejo de fuentes mejorado: Bueno, el viejo amigo Source Safe.. cumplió con creces su cometido. Pero ahora necesitamos, y desde hace rato, algo mejor. El manejo de branches es algo que desde el open-source SVN viene haciendo hace tiempo y es sumamente importante. Pues bien, el manejador de fuentes de TFS tiene eso.
• Respecto de TFS, trae un SharePoint y permite administrar proyectos completos, con documentación versionada, items, issues, etc. Todo personalizable.
• Rosario: Prometen mejoras más profundas en esta nueva versión... veremos que pasa.

Scrum, Agiles, Disciplina?

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.

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 ;)

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.