¿Y si jugamos a que hacemos software?

Desde hace un tiempo, estoy dando una mirada de vez en cuando a una revista online sobre metodologías ágiles en portugués. Visão Ágil, como tarea hogareña del curso portugués que estoy haciendo, y con la intención de leer un poco sobre este tema (como dice la poco ecológica metáfora: matar dos pájaros de un tiro).

La técnica del Tomate

En el blog de esta revista encontré recientemente un artículo sobre la “Técnica Pomodoro” de Manoel Pimentel. La Técnica Pomodoro se utiliza para la administración personal del tiempo, y está inspirada en ideas de las metodologías ágiles, como TimeBoxing y el uso de herramientas de “baja tecnología”, puntualmente: papel, lápiz y un timer de cocina.

Estos timers con forma de tomate (pomodoro en italiano) son los que dan nombre a la técnica

Si bien ese artículo tiene un mindmap que resume muy bien los puntos clave, lo que más destacaría es la simplicidad, el énfasis en mantener el foco, y la asignación rígida de tiempos (véase TimeBoxing) tanto a las tareas como a los intervalos de descanso entre éstas.

Con respecto a este último punto, el libro oficial que puede descargarse de http://www.pomodorotechnique.com destaca la importancia de estos intervalos para “asimilar lo aprendido y hacer algo bueno por tu salud”, como caminar, ejercicios de respiración o contar un chiste. Interrumpir este período de descanso con cualquier tarea que implique un esfuerzo mental, “bloqueara el constructivo proceso mental de integración necesario para estar alerta y listo para el proximo ciclo”. Una especie de build de integración que se ejecuta periódicamente en background en nuestro cerebro.

El último que se escondió arma el release!

Sin embargo lo que quería mencionar en este artículo (y por eso el título), es algo que me parece muy valioso y puede pasar desapercibido a primera vista. Es el espíritu lúdico que hay detrás de esta técnica (vi este punto escrito en el mindmap del artículo de Pimentel).

Una idea que tambien está implícita en varias técnicas utilizadas en metodologías ágiles.

Creo que en esta manera de encarar el trabajo (y cualquier otra cosa) hay mucho más jugo de lo que se cree habitualmente. Especialmente en ambientes que promueven la productividad y la creatividad.

No hay que confundirlo con una forma de hacer apología de la competencia (que casi nunca es sana), o de esquivar el bulto a las tareas tediosas. Se trata más bien de evitar que nuestro trabajo sea una letárgica marcha atrás de la recompensa monetaria de fin de mes (Dispositivo del burro y la zanahoria),

para empezar a disfrutar del día a día, transformándolo en un juego constructivo, hasta casi “sentir que no trabajamos”.

Sin duda el tema, da para mucho más que este artículo (y para autores más calificados!) pero la intención era traer a colación el tema, y tratar de poner en evidencia, o preguntar, ¿Cuántas cosas hacemos (o podemos hacer) en este sentido?

Leer más...

"La columna del medio"

Aportando dinámica a la pizarra

En nuestro equipo de trabajo contamos con los ambientes de desarrollo (pruebas de unidad) y de QA (pruebas de integración).

Desde hace tiempo venimos aplicando prácticas de SCRUM. Con el uso de la pizarra notamos la necesidad de diferenciar las tareas cuyo desarrollo se encontraba en progreso de aquellas terminadas y a la espera de un pasaje al ambiente de QA.

Esto era debido a que cada vez que terminábamos una tarea la pasábamos a la columna de “Test”, ocasionando muchas veces confusiones ya que no teníamos manera de saber si las tareas que se encontraban en esta columna estaban contempladas dentro del último build.

Durante un tiempo intentamos hacer el pasaje de papelitos solamente cuando hacíamos el build al ambiente QA, pero para eso contábamos con nuestra memoria para saber que tareas estaban completas, lo que no siempre resultaba con éxito por que… seamos sinceros… esta no siempre nos era fiel =)

Entonces un día, durante la retrospectiva de uno de nuestros proyectos tuvimos la siguiente maravillosa idea para arribar a una solución:

Agregar una columna intermedia entre DESA (In progress) y QA (Test) que nos permitiera saber, de forma inmediata, cuáles eran las tareas que estaban listas pero que todavía no estaban disponibles para ser probadas en QA…

¿Como funciona?

Cada vez que el desarrollador termina alguna tarea, mueve el papelito correspondiente de “In Progress” a la columna “DESA/TEST”(la columna del medio) indicando de esta manera que el desarrollo ha finalizado y estará disponible en el próximo build para su prueba.

Si bien debo reconocer que en un principio tuve mis dudas acerca de si la nueva columna iba a servir de algo, el uso de la misma nos demostró gran efectividad.

Su implementación acarreó las siguientes mejoras:

• Nos permitió tener una noción más precisa del avance del sprint, rompiendo con la sensación de un “avance estático” generado por la acumulación de tareas en la columna de desarrollo.
• Da una idea más clara al desarrollador de qué tareas le falta completar y cuáles completó.
• Brinda al tester la certeza de saber qué estará para probar.
• Es mucho más fácil decidir en qué momento hacer un pasaje de ambiente.

Resultado final

 

Conclusiones

Por nuestra experiencia, la incorporación de esta nueva columna trae grandes beneficios a la dinámica del equipo, agilizando la comunicación. Los invitamos a probar esta alternativa y que compartan con nosotros sus experiencias.

Leer más...

Sobre Ratas, Elefantes y TimeBoxing

La semana pasada nos dispusimos a realizar un cronograma de entregas para las próximas semanas de uno de nuestros proyectos, así que me reuní con el resto del grupo involucrado, y empezamos una planificación, haciendo una revisión rápida de las historias de usuario prioritarias en nuestro backlog.

Acto seguido, ubicaríamos estas historias de usuario según sus “tamaños” , prioridades y dependencias, en hipotéticos sprints, manteniendo presente el concepto de TimeBoxing.

La bolsa de Gatos

La lista resultó ser bastante extensa, y estimar el esfuerzo requerido por cada ítem, se volvía un poco confuso. Eran demasiado heterogéneas (lo que comúnmente llamamos bolsa de gatos).

Era necesario dividir un poco las aguas y separar cosas como “cambiar el color de fondo del campo X” de “diseñar un generador de fusión en frío”.

Creo que lo más peligroso de esto es que camufladas en medio de la estampida de historias de usuario más pequeñas, podían pasar desapercibidas las más pesadas o de más difícil estimación.

Una metodología de planificación para toda la familia

Normalmente utilizamos para estimar el esfuerzo requerido de cada historia de usuario, cartas de Planning Poker (gracias a Mountain Goat) al comienzo de cada sprint, sin embargo esta planificación prolongada requería de una primera clasificación grosera.

Fue así que con el ánimo de innovar un poco y de hacer la reunión un poco más divertida inventamos (y ofrecemos sin patente alguna) un método de planificación que podría llamarse “El Arca de Noé”.

Es importante que participen todos los miembros del equipo (funcionales, desarrolladores, líder de proyecto, etc. con sus diferentes visiones) y consiste básicamente en 2 etapas:

1. Clasificación

En esta etapa se toma cada una de las historias de usuario, y luego de una breve descripción, y discusión sobre sus implicancias (aquí típicamente es el momento de que un desarrollador advierta sobre dificultades posibles, o calle para siempre :)). se procede a su clasificación.

Las tareas se ubicarán en 3 grandes categorías de acuerdo al esfuerzo que representa la tarea, para hacerlo más entretenido decidimos identificar estas categorías con especies animales:

1. Rata: Con este nombre identificamos historias de usuario más rápidas de resolver y que no requieren casi ningún análisis sobre la forma de implementarlas. Típicamente cambios estéticos, cambios de configuración, pseudo-duplicar un componente ya existente, etc.
2. Perro: En esta categoría van tareas que implican un cierto análisis y/o un trabajo más cuidadoso o extenso que las anteriores.
3. Elefante: Finalmente elefantes son las historias de usuario más pesadas, generalmente requieren un esfuerzo de diseño, o hay muchas dudas sobre la forma implementarlo, o implica un riesgo díficil de estimar.

Finalmente es importante entender que tanto el número de categorías (3), como los criterios para ubicar un historia de usuario en cada categoría, son parámetros que deben ajustarse con el tiempo a las particularidades de cada equipo.

2. Planificación

En esta etapa al igual que Noé con su Arca, es dónde tenemos que acomodar estos animales (o historias de usuario) en compartimientos finitos (o sprints).

Advertencia: Si la cantidad de sprints es limitada, es posible que algunas historias de usuario se pierdan en el diluvio universal.

Para esto tenemos que sopesar diferentes criterios:

• Historias prioritarias para el cliente
• Dependencias entre éstas
• Recursos disponibles
• Imprevisibilidad o riesgo de una tarea (generalmente es preferible comenzar estas tareas lo antes posible para en caso de necesidad ajustar el rumbo a tiempo)

y otros que puedan ser particulares del proyecto.

Aquí es dónde se aplican todas las metodologías de planificación que normalmente utilizamos.

Por supuesto que la medida de cuántos “elefantes” entran en cada sprint, además de depender de los recursos disponibles en ese sprint, es algo que los miembros del equipo irán refinando con el paso del tiempo.

El Resultado:

Conclusiones

Antes de empezar a dibujar Gantts, Cronogramas o un Análisis de Riesgo, se hace necesario hacer una primera pasada que identifique las historias de usuario clave. Esta variante simple resulta bastante divertida, lo cual en una larga planificación nunca está demás.

Eso sí, una consecuencia inmediata y un poco vergonzosa, son expresiones del tipo; “Yo 2 elefantes en esta semana no me puedo comer, mejor empiezo agarro un elefante y voy intercalando con algunas ratitas” o “Me parece que nos estás vendiendo perro por rata”

Quién se anima a compartir otras variantes de este tipo?

Leer más...

Como excluir archivos de configuración de Source Control

Una pregunta que alguien se podría hacer al leer este artículo, es ¿porque voy a querer quitar los archivos de configuración del repositorio de código fuente?

El objetivo de los Repositorios de Código es justamente ese, resguardar el código, los archivos de configuración son necesarios al ejecutar la aplicación, y muchas veces al compilarla, tal es el caso del web.config, por este motivo necesitamos que sean parte del proyecto, pero tenerlos en el repositorio de código fuente nos puede traer algunos problemas.

Uno de los inconvenientes ocurre en los procesos de Deployment, ya que los archivos de configuración, ente otras cosas, almacenan información referida al ambiente donde corre la aplicación:

• Desarrollo
• Qa
• Producción
• etc

y el repositorio almacena versiones del código, independientemente de los ambientes en donde se instale.

En este sentido excluirlos, nos obliga a hacer un manejo especial con ellos en los diferentes pasajes de ambiente, que nos puede evitar errores. Por otro lado mientras estamos desarrollando, es bastante común hacer pruebas modificando los archivos de configuración, pruebas que nunca vamos a querer subir al repositorio de código (Ej.: apuntar la configuración a una Base de Datos local), si tenemos los archivos en el repositorio, es necesario hacer CECK OUT, para luego hacer UNDO PENDING CHANGES al finalizar la prueba. Esto, mas allá de ser una tarea tediosa para el desarrollador, es problemática si son muchos los que están trabajando al mismo tiempo.

Veamos cómo hacerlo

En este caso vamos a hacer un ejemplo utilizando como Repositorio de Código Fuente a Team Fundation Server.

En este ejemplo, voy a abrir la solución correspondiente al Sitio corporativo de Tercer Planeta http://www.tercerplaneta.com/, para excluir al web.config, cabe aclarar que esto se puede aplicar también, en una aplicación WinForms, excluyendo el app.config.

Al abrir la solución vemos la siguiente estructura de carpetas y archivos desde Solution Explorer de Visual Studio 2008.

El primer paso consta de hacer una copia del web.config, para luego renombrarlo como web.config.template. Este témplate nos sirve para almacenar la configuración que requiere la aplicación, en el también podríamos identificar de alguna manera, que cosas vamos a tener que modificar, cada vez que la aplicación se encuentre en un ambiente diferente.

Para esto nos paramos sobre el archivo web.config en el Solution Explorer, hacemos una copia del mismo y lo renombramos como lo dijimos anteriormente.

Luego de subir los cambios, pasamos a excluir el web.config de Source Control.

Para ello, seleccionando el web.config desde el Solution Explorer, debemos ir al punto de menú File / Source Control /Exclude web.config from Source Control como se ve a continuación.

Este último paso hace CHECK OUT del proyecto para marcar al web.config como archivo excluido.

Luego de guardar los cambios debemos eliminar definitivamente al web.config de Source Control, para esto en la solapa Source Control Explorer de Visual Studio 2008, debemos pararnos sobre el archivo web.config y hacer Click Derecho / Delete.

Si en este punto miramos la columna Pending Change, de la solapa Source Control Explorer vamos a ver que marca el archivo web.config como Delete y además hace cambios sobre los archivos del proyecto.

Como solo queremos quitarlo de Source Control y no del proyecto, lo que tenemos que hacer es desde el Source Control Explorer, deshacer los cambios sobre los archivos del proyecto.

Para eso los seleccionamos y hacemos UNDO PENDING CHANGES como se muestra a continuación.

Luego hacemos CHECK IN sobre el web.config , para podes borrarlo definitivamente.

Estos últimos dos pasos, hacen que el web.config desaparezca del árbol de Source Control, pero no lo excluye del proyecto web.

Si ahora observamos nuevamente el Solution Explorer vamos a ver que el web.config sigue apareciendo en la lista de archivos, pero ahora con dos iconos.

El icono rojo indica que el archivo está excluido de Source Control, mientras que el icono amarillo nos dice que no lo tenemos actualmente en el disco local.

El último paso consta de ir a nuestro disco local, hacer una copia del témplate que generamos en los pasos anteriores, y renombrarla como web.config, de esta manera en el Solution Explorer solo veríamos el icono rojo.

A partir de este momento el web.config, está localmente y nunca se va a pisar cuando hagamos Get Latest Version. Es importante aplicar los cambios al Témplate cuando se necesite hacer un cambio en el web.config, y avisar de esto al resto del equipo, para que lo actualice localmente.

De esta manera, cada puesto de trabajo pasa a tener su copia del web.config, que el desarrollador puede modificar cuando quiera, evitando hacer CHECK-OUT cada vez. Por otro lado, cada ambiente donde se instale la aplicación va a tener que tener su propio web.config, la forma de obtenerlo en este caso dependerá del mecanismo que utilicemos como publicación.

Leer más...