… de personas y sistemas.
Experiencias
Las Leyes de Mariana para implementar Scrum
27 ago
¿quién es Mariana? Fiel al mejor estilo periodístico que no da a conocer sus fuentes, muchas veces por razones de ética profesional y muchas otras para fastidiar de manera divertida a la audiencia, no revelaré su verdadera identidad . Llamémosla simplemente “Mariana”. Procedo a desarrollar la ancécdota.
“Mariana” es una alumna que asistió a uno de los cursos que dicté este año. Al finalizar el curso, junté todas mis pertenencias, entre ellas el material que usualmente utilizo como cartas, fichas, post-its, rollos de cinta, marcadores, etc. Más tarde cuando llegué a mi casa, al a acomodar las cosas para guardarlas encontré este papel:
Leyes infalibles para Implementar Scrum
1. Hacerlo de forma Iterativa, Incremental
2. No querer abarcar todo desde el principio
3. Controlar las expectativas de los primeros Sprints|
4. No abrumarse frente a los impedimentos que van a surgir (hasta ahora ocultos)
5. Tener coraje, experimentar y dejar experimentar – Errar no es malo, lo malo es no aprender del error.
Bueno, la verdad es que yo tampoco supe quién fue el autor o la autora de esta nota porque no estaba firmada. Solo adivino que fue una mujer porque dobló el papel sospechosamente muy prolijo y por eso adopté llamarla “Mariana”. Hoy lamento que no haya compartido estas ideas con sus compañeros durante el curso, hubiera sido algo muy productivo, pero al menos lo bueno es que entendió de qué se trata llevar Scrum a la práctica.
photografía: http://www.flickr.com/photos/limaoscarjuliet/225249268/
Música ágil para mis oidos
10 jun
Anoche en las oficinas de Microsoft tuvo lugar un atípico Ágiles@BsAs.
Ya de entrada sabíamos que venía desafiante la jornada, que estaba relacionada con sacarnos de la zona de confort para experimentar las diferentes sensaciones y resultados bajo un paradigma de comando y control contrastado con uno de colaboración y auto-organización.
Comenzamos apenas pasadas las 19hs armando equipos de “especialistas”. Había diferentes estilos de percusionistas (3 tipos diferentes) y cantantes. Nos dividieron en 4 grupos: Percusioninstas 1, Percusioninstas 2, Percusioninstas 3 y Cantantes, por especialidad digamos. Nos enseñaron las diferentes partes de una misma canción y nos evaluaban en función de los conocimientos que adquiríamos al respecto.
Lo interesante era que las consultas no estaban bien vistas por la empresa. (al relativamente común)
Luego llegó la hora de tocar en público. Nos integraron a un especialista de cada grupo en un único grupo musical… y a tocar. Fue un verdadero desastre. Horrible.
Inmediatamente después, lo intentamos de una forma más ágil.
Nos dividimos en equipos, ya no había áreas de especialización sino grupos musicales. Cada cual podía tomar el rol que mejor le salga (a mi me pusieron a cantar,.. así que imagínense lo malos que eramos. jaja).
Entregamos en tres iteraciones incrementales. El resultado estuvo genial. la canción se reconocía, había buen humor y terminamos haciendo aplaudir y bailar al auditorio. Muy divertido.
La retrospectiva?
El primer modelo lo asociamos al modelo organizacional tradicional, jerárquico y dividido en áreas de especialización. Los resultados fueron bastante pobres, hubo poca colaboración, las métricas individuales que se utilizaron eran irrelevantes con respecto al resultado final. No me gustaría pasarme la vida trabajando así. Claramente.
Luego pasamos a un modelo mucho más colaborativo y de trabajo en equipo. Eliminamos las especializaciones y comenzamos a medir el resultado final, en forma incremental. Fuimos agregando complejidad y ayudándonos entre nosotros. Adoptando los roles en los que más cómodos nos sentíamos y auto-organizándonos. El resultado fue algo así como lo siguiente…
Bueno, no tanto, pero abismalmente superior al alcanzado en primera instancia.
Excelente el trabajo de Pablo y Rick creando, organizando y facilitando la actividad. Esperemos verlos en Ágiles 2010. 
Instalando Rails 3 en OSX Leopard
23 may
Finalmente pude instalar Rails 3 en Leopard (OSX 10.5.5). Aparentemente era algo sencillo de hacer, pero el upgrade de Ruby y de RubyGems en Leopard no funciona del todo bien. Por lo tanto, luego de 12 horas, puedo decir que tengo Rails 3 funcionando, pero me hizo trabajar bastante.
Para que sirva de referencia, como bitácora o para que otro no transpire como lo hice yo hoy, lo dejo aquí registrado.
Antes de comenzar, la versión de OSX sobre la que lo hice es la 10.5.5 (Leopard):
El primer paso -antes de comenzar- es intalar MacPorts y esta versión específica de Xcode.
Inmediatamente después debemos eliminar del sistema (casi) todo Ruby y RubyGems:
sudo rm -r /System/Library/Frameworks/Ruby.framework/ sudo rm -r /Library/Ruby sudo rm /usr/bin/ruby sudo rm /usr/bin/gem
Luego instalamos RubyGems a través de MacPorts:
sudo port install rb-rubygems
Ya tienes RubyGems 1.3.5 en tu sistema, pero debemos actualizarlo a la versión 1.3.7. “sudo gem update –system” no hará el trabajao, por lo que debemos hacerlo de una manera alternativa:
sudo gem install rubygems-update sudo update_rubygems
Terminados esos pasos, ya podemos proceder con la instalación de Rails3:
sudo gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n sudo gem install rails --pre
… y de esta manera, ya debería estar Rails 3 instalado en tu leopar 10.5.5:
Agregando columnas auto increment
19 may
Estoy trabajando en una demo/tutorial sobre desarrollo evolutivo de bases de datos y sus herramientas.
Ya que ayer instalamos un mysql en un cliente para operaciones de software configuration management, se me ocurrió utilizar mysql para el tutorial/demo en cuestión.
Me encontré con algo curioso al intentar agregar una columna auto-incremental a una tabla existente.
Dada esta tabla:
create table program (required_solo_hs int not null, required_inst_hs int not null, required_hs int not null
Intenté agregar una columna id:
alter table program add column id int not null auto_increment
Obteniendo el siguiente error;
Script line: 1 Incorrect table definition;there can be only one auto column and it must be defined as a key
La solución es simplemente indicar que dicha columna además de auto increment es primary key:
alter table program add column id int not null auto_increment key;
Una vez más.. posiblemente a alguien le resulte útil.
Windows Vista 64bits & MySQL: ERROR 1045 (28000): Access denied for user ‘root’@'localhost’
18 may
Hoy en Kleer, pasamos por la experiencia de instalar MySQL 5.1 por primera vez en Vista 64bits. Lejos de ser una instalación amena, como las que estamos acostumbrados, esta nos hizo transpirar la gota gorda.
Luego de bajar el instalador de 64bits, instalarlo y configurarlo, el asistente de configuración no paraba de dar el error:
ERROR 1045 (28000): Access denied for user 'root'@'localhost'
Probamos infinidad de soluciones, pero ninguna funcionó. Salvo la siguiente:
- Parar el servicio “MySQL” desde “Control Panel->Administrative Tools->Services”
- Ir a “C:\Windows\System32″
- Buscar el file cmd.exe, hacer click derecho con SHIFT presionado y seleccionar “Run as administrator”
- Ejecutar el siguiente comando:
mysqld --skip-grant-tables
- Dejar esa ventana corriendo
- Abrir otra ventana de terminal, esta vez NO como administrator: “Start->Run->cmd” ENTER
- Ejecutar el siguiente comando:
mysql -u root mysql
- Walá! Estamos adentro. Ejecutar la siguiente sentencia, cambiando MyPass por un password real que quieras setear:
UPDATE user SET Password=PASSWORD('MyPass') where USER='root'; FLUSH PRIVILEGES; - Salir:
exit
- Cerrar la ventana
- Cerrar la ventana que estaba corriendo como administrator
- Abrir el task manager y matar todos los procesos “mysqld” (debería haber uno solo, de otro usuario “Administrator”)
- Levantar el servicio desde “Control Panel->Administrative Tools->Services”
- Conectarse nuevamente, esta vez como lo veníamos haciendo:
mysql -u root -p
Con este último paso, ya deberían estar conectados sin problemas. Espero esta solución pueda servirle a alguien y se ahorren un buen tiempo.
Agile Open Buenos Aires 2010 – Calidad
28 mar
Excelente experiencia la del AO Buenos Aires del 13 de Marzo. Puedo decir que he conocido mucha gente y muy buenas experiencias ajenas. Dejo aquí el link a las fotos del evento: http://bit.ly/coCnnA
Saludos!
Resultado del AO La Plata 2009
22 jun
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.
Post-Its Voladores
11 may
Hace unos días, en la lista de la comunidad ágil (http://tech.groups.yahoo.com/group/foro-agiles/message/1738), se planteó el tema de los Post-Its Voladores, que se despegan, se caen, se vuelan, etc. de los ScrumBoards o TaskBoards.
Las opciones recomendadas fueron varias; como por ejemplo:
- el uso de Post-Its super sticky,
- cinta Scotch Magic,
- pegamento UHU Tac
- Pizarras Magnéticas.
En mis últimas experiencias de aplicación de Scrum en equipos de delivery hemos experimentado utilizando pizarras de corcho, post-its comunes y chinches para sujetarlos. La primer implementación de este tipo surgió de forma casual; estábamos a la espera de la llegada de la pizarra mientras utilizabamos rota-folios unidos en su lugar (Fig.1). Frente a la demora de su llegada, tomamos una pizarra de corcho que no estaba siendo utilizada y comenzamos a pegar los post-its allí. No pasó mucho tiempo hasta que comenzaron a despegarse, a lo que reaccionamos sujetándolos con chinches (Fig.2).
Al hacerlo de esta manera, hemos encontramos al menos 2 beneficios: 1) poder sujetar un conjunto importante de post-its encimados (Fig.3), ocupando menos superficie de la pizarra (por ejemplo en la sección “pendientes”), y 2) utilizar chinches de colores diferentes para cada miembro del equipo (Fig.4), facilitando la identificación de la persona que está trabajando en cada post-it.
Referencias:
Fig.1: Pizarra de Rota-folio @ Accenture - SCM Team
Fig.2: Convertida en Pizarra de Corcho @ Gorricho
Fig.3: User Story + Tasks en Sección de "Entregados"
Fig.4: Cada Miembro un Color.
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!
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:
