Antes de seguir, aclaro que mi postura es la de definir al programador como aquel que no se especializa en otra cosa que no sea codificar nuevas funcionalidades en función de diseños recibidos. No contribuye a escribir o entender las especificaciones. Ni se le ocurre escribir pruebas automatizadas. No colabora para mantener el build actualizado. Ni que hablar de las pruebas. No ayuda al cliente a comprender sus necesidades ni a resolver sus problemas. Se dedica solo a eso, a escribir código.

La tendencia actual del desarrollo de software y las metodologías ágiles está comprendiendo cada vez más la necesidad de contar con equipos multidisciplinarios, o en otras palabras, personas que contribuyan de distintas maneras al objetivo buscado, en lugar de personas que solo se especialicen en una parte del proceso y que no tengan una visión completa de él.

De esta manera, todos son igual de responsables por alcanzar los logros y la existencia de fracasos (si la hubiera). La solución más razonable que algunas organizaciones están ofreciendo frente a los contextos de negocios cambiantes es aumentar la flexibilidad. Incluso es lógico deducir que el hecho de contratar solo especialistas en determinadas áreas generará muchos mayores costos económicos e incluso de comunicación dentro del equipo, lo que puede atentar contra el desarrollo exitoso del producto.

¿Qué se espera de un desarrollador? El desarrollador es básicamente quien aunque no hace TODO al mismo tiempo (eso sería un absurdo), conoce el proceso de principio a fin y por eso logra detectar “a tiempo” cualquier “contratiempo” que pudiera surgir. En otras palabras, sería como esas nuevas cámaras digitales que obtienen una imagen panorámica que ofrece una visión completa de la escena fotografiada.

Entre las tareas de un desarrollador se encuentran:

• Entender el negocio y los objetivos que se están persiguiendo
• Colaborar con el Product Owner para identificar las historias de usuario y sus criterios de aceptación
• Ser parte protagonista a la hora del armado y mantenimiento del entorno de trabajo
• Garantizar las prácticas ágiles de desarrollo de software como Integración Continua, TDD, ATDD
• Participar en el diseño de la solución, tanto lógico como arquitectónico

Por un mundo mejor, las responsabilidades del desarrollo del producto deben estar compartidas entre todos los involucrados en el proyecto, con la salvedad de que el Product Owner no requiere, en la mayoría de los casos, tener conocimientos técnicos. Sí, percibo que la siguiente pregunta es: ¿y el Scrum Master? Mi respuesta es otra pregunta ¿Cómo podría el Scrum Master remover impedimientos y garantizar al equipo un adecuado entorno de trabajo si no tiene los conocimientos técnicos necesarios de los desarrolladores? Cito:

“Un conocimiento íntimo y detallado de cómo algo funciona incrementa las posibilidade de que el líder ayude al equipo a descubrir las cuestiones técnicas más sutiles que deban ser tratadas” (LaFasto & Larson, When teams work best, 2001, p. 133).

En el fondo, aunque el equipo sea el encargado principal de desarrollar el producto y naturalmente es quien mejor conoce su desarrollo, el Scrum Master no debería desconocer los aspectos del desarrollo y en algunos casos, hasta debería ser quien mejor los conozca si es que se quieren evitar problemas de comunicación, interpretación y estimación; pero sobre todo, si se pretende alcanzar un objetivo exitoso.

Volviendo al comienzo: lo que necesitamos son verdaderos desarrolladores, personas que cuenten con las herramientas y prácticas necesarias para lograr un proceso de desarrollo exitoso y un producto de alta calidad. Esto no quiere decir que no se necesite también de los programadores, pero no confundamos un desarrollador o “developer” con un simple programador. Incluso un excelente programador podría ser un pésimo desarrollador y un Scrum Master que no ha adquirido estas herramientas a lo largo de su formación podría eventualmente ser percibido por el equipo de desarrollo como falto de las habilidades necesarias para cumplir su función.

Si apenas podemos entender estas diferencias fundamentales, habremos dado un paso más hacia un mundo de trabajo mejor.

Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “DBAs” como parte de la serie “Roles ágiles“.

DBAs Ágiles

Los profesionales de datos, sean administradores de bases de datos, ingenieros de base de datos, o algo más, pueden ser unos de los más resistentes a la adopción de Scrum. Mucho de lo que en la sección anterior se dijo acerca de los programadores también aplica para los administradores de base de datos. Además, los profesionales de datos se enfrentan a aprender a hacer gradualmente lo que ha sido considerado tradicionalmente como parte de un proyecto tradicional.

El estándar en asesoramiento en diseño de bases de datos ha sido el de hacer un análisis completo de las necesidades del sistema, crear un diseño de base de datos lógica o conceptual, y luego el mapeo de esos conceptos a las limitaciones de una base de datos del mundo real, durante el diseño de base de datos física. El éxito en esta serie de pasos se basa en un análisis completo y preciso por adelantado. El punto de vista de los profesionales de datos tradicionales fue resumido de la mejor manera por un compañero de viaje en un avión de Chicago a Sacramento. Era un vicepresidente de desarrollo de base de datos para una compañía de salud relativamente grande. Su punto de vista sobre el mundo era “las aplicaciones cambian, los datos son para siempre”.

Este tipo de pensamiento conduce a un fuerte enfoque en hacer un análisis completo por adelantado. Esto es lindo en teoría, pero al mismo tiempo en que estamos haciendo  el análisis completo, el mundo sigue evolucionando. Las necesidades de los usuarios están cambiando. Los competidores están lanzando sus productos. Las bases de datos necesitan evolucionar para apoyar la evolución de las aplicaciones construidas sobre ellos.

En muchas formas, el diseño de experiencia de usuario, arquitectura y diseño de bases de datos son todos casos especiales del mismo desafío: trabajar de forma incremental en algo que está pensado de manera integral. Gran parte del día a día de un DBA no va a cambiar mucho, pero cómo los DBAs van a enfocarse y agendar su trabajo va a cambiar drásticamente y se discutirá en el capítulo “Trabajando Juntos a lo largo del Sprint”.

Hace un tiempo escribí un artículo acerca de la técnica de defragmentación del día laboral. Desde ese momento en adelante intenté implementarla en mi día a día sin mucho éxito, la verdad. Los inconvenientes que encontré en el camino pueden corresponder a una particularidad del entorno: trabajar en un equipo global, con gente en España y Chicago, lo que no me permitió agrupar las reuniones. Este tema definitivamente echó por tierra la teoría.

Por tanto seguí con una técnica que hacía un tiempo tenía en el cajón, la cual parece muy interesante y no tan difícil de implementar: la Técnica Pomodoro de Francesco Cirillo. Lo que más me atrae de ella son las similitudes que tiene con las bases de las metodologías ágiles: planificación incremental, priorización por ROI, time-boxing, retrospectivas, etc. (ya trataremos este tema en otro post).

En este post no pretendo hacer un análisis minucioso de la Técnica Pomodoro, simplemente explicar de una manera breve su funcionamiento para quien no la conozca y quiera eventualmente probarla. Si alguien desea ir más en profundidad, hay un PDF muy bueno en el site oficial y un libro llamado The Pomodoto Technique Illustrated, 100% recomendable.

Introducción

La Técnica Pomodoro funda sus bases en el supuesto de que el tiempo es considerado un enemigo por mucha gente y que la generación de ansiedad (consecuencia) lleva a las personas hacia un comportamiento ineficiente en el estudio y el trabajo. El resultado inmediato es: postergar las cosas en el tiempo.

La Técnica Pomodoro identifica dos aspectos profundamente interrelacionados que parecen coexistir con relación al tiempo:

• El “devenir“: Un aspecto abstracto y dimensional del tiempo, que da origen al hábito de medir el tiempo (segundos, minutos, horas); la idea de representar el tiempo en un eje, el concepto de la “duración”, la idea de “tarde”.
• Sucesión de eventos: Un aspecto concreto del orden temporal: Nos levantamos, tomamos una ducha, tomamos el desayuno, estudiamos, almorzamos, tomamos una siesta, jugamos, comemos y nos vamos a dormir.

El propósito de la Técnica Pomodoro es proveer una herramienta/proceso simple para mejorar la productividad (la propia y la de tu equipo) que sea capaz de hacer lo siguiente (entre otras):

• Aliviar la ansiedad vinculada con el devenir
• Mejorar el foco y la concentración a través de la disminución de interrupciones
• Impulsar la motivación y mantenerla constante
• Reafirmar la determinación de alcanzar tus metas
  (para ver la lista completa, referirse al paper oficial)

Los Artefactos

En la Técnica Pomodoro hay tres artefactos:

• Inventario de Actividades: Una lista donde se registran las tareas a medida que aparecen. Al final del día se tildan aquellas que ya fueron finalizadas.
• Tareas para Hoy: Una lista de las tareas para hacer durante el día, ordenadas por prioridad. Y una sección rotulada “Imprevistos y Actividades Urgentes” donde cualquier tarea inesperada con la que hay que lidiar debe ser listada a medida que aparece. Estas últimas podrían modificar el plan del día.
• Planilla de Registro: donde registraremos al final del día las tareas completadas y la cantidad de Pomodoros (ya veremos que son) que tuvimos que invertir para termina cada una.

El Pomodoro

El corazón de la Técnica Pomodoro es un cronómetro de cocina (de quien adopta la expresión italiana “Pomodoro”, por su forma de tomate). Este cronómetro es utilizado para marcar los time-boxes que dan el ritmo/iteraciones que utilizaremos para trabajar en las tareas durante el día.

Las Iteraciones

También llamadas “Pomodoros”, son periodos de tiempo fijos (30 minutos) de los cuales 25 minutos están dedicados a una tarea y 5 minutos utilizados para descansar, recrearse. Una vez terminados estos 5 minutos, se inicia una nueva iteración de 25 minutos. La herramienta para marcar estos 25 minutos iniciales es un cronómetro con alarma.

Cada Pomodoro es indivisible e ininterrumpible. Si por alguna razón debo interrumpir el Pomodoro, dicha iteración se considera inválida y se debe comenzar una nueva, desde cero.

Cada 4 Pomodoros válidos el recreo es más extenso: de 15 a 30 minutos.

Nota: Aquí solo me limito a describir la técnica. Cada recreo, y sus longitudes, tienen una razón; para entrar más en detalles recomiendo leer el paper oficial.

Las Tareas y El Proceso

Las tareas que van apareciendo, si no son urgentes, deben registrarse en el “Inventario de Actividades”. Al principio de cada día se seleccionan las tareas que se van a realizar durante esa jornada y se copian a la planilla “Tareas para Hoy”. Esta planificación puede realizarse durante el primer Pomodoro (iteración) del día.

En la próxima iteración tomo la primer tarea de las “Tareas para Hoy” y me enfoco 100% en dicha tarea. No puedo quitar la atención durante esos 25 minutos. Esto significa no leer e-mails, no ponerme a chatear con un amigo, no charlar con el compañero, no perder el tiempo. Ya tendré unos minutos para hacerlo al término de la iteración.

Si termina el Pomodoro y no he terminado la tarea, no importa: me tomo el recreo de 5 minutos sí o sí. Luego comienzo una nueva iteración enfocándome en la tarea en la que venía trabajando y aun no está terminada.

A medida que voy consumiendo las iteraciones, voy marcando una “X” por cada iteración en la tarea a la cual me dediqué. Es importante aclarar que una iteración debe dedicarse a una única tarea. Si tengo tareas muy chicas, las agrupo en un único conjunto y dedico la iteración al conjunto entero.

Si por alguna casualidad, termino la tarea dentro de los 5 minutos iniciales de la Iteración, considero dicha iteración como inválida. No registro la “X”, paso a la próxima tarea e inicio una nueva iteración desde el comienzo.

Ejemplo simple del proceso

Supongamos por un momento que estas son todas las cosas que debo realizar:

Al comenzar el día, selecciono las cosas que voy a hacer hoy y las ordeno por prioridad en mi lista de “Tareas para Hoy”:

Seteo mi cronómetro en 25 minutos, lo lanzo y de esta manera arranco mi primer Pomodoro, dedicándome a la primer tarea de la lista. Al cabo de esos 25 minutos suena la alarma del cronómetro, lo que indica la finalización del Pomodoro y registro con una “X” dicho Pomodoro en la tarea correspondiente (ver en rojo):

Tomo un recreo de 5 minutos, desconectándome por completo de la tarea que estaba realizando. Al terminar el recreo, vuelvo a lanzar un nuevo Pomodoro y sigo con la tarea en la que venía trabajando.
Al finalizar este y dos Pomodoros más, ya llevo un total de cuatro Pomodoros. Es el momento de tomarme un recreo más extenso (de entre 15 y 30 minutos):

Al terminar el recreo, vuelvo a lanzar un nuevo Pomodoro y sigo con la tarea en la que venía trabajando. Entre Pomodoro y Pomodoro descanso 5 minutos y cada 4 Pomodoros me tomo un recreo más largo. De esa manera sigo hasta terminar con la tarea en cuestión. En ese momento la tacho:

Y de esta manera continúo Pomodoro tras Pomodoro hasta terminar el día:

Lidiando con las interrupciones

Las interrupciones son el tema más sensible a la hora de implementar la Técnica Pomodoro.

La Longitud de un Pomodoro, 25 minutos, parece ser lo suficientemente corto para evitar que la persona sea distraida por varios tipos de interrupciones. Pero la experiencia muestra que una vez utilizando la Técnica Pomodoro, las interrupciones pueden transformarse en un verdadero problema.
Fuente: The Pomodoro Technique, by Francesco Cirillo

La técnica pomodoro propone una estrategia efectiva para minimizar la cantidad de interrupciones, y para esto, divide dichas interrupciones en dos categorías: Internas y Externas, tema que será abordado en un artículo posterior.

Importante

Como he comentado anteriormente, este post solo es un resumen parcial de la Técnica Pomodoro. Para obtener más detalles y profundizar los conocimientos de la misma recomiendo a todo lector visitar el sitio oficial: The Pomodoro Technique by Francesco Cirillo.

Read this article in English

Hace algunos días mientras estaba navegando en Internet, encontré un artículo llamado “Desfragmenta tu Día”, el cual me llamó la atención.

Leyendo el mismo, la idea es agrupar las diferentes actividades del día en segmentos del mismo tipo en vez de desparramar dichas actividades en el calendario.

Aparentemente es una buena idea para mejorar, pero aún tengo algunas dudas en su implementación, porque asume que las personas trabajan al menos 3 horas por las noches luego de las 22:00… ¿¿¡¡Qué!!?? Vamos, yo no quiero pasar el resto de mi vida trabajando de 10PM a 1AM todas las noches (además de mis horas normales de oficina). ¿Vos sí?

Ok, démosle crédito de todas maneras, podríamos asumir que es un esquema para un periodo de mucho trabajo, como una implementación, o un cierre de libros anuales, etc. Que demandaría un mayor esfuerzo de tu parte.

Entonces, yo voy a tratar de evitar esas 3 horas cada vez que pueda, dejándolas solo para casos de emergencia o situaciones críticas. ¿Tiene sentido? Espero…

Si asumimos eso, parece ser una buena idea. ¿Sabes qué? La voy a poner en práctica en mi día a día a ver cómo resulta y qué problemas encuentro. Adicionalmente, voy a postear aquí mis experiencias al respecto.

De paso, el artículo original fue escrito por Kevin Milden para New Leaders. Lo puedes encontrar aquí: http://newleaders.com/discussions/369-defragment-your-day; yo hice una traducción al español para quien no sabe o no le interesa leerlo en Inglés, también disponible aquí: http://es.agilebar.com/2009/04/desfragmenta-tu-dia/

Saludos!