viernes, 17 de septiembre de 2010

Juegos para aprender en Ágiles@BsAs


Luego de una breve interrupción, la comunidad ágil de bs. as. retomó sus encuentros de los miércoles, esta vez en la oficinas de SouthWorks.

La propuesta en este caso fue realizar juegos ágiles en un formato open space. Junto con Ingrid Astiz y Adrian Eidelman preparamos la siguiente visión de la actividad:
La idea de este encuentro es experimentar trayendo a la comunidad juegos nuevos e invitar a quienes estén interesados en practicar habilidades de facilitación a guíar un juego. Proponemos salir de los juegos convencionales que se hacen generalmente en los cursos y poner un poco de nuestra creatividad para descubrir juegos nuevos o poco conocidos, introducir alguna variación a uno conocido que permita otra experiencia y porque no inventar alguno.
Estos fueron los juegos que propusieron los participantes (probablemente me olvide algún juego o facilitador). Algunos de los juegos tienen link (x si alguien quiere facilitarlo alguna vez):
Fue un encuentro muy divertido, donde todos aportamos algo proponiendo juegos, participando, debatiendo, etc y creando entre todos un lindo espacio para aprender.

ahh, gracias Martín Salías x las fotos!

lunes, 30 de agosto de 2010

Armando un campamento colaborativamente - 1ra parte


El sábado pasado nuevamente los chicos del clan del grupo scout Santa Cruz fueron víctimas de otro experimento. La actividad para el sábado era armar la planificación del próximo campamento de grupo.

Para calentar los motores, hicimos el juego pair draw, para experimentar el potencial de trabajar por pares.

Luego elaboramos el marco del campamento (o visión). Para eso hicimos un ejercicio muy simple. De a pares armamos una lista de posibles marcos. Luego nos juntamos de a 4 y armamos una nueva lista. Finalmente, armamos una propuesta entre todos y quedó "32 bit camp", relacionado con los juegos tipo Monkey Island, Age of Empires y Mario Bross, que fueron los marcos finalistas.

El siguiente paso fue armar un conjunto de propuestas de actividades, encuadradas bajo el marco propuesto. Para eso cada uno escribió las actividades que se le ocurrieron en un hoja. Luego pasábamos la hoja al de al lado, tomábamos la del compañero y usábamos las actividades escritas como disparadores de nuevas ideas (triple nickels).

Al finalizar pegamos las propuestas en un pizarrón y las priorizamos por puntos.


Luego, hicimos un juego conocido cómo "censo de paises", para aprender a estimar colaborativamente:



y aplicamos lo que aprendimos p/estimar las actividades del campamento haciendo planning poker, empezando por las que consideramos más importantes:



Si bien no pudimos terminar ese día con la planificación, hicimos lo mejor posible enfocándonos en las cosas que nos parecieron importantes.

Esta historia continuará...

jueves, 12 de agosto de 2010

Scrum Master: un trabajo que no es fácil



Scrum es simple, pocas reglas, basado en principios, técnicas simples, pero muy difícil de implementar. El trabajo del scrum master, dueño del proceso, no es un trabajo fácil ya que encierra grandes desafíos. Pero, con algunas distinciones, se pueden abrir un mundo de posibilidades:

  • El entregable es el producto y el equipo (vía @ajlopez)
    http://msmvps.com/blogs/lopez/archive/2009/08/06/tales-from-the-scrum-su-equipo-el-pr-243-ximo-nivel.aspx
  • Una buena manera de mejorar un proceso estable es cambiando el proceso. Acelerarlo probablemente lo empeore.
  • Un equipo no es más productivos cuando el pipeline de trabajo está lleno. Si se maximiza la asignación de recursos, no se obtiene el mejor rendimiento. Un equipo a full es cómo un motor sin aceite, puede que todas las piezas encajen a la perfección, pero necesitamos del aceite para que funcionen bien en movimiento.
  • Facilitar el proceso en lugar de dirigirlo. Cuando vemos que algo no funciona bien, en lugar de intervenir directamente y corregirlo, podemos ser un espejo que refleje los problemas que vemos al equipo y dejar que ellos encuentren la mejor manera de resolverlos.
  • Cultivar vs construir. El trabajo de un scrum master tiene más que ver con cultivar que construir, ya que no controlamos directamente el resultado. Verlo de esta manera ayuda a poner el foco en generar las condiciones para que el equipo sea auto organizado y colaborativo.
  • Ritmo. Cambiar de ritmo tiene costo, ya sea que se acelera o desacelera la velocidad.
  • Las personas no somos buenas haciendo multi-tasking.
  • Una visión: calidad, productividad y felicidad.
  • Ideas de Lisa Adkins.
  • “No temas a los errores. No los hay.” – Miles Davis. El error es una inversión en aprendizaje.

saludos!

lunes, 9 de agosto de 2010

Asado y scrum con los chicos de la Cooperativa Hormingón



Ayer junto con mi amigo Clodo, facilitamos un taller de scrum para los chicos de la cooperativa Hormigón. La verdad fue una experiencia muy buena para todos.

Algo interesante que hicimos, a diferencia de otros talleres, es que en este construimos la visión en conjunto, haciendo un juego conocido como tríbus y nos quedó esto:

"Mejorar el método de laburo que venimos construyendo hace 3 años con técnicas nuevas"

Para conseguir la visión, escribimos para cada actividad el nombre, el para que y la duración y les pedimos a ellos que las prioricen según lo que ellos consideran los acerca más a la visión. Nos quedó así:
  • Máquina humana, para entender la esencia de la colaboración y el ritmo, 20'
  • Multitasking, para entender porqué es bueno focalizarse, 10'
  • Pelotas, para entender porque es importante la retrospectiva, 10'
  • Supervivencia, para entender cómo priorizar riesgos, 30'
  • Pajarraco, para aprender a construir algo empíricamente, 60'
  • Censo de Paises, para estimar guiados por consenso, 10'
  • Pair drawing, para entender el potencial de la colaboración, 20'
  • Retrospectiva, 20'

Al finalizar cada una de las actividades, hicimos una ronda de preguntas abiertas que nos permitieran descubrir qué cosas aprendimos y contrastar cómo los principios de scrum ayudan a mejorar el trabajo en equipo.

Tuvimos algunos imprevistos, como un gran asado y algunas actividades que nos llevaron un poco más de tiempo. Al final hicimos una retrospectiva del taller, se nos hizo un poco largo, gustó la didáctica y aprendimos herramientas para trabajar mejor. Uno de los juegos que más sorprendió a todos fue el de multitasking y el de estimación (países)

saludos!

domingo, 8 de agosto de 2010

Un poco de supervivencia para priorizar riesgos



Algo que me parece interesante de las actividades al aire libre, es que la naturaleza es un gran escenario de aprendizaje. Particularmente, la supervivencia en terrenos agrestes es un juego muy bueno para priorizar riesgos en un entorno cambiante. Esta es una actividad que hicimos hoy con los chicos de la cooperativa Hormigón:

"Somos un grupo de 4 personas que viajamos en avioneta cruzando los andes. Mientras cruzábamos por la zona de Bariloche, uno de los motores empieza a fallar y el avión se estrella. Lamentablemente el piloto no sobrevive al accidente. En cambio, los 4 tripulantes consiguen sobrevivir sin lesiones de gravedad. Son las 3 de la tarde, nos encontramos en un bosque nevado rodeado de montañas. Es el mes de agosto y sabemos que durante el día hace 0 grados aprox y por la noche puede bajar a -20. Sabemos que estamos a 40km de la ciudad y escuchamos a lo lejos el ruido de un arroyo. ."

El ejercicio consiste en priorizar en 10 minutos la siguiente lista de cosas para sobrevivir:
  • encendedor sin bencina
  • hacha
  • pistola calibre 45 c/1 bala
  • espejo
  • diarios (1 por persona)
  • virulana
  • ropa extra
  • naylon de 3x2
  • mapa
  • botella de whisky
  • brújula
  • 1 chocolate familiar
Algunas preguntas interesantes para hacer al finalizar la lista:
  • Si solo pudieran elegir 1 elemento, se sienten conformes con la priorización que hicieron?
  • Y si pudieran elegir 3?
La siguiente consigna es armar en 10 minutos una lista de los riesgos del escenario identificando para cada uno el impacto y la probabilidad de ocurrencia (alto, medio, bajo) y priorizarlos (1ro lo que tiene más impacto y más probabilidad).

La tercer consigna es volver a priorizar en 10 minutos la lista de cosas, pero teniendo en cuenta los riesgos identificados. Es decir, tengo que elegir primero las cosas que me cuidan de los riesgos más graves.

Al finalizar, algunas preguntas para debatir:
  • En cual de las 2 listas sienten que tienen más chances de supervivencia?
  • Les parecen útiles la distinción de impacto y probabilidad de ocurrencia para priorizar riesgos?
  • De qué otra manera lo harían?
  • Cómo fue el proceso de toma de decisiones al elaborar las 2 listas? Qué diferencias encontraron?
  • Encontraron en este juego alguna similitud con la realidad?

Este juego es una variación de este otro:

saludos!

sábado, 7 de agosto de 2010

Scouts, scrum y panchos



El viernes pasado con mi amigo Clodo hicimos un taller con la siguiente visión "Aprender herramientas para resolver problemas con recursos limitados". Las víctimas fueron los chicos del Clan del grupo Scout Santa Cruz.

La idea era darles herramientas a los chicos que los ayudaran a ponerse objetivos y cumplirlos. Apuntamos a enseñar los principios en lugar de la técnica o las recetas. En general los problemas que les tocan resolver tienen que ver con supervivencia, organizar un servicio, hacer un bastón (revista interna), etc. En todos ellos cuentan con recursos limitados para poder hacerlo. Así que tomando los principios de scrum, quisimos presentarles estas distinciones:
  • Empirismo
  • Priorización
  • Ritmo
  • Auto-organización
  • Colaboración
Para eso, hicimos una serie de juegos que nos permitieron ver cómo estos principios afectan a un equipo y nos ayudan a conseguir productividad, calidad y felicidad.

Uno de ellos fue "multitasking", donde vimos que las personas no somos buenas haciendo varias cosas al mismo tiempo:

El "pajarraco", facilitado por el mostro:

Acá está el pájaro mitológico Hozambique y su hijito:

En este juego aprendimos la importancia de priorizar las cosas que más valor me dan con menor costo y las ventajas de trabajar usando un proceso empírico:

También hicimos otros, como la "máquina humana" para experimentar los cambios de ritmo y el potencial de la colaboración, y "pelotas" para entender el valor de la inspección y adaptación (empirismo).

Fue una linda noche, terminamos con una picada y unos panchos.

saludos!

viernes, 30 de julio de 2010

lunes, 21 de junio de 2010

La rueda loca en una servilleta



Esto que algunos llamamos #laruedaloca de Hacer Historia, es una herramienta para diseñar la coordinación de las conversaciones necesarias para producir valor en mis clientes (donde el valor es un juicio de los clientes).

Con esta "simple" herramienta podemos descubrir espacios de acción que no teníamos en claro, pensar en los posibles quiebres que pueden ocurrir, cosas que pueden salir mal, darnos cuenta de qué cosas necesitamos pedir y a quien, ya que no se puede hacer todo solo.

Sin entrar en detalles me gustaría contar lo que hay en el medio de la rueda. La rueda gira en torno a las preocupaciones de mis clientes, que tienen que ver con:
  • Ver el negocio en dimensiones que hasta entonces no podía ver.
  • Entender mejor su negocio para conseguir objetivos particulares (bajar costos, expandir el negocio, aprovechar mejor los recursos, etc).
  • Contar con información clave a tiempo para tomar decisiones.

La esencia de mi oferta se basa en:
  • Agilidad.
  • Soluciones simples pero de alto valor p/el cliente.

Algo anecdótico es porque elegí una servilleta para hacer este ejercicio. Algunas razones:

Este post va dedicados a todos mis amigos de Hacer Historia, que me ayudaron con esta rueda y me mostraron posibilidades ahí donde yo estaba ciego.

saludos!

martes, 15 de junio de 2010

Generación de código, seguimos sin ver la luz?

En el pasado agile open de programación, junto con @claudiomeschini, @mariodallago y otra persona más que no recuerdo quien era, participamos de una sesión que los muchachos llamaron "Generación de código, seguimos sin ver la luz?" en referencia al maestro @ajlopez, alguien que para mi hace aportes muy interesantes a la comunidad. El material del encuentro lo pueden encontrar acá: http://www.agiles.org/agile-open-tour/ba-2010-coding/resultados

Hablamos sobre experiencias personales en el uso de generación de código p/construir aplicaciones y sobre temas relacionados. Voy a tratar de hacer un resumen de los temas que tocamos. Visiten el blog de Claudio, que en cualquier momento escribe algo también:

Experiencias personales de uso

Claudio comentó sobre su proyecto Quetzal de generación de código. Yo comenté sobre una experiencia de hace unos años usando AjGénesis en un proyecto real y la de hace unas semanas, donde a partir de un modelo muy simple, generamos una solución web mvc con las características que venimos usando últimamente (service layer, domain model, repository, log4net, structure map, manejo de errores c/páginas amigables, etc). También generamos los scripts de nAnt p/integración continua con cruise control y deploy automatico al ambiente de QA.

Modelos abstractos

Dijimos que algo destacable de la generación de código es trabajar con modelos abstractos. A partir del modelo, es posible generar código con una herramienta (ej: AjGénesis) o en runtime (ej: mapeos de nhibernate). De hecho hicimos extensible el concepto a no solo generar código, sino cualquier artefacto de texto como pueden ser script de base de datos, archivos de mapeo nhibernate, archivos de configuración, etc.

Una distinción importante para hacer en el modelo es separar el modelo de la tecnología o aspectos de implementación (como podrían ser paths, lenguage de programación, etc).

Algo interesante de AjGénesis es que el modelo se puede cargar de cualquier lado. Por ejemplo se podría cargar una parte del modelo a partir de las clases de una dll. Y luego completar ese modelo con más información, cómo por ejemplo que campos son requeridos p/armar un ABM.

Otra cosa que puede servir a la hora de diseñar un modelo es la de favorecer convención sobre configuración, para que sea menor la cantidad de cosas a definir en el mismo. Por ejemplo, podría asumir que todos los campos de mis entidades son requeridos y especificar puntualmente cuales no.

Mantenimiento

Uno de los problemas que a veces se presenta, es que después de generar el código surgen necesidades que me obligan a cambiarlo. Si el cambio lo hacemos directamente en el código, este gap es costoso de mantener y me pierdo de volver a cambiar el modelo y regenerar nuevamente.

Una manera de lidiar con esto vimos que es importante crear buenas abstracciones que separen la parte del problema que puede ser resuelta con generación de código, de la que no. De esa forma, hacer un cambio se traduce a modificar el modelo y volver a generar el código.

Cuando conviene usar generación de código?

Pregunta de respuesta fácil, depende... De qué depende? eso es más difícil de responder. La generación de código es una manera de automatizar tareas repetitivas, por lo que si hay algo que se repite muchas veces, podría considerarla como una buena opción.

Criterios de evaluación

Conversamos también sobre algunos criterios para evaluar una herramienta de generación de código:
  • El código generado debería ser el mismo que escribiría a mano sin usar la herramienta.
  • Una prueba ácida sería que a partir del mismo modelo, debería ser posible generar código para otra tecnología.
  • El modelo a definir debe ser libre.
  • Posibilidad de cargar este modelo de cualquier lado: xml, excel, txt, dll, tablas, etc.

Pueden ver mucha más información sobre este tema en el blog de @ajlopez:

saludos!
pd: este post salió hablando x twitter con @jfroma y @ajlopez

jueves, 8 de abril de 2010

El cuento de Juan Carlos



Este por suerte no es el cuento del tío, sino el que nos cuenta Juan Carlos Lucas en Hacer Historia y tiene que ver con cómo vemos al mundo.

El cuento más fácil es en el cual los resultados dependen del contexto. Donde uno no pude hacer nada, ya que es así por alguna razón ajena a nosotros. Pero esto es, según el cuento de @juancarloslucas, sólo la punta de iceberg. Por debajo de la superficie del agua los resultados dependen de las acciones. Hasta acá, no había nada nuevo para mi...

Buceando un poco más profundo vimos que las acciones dependen de las conversaciones. No es loco pensarlo, generalmente hago las cosas porque antes las converso. Y ciertas conversaciones me posicionan desde un lugar donde mis acciones serán distintas. Siempre puedo elegir las conversaciones en las que quiero participar.

Un poco más profundo, las conversaciones dependen de las emociones. No converso de la misma manera cuando me paro en el resentimiento que cuando me paro en el entusiasmo.

Las emociones y el cuerpo tienen una sintonía muy grande, mayor de la que creemos. Esta conexión la descubrí en los cursos y talleres de scrum que organiza @acyment y es una muy buena técnica de facilitación para equipos el hacer actividades con el cuerpo. Esto los animales lo tienen muy en claro, yo lo experimento seguido con mi perro, si me abro de pies y manos y abro los ojos, con signo de exclamación, seguramente me va a saltarme encima con mucha alegría.

Las emociones dependen de las interpretaciones que hacemos y estas de la deriva histórica, nuestra historia y experiencia desde el momento que nacemos.

Lo interesante de esta manera de ver las cosas es que abre un mundo de posibilidades. Si me quedo con el cuento que los resultados solo dependen del contexto, entonces en un contexto desfavorable no puedo hacer nada. Si me quedo con el cuento de que los resultados dependen del contexto y de mis acciones, tengo posibilidades, pero mi universo se limita a trabajar sólo en las acciones. Si por ejemplo quiero impulsar nuevas prácticas en un equipo, en algún momento me voy a encontrar con no saber cómo influir en las acciones de los demás.

Si en cambio, tomo este otro cuento, las posibilidades que tengo para influir en los resultados son mucho mayores.

En mi caso, este cuento me enseño a discernir en un dominio donde antes estaba ciego. Algo que dijo Juan Carlos y que me abrió los ojos fue que el dominio de intervención de un coach está en las acciones, las conversaciones, las emociones y las interpretaciones. Que todas estas cosas se pueden cultivar. Y usó especialmente la palabra cultivar, en lugar de construir, porque es algo que no se puede controlar.

Muy buena la 2da clase de Hacer Historia!
saludos,

jueves, 1 de abril de 2010

Nos cuesta estimar valores absolutos



Este es un ejercicio simple para descubrir lo difícil que es estimar en absolutos. Mirando la foto, cuanto mide el edificio más alto? mmm, no se, mucho...

Sin embargo puedo decir que es el doble del de más a la derecha.

En un post de ajlopez encontré este video de Mike Cohn donde habla de estimaciones ágiles y menciona esta dificultad:

miércoles, 31 de marzo de 2010

Re-encendiendo scrum en un equipo


Hace poco empecé a colaborar con un equipo que desde hace un tiempo viene usando scrum, pero no del todo. A veces hacen daily meetings, a veces no, de a poco dejaron de hacer sprints time box. Pero más allá de las prácticas, no trabajan como un equipo auto organizado, sino que uno de ellos llevaba las cosas adelante, asigna las tareas, carga solo con toda la responsabilidad, etc.

Me imagino que esto deber ser algo común, un equipo empieza usando scrum, pero poco a poco la iniciativa va perdiendo fuerza hasta que se diluye. Seguramente deben haber muchos factores que ayudan a que pase esto. Me hace acordar a un chiste de Dilbert:



Mas allá de las causas, que podría hacer para ayudarlos a conseguir mejor calidad, productividad y felicidad?

Una manera de implementar scrum que me gusta es la que @acyment llama PDF, pain driven facilitation, facilitación guiada por el dolor, o en otras palabras, empiezo por lo que más me duele. Si bien duele, me gusta porque es empírica, exige que seamos prácticos, requiere una gran habilidad para que el equipo descubra y priorice que es lo que más duele y esto es un muy buen ejercicio para un scrum master.

Lo que nos propusimos hacer es volver a hacer un sprint time box. Y para comenzar, hicimos una retrospectiva, antes del sprint. La idea de la retrospectiva era entender cómo estamos. Y no solo eso... también quería transmitirles el espíritu de scrum. En el fondo me daba un poco de miedo participar en la retrospectiva de otro equipo, sobre todo porque nunca habían hecho una y me preocupaba que llegara a ser demasiado tensa.

Así que preparamos algo así (tomado del resumen de retrospectivas ágiles de Juan Gabardini):
Preparar escenario: ball game, para repasar los principios de scrum
Recabar datos: post-it bueno / malo
Generar entendimiento profundo: 5 porqué
Decidir qué hacer: brainstorming / filtrado
Cierre: nos comprometimos a hacer 1 cosa

Como facilitador de la reunión, traté de recordar permanentemente que este es un espacio para decir lo que pensamos, lo que sentimos y para escuchar a los demás también. Al final, no pasó ninguno de mis miedos infundados, de hecho la pasamos bastante bien y como conclusión identificamos que el mayor impedimento es que toda la responsabilidad del proyecto cae en una persona. Esto es como una espiral descendente, ya que genera menos compromiso y motivación en las demás personas, sobrecargando aún más a quien lleva la responsabilidad.

Me parece muy bueno y enriquecedor poder colaborar y ayudar a otro equipo. La verdad no es algo que lleve mucho tiempo, solo 2 a 3 horas por sprint y creo es una inversión que vale la pena.

En las retrospectivas siguientes me gustaría usar el comienzo de la misma (preparar escenario) para reforzar los principios de scrum con diferentes juegos y actividades, despertar el entusiasmo en las personas y re-encender scrum poco a poco.

También ir variando las distintas técnicas del resumen de Juan. Animar a las mismas personas del equipo a facilitar la retrospectiva, hasta que se sientan en confianza para llevarlas solos. Esto es algo que hacemos en mi equipo y la verdad nos funciona muy bien, ya que refuerza el "todos pueden hacer todo".

saludos!

domingo, 28 de marzo de 2010

Algunas actividades para preguntarnos cómo trabajamos?



En el pasado taller de scrum, quise despertar la duda en las personas. Encender la inquietud respecto a cómo fomentar auto organización, colaboración, ritmo, empirismo en un equipo. Quería que el taller sea intenso, pero con gusto a poco, o mejor dicho, con hambre de aprender más.

Para tratar de conseguir esto, se me ocurrió tomar como base un video de Lisa Adkins donde describe un camino para conseguir la magia de los equipos altamentecolaborativos.

Cambios de conversaciones y comportamiento (behaviour and conversation changes)

Esta actividad es muy simple, se hace de forma grupal (10 personas anduvo bien). En el piso, de forma desordenada, hay tarjetas de papel que tienen escritas las siguientes palabras:
  • Coordinar esfuerzos inviduales
  • Fomentar la colaboración
  • Ser un experto en un área
  • Ser un facilitador para el equipo
  • Foco en objetivos específicos
  • Foco en la performance del equipo
  • Conocer la respuesta
  • Preguntar al equipo por la respuesta
  • Liderar el equipo
  • Dejar que el equipo encuentre su propio camino
  • Manejar
  • Guiar
  • Hablar de deadlines y opciones técnicas
  • Hablar de valor de negocio
  • Hacer lo óptimo
  • Hacer lo correcto ahora
La consigna es ordenar las tarjetas en 2 columnas. La de la izquierda son las cosas que deberíamos dejar de hacer para favorecer la colaboración. La de la derecha, las que deberíamos empezar a hacer. El resultado final es algo así:
  • Coordinar esfuerzos individuales => Fomentar la colaboración
  • Ser un experto en un área => Ser un facilitador para el equipo
  • Foco en objetivos específicos => Foco en la performance del equipo
  • Conocer la respuesta => Preguntar al equipo por la respuesta
  • Liderar el equipo => Dejar que el equipo encuentre su propio camino
  • Manejar => Guiar
  • Hablar de deadlines y opciones técnicas => Hablar de valor de negocio
  • Hacer lo óptimo => Hacer lo correcto ahora
Algo que me parece bueno, es hacer el ejercicio en el piso, ya que eso da visibilidad a todos de las tarjetas y por otro lado, para ordenarlas hay que mover el cuerpo (no se bien porqué, pero en las actividades donde me muevo, me comprometo más con la actividad). Una cosa que hubiese sido mejor, me parece, es que las tarjetas que se corresponden no empiecen con la misma palabra, para no hacer tan obvio algunas asociaciones. Por último, es valioso hacer una ronda de reflexión al final de la actividad, para que cada uno exprese lo que le generó la misma.

Promover o inhibir (promote or inhibit)

En un rotafolio, se escriben algunas características de un equipo en scrum, una columna de promuevo y otro de inhibo. La idea es que cada participante haga vea en retrospectiva cómo desde su rol promueve o inhibe estás características. Se reparte un marcador a cada uno y luego se los invita a marcar un punto donde sientan que encaja mejor.



Después de esta actividad, un compañero dijo que reconoció que sin querer inhibía mayormente estas características en su equipo. El descubrirlo fue una sorpresa para él, eureka!

FishBowl

Esta actividad me sorprendió, ya que no me esperaba que gustara tanto ni que espontáneamente hiciéramos uno al día siguiente. El debate arrancó con la pregunta "cómo usamos scrum en nuestros equipos". Luego cada uno contó sus experiencias y desaciertos. Quien quería preguntar, debía ocupar el lugar del fishbowl o esperar a que se vaciara.

saludos!

viernes, 26 de marzo de 2010

Taller de scrum en la empresa


Hace unas semanas organicé un taller de scrum en la empresa donde trabajo. Fue breve pero intenso (medio día, 10 personas).

La verdad fue muy entretenido prepararlo y realizarlo. Todo empezó tomando como base la visión del área de desarrollo, nos juntamos, la escribimos y nos preguntamos, es ahí hacia donde queremos ir? Luego, armamos una propuesta.

Dado que era la primera vez que lo hacía y no estaba seguro de cuanto tiempo llevaría cada actividad, armamos un mini task board donde dividimos el taller en 4 horas. Luego llenamos cada hora con actividades y 10' de break. Sobre la marcha, la hora nos servía cómo punto de control para ir quitando las actividades menos importantes (nos extendimos más de lo estimado en algunas...). Finalmente, pudimos hacer las siguientes actividades:

Parte 1 - El espíritu de scrum

La idea en esta parte del taller es que cada uno experimente en carne propia la esencia de scrum. Algo parecido, salvando las distancias, al taller facilitado por Tobias y Alan.

Actividades
  • ball game, 20'
  • spaguetti game, para entender el potencial de un equipo auto organizado, 10'
  • Si, pero, 5'
  • Si, y, 5'
  • Si, entonces, 10', para aprender a aceptar lo que me dice el otro y construir colaborativamente
Parte 2 - Scrum Framework

El objetivo de esta parte es mejorar nuestro entendimiento del framework scrum y conocer cómo están trabajando otros equipos.

Actividades
  • Explicale a tu abuela los roles de scrum, 10'
  • Elaborar y priorizar, primero 1, luego entre 2, luego entre 4, luego ..., 20'
    Que skills tiene un buen PO, SM?
  • La dinámica de scrum, 10'
  • Fishbowl: Cómo usan scrum en sus equipos? 20'
Parte 3 - Transformación hacia una cultura ágil

La idea de esta parte es entender dónde estamos parados en la transformación hacia una cultura ágil y que cada uno pueda hacer una breve retrospectiva de cómo su rol impacta en el equipo.

Actividades
  • Espejo, para entender la diferencia entra liderazgo tradicional y emergente, 10'
  • Behaviour and conversation changes, 10'
  • Promote or inhibit, 10'
  • Retrospectiva
bueno, ahora pasemos a lo interesante, las
Conclusiones

Algo que tuvo muy buena aceptación fue hacer juegos y actividades, hizo que el taller sea divertido y llevadero para todos. Por otro lado, la experiencia de aprendizaje es mucho mejor, que la clásica donde uno expone y otros escuchan.

El spaguetti game no salió como esperaba. Hicimos el spaguetti con 6 personas y el analista / pm lo pudo resolver. Creo que 6 es poco, deberíamos haber usado 8.

Para romper el hielo, empezamos el taller sacándonos el calzado, lo cual ayuda entre otras cosas a preparar el ambiente.

En la sala teníamos 1 pizarra con el espíritu de scrum (auto organización, empirismo, colaboración, ritmo, priorización), 1 pizarra con el taskboard y un rotafolio donde íbamos resumiendo el resultado algunas actividades. Fue bueno tener estos 3 materiales siempre visibles.

Después de cada juego, hicimos una pausa donde charlamos entre todos sobre la experiencia del mismo. En este punto creo que es muy importante que el facilitador del taller realice preguntas que pongan en relieve la intención del juego (repasando la pizarra con el espíritu de scrum).

Propuse la idea del fishbowl, solo como un método para poder hablar ordenadamente entre todos y fue una de las actividades que más gustó! De hecho, al día siguiente hicimos otro en donde tratamos problemáticas más particulares de los proyectos.

Para la última parte del taller, busqué juegos en http://blog.tastycupcakes.com/, pero no encontré uno que me cerrara. Así que inventé algunas actividades en base al video de Lisa Adkins, The Road from Project Manager to Agile Coach - 2 of 2 (dejo una traducción no muy buena de la 1ra parte). Fue divertido tratar de inventar una actividad...

Mi idea era que las personas disfrutaran del taller, se llevaran algún aprendizaje, pero sobre todo inquietudes, dudas y ganas de trabajar de esta manera.

saludos!

miércoles, 17 de marzo de 2010

Ideas de Lyssa Adkins para fomentar el espíritu de scrum


Hace un tiempo encontré este video muy bueno que habla sobre el camino de aprendizaje de una persona de PM a agile coach: http://www.youtube.com/watch?v=TvYqhYEaqMs

Si bien la autora Lyssa Adkins, expone este tema desde la perspectiva de un PM, creo que sus ideas encierran el espíritu de scrum.

Esta es una traducción de la primera parte del video. En algunas partes no llegué a comprender bien el inglés, así que las completé con lo que entendí.

Separate de los resultados
  • Dar al equipo todo el espacio del mundo, para que vengan con las mejores ideas y el mejor producto.
  • Como su coach, solo sos una persona cuando ellos resuelven temas específicos. No te enfoques en esto, tenés un rol más grande que jugar.
  • Enfocate en cómo el equipo trabaja en conjunto, entonces los podés ayudar a mejorar la calidad total del trabajo.
  • Si estás en el cómo, lejos de los detalles del qué, podes conseguir estar separado de los resultados. Siendo independiente, dejás que ellos sean independientes también y que sean los dueños de su propio resultado.
Dejáselo al equipo
  • Lo creas o no, no sos la mejor persona para resolver los problemas del equipo cuando hay un problema con la manera que el equipo está trabajando o un problema con el producto que el equipos está construyendo.
  • Cada vez que pienses que necesitás resolver algo y empezás a crear planes y estrategias de implementación en tu cabeza, PARA!. En lugar de hacer eso, hacé la observación de lo que estás viendo al equipo.
  • Dejálos a ellos y fijate qué pasa, aún si es nada.
  • Si diagnosticas el problema e implementás una solución, corrés el riesgo de alejarte de estas ideas.
Se un espejo
  • Reflejá al equipo, sin tu juicio, los comportamientos o síntomas que ves.
  • Dejálos ser ellos a través de tu observación.
  • Simplemente empezá con una pregunta, esperá y escuchá.
Dominá tu cara
  • Para hacer esto bien hay que practicar comunicación sin jucio y sin violencia.
  • No solo tu vos y lo que decís, sino también tu cara.
  • Si juzgás, todo se verá en tu cara.
  • Asi que abrí tu cabeza y dominá tu cara.
Dejá que haya silencio
  • Sentite confortable con el silencio incómodo.
  • No lo llenes con tus palabras.
  • Dejá que alguien más del equipo tenga lugar para hablar y lo hará.
Date lugar a no ser siempre razonable
  • Son asombrosas las cosas que están escondidas en un equipo.
  • Las creencias sobre qué es o no algo típico, escuchar cosas cómo "es la típica manera, tarda 5 días en suceder", cuando vos sabés que eso lleva 5 minutos.
  • Cuando escuches estas limitaciones, exponelas preguntando "es un impedimento para terminar tu trabajo?" o "si no tuvierás limitación, que harías ahora?".
  • Tirá algunas ideas locas al equipo, dejalos que no sean razonables para vos, así ellos se pueden cuestionar sus asumciones y limitaciones.
Dejá que el equipo se equivoque
  • No estamos hablando de fallas catastróficas.
  • Pero un equipo que falla junto y se recupera, es más fuerte que un equipo protegido.
  • El equipo puede sorprenderte.
  • Asi que limpia, esperá y confía.
Se su fan más grande
  • Pero con cuidado, no elogies el trabajo que ellos hacen.
  • El trabajo fluye al equipo, va y viene.
  • El trabajo que hacen no es lo que los hace grandes, lo que los hace grandes es convertirse en mejores individuos y en un equipo saludable, asi que destacá estas cosas.
  • Se su fan más grande de eso, decíselos y todos sabrán que tanto mejoraron cómo equipo.
Para mi la idea que más me gustó es la de ser un espejo para el equipo, preguntar y dejar que el silencio despierte en otros las ganas de hablar. También la aclaración sobre alentar su crecimiento en lugar de su trabajo.

saludos!

domingo, 7 de febrero de 2010

Cómo empezamos a estimar usando Story Points



Quisiera comenzar a escribir sobre las cosas que fuimos aprendiendo junto con mis compañeros de trabajo en uno de los proyectos que estoy trabajando. Me gustaría comentar sobre las cosas que nos costaron , los errores que fuimos cometiendo y los pequeños ajustes que fuimos haciendo para ir mejorando.

Cuando empezamos a trabajar en este proyecto, estimábamos las historias en horas. Nos pasaba frecuentemente en el sprint planning que nos era difícil ponernos de acuerdo en las estimaciones. Esto se debía a varias razones:

  • Como equipo era la primera vez que hacíamos este tipo de tareas.
  • Es difícil estimar con precisión y diferenciar si una tarea lleva 5hs o 6hs.
  • Por otro lado, al tener perfiles y experiencias distintas, es perfectamente natural que para Jose Senior lleve 2hs y para Juan Junior lleve 6hs.

Lo que nos pasaba, era que perdíamos tiempo en consensuar las estimaciones, éramos poco efectivos. Tampoco era muy repetible lo que hacíamos, ej: en un sprint planning decíamos que una tarea nos llevaba 3 hs y luego en otro para una tarea similar decíamos 6 hs.

Aprovechando la época de las fiestas, que nos rompió la duración del sprint, dijimos “porque no usamos este sprint, en el cual no vamos a comprometernos con un backlog de cosas, para estimar con story points y vemos que sale?”

Bueno, la verdad es que nos salió mal. Comenzamos usando la siguiente escala, que tomamos del libro Scrum & XP from trenches:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100

Y definimos que 3 era una página simple que mostraba un listado sin paginar filtro. Nos costó mucho con esta escala decidir que es un 5, un 2, un 13, etc?

Luego, para el siguiente sprint (que fue un sprint de verdad), decidimos ajustar la escala:

1, 2, 4, 8, 16, 32, 64

Gracias a un twitt de Jorge Gamba conocí el libro User Stories Applied y aprendí una técnica muy simple llamada triangulación, que consiste es armar un cuadro con user stories de pesos similares (esto ayuda a estimar por comparación):

1248163264
story 1story 2story 3listado sin paginar c/filtrostory 5story 6story 7

Imprimimos una hoja para cada uno y la llevamos al sprint planning, para ver que salía. Nos llamó la atención cómo empezamos a coincidir en la estimaciones. De a poco empezamos a conversar sobre tamaño, incertidumbre y complejidad para comparar user stories.

Algo positivo de la experiencia fue que nos animamos a introducir un cambio que suponíamos iba a tener un impacto importante si nos salía mal, y que encontramos el momento para hacerlo (las fiestas, donde la expectiva es baja). Otra cosa positiva fue el encare empírico, es decir, hagámoslo, vemos que sale y ajustemos.

saludos!

domingo, 31 de enero de 2010

Guerrero de la Basura



Gracias a mi amigo Andres, ayer vi esta película que trata sobre la historia de un hombre construyendo casas de basura durante casi 30 años:

Algo que me llamó la atención, fue el espíritu colaborativo de su equipo, que más que un equipo parecía una familia. Es hasta contagiosa la pasión que esta gente siente por lo que hace.

Me pareció muy bueno cómo ayudaron a las personas víctimas del tsunami en India y del huracán Rita a construir lugares sanos donde puedan refugiarse. Creo que lo más emocionante fue ver como despertaron un nueva esperanza en una comunidad que perdió todo.

Sus ideas me parecieron muy ingeniosas, creativas y simples. Es admirable ver como luchó con un sistema tan lento y pesado cómo el jurídico para impulsar sus ideas y el enorme contraste que encontró en lugares que pasaron por crisis terribles. Como él mismo dice, después de una crisis, las personas están más abiertas a nuevas ideas.

Por otro lado, su filosofía y esencia se alinean muy bien con las metodologías ágiles. Cuando dice:

acá en 14 días pudimos hacer los que en Nuevo Mexico no conseguimos en años. En menos 5 minutos puedo explicar a ingenieros indios el principio de sus casas, sin escribir kilos de documentación que nadie va a leer.

Esto es favorecer un producto funcionando sobre documentación llevado al extremo.

La verdad que me inspiró a pensar en hacer cosas por los demás, algo grande, importante. Algo que ayude a personas con poco recursos a mejorar su calidad de vida.

Otra cosa que tomo de la película es la buena predisposición de la gente que tiene una necesidad. Parecería que en estos casos hay mas “si, entonces”, “si, y”, que “si, pero”, “no”. Me hace pensar que estos son buenos escenarios para usar un enfoque ágil, basado en la colaboración, el ritmo, empirismo, auto organización, es decir, creatividad orgánica.

saludos!

viernes, 29 de enero de 2010

Improvisación para Equipos


Al igual que el post anterior, no quiero detallar qué fue lo que hicimos en el taller, para no sesgar o influir de alguna manera a quienes lo quieran hacer. Creo que es mejor ir a este tipo de actividades sin conocer mucho de antemano, así se disfrutan más. Lo que si me gustaría comentar, son las cosas que me llevé y sobre las que me quedé pensando.

En palabras de Alan, la improvisación se trata de:

Aprender a escuchar lo que pasa a mí alrededor, a los otros actores y a escucharme a mí mismo. Improvisar es aceptar lo que me proponen. Cuando me proponen algo y lo acepto, desarrollo mi capacidad de escuchar a los demás. Cuando propongo, aprendo a escucharme a mí mismo y a ver que tengo para ofrecer.

A partir de pequeños movimientos, pequeñas acciones que surgen de lo espontaneo, otra acción igual de pequeña surge, seguida de otra y otra más, creando un efecto de continuidad y fluidez.

La colaboración permite crear formas más ricas de las que puede crear una sola persona, incluso inimaginables, imposibles. Pero, que trabajen 2 personas juntas no quiere decir que estén colaborando. Hicimos varios ejercicios donde notamos que bajo ciertas combinaciones la cosa se vuelve lenta, torpe. Me llevo el desafío tomar otras situaciones y pensar en cómo combinar de distinta manera para crear colaborativamente.

Me pareció muy bueno cómo se generaron distintas experiencias desde lo físico. A partir de algunas actividades, entendí claramente lo que significa la visión, tener un objetivo y que sea claro, que no es lo mismo que tener un plan. Un plan me hace rígido, poco flexible y puede resultar frustrante si por algún motivo no se puede realizar. En cambio, un objetivo claro me permite adaptarme al entorno, entender mejor cómo me afecta y proponer un nuevo cambio.

Creo que el primer taller me sirvió para entender y reforzar la importancia de los valores de scrum y su porqué.

El segundo todavía me dejó pensando. Me di cuenta que con hacer daily meetings, restrospectivas y usar story points no es suficiente para generar auto organización, colaboración, ritmo. Son herramientas que ayudan un poco a conseguirlo, pero lo realmente valioso es dominar esa magia que genera movimiento orgánico en el equipo, para pasar a explotar un potencial mayor del que podemos entender.

saludos!

El Espíritu de Scrum

El miércoles pasado se dio este taller, guiado por Tobías y facilitado por Alan, que trató sobre los principios de scrum. La dinámica consistió en experimentar y explorar mediante juegos y actividades los significados de:
  • Empirismo
  • Auto-organización
  • Ritmo
  • Colaboración
  • Priorización
Salí del taller con mucha información para digerir, nuevas ideas, sensaciones, experiencias. Mientras volvía a mi casa en colectivo y con un calor aplastante, me quedé pensando en varias cosas:

Sobre lo orgánico de un equipo auto organizado. Es cómo que hay una fuerza invisible que va ordenando y dando sentido al caos. Desde afuera es sutil es imperceptible. Pero desde adentro, cuando se vive en carne propia mediante este tipo de actividades, te deja una buena sensación, como un gusto agradable.

En las posibilidades. Si alguien le dice al equipo cómo hacer las cosas, me pierdo de un montón de posibilidades. Lo mismo si alguien no participa. Nadie mejor que el mismo equipo para encontrar el mejor camino.

En el movimiento como una manera de generar valor constantemente. Genero valor porque hago, porque me equivoco, porque aprendo, porque se me ocurre una idea y vuelvo a probar. Moviéndonos sin pensar ni planificar de antemano pudimos hacer cosas que al principio nos resultaban imposibles o muy difíciles. Realmente llegué a sorprenderme por las cosas que conseguimos hacer teniendo al movimiento como principal estrategia.

En la importancia de la colaboración. Es como un círculo virtuoso, la colaboración genera más colaboración.

En el ritmo. Nos fue fácil mantener un ritmo y nos fue costoso cambiarlo y adaptarnos a uno nuevo.

En los valores. Sin valores nada de esto es posible ni sustentable en el tiempo. Los valores lo transforman en algo con sentido y energizante.
En tener clara una visión / objetivo trascendente, que sea más grande que yo, como motor y aliciente frente a las dificultados.

Siempre es un gusto asistir a estos eventos para conocer otras personas y encontrarme con otros colegas. Está muy bueno compartir este tipo de actividades con gente con gran motivación y pasión por lo que hacen.

saludos!

sábado, 16 de enero de 2010

Una herramienta simple para expresar ideas

Hoy me enteré por un RT de @emaraschio, sobre SimpleDiagrams, una herramienta para expresar ideas de manera visual y simple.

Tiene una versión free, que puede bajarse y usarla para empezar a crear diagramas. La verdad me pareció una muy buena manera de comunicar ideas, de hecho, la usé para explicar Kudewe Reports a un cliente:



No hay como la simplicidad...

saludos!

miércoles, 6 de enero de 2010

Home, una película sobre la importancia de cambiar

Gracias a Andrés Navarro, me enteré de la película Home, la cual se puede ver por youtube:

Esta trata sobre cómo se desarrolló la vida en la tierra, desde sus inicios, hasta la llegada del ser humano. La película tiene imágenes y escenas de la tierra que son realmente impactantes. Pero lo más impactante es la retrospectiva que hace sobre nuestro impacto en el planeta.

Algunas frases de la película que me parecieron geniales:
  • El motor de la vida es el vínculo.
  • Nuestra tierra reposa en un equilibrio en el cual cada uno tiene su lugar y solo existe gracias a la existencia del otro.
  • En la gran aventura de a tierra, cada especie tiene un papel, cada especie tiene su lugar, ninguna es inútil o dañina, todas se equilibran.
  • No hemos tomado conciencia de que estamos agotando lo que la naturaleza nos ofrece.
  • Lo orgánico es el vínculo entre el agua, el aire, la tierra y el sol.
  • Estemos donde estemos, nuestras acciones tienen repercusiones en el resto del planeta.
Ver las imágenes de terrenos modelados para aprovechar mejor la agricultura, me hizo acordar cuando caminé por los valles de Nepal con mi amigo Rober. Ya pasaron muchos años de ese viaje, pero no me olvido de las personas simples y alegres que habitaban esas tierras.

Esta película me hizo ver que el humano es la única especie que rompe equilibrios.

Me resulta interesante la sabiduría que esconde la naturaleza detrás de su simplicidad. En la película pude notar algunos defectos de nuestra manera de organizarnos:
  • Reemplazar la diversidad por la estandarización.
  • La desigualdad provoca desplazamientos de personas, de los cuales no hemos tomado realmente conciencia.
  • Cerrar los ojos, no ser adaptativo y ágil
  • No somos capaces de hacer un balance y ver todo aquello de lo que somos responsables
Pero se estan haciendo algunas cosas. Comienza una nueva aventura humana, basada en la moderación la inteligencia y el reparto. A nosotros nos queda escribir el resto de esta historia...

saludos!

150 x 300 Por una escuela

Otra de las iniciativas con impacto social que apoyamos, es la de Rodolfo Llanos (@soloenglish). Su proyecto consiste en construir una escuela en el Barrio Congreso Nacional, Cerrillos, Salta.

Para eso, Rodolfo corrío una carrera muy dura en patagonia (150km) y le propuso a la gente comprar cada kilómetro recorrido. Si ganaba, los vendía. El proyecto es interesante a nivel social y deportivo.

Para quienes estén interesados, todavía es posible comprar kilómetros para colaborar con la causa.

150×300

saludos!

Un viaje en bicicleta por America retratando pueblos

Como parte de esta idea loca de hacer un mundo mejor, nos sumamos como cómplice de Juan Villarino y su viaje de Mar del Plata a Alaska en americiclo.

Creo que su viaje puede ser una lección importante para toda la sociedad. Me da la sensación que hay mucho para aprender de los pueblos que viven con simpleza. Como dice Juan, la hospitalidad de estas personas es asombrosa. Reatratar el lado bueno de las personas es algo que refuerza nuestros valores humanos. El espíritu de su viaje me ayuda a recordar los valores con los que impulso este emprendimiento llamado Kudewe.

Por otro lado, su proyecto cultural se basa en la diversidad, en la mezcla de culturas distintas. Sin duda será una actividad muy interesante la de mostrar a los pueblos fotos de otros pueblos visitados. Se imaginan a un esquimal viendo fotos de pescadores en el amazonas y aprendiendo sobre sus costumbres?

Además, veo a su proyecto como una exploración a pueblos desconocidos para mi, donde puedo conocer comunidades a quienes ayudar en algún futuro.

Es interesante destacar cómo hay gente que con creatividad diseña su propia vida y encuentra su lugar en el mundo.

saludos!

martes, 5 de enero de 2010

Configurando Cruise Control .net + svn + MS Test desde 0

Hace poco incursioné en el mundo de la integración continua. Les dejo una breve guía de cómo configurar un Cruise Control .net + svn + MS Test desde 0.

1. Instalar CCnet http://confluence.public.thoughtworks.org/display/CCNET/Download.

2. Bajar nAnt http://nant.sourceforge.net/ y copiar a directorio local (yo los copié en c:\archivos de programa).

3. Bajar nAnt Contrib http://nantcontrib.sourceforge.net/ y copiar a directorio local.

4. Bajar svn command line http://nantcontrib.sourceforge.net/ y copiar a directorio local.

5. Configurar un proyecto de build en ccnet.config, ubicado en el directorio de instalacion de CCnet. Es recomendable hacer esto paso por paso, para ir probando como funciona

<cruisecontrol cb="urn:ccnet.config.builder">
<!-- This is your CruiseControl.NET Server Configuration file. Add your projects below! -->
<project>
<name>myProject</name>

<!-- Step1: trigger build from commit, check every 60 seconds -->
<triggers>
<!--<intervaltrigger seconds="60" buildcondition="ForceBuild">-->
<intervaltrigger name="Subversion" seconds="60">
</triggers>

<!-- configure svn repository -->
<sourcecontrol type="svn">
<trunkurl>http://svn.com/myProject/trunk/src/</trunkurl>
<workingdirectory>C:\Archivos de programa\CruiseControl.NET\server\myProject\WorkingDirectory\Source</workingdirectory>
<username>user</username>
<password>pass</password>
<executable>C:\Archivos de programa\CollabNet\Subversion Client\svn.exe</executable>
</sourcecontrol>
<tasks>
<!-- Step 2: Build solution -->
<nant>
<executable>C:\Archivos de programa\nant-0.85\bin\nant.exe</executable>
<buildfile>cruise.build</buildfile>
<targetlist>
<target>run</target>
</targetlist>
</nant>
<!-- Step 3: Run tests -->
<exec>
<!--Call a batch file that contains del testResults.trx -->
<!--this is required as MsTest will not create the file if it exists-->
<!--this could be merged with the mstext action in a single batch file-->
<executable>deleteTestLog.bat</executable>
<basedirectory>C:\Archivos de programa\CruiseControl.NET\server\myProject\WorkingDirectory</basedirectory>
<buildargs></buildargs>
<buildtimeoutseconds>30</buildtimeoutseconds>
</exec>
<exec>
<!--Call mstest to run the tests contained in the TestProject -->
<executable>C:\Archivos de programa\Microsoft Visual Studio 9.0\Common7\IDE\mstest.exe</executable>
<basedirectory>C:\Archivos de programa\CruiseControl.NET\server\myProject\WorkingDirectory\Source</basedirectory>
<!--testcontainer: points to the DLL that contains the tests -->
<!--runconfig: points to solutions testrunconfig that is created by vs.net, list what test to run -->
<!--resultsfile: normally the test run log is written to the uniquely named testresults directory -->
<!-- this option causes a fixed name copy of the file to be written as well -->
<buildargs>/testcontainer:Test\bin\Debug\Test.dll /runconfig:LocalTestRun.testrunconfig /resultsfile:testResults.trx</buildargs>
<buildtimeoutseconds>120</buildtimeoutseconds>
</exec>
</tasks>
<publishers>
<!--to get the test results in the dashboard we have to merge the results XML file -->
<!--the project working directory is used as the base path here -->
<merge>
<files>
<file>Source\testResults.trx</file>
</files>
</merge>
<!--this is the line I missed for ages, without it you get strange missing publisher log errors -->
<xmllogger>
</publishers>
</project>
</cruisecontrol>

Este es el archivo cruise.build que compila la solución VS2008 usando nNant (ubicado en C:\Archivos de programa\CruiseControl.NET\server\myProject\WorkingDirectory):

<?xml version="1.0"?>
<project default="run">
<property name="nant.settings.currentframework" value="net-3.5">
<property name="MSBuildPath" value="C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe">
<property name="SolutionFile" value="C:\Archivos de programa\CruiseControl.NET\server\myProject\WorkingDirectory\Source\myProject.sln">
<property name="SolutionConfiguration" value="Debug">

<target name="run" depends="build">
</target>

<target name="build">
<exec program="${MSBuildPath}">
<arg line="'">
<arg line="/property:Configuration=${SolutionConfiguration}">
<arg value="/target:Rebuild">
<arg value="/verbosity:normal">
<arg value="/nologo">
<arg line="'/logger:">
</exec>
</target>
</project>

6. Configurar dashboard. Simplemente hay que crear un virtual directory en IIS y apuntarlo a C:\Archivos de programa\CruiseControl.NET\webdashboard.

Luego ingresar a http://localhost/ccnet, para ver que el dashboard funciona. Debería verse el proyecto de build. Para agregar los resultados de los test hay que entrar a administer dashboard e instalar MS Test Results y modificar los plugins de dashboard.config (ubicado en C:\Archivos de programa\CruiseControl.NET\webdashboard)

<buildplugins>
<buildreportbuildplugin>
<xslfilenames>
<xslfile>xsl\header.xsl</xslfile>
<xslfile>xsl\modifications.xsl</xslfile>
<xslfile>xsl\MsTestSummary2008.xsl</xslfile>
<xslfile>xsl\compile.xsl</xslfile>
</xslfilenames>
</buildreportbuildplugin>
<buildlogbuildplugin>
<xslreportbuildplugin description="MSTest Report" actionname="MSTestBuildReport" xslfilename="xsl\MsTestReport2008.xsl"></xslreportbuildplugin>
<xslreportbuildplugin description="NAnt Output" actionname="NAntOutputBuildReport" xslfilename="xsl\NAnt.xsl"></xslreportbuildplugin>
<xslreportbuildplugin description="NAnt Timings" actionname="NAntTimingsBuildReport" xslfilename="xsl\NAntTiming.xsl"></xslreportbuildplugin>
</buildplugins>

7. Instalar CC Tray. Esta es una aplicación que corre en el system tray y que muestra mediante semáforos el estado del build. La aplicación se baja desde el dashboard. Luego se agrega el servidor de build y se selecciona el proyecto de que se quiere monitorear.

Algunos links que me fueron útiles

Tutoriales:
http://confluence.public.thoughtworks.org/display/CCNET/Resources
http://www.codeproject.com/KB/dotnet/cruisecontrol_continuous.aspx

Configurar frw 3.5:
http://codebetter.com/blogs/jeffrey.palermo/archive/2007/11/28/upgrade-nant-for-use-with-vs2008-solutions-and-net-3-5.aspx

Configurar build:
http://stackoverflow.com/questions/1195389/msbuild-task-or-msbuild-exe-with-nant

Configurar MS Test:
http://blogs.blackmarble.co.uk/blogs/bm-bloggers/archive/2006/06/14/5255.aspx
http://stackoverflow.com/questions/362208/mstest-failing-in-2008-from-build-script


saludos!