lunes, mayo 17, 2010

Cumplir con la retrospectiva

Si alguna vez trataron de cambiar algún hábito personal (como comerse las uñas, por ejemplo) saben que es virtualmente imposible de lograrlo a menos que tengan algo para reemplazar el hábito viejo. Es más fácil adoptar un comportamiento nuevo que extinguir uno viejo. Lo mismo ocurre para los equipos en las organizaciones.

En su retrospectiva, el equipo de Lynn decidió dejar de empezar a codificar sin tener un plan. Pero en la siguiente reunión de planificación de la iteración, dos miembros del equipo abrieron sus notebooks para compartir código en el que habían trabajado durante el fin de semana. Creían que le estaban dando una ventaja al equipo.

Lynn les recordó a todos el acuerdo y compartió varias ideas para planificar que había leído en grupos de discusión Ágiles. El equipo acordó actuar de acuerdo a lo decidido y probar las ideas de Lynn para la planificación. A medida que el equipo empezó a hablar sobre el trabajo que debía hacerse, el equipo se dió cuenta que el código escrito durante el fin de semana no contribuía al objetivo de la iteración - fue un esfuerzo en vano.

Sin un reemplazo (como estas ideas para planificar), el equipo no tuvo más alternativa que caer en su comportamiento anterior.

Todos los comportamientos nuevos resultan extraños al principio. Las personas desarrollan tranquilidad con la práctica - sea tanto al aprender un nuevo saque de tenis como aprender a escribir código en un nuevo lenguaje. Debemos brindar apoyo y recordar que está bien cometer errores mientras se aprenden nuevas habilidades.

Brindar apoyo

El trabajo de provocar un cambio no termina con el cierre de la retrospectiva. Incluso los cambios más pequeños necesitan ser cuidados y apoyados. El apoyo proviene de diferentes formas: refuerzos, empatía, oportunidades de aprendizaje, oportunidades de práctica, y recordatorios. Algunos tipos de apoyo provienen del equipo (como la empatía y los recordatorios). Otros requieren de recursos y presupuesto externos. Los líderes de equipos, coaches y gerentes tienen la responsabilidad de obtener el apoyo que requiera de gastos.

Refuerzos

El cambio es difícil. Debemos apoyar al equipo (y a nosotros mismos) haciendo notar el avance. Demos frases de aliento sobre lo que estamos haciendo bien.

Debemos brindar información sobre lo que va bien para que el equipo pueda ver que están avanzando. Demos feedback que describa el comportamiento y destaque el impacto: "Noté que ayer no nos fuimos de tema en la reunión diaria. Acordamos sólo responder las preguntas del scrum diario, y eso hicimos. Nos ayudó a ver cuáles eran los obstáculos".

Empatía

Es válido que las personas sientan frustración o pérdida por el cambio. Veamos como Fred manejó mal la situación cuando un miembro del equipo le habló sobre los cambios. Fred escuchó a Katie explicar cómo se sentía sobre tener que dejar su cubículo personal cuando el equipo se ubicó en un espacio abierto. "Estuve pensando lo que me contaste", le dijo Fred, "y no hay ningún motivo para que te sientas así". ¡Eso no es empatía! Debemos respetar los puntos de vista de las otras personas, aunque no los compartamos. A veces un simple "Te escucho" es suficiente.

Oportunidades de aprendizaje

Debemos apoyar la exploración y el aprendizaje, y demostrarlo. Es posible que el equipo necesite aprender nuevas habilidades para tener éxito en los experimentos que eligieron para su plan de acción. Se pueden organizar almuerzos y sesiones para que los miembros aprendan entre ellos. Se pueden dar listas de recursos web y artículos para que el equipo investigue ideas nuevas. La programación de a pares ayuda a aprender nuevos lenguajes y técnicas. Y se puede hacer todo esto sin un presupuesto.

También debemos estar dispuestos en gastar dinero para apoyar un cambio. No todas las habilidades se pueden aprender desde un sitio web o leyendo un artículo. Invirtamos en capacitación para construir las bases de nuevas habilidades. Armemos una biblioteca de referencia para que el equipo pueda consultarla.

Oportunidades de práctica

Las personas necesitan practicar para ganar experiencia. Una forma es dejar al equipo con el proyecto para que prueben algo nuevo. Otra opción es crear un espacio formal de práctica usando algún proyecto pequeño, un área de práctica, o un programa tipo Hola Mundo.

Los proyectos cortos -uno que dure dos días, o incluso menos- sirven para explorar posibles soluciones y probar métodos nuevos. El límite de tiempo en los proyectos cortos crea un punto de verificación explícito en donde el equipo puede comprobar su aprendizaje y las decisiones en el experimento.

Las áreas de práctica son un lugar donde el equipo puede cosas nuevas sin afectar al producto real. Un área de práctica puede ser un área especial de desarrollo o prueba que no se utiliza para el desarrollo actual del producto.

Alentemos a que el equipo prueba programas del tipo Hola Mundo. Los programas Hola Mundo son muy simples (en general sólo muestran el mensaje "Hola, Mundo"), pero sirven para probar entornos de desarrollo, configuraciones y encontrar problemas rápido (o confirmar que algún concepto básico funciona).

Recordatorios

Los tableros grandes y visibles y los check-in son recordatorios que ayudan a que el equipo se enfoque en los cambios. Por ejemplo, el equipo de Terry decidió que necesitaban realizar refactors más seguido. Crearon un tablero grande donde cada miembro agregaba un punto verde cuando terminaban una tarea de refactor. Al final de cada día, revisaban el gráfico y discutían los resultados.

Un check-in le permite al equipo informar lo que están haciendo con un cambio en particular. Debemos mantener preguntas y respuestas cortas: "En una o dos palabras, ¿cómo estamos con las estimaciones?". Las respuestas nos pueden ayudar a saber cómo está avanzando el cambio.

Fuente

viernes, mayo 07, 2010

¿Inteligente o Tonto?

¿Cuál es la diferencia entre ser inteligente o ser tonto? Creo que podría resumirse en dos cosas: qué tan lejos en el futuro podés pensar, y qué tan rápido podés generar este pensamiento. Cuando alguien juega ajedrez, o poker, sus habilidades están determinadas por cuántas movidas puede pensar por adelantado. Cuánta historia pueden recordar, y así planificar el siguiente movimiento.

En el desarrollo de software, ¿qué tan lejos podés mirar? ¿Estás usando prácticas destructivas porque estás muy ocupado "terminando el trabajo"? ¿Estás ignorando buenas prácticas que podrían ahorrarte tiempo?

Podemos relacionarlo con armar un camino que atraviese un bosque. Estás trabajando muy, muy duro. Todos en el equipo están transpirando, astillándose las manos, todo el tiempo. No se puede cuestionar la lealtad ni dedicación de nadie.

Pero...

¿Cuándo fue la última vez que detuviste esta tala de árboles metafórica, te subiste a un árbol... o miraste el mapa... o afilaste el hacha? El problema con la mayoría de los equipos de software que talan árboles en el bosque es que no comprueban si el camino que están armando está dirigido hacia la ciudad correspondiente. No comprueban si es un camino recto. No analizan si podrían comprar algunas sierras eléctricas para reemplazar a las hachas obsoletas que vienen usando.

Por supuesto que esto también puede abusarse. No queremos pasar todo el día en el negocio buscando herramientas nuevas, pero de vez en cuando necesitamos mirar los alrededores, ver si seguimos en línea recta. Debemos asegurarnos de estar usando las herramientas correctas para el trabajo. Comprobar si siguen afiladas las hojas.

Les dejo algunas sugerencias como herramientas para asegurarnos que seguimos en el camino correcto.

  • Integración Continua. Hay muchas herramientas de Integración Continua que ayudan muchísimo al equipo. Hace que el equipo siga escribiendo código en vez de arreglar compilaciones, mantiene limpio al producto, y encuentra problemas rápido.
  • Demos frecuentes. Tanto si son internas o para el cliente, estas demostraciones públicas ayudan a entender lo que estamos haciendo, y nos sugiere correciones al curso. Si estamos cortando el camino en la dirección incorrecta, ¿cuánto tiempo queremos seguir perdiendo? Debemos mostrar lo que hacemos, y averiguar lo que piensan lo antes posible.
  • Iteraciones de duración fija. Las iteraciones acotadas brindan una forma más efectiva de enfocar los esfuerzos y asegurarse de estar construyendo el software adecuado.
  • Pruebas automatizadas. Cuando codificamos nuestro conocimiento del producto en una prueba automatizada (que se ejecuta en un servidor de integración continua), se hace imposible que alguien del equipo rompa el código sin que se descubra rápidamente.
  • Pruebas guiadas por los defectos. ¿Encontraste un bug? Agregá una prueba. Siempre. Esta perspectiva extreme a la automatización de pruebas nos brinda cobertura justo en donde era necesaria. También, no agregues una sola prueba... buscá armar escenarios derivados de la situación.
  • Desarrollo guiado por pruebas. Escribir una prueba antes de escribir el código productivo hace que surja un código completamente diferente. Es más pequeño, más enfocado y (¡sorpresa!) está probado. TDD es un camino de ida... ¡probalo!
  • Reuniones diarias de parado. Estas reuniones diarias y breves hacen que todos hablen y se vean la cara, todos los días. Se responden 3 preguntas que ayudan a compartir información. ¿Cuántos equipos conocen que no se hablan a diario?
Fuente