Martín Alaimo
… de personas y sistemas.
Arquitectos Ágiles
0hace 2 años
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
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 “Arquitectos” como parte de la serie “Roles ágiles“.
Arquitectos Ágiles
Muchos arquitectos han trabajado durante años para merecer el título de arquitecto. Están legítimamente orgullosos de sus conocimientos, experiencia y capacidad para proponer soluciones elegantes a los desafíos técnicos y de negocio. Me parece que muchas de las preocupaciones planteadas por los arquitectos frente a la adopción de Scrum se pueden ubicar en estas dos categorías:
- ¿Las Personas seguirán aplicando las arquitecturas que les digo?
- ¿Cómo puedo asegurar que construiremos un producto con buena arquitectura sin una fase de diseño de arquitectura?
Gerentes de Proyecto Ágiles
0hace 2 años
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
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 solo la sección de “Gerentes de Proyecto” como parte de la serie “Roles ágiles“.
Gerentes de Proyecto
En un proyecto con un proceso de desarrollo secuencial, el gerente del proyecto tiene la difícil tarea de asegurar que el producto que desea un cliente es el que se desarrolla. Para ello, el gerente del proyecto debe tratar de manejar todo lo relacionado con el alcance, costo, calidad, personal, comunicación, riesgo, adquisiciones, etc. Algunas de estas responsabilidades en realidad pertenecen a otros. El control del Alcance, por ejemplo, por derecho le pertenece al cliente. (más…)
Analistas Ágiles
0hace 2 años
“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”
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 solo la sección de “Analistas” como parte de la serie “Roles ágiles“.
Analistas
Con un conocimiento íntimo del producto y fuertes habilidades de comunicación, algunos analistas van a tender a transformarse en Product Owners. (más…)
Pausas entre Sprints
0hace 2 años
por Martin Alaimo
en Proyectos Ágiles
La semana pasada hubo una conversación dentro de una organización en la cual estoy trabajando con la implementación de metodologías ágiles en la industria de servicios creativos.
El punto clave era si había una forma de introducir una pausa entre sprints, esto es algo que surgió de una retrospectiva. El hecho es que el equipo lo solicitó, pero el Product Owner no estaba del todo de acuerdo, en realidad no quería pausas entre sprints. Sus argumentos fueron: Necesitamos un ritmo sostenido y pasar todo el tiempo haciendo el trabajo necesario para producir los entregables.
Después de discutir con ambas partes y que ellos expongan sus puntos de vista, le di mi opinión:
Yo personalmente no creo que tener un descanso entre sprints atente contra el ritmo sostenido. La ritmo sostenido es como su nombre lo indica: “ritmo”, los latidos del corazón, no es sobre “el desarrollo continuo”. Es decir, podemos tener un sprint de longitud fija, sin alteraciones y una pausa de longitud fija, digamos de medio día. Si lo hacemos de esa manera, y preservamos esas longitudes en el tiempo, entonces todavía seguimos hablando de ritmo sostenido, ¿correcto?
Otra situación podría ser completamente diferente si tenemos longitudes de tiempo aleatorias, como la mitad un día después del primer sprint, dos días después del segundo sprint y un día después del tercer sprint. Esto atenta completamente contra el “ritmo sostenido”.
Por otra parte, al hablar de “desarrollo continuo”, me di cuenta de que el PO estaba hablando de que los miembros del equipo solo debían trabajar en entregables creativas todo el tiempo (diseño, redacción, creación, etc) … ok, yo tendría mucho cuidado en esto, debido a que la gente todavía necesita ser capacitada y entrenada, independientemente de la industria en la que estén.
Yo mismo vengo de la industria de la ingeniería de sistemas, un rubro en el que cualquiera puede convertirse en un programador obsoleto si no recibe entrenamiento o actualizaciones sobre las últimas tecnologías. Por supuesto, esto es de alguna manera extremo, pero ocurre a todas las personas independientemente de su industria.
No hubo demasiada discusión hasta que logramos un acuerdo compartido sobre los descansos entre sprints: decidimos tener la demo y reuniones de retrospectiva durante la mañana del último día de cada sprint y luego un espacio libre durante la tarde (cada 2 semanas).
¿Qué van a hacer? Bueno, será utilizado de tres formas diferentes:
- El equipo asistirá a las sesiones de entrenamiento o preparará las sesiones de capacitación sobre actualizaciones de la industria o
- invitar a alguien de interés a asistir a una sesión de discusión con ellos, a fin de actualizarse y discutir sobre nuevos enfoques, nuevos movimientos o de los últimos eventos de la industria o
- Las personas participar en el blog corporativo, con un artículo, o conseguir que participen en las conversaciones en blogs y así conseguir los beneficios de la web 2.0
Estaremos monitoreando de cerca cómo va esto… estoy muy emocionado con este enfoque. Sin duda alguna, recomendaría una pausa de estas características entre sprints. 
Triple Restricción Ágil
0hace 2 años
Volviendo de las vacaciones, este año que pasó fue bastante movilizante; lleno de cambios y desafíos. Este año que vino es uno del cual soy muy optimista; veo muchas oportunidades, espacios de discusión y nuevas ideas apareciendo.
Año Nuevo: blog post nuevo. Esta oportunidad quiero escribir acerca de una comparación/competencia que escucho mucho en el mundo ágil: PMPs en un entorno ágil.
Muchas veces escucho preguntas o argumentos de parte de PMPs (yo mismo también soy PMP) acerca de cómo implementar agile, por qué agile no aplica en un entorno PMI, y demás.
Están sucediendo muchas cosas en el mundoPMI-Agile, especialmente desde mediados del 2009. Un enfoque interesante que he escuchado sobre cómo ayudar a PMPs a cambiar su filosofía/o entender mejor la forma en la que agile funciona a alto nivel es:
Agile se concentra en tres aspectos diferentes:
- Prácticas de Ingeniería
- Prácticas de Liderazgo
- Prácticas de Gestión de Proyectos
Enfocándonos solo en el aspecto de la Gestión de Proyectos, podemos hablar de la conocida “restricción triple”:
En cualquier entorno de Gestión de Proyectos, las variables más importantesa monitorear son: Alcance, Tiempo y Costo. (También lo son la Calidad, la Satisfacción del Cliente y los Riesgos; pero en esta oportunidad prestaremos especial atención a las primeras tres).
la Gestión de Proyectos tradicional determina que siempre que se comience un proyecto, se debería comenzar por el Alcance. Una vez que elalcance esté lo suficientemente claro uno puede comenzar a “jugar” con los recursos, asignaciones, secuencias de actividades, etc., que nos llevarán a determinar el Tiempo que va a llevar y el Costo del trabajo. Resultado: unlindo Gantt chart.
Luego uno presenta este Gantt chart a los sponsors y la reacción típica es: Nos solicitan reducir el Tiempo y el Costo.
Luego, como Project Manager, uno comienza a pensar en incrementar el equipo, dividir el trabajo en diferentes fases, construir en paralelo (incrementando el riesgo, por supuesto). El desafío tradicional luego se convierte en elproblema tradicional: Gantt charts muycomplejos, con dependencias complejas que van a requerir coordinación compleja.
En vez de eso, el enfoque ágil ataca el problema desde otra dirección; el punto de partida es el Tiempo y el Costo: Cuánto dinero se quiere invertir durante cuento tiempo? Esto da como resultado un equipo durante una tiempo predeterminado, y el compromiso de entregar la mayor cantidad de software funcionando posible.
De esa manera tenemos:
- Un Costo fijo: El equipo en sí (horas de trabajo).
- UnTiempo fijo: Time boxes, iteraciones, releases.
- Un Alcance variable: El alcance es el lado variable del triángulo, el cuales inyectado iteración trás iteración y transformado en software funcionando.
En mi opinión, esta es la explicación más clara de la diferencia de puntos de vista de cada enfoque: tradicional y ágil. ¿No te parece?
Fotografía por Yui Kubo: http://www.flickr.com/photos/yu-kubo/398714467/
Resultado del AO La Plata 2009
0hace 2 años
El Sábado 20 de Junio se realizó el evento Agile Open La Plata 2009, donde contamos con la presencia de 65 personas.
Luego del desayuno realizamos la Apertura, que me tocó facilitar a mí. Una experiencia increíble: fue mi primer facilitación de un evento Open Space. El principio fue como suele suceder en este tipo de eventos: la gente no termina de digerir el formato sino hasta unos 10 minutos luego de que ponen manos a la obra, el resultado fue cerca de 40 propuestas de sesiones, una votación bastante fluida y la siguiente definición de agenda:
Agenda AO La Plata 2009
Destaco algunas sesiones en las que pude participar, todas de un excelente nivel:
Introducción a Lean (facilitada por Juan Gabardini) e Introducción a las Metodologías Agiles (moderada por Nicolás Paez) fueron las dos sesiones que dieron el puntapié inicial. A la gente se la vio muy enganchada con los temas y reconozco que me costó bastante cortar las mismas en tiempo, debido al entusiasmo de los presentes.
Las estrellas del segundo track fueron Introducción a SCRUM (propuesta y moderada por Marcelo Belnicoff) y Comunicación en Equipos Ágiles (moderada por Nicolás y Esteban).
El almuerzo se realizó a tiempo, se generó un excelente clima donde la gente siguió compartiendo inquietudes, experiencias, dudas, opiniones. Un gran contexto para el networking.
La tarde comenzó con el Juego del Pajarraco, del cual tengo un par de fotos del proceso (sacadas con el celular) y con muchas otras sesiones paralelas, ya más avanzadas en las que tuve la suerte de participar: CMMI+PMI+Agile, Equipos MUY chicos, Testing Ágil, Cómo vender ágil al cliente, metodologías ágiles fuera de la industria IT, etc.
* Fotos Pajarraco:
Luego de un coffee break que llegó para amenizar la tarde de muchos desde el punto de vista gastronómico , se debatió bastante sobre Retrospectivas (discusión abierta) y hubo una presentación de Arquitectura Ágil (por Diego Fontdevila).
Llegamos al cierre con una considerable cantidad de gente (arriba de 40). El mismo fue facilitado por Diego con resultados excelentes, a los que estamos acostumbrados en todo Open Space: gran interacción personal, mucha participación activa en general, temas realmente interesantes, debatir sobre metodologías ágiles en una conferencia organizada en forma ágil, experiencias vivenciales, etc. El Resumen fue más que positivo:
Resultado AO La Plata 2009
Los próximos pasos a nivel “La Plata” son organizar encuentros mensuales para discutir sobre metodologías ágiles replicando el modelo que lleva meses funcionando en Buenos Aires mientras que a nivel nacional tenemos por delante la organización y realización de los Agile Open Rosario, Mar del Plata y Bahía Blanca. Y cualquier otra nueva ciudad que quiera sumarse.
Pasó un nuevo Agile Open, que como todos los anteriores también ha dejado su huella.
Trabajando con la Generación Y
1hace 2 años
Liderar un equipo de gente joven (y no me estoy refiriendo al niño interior que todos llevamos dentro, sino a adultos jóvenes en sus 20s) requiere conocerlos y entender cómo interactúan con las metodologías agiles.
¿Quiénes son? La generación “Y” o también llamados “Millennials”, “Internet Generation” e incluso “Google Generation” es la que comprende al grupo poblacional nacido entre 1981 y 1997. Y ya se han convertido en la nueva “fuerza laboral” mundial.
Es la generación de MTV y las zapatillas “All Stars” que vivió el fin de la Guerra Fría, la expansión de modelos familiares no tradicionales, y la revolución tecnológica. Son los jóvenes que no conciben la vida sin tecnología (SMS, telefonía celular, IPods, Reality Shows, Internet 2.0) y que probablemente no podrían vivir sin ella.
La fuerte identificación de grupo a partir del cual construyen su identidad personal es una de sus características más contundentes (¿a quién no le suena el concepto de “tribus urbanas”?). No piensan en un futuro teniendo como eje el trabajo (como sí sucede en las generaciones anteriores), ni mucho menos piensan en un proyecto a largo plazo. Su proyecto de vida es el “hoy”, son curiosos, les encanta experimentar, cambiar de trabajos y no “casarse con nadie”.
Por alguna razón, a diferencia de la generación que los antecede, no sienten entusiasmo por la vida pública y no aceptan los modelos tradicionales de autoridad, siendo más colaborativos que jerárquicos.
¿Qué es lo que hay que tener en cuenta para trabajar con la Generación Y en el desarrollo de tecnologías, pero también en cualquier otro tipo de trabajo?
- La Generación Y es ávida de aprender, y les gusta mantenerse al día con los avances tecnológicos, algo muy positivo para captar rápidamente nuevos conceptos y modalidades de trabajo
- Mantienen un nivel muy bajo de concentración, y se aburren fácilmente. Por ello son recomendables las tareas que no se expanden en el tiempo y que brindan resultados concretos a corto plazo. Esto no quiere decir que no les guste trabajar, al contrario, son muy entusiastas, pero requieren gratificaciones inmediatas (tal como las obtuvieron en su infancia)
- Por otro lado, ignoran los planes a largo plazo, los alcances estrictamente definidos. Tienen afinidad con la planificación y el desarrollo incremental del cual quieren participar activamente.
- Son impacientes: no pueden esperar para obtener un mejor puesto, incluso aunque recién hayan empezado y no cuenten con la experiencia necesaria. Hay que ayudarlos a controlar su ansiedad.
- Están acostumbrados al caos, y de alguna manera no les disgusta la confusión. Esto representa una ventaja si se consideran los constantes cambios que vemos hoy en los negocios. Sin embargo, requieren de un fuerte acompañamiento que los guie y un entorno tal que acepte estos cambios y los mantenga enfocados hacia objetivos en continua redefinición.
- Son flexibles (tal vez demasiado). La variedad de opciones que tienen al alcance de su mano les hace pensar que si no obtienen lo que quieren de algún modo, pueden conseguirlo de otro. Esto afecta el empleo en la medida en que a la hora de elegir un trabajo, muchos de ellos no trabajan “porque lo necesitan” sino “porque quieren” y los horarios, las exigencias, el salario y el crecimiento laboral son cruciales a la hora de elegir quedarse o irse de un trabajo.
- “multi-tasking”: Desarrollaron una gran habilidad para manejar más de un tema al mismo tiempo. Lo que a simple vista parece una ventaja, Puede tornarse en un problema por la dispersión y el retraso que el multi tasking genera en contraposición a trabajar enfocado en una cosa por vez.
Aun son muy jóvenes. Aunque parece que “lo supieran todo” por el modo en que se presentan, los jóvenes Y no cuentan con una gran experiencia en el mercado laboral, y no sabemos exactamente qué esperar de ellos en su comportamiento laboral. Además, Su reciente incorporación al mercado de trabajo y su modo de trabajar puede traer conflictos de integración con las generaciones anteriores. Por ello es necesario conocer cómo actúan y mantenerse alerta en pos del equipo.
Con sus pros y sus contras, la generación Y llego para quedarse y las metodologías ágiles van a crecer con ellos, retrospectiva tras retrospectiva, incorporando su input y siendo modeladas en base a su comportamiento. Definitivamente.
Agile Open La Plata 2009
0hace 2 años
por Martin Alaimo
en Agenda
* Foto: AO Bs As 2009 por Xavier Quesada Allue
Luego del exitoso evento Agiles 2008 y de los Agile Open Buenos Aires y Córdoba 2009, se organizará el evento Agile Open La Plata 2009, que combina la temática de Desarrollo Ágil con una forma novedosa de realización de eventos.
Este evento servirá para la capacitación y el intercambio de experiencias relacionadas con la implementación de Desarrollo de Software Ágil en organizaciones de la Ciudad de la Plata y la Provincia de Buenos Aires.
Apurate a incribirte aquí, solo queda una semana para el evento.
La Técnica Pomodoro
14hace 2 años
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:
| Inventario de Actividades |
| Escribir artículo sobre la Técnica Pomodoro |
| Revisar gramática del artículo sobre la Técnica Pomodoro |
| Ir al supermercado |
| Enviar e-mails al grupo con respecto a la organización del evento |
| Pagar televisión por cable y seguro del auto |
| Armar lista de temas para el Karaoke del próximo sábado |
| Traducir artículo sobre la Técnica Pomodoro al Inglés |
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”:
| Tareas para Hoy – 7 de Junio de 2009 | |
| Escribir artículo sobre la Técnica Pomodoro | |
| Revisar gramática del artículo sobre la Técnica Pomodoro | |
| Traducir artículo sobre la Técnica Pomodoro al Inglés | |
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):
| Tareas para Hoy – 7 de Junio de 2009 | |
| Escribir artículo sobre la Técnica Pomodoro | X |
| Revisar gramática del artículo sobre la Técnica Pomodoro | |
| Traducir artículo sobre la Técnica Pomodoro al Inglés | |
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):
| Tareas para Hoy – 7 de Junio de 2009 | |
| Escribir artículo sobre la Técnica Pomodoro | XXXX |
| Revisar gramática del artículo sobre la Técnica Pomodoro | |
| Traducir artículo sobre la Técnica Pomodoro al Inglés | |
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:
| Tareas para Hoy – 7 de Junio de 2009 | |
| Escribir artículo sobre la Técnica Pomodoro | XXXXXXX |
| Revisar gramática del artículo sobre la Técnica Pomodoro | |
| Traducir artículo sobre la Técnica Pomodoro al Inglés | |
Y de esta manera continúo Pomodoro tras Pomodoro hasta terminar el día:
| Tareas para Hoy – 7 de Junio de 2009 | |
| Escribir artículo sobre la Técnica Pomodoro | XXXXXXX |
| Revisar gramática del artículo sobre la Técnica Pomodoro | XX |
| Traducir artículo sobre la Técnica Pomodoro al Inglés | XXX |
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.
Incrementando la Productividad utilizando Múltiples Monitores
3hace 2 años
Hace algunos meses leía un artículo publicado inicialmente por Jason Calacanis y traducido al español por Alec Oxenford acerca de como ahorrar dinero implementando tips rápidos y simples en el inicio de una start-up. Uno de los puntos más discutidos era la utilización de múltiples monitores para maximizar la productividad de los desarrolladores.
Hoy encontré en Flikr una foto del home office de Stefan Didak
Esto terminó por despertar mi curiosidad -además del asombro causado- sobre cómo se altera la productividad de los desarrolladores mediante la utilización de múltiples monitores …
Luego de investigar un poco en busca de material estadístico y pruebas del incremento de productividad no encontré más que experiencias personales redactadas por individuos que hicieron la prueba por mera curiosidad y/o papers de empresas fabricantes de monitores o placas de video.
Un artículo del New York Times comenta que el incremento en la productividad va de un 20% a un 30%. Las experiencias son de escritores que pueden trabajar en sus artículos y al mismo tiempo ver el outline o draft en el cual están basando sus ideas; diseñadores que pueden editar imágenes en un monitor y al mismo tiempo tener como referencia una previa (sin editar) en el segundo monitor. Webshoppers que pueden comparar artículos de forma más sencilla.
Obviamente todas estas cosas también pueden hacerse con un único monitor; aquí el tema es el incremento de la velocidad. Uno no tarda lo mismo en dirigir su mirada hacia el monitor de al lado que en bucar la ventana en la barra de tareas y hacerle click con el mouse. Si, los más expertos utilizan Alt-Tab; aquí el problema es cuando uno se pasa de ventana, tiene que 1) volver utilizando Alt-Shift-Tab o 2) dar la vuelta completa. Esto sí es una perdidad de tiempo muy habitual.
Por otro lado, dí con un artículo publicado en Computerworld; en el mismo hacen hincapié en que los empleados prefieren seguir con un único monitor que les permite tener mucho espacio libre en sus escritorios a perder ese espacio por la utilización de dos monitores.
En lo que a mí respecta, yo suelo trabajar con una notebook de 14 pulgadas, widescreen. Durante un tiempo tuve la oportunidad de tener un segundo monitor en la oficina, de 17 pulgadas, y la comodidad que eso me dió fue realmente alta. Me permitía trabajar en los planes de proyectos, seguimientos, planillas, documentos mientras en el otro monitor tenía el correo electrónico, leía y escribía e-mails o lo alternaba con MS project, el cual es muy incómodo de utilizar en un monitor de 14 pulgadas.
Un segundo monitor, definitivamente puede incrementar la comodidad y velocidad; consecuentemente incrementando la productividad. Lo que restaría analizar es si el incremento de costos asociado a la compra y mantenimiento del doble de monitores realmente vale la pena … Esto lo dejo a criterio de cada uno.
