… de personas y sistemas.
Archivo de abril, 2009
Desfragmentando mi Día
23 abr
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!
Desfragmenta tu Día
17 abr
¿La vida parece aleatoria? ¿Descargas interminable de e-mails, llamadas telefónicas, reuniones irrumpiendo en tu calendario y almorzando frente al monitor durante tus horas de trabajo? Recientemente encontramos la forma de manejar estas insurgencias de tiempo, lo que ayuda a tener tu día de vuelta.
Todos los días somos bombardeados por toneladas de información. Es sin pausa, al instante y casi todo se clasifica como emergencia. Lo que necesitas es organizar tu tiempo en segmentos que te permitan incrementar tu productividad en cada actividad. Separa tus horas facturables, comunicaciones, reuniones, y tiempo personal en diferentes segmentos. Hacer esto te va a permitir enfocarte completamente en cada actividad. Y cada tema va a poder ser tratado solo durante su respectivo segmento de tiempo.
El diagrama ilustra diferentes segmentos de tiempo, ordenados por tipo.
Este ejemplo muestra un día promedio de cualquiera de nosotros antes de optimizarlo. Una reunión o conference call por la mañana, trabajo mezclado con e-mail, almuerzo, otra reunión, más trabajo y un poco de e-mails, etc. Los E-mails nos distraen y nos impiden terminar nuestras tareas y, lo que es peor, nos impiden “facturar”. Para evitar esto, institucionalizamos una nueva forma de segmentación de nuestros días.
Para la primera parte del día trabajamos durante 3 horas en temas “facturables”, trabajo en sí, entregables, etc. en base a requerimientos recibidos previamente. Estos requerimientos pueden haber llegado unas horas o incluso semanas antes, realmente no importa. Sin embargo, ningún requerimiento del día de hoy se trata durante este segmento de tiempo inicial.
Ahora, a almorzar, no te preocupes por lo de hoy por el momento, solo ten un almuerzo feliz.
Luego del almuerzo, dedicamos una hora completa a chequear e-mails. Lee todos y cada uno de los e-mails que te llegaron y responde de modo significativo a cada uno que sea necesario. Envía cualquier entregable a tus clientes.
El resto del día está dedicado a temas administrativos, reuniones, estimaciones, facturación, proyectos internos, gestión, llamadas, reuniones, etc. Si necesitas tener una reunión o llamada, solo se puede programar entre las 2PM y las 5:30PM de cada día. La gente también tiene temas personales que resolver durante el día, como pagar facturas, hacer algún llamado telefónico al service, ir al banco, etc. Estos temas también se organizan en este segmento de las 2PM a 5:30PM.
Eso es todo. Andate a casa a las 6PM previo un rápido chequeo de e-mail de media hora. No te quedes trabajando, salí con tu familia, cena, mira tele, juga con tus hijos, lo que sea. Este es tu tiempo personal, úsalo inteligentemente.
A las 10PM todos se conectan nuevamente desde sus casas y pasan entre 2.5 y 3 horas haciendo trabajo facturable. Este periodo tiene cero distracciones y las personas tienden a ser ultra-creativas por la noche. Este periodo es opcional, pero si te interesa estar al tanto de todos los temas sin estar sobrepasado, recomendamos que lo hagas.
Al final de este segmento de tiempo, verifica tus e-mails para hacerte una idea de cómo va a ser tu periodo nocturno del día siguiente y cómo vas a priorizar la siguiente mañana.
Encontramos que este proceso no solo te ayuda a incrementar tu productividad en el día a día sino también el retorno generado de cada segmento. Si te desvías de tanto en tanto, está bien, solo trata de volver a segmentar tu día. No siempre es fácil ajustarse al régimen, pero si logras hacerlo, harás más dinero y estarás menos distraído por todos los temas que pueden y van a suceder.
** Nota: Esta es una traducción directa del inglés al español del artículo que pueden encontrar aquí: http://newleaders.com/discussions/369-defragment-your-day
Tareas no planificadas
11 abr
Implementando SCRUM en un cliente, como parte de una consultoría en gestión de proyectos, descubrimos que trabajaba bajo dos modalidades que deliberadamente decidimos llamar Tareas Planificadas y Fires.
El concepto era que las Tareas Planificadas eran todas aquellas que salían del BackLog y se incluía en el Sprint durante la reunión de planificación, mientras que los Fires eran las tareas que se incluían durante el Sprint, sin previa planificación.
La razón detrás de esta decisión fue que el cliente trabajaba con iniciativas de identidad, entregas planificadas, compromisos previamente acordados con cierta anticipación y, en paralelo, con mantenimientos a los cuales asignaba una determinada cuota de horas mensuales, carente de previsibilidad alguna.
La decisión inicial
Inicialmente decidimos tomar items del BackLog y transformarlos en Story Cards, los cuales a su vez se descomponían en Tareas Planificadas. Esta actividad se realizaba durante la segunda mitad de la reunión de planificación, donde el equipo de trabajo mismo determinaba esa descomposición. A medida que se realizaba, los miembros del equipo iban llenando con Tareas Planificadas la columna correspondiente al To-Do (segunda columna) en el TaskBoard, dejando la primera para los Story Cards, llamada Commited BackLog.
Si eventualmente surgía una tarea de mantenimiento y/o urgencia que no podía esperar al próximo Sprint para ser resuelta, se ingresaba un Fire en el TaskBoard.
¿Cuándo agregarlas?
El primer desafío que nos encontramos fue determinar cuándo esas tareas Fires debían ser agregadas al TaskBoard. Evaluamos cuatro posibilidades:
1. En cualquier momento: La idea es agregar los Fires inmediatamente luego de que son detectados o se determina que hay que trabajar en ellos. La contra que encontramos fue que agregarlos en medio del día no les da la visibilidad esperada, y recién son conocidos por la totalidad del equipo en la próxima Daily Standup Meeting.
2 y 3. Antes/Durante la Daily Standup Meeting: Agregarlos al TaskBoard 10 minutos antes de la Daily Standup Meeting o durante ella para darles mayor visibilidad. El perjuicio de ello era el de alargar innecesariamente la reunión que debía durar no más de 15 minutos, discutiendo los nuevos Fires que aparecían, en lugar de enfocarse en el verdadero contenido de la reunión.
3. Luego de la Daily Standup Meeting: Evaluamos también agregar dichas tareas una vez terminada la reunión para no alargarla, el inconveniente que detectamos fue que el hacerlo cambiaba automáticamente la realidad del resto del día, por lo cual lo discutido en la Daily Standup Meeting perdía su sentido.
Finalmente nos volcamos por la primer opción: “los Fires se agregan al TaskBoard a medida que van apareciendo”. La forma que hallamos de morigerar la falta de visibilidad consistía en que el miembro del equipo que lo agregaba debía primero notificar a sus compañeros que lo iba a agregar en breve. Una opción un poco más efectiva y ruidosa que evalué fue la de poner una bocina para ser tocada cada vez que un Fire apareciera… pero por el momento, me la guardo en el BackLog.
¿Cómo distinguirlas?
El segundo desafío a resolver -previo a su implementación- consistía en cómo distinguir a las tareas entre si. En primera instancia, evaluamos una solución interesante que plantea Xavier Quesada Allue en su blog Visual Management: dejar un workstream vacío arriba de todo para hacer el seguimiento de este tipo de tareas. El post se llama Unplanned Items and Legacy Issues.
Luego de discutir un buen rato, decidimos que si bien la solución de Xavier funciona en la mayoría de los casos, la particularidad en esta ocación resultaba en que los Fires tenían cierto buffer que permitía terminar primero una o varias Tareas Planificadas, y nosotros debíamos poder reflejar eso.
Finalmente, decidimos utilizar Post-Its de diferentes colores: Amarillos para las Tareas Planificadas y Naranjas para Fires, preservando de esta manera la dimensión vertical con el objetivo de reflejar prioridades.
Resultado:
Si bien en la implementación de este enfoque encontramos temas mínimos a mejorar (que voy a comentar en sucesivos posts, y cómo efectivamente los mejoramos) el resultado fue el siguiente:
1. Si un Fire aparece, se crea un Post-It de color anaranjado.
2. Se avisa a todo el resto del equipo que un nuevo Fire va a ser ingresado en el TaskBoard.
3. Se determina su prioridad con respecto al resto de las Tareas Planificadas existentes en el TaskBoard.
4. Se ingresa en la columna To-Do, sin StoryCard, representando verticalmente su prioridad (más alto, más prioritario).
En la práctica:
En blanco los StoryCards, en amarillo las Tareas Planificadas y en Naranja los Fires:
Introducción a Agile
9 abr
Entonces, ¿De qué se trata toda esta cosa de “lo ágil”?
Esta es una pregunta bastante recurrente que tenemos que contestar. También me parece importante compilar esta información ya que no podemos asumir que todo el que visita este blog sepa per se de qué se tratan las metodologías ágiles.
Por otro lado, ya hay mucha información en Internet acerca de metodologías ágiles y sus diferentes variantes (o implementaciones) que van a un muy buen detalle: entonces, en vez de escribir un post extenso acerca del tema solo voy a referirme a artículos/libros/sitios que ya explican estos conceptos.
1. Manifiesto Ágil
El primer concepto que debemos conocer es la semilla de la cual crecen todos los movimientos/metodologías ágiles, el mismo es el Manifiesto Ágil (o Agile Manifesto en inglés). El mismo es un manifiesto elaborado por un grupo de personas del rubro de desarrollo de software que dice:
Estamos descubriendo mejores formas de desarrollar software, haciéndolo y ayudando a otros a hacerlo. Mediante este trabajo hemos aprendido a valorar:
- a los individuos y las interacciones por sobre los procesos y las herramientas
- el software funcionando por sobre la documentación detallada
- la colaboración con el cliente por sobre la negociación de contratos
- la respuesta al cambio por sobre el seguimiento de un plan
Esto significa que, si bien encontramos valor en los items de la derecha, valoramos por sobre ellos los de la izquierda.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
Nota: Esta es una traducción directa del inglés al español del Agile Manifesto, el cual pueden encontrar aquí: http://www.agilemanifesto.org/
2. Principios detrás del Manifiesto Ágil
Las mismas personas que confeccionaron el manifiesto ágil, también aseguran que éstos son los principios a seguir para poder sostenerlo:
- Nuestra mayor prioridad es satisfacer al cliente a través de entregas tempranas y continuas de software con valor.
- Aceptar el cambio incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan los cambios para darle al cliente ventajas competitivas.
- Entregar software funcionando en forma frecuente, desde un par de semanas a un par de meses, preferenciando el periodo de tiempo más corto.
- Expertos del negocio y desarrolladores deben trabajar juntos diariamente durante la ejecución del proyecto.
- Construir proyectos en torno a individuos motivados. Generándoles el ambiente necesario, atendiendo sus necesidades y confiando en que ellos van a poder hacer el trabajo.
- La manera más eficiente y efectiva de compartir la información dentro de un equipo de desarrollo es la conversación cara a cara.
- El software funcionando es la principal métrica de progreso.
- Los procesos ágiles promueven el desarrollo sostenible. Los sponsors, desarrolladores y usuarios deben poder mantener un ritmo constante indefinidamente.
- La atención continua a la excelencia técnica y buenos diseños incrementan la agilidad
- La simplicidad –el arte de maximizar la cantidad de trabajo no hecho — es esencial
- Las mejores arquitecturas, requerimientos y diseños emergen de equipos auto-organizados.
- A intervalos regulares, el equipo reflexiona acerca de cómo convertirse en más efectivos, luego mejora y ajusta su comportamiento adecuadamente.
Nota: Esta es una traducción directa del inglés al español de los Principles behind the Agile Manifesto, los cuales pueden encontrar aquí: http://www.agilemanifesto.org/principles.html
3. Más detalles sobre Metodologías Ágiles
A partir de ahora sí, como se comentó antes, podemos encontrar muchísimo material en internet referente al tema. Yo recomiendo (para empezar) el siguiente material, en este orden:
- Conocido el manifiesto y los principios ágiles, un buen lugar para empezar es la Introducción a las Metodologías Ágiles por Ricardo Colusso.
- Con las bases incorporadas, el próximo paso que recomiendo es la Introducción a SCRUM escrita por Xavier Albaladejo.
- Y finalmente, es una parada obligada, la lectura del e-book SCRUM y XP desde las Trincheras, traducción al español del libro original SCRUM and XP from the Threnches escrito por Henrik Kniberg.
Hola mundo ágil!
4 abr
Hace ya varios años que vengo incursionado en el mundo de las metodologías y prácticas ágiles, pero no fue sino hasta unos meses atrás que fui consciente de que lo estaba haciendo muy seriamente.
Hoy estoy definitivamente convencido de la eficacia de las formas y certeza de los objetivos cuando hablamos de “agilidad”. He vistos en estos meses cómo las metodologías ágiles logran un salto cualitativo en los equipos que las implementan y llevan a obtener resultados concretos.
Hoy comienzo este blog sobre metodologías ágiles en el cual pretendo dejar registro de mis experiencias, inquietudes, anécdotas e ideas surgidas durante mi tránsito por este camino.
Desde que obtuve mi certificación de PMP tiendo a ver todo lo que me rodea con forma de proyecto; y si consideramos que un blog es también un proyecto, podemos asumir que se puede desarrollar de forma ágil.
Dicho esto, bienvenido a mi blog!
