Monthly Archives: septiembre 2009

La Técnica Pomodoro

pomodoroLa técnica de pomodoro al igual que GTD (getting things done) o ZTD (zend to done), son técnicas para realizar las tareas diarias de forma ordenada y evitando distracciones.

Esta técnica debe su nombre a un reloj de cocina con forma de tomate (pomodoro), ya que, la propia técnica se basa en la medición del tiempo con un cronómetro, como los utilizados en la cocina.

La lista de tareas

Básicamente, hay tres artecfactos que se emplean para poder realizar esta técnica:

  • Inventario de Actividades: donde habrá que recoger todas las tareas a realizar.
  • Tareas para Hoy: las tareas que se han planteado para hacer hoy. El criterio para su selección puede ser la prioridad, dificultad o antigüedad.
  • Registro: donde, diariamente se apuntarán las tareas realizadas, junto con los pomodoros empleados para su compleción.

La gestión del tiempo

La técnica en sí, se basa en la gestión del tiempo mediante cortos periódos de dedicación exclusiva. Esto quiere decir que, cuando se comienza un periódo, se debe de estar completamente dedicado a esa actividad hasta que suene la campana.

Para desarrollar la técnica con precisión, necesitaremos un cronómetro o un sistema que nos alerte de cuando comienza y termina un pomodoro. Como su origen indica, puede ser un cronómetro fijo y real en la mesa del trabajador (lo cual puede ser algo incómodo en una oficina con muchas personas trabajando) o uno informático como este.

Los pomodoros (entendidos como los periódos de tiempo) deben de ser de no más de 30 minutos, con lo que, lo ideal, sería tener períodos de 25 minutos, con 5 minutos de descanso y, cada 4 períodos, hacer el descanso extensible de 15 a 30 minutos.

Cada tarea puede ocupar no solo un pomodoro, sino varios, esto se registra al final en el registro, poniendo las tareas realizadas, junto con el número de pomodoros invertidos en su realización.

Las interrupciones

Cuando se está trabajando en una tarea concreta y entra otra distinta con mucha prioridad, tanto que no puede esperar al final del pomodoro actual, se anula el pomodoro en curso y se comienza otro nuevo con la nueva tarea.

Este es el punto débil, quizás, de esta técnica, ya que si la dinámica de trabajo es hacerlo con incidencias y/o peticiones, podría producirse un momento en el que ningún pomodoro pudiese completarse en ninguna tarea, con lo que, llegamos al punto de que no se usa, realmente, esta técnica.

Conclusiones

Para las tareas de desarrollo y sobre todo en proyectos, sin incidencias, esta es una gran técnica equiparable a GTD y ZTD. No obstante, si el entorno de trabajo es más orientado a eventos, a interrupciones, esta técnica no aplica, puesto que las propias interrupciones son las que van marcando los tiempos a poder aplicar.

Para saber más:

Entrenador (Coach) de Desarrollo de Software

El término de entrenador (coach) de desarrollo de software es un papel que suele ser muy importante en el quehacer diario de una empresa que tiene desarrollos de software, ya sean internos o para clientes externos.

¿Qué hace el entrenador (coach)?

Los cometidos del entrenador son dos, que pueden parecer contrapuestos, pero que se pueden combinar para conseguir lo mejor de cada una de ellas, según el momento en que se necesiten emplear:

  • El mentor, de las tareas propias de desarrollo, indicando e incluso enseñando con el ejemplo, el cómo se hacen las tareas. De este tipo, aunque no se suelen dedicar exclusivamente a esto, hay algunos en las empresas de software actuales.
  • El entrenador, propiamente dicho, se encarga de trazar la estrategia y encauzar a los jugadores dentro de la misma a hacer lo que mejor saben hacer para conseguir los mejores resultados. Realmente, cualquier jefe o mando intermedio se encarga de estas tareas mediante órdenes. El trazado del plan estratégico a seguir, el plan de proyecto, es algo que pocos jefes o mandos intermedios hacen.

La faceta del mentor

La labor de enseñanza es algo intrínseco al mundo de la informática, ya que todo avanza tan rápido, que es necesario ponerse cada poco tiempo al día de las nuevas tecnologías, y sobre todo, las que nos ayuden a mejorar el ritmo de desarrollo de nuestras labores cotidianas.

Por tanto, para hacer la labor de enseñanza, el perfil de coach debería de ser técnico, ya que, además, en el mundo en que vivimos, decir a un subordinado, ya estresado por el trabajo, que aprenda solo una tecnología y la aplique a un proyecto, puede ser el detonante principal de quedarse, poco a poco, sin equipo.

Por otro lado, si la formación es impuesta por el coach mediante ejemplos en el propio proyecto de desarrollo, ya sea por él mismo o por gente subcontratada que dé el primer paso (en caso de que el coach no tenga un perfil técnico). Como se suele decir predicar con el ejemplo.

La faceta del entrenador

Como es normal, un gestor de proyectos, es necesario e imprescindible que gestione de la mejor forma posible los recursos humanos y los proyectos que hay que realizar, dados por prioridades, para que cada uno de ellos se consiga terminar en el menor tiempo posible.

El gestor de proyectos debe de facilitar, al igual que el perfil de Scrum Master con su equipo, todo lo necesario para que su equipo pueda realizar sus proyectos.

Conclusiones

El coach es el perfil que estaría, en Scrum, jerárquicamente, por encima del Scrum Master y que ayudaría a los equipos a su gestión y promoción para su mejora.

Se encarga de la recepción de los proyectos, la valoración con los equipos o equipo específico, y su apilación en la lista de proyectos a realizar. Esta es, quizás su faceta más importante.

No obstante, la labor de enseñanza, hacer de mentor o facilitar mentores para sus equipos, no es nada desdeñable y debe de considerarse también como un punto importante en las tareas a desempeñar de este rol.

La Historia de Erlang

He encontrado un documento (en inglés) que redacta la historia de Erlang contada por su desarrollador principal, en los laboratorios de Ericsson:

Erlang fue diseñado para escribir programas concurrentes que se ejecutasen eternamente. Erlang usa procesos concurrentes para estructurar el programa. Estos procesos no tienen memoria compartida y se comunican por paso de mensajes asíncronos. Los procesos de erlang son ligeros y pertenecen al lenguaje, no al sistema operativo. Erlang tiene mecanismos que permiten que los programas cambien on-the-fly (en vivo) así, esos programas pueden evolucionar y cambiar sin detener su ejecución. Estos mecanismos simplifican la construcción de software implementando sistemas non-stop (que no se detienen).

El desarrollo inicial de Erlang tuvo lugar en 1986 en el Laboratorio de Computación de Ericsson. Erlang fue diseñado con un objetivo específico en mente: proporcionar una mejor forma de programar aplicaciones de telefonía. En ese momento, las aplicaciones de telefonía eran atípicas del tipo de problemas que podían resolver los lenguajes de programación convencionales. Las aplicaciones de telefonía son, por su naturaleza, altamente concurrentes: un simple switch debe manejar decenas o cientos de miles de transacciones simultáneas. Tales transacciones son intrínsecamente distribuidas y el software se espera que sea altamente tolerante a fallos. Cuando el software que controla los teléfonos falla, sale en los periódicos, algo que no ocurre cuando fallan las aplicaciones de escritorio. El software de telefonía debe también cambiar on-the-fly, esto es, sin perder el servicio mientras se realiza una actualización del código. El software de telefonía debe también operar en tiempo real, con ajustados requisitos de tiempo para algunas operaciones, y más relajado tiempo en otras clases de operaciones.

Como puede leerse en el extracto, Joe Armstrong, fijó los requisitos de Erlang en solucionar los problemas de un entorno altamente concurrente, que no puede permitirse caer y que debe de actualizarse sin pérdida de servicio.

Actualmente, esta definición casa con casi la mayor parte de servicios en Internet.

Cuánto cuesta un Proyecto de Software

Hoy ya hace unas semanas que en la empresa en la que trabajo se ha comenzado un movimiento positivo en favor de medir lo que cuesta realizar desarrollos de software, dentro del departamento de desarrollo, lo cual es positivo desde el punto de vista del desarrollador, del programador y de los directivos.

Hay que tener siempre presente que, cuando se realiza un trabajo, ya sea el que sea, si lo realiza una persona ajena, no de la empresa, se paga una factura por sus servicios, en los que viene detallado, normalmente, la mano de obra, que suele cobrarse en factor de tiempo empleado.

El coste asociado de emplear a una persona que está en nómina, dentro de la propia empresa, puede ser menor, pero no cero. Si un empleado cobra en bruto unos 2000 euros mensuales y le mandamos hacer un trabajo para lo cual gasta todo un mes, es de lógica pensar, que ese trabajo me ha costado esos 2000 euros, ya que es lo que ha hecho el empleado. Si el proyecto al final solo hace ingresar a la empresa 200 euros, la empresa ha perdido con ese desarrollo 1800 euros.

En el caso de que un proyecto se desarrolle en dos semanas de ese trabajador, por redondear, damos que son 1000 euros el coste y se consiguen 1200 euros. La empresa ha conseguido con su labor 200 euros… pero si el desarrollo ha sido deficiente, por el poco tiempo empleado, y el programador tiene que ir invirtiendo horas, que al final resultan ser días (en suma) y llegan a ser otras dos semanas, tendremos que esos 200 euros se convierten en 800 euros de pérdidas.

El las metodologías ágiles se hace hincapié a dar valor, es decir, realizar el desarrollo por iteraciones, siempre haciendo lo que más valor dé al cliente. Por ejemplo, si tenemos 10 requisitos en un proyecto, impuestos por el cliente, pero los más importantes son los 2 primeros, podemos negociar con el cliente el hacer esos dos primeros, valorarlos con el tiempo que toma el realizarlos y, en caso de querer el resto de requisitos, o algunos más, volver a realizar otra petición.

¿Qué conseguimos con esto?

  • Que el cliente pida lo que necesita, únicamente.
  • Que el precio que se pague sea el justo y necesario, e incluso no muy desorbitado para el cliente.
  • Que la estimación de tiempo sea más ajustada a la realidad, siendo los plazos de desarrollo más cortos.
  • Que el cliente consiga su producto, su valor, antes.

Por lo que recomiendo a todos los que trabajan en nómina en una empresa, y su jefe (o siendo jefes) no se lleven el cómputo de horas invertidas en proyectos, incidencias, etc., que lo hagan, porque es una moneda de cambio muy útil para cuando se quieren conseguir cosas importantes, dentro de la empresa.