Al estar en fase Piloto, los resultados del examen se conocerán recién en Diciembre de este año, pero mientras tanto, aprovecho para dejar aquí registradas mis impresiones.

Lo que creo es Positivo

• Valores. La sorpresa más grande que me llevé fue ver que todos los contenidos y preguntas del examen estaban fuertemente orientados a los valores y filosofía ágil. Una de las incógnitas que me acompañaron todo el camino hacia el lugar donde rendí el examen fue justamente ¿Cuál será la visión del PMI de la agilidad? (En especial me preocupaba un artículo que había publicado el PMI en el 2010 con una visión bastante alejada -a mi gusto- de las metodologías ágiles; sobre el cual he escrito en su momento (ver artículo original). Pero volvamos al examen. Parece que el steering comitee de la certificación ágil ha hecho un buen trabajo.
• Manifiesto Ágil y Valores Lean. Hubo varias preguntas sobre los valores y principios del Manifiesto Ágil (es indispensable conocerlos) y Valores Lean. Me gustaron particularmente algunas preguntas que hablaban de paralelismos o mapeos entre el Manifiesto Ágil y Lean.
• Metodologías. Tanto XP, Lean, Scrum y Kanban estuvieron cubiertos por el examen. Hubo preguntas relacionadas a  estos cuatro enfoques ágiles. Aunque debo reconocer que la mayoría están asociadas a XP y Scrum y un menor número a Lean y Kanban.
• No tantas Herramientas y Procesos. Excelente desde mi punto de vista. La mayor parte del examen estuvo orientada hacia las interacciones entre las personas, la colaboración con el cliente y el aprendizaje y adaptación constante.
• Preguntas situacionales. Al igual que el examen PMP, muchas preguntas fueron situacionales. Ej: Se plantea una determinada situación hipotética frente a la cual uno debe plantear una acción concreta. Para esto uno debe elegir la opción “mas correcta” de una serie de “opciones correctas”.
• Oposiciones. Me gustó mucho la forma en las que algunas preguntas estuvieron planteadas. Me refiero específicamente a varias que incluían dos tipos de respuesta correcta: la que escogería un PMP y la que escogería un Practicante Ágil, de hecho, son preguntas que podrían formar parte del examen de PMP y por ende, tener otra respuesta correcta que la que tienen en este contexto. Creo que este punto es fundamental y requiere del candidato un cambio paradigmático de la forma de trabajo.
• Conocimiento Técnico. Si bien no es necesario tener un alto nivel de conocimiento técnico, hay prácticas de XP que se presentaron en el examen, como TDD/ATDD/IC. Me puso muy feliz verlas allí.
• Cobertura de la Bibliografía. Las preguntas del examen cubrieron prácticamente toda la bibliografía recomendada por el PMI.

Lo que veo como Oportunidades de Mejora

• Preguntas. Hubieron determinadas preguntas con errores semánticos. Recomiendo a quien rinda el examen estar atento a dichas situaciones.
• Manifiesto Ágil y Valores Lean. A mi gusto haría mayor hincapié en los principios ágiles y valores lean. Entiendo (y es una opinión personal) que es fundamental comprender los mismo antes de tratar de entender alguna metodología o marco o implementación particular.
• Metodologías. Sería bueno la incorporación al examen algunas preguntas sobre DSDM, Crystal Clear, OpenUP, etc.
• Muchos “Cómo” y pocos “Por Qué”. En su mayor parte, el examen estuvo enfocado en “Cómo” resolver determinadas situaciones o “Cómo” determinada metodología resuelve alguna que otra situación pero no dedica demasiado tiempo a los “Por Qué” de dicha resolución.

En definitiva y a mi forma de ver, el examen tiene más puntos positivos que oportunidades de mejora. Debo reconocer que mis expectativas fueron superadas ampliamente.

¿Dónde se ubicaría, a mi parecer, esta certificación en relación a las de la Scrum Alliance? Este tema lo dejaré para un siguiente post.

¿Cómo acceder a esta certificación? Más información en el sitio oficial de la certificación PMI-ACP.

¿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/

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.

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:

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.

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:

1. Parar el servicio “MySQL” desde “Control Panel->Administrative Tools->Services”
2. Ir a “C:\Windows\System32″
3. Buscar el file cmd.exe, hacer click derecho con SHIFT presionado y seleccionar “Run as administrator”
4. Ejecutar el siguiente comando:

   mysqld --skip-grant-tables

5. Dejar esa ventana corriendo
6. Abrir otra ventana de terminal, esta vez NO como administrator: “Start->Run->cmd” ENTER
7. Ejecutar el siguiente comando:

   mysql -u root mysql

8. 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;

9. Salir:

   exit

10. Cerrar la ventana
11. Cerrar la ventana que estaba corriendo como administrator
12. Abrir el task manager y matar todos los procesos “mysqld” (debería haber uno solo, de otro usuario “Administrator”)
13. Levantar el servicio desde “Control Panel->Administrative Tools->Services”
14. 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.

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!

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.

Read Article in English

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.

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!