Martin Alaimo
(5 comentarios, 46 entradas)
Este usuario no ha compartido ninguna información de perfil
Entradas de Martin Alaimo
El día que rendí el examen PMI-ACP (Agile Certified Practitioner)
3A mediados de Septiembre del 2011 se abrió el examen PMI-ACP (Agile Certified Practitioner) del Project Management Institute. En lo personal, tuve la suerte a rendir el primer examen de esta certificación en Latinoamérica hace ya unas semanas.
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.
Simulación de Scrum (Extendida)
0Hace ya unas semanas que estaba con ganas de publicar este post. Lamentablemente, el día a día me fue demorando, pero este mensaje en el foro de metodologías ágiles fue detonante para que finalmente lo haga.
A partir de febrero del 2010 comencé a utilizar en varios de los cursos de Introducción a Scrum una simulación extendida basada en la de Alexey Krivitsky (Lego For Extended Scrum Simulation).
¿Cómo es el desarrollo de la dinámica?
Dejo una guía que te puedes bajar para realizar la dinámica donde y cuando quieras, solo ten en cuenta los términos de la licencia.
Licencia

Esta obra está licenciada bajo una Licencia Creative Commons Attribution-ShareAlike 2.5 Argentina .
WebTest Fixtures, FitNesse, Selenium y Autenticación de Windows Integrada
0Como parte de uno de los últimos coachings en implementación de Scrum en un equipo de desarrollo de software, se decidió implementar ATDD y para ello utilizamos FitNesse para la escritura y preparación de las pruebas y Selenium para la ejecución de las mismas.
Para poder vincular FitNesse con Selenium, utilizamos WebTests Fixtures (gracias Gojko et al.)
La sorpresa que nos esperaba era una aplicación web desarrollada en .NET con Autenticación de Windows Integrada. Quien haya pasado por esto, sabrá que no hay mucha información online que nos permita resolver el problema. Salvo un par de modificaciones al core de WebTest y unos cuantos posts aislados, no podemos dar con una fuente unificada para solucionar este problema.
Desde el principio teníamos claro que no queríamos modificar el código de las herramientas de test que empleamos, para darles la posibilidad de ser actualizadas a medida que salgan nuevas versiones sin grandes problemas, por lo tanto, la solución debía ir por fuera.
Luego de investigar un tiempo, decidimos que la mejor opción era hacer que Selenium ejecute una instancia de Firefox lo suficientemente configurada para que la Autenticación Integrada de Windows no sea un problema.
Contexto
Tanto FitNesse como Selenium están instalados y corriendo como servicios en un servidor windows. La versión de FitNesse es la que viene con el download de WebTest Fixtures, mientras que la versión de Selenium es la más reciente, puesto que la que viene con WT soporta hasta Firefox 2, no 3.
Solución
En principio debemos crear un profile nuevo de Firefox con una determinada configuración para que las credenciales del usuario bajo el cual el servicio de Selenium está corriendo sean enviadas a la aplicación web de forma transparente, sin pop-ups ni alertas que impidan a Selenium realizar su trabajo. Luego debemos configurar a selenium para que levante ese perfil específico de Firefox, y no otro.
Creación del Perfil en Firefox
Para crear un nuevo perfil para firefox es importante estar logueado con el usuario bajo el cual el servicio de Selenium está corriendo. Una vez dentro del sistema se deben seguir estos pasos (NOTA: se asume Windows):
- Ejecutar:
firefox.exe -ProfileManager
- Hacer click en “Crear Perfil”
- Poner un nombre al perfil. En nuestro caso utilizamos “WEBTEST-FFPROFILE-IWA”
- Seleccionar una carpeta. En nuestro caso utilizamos “C:\webtest\WEBTEST-FFPROFILE-IWA”
- Hacer click en “Fin”
- Seleccionar “No preguntar al iniciar”
Configuración del Perfil en Firefox
- Continuando desde el paso anterior, seleccionar el perfil recientemente creado y hacer click en “Iniciar Firefox”
- Ir a “Ver->Toolbars” y desactivar “Marcadores”
- Hacer click derecho sobre el toolbar y seleccionar “Personalizar”
- Seleccionar “Usar Iconos Pequeños” y aceptar
- Ir a “Herramientas->Opciones”
- En el Tab “Principal” setear “about:blank” como homepage y desactivar “Mostrar Descargas”
- En el Tab “Perstañas” seleccionar nueva ventana para nuevas páginas y desactivar todos los alertas
- En el Tab “Contenidos” desactivar el bloqueo de Pop-Ups
- En el Tab de “Privacidad” desactivar todas las opciones del Historial
- En el Tab de “Seguridad” desseleccionar las opciones de seguridad y en “Configuración…” desactivar las alertas
- En el Tab “Avanzado” desactivar “desplazamiento automático” del subtab “General” y desactivar alertas y motores de búsqueda del tab “Actualizaciones”
- Ir a “Herramientas->Complementos” e instalar Firebug, Selenium IDE y ScreenGrab
- En la barra de direcciones escribir “about:config”
- Crear la entrada lógica (boolean) “extensions.update.notifyUser” –> falso
- Crear la entrada lógica (boolean) “extensions.newAddons” –> falso
- Modificar la entrada “network.automatic-ntlm-auth.trusted-uris” e ingresar el dominio del servidor donde queremos probar la aplicación web
- Modificar la entrada “network.ntlm.send-lm-response” y darle un valor de “verdadero”
En este punto ya debemos tener el perfil de Firefox correctamente configurado.
Configuración de Selenium para tomar el perfil de Firefox Creado
Modificar el archivo batch que ejecuta Selenium (en el raíz de WebTest) e incluir este parámetro detrás del llamado al JAR: “-firefoxProfileTemplate C:\webtest\WEBTEST-FFPROFILE-IWA” (cambiar C:\webtest\WEBTEST-FFPROFILE-IWA por la dirección de tu carpeta donde guardaste el perfil de Firefox creado recientemente.
Listo, los tests ya deberían ejecutarse satisfactoriamente bajo la Autenticación de Windows Integrada.
Espero te sirva si en algún momento te topás con este problema.
Programador no significa Desarrollador
4A menudo me encuentro frente a situaciones donde se confunde “programador” con “desarrollador”, o más aún, “desarrollador” con “programador”.
Antes de seguir, aclaro que mi postura es la de definir al programador como aquel que no se especializa en otra cosa que no sea codificar nuevas funcionalidades en función de diseños recibidos. No contribuye a escribir o entender las especificaciones. Ni se le ocurre escribir pruebas automatizadas. No colabora para mantener el build actualizado. Ni que hablar de las pruebas. No ayuda al cliente a comprender sus necesidades ni a resolver sus problemas. Se dedica solo a eso, a escribir código.
La tendencia actual del desarrollo de software y las metodologías ágiles está comprendiendo cada vez más la necesidad de contar con equipos multidisciplinarios, o en otras palabras, personas que contribuyan de distintas maneras al objetivo buscado, en lugar de personas que solo se especialicen en una parte del proceso y que no tengan una visión completa de él.
De esta manera, todos son igual de responsables por alcanzar los logros y la existencia de fracasos (si la hubiera). La solución más razonable que algunas organizaciones están ofreciendo frente a los contextos de negocios cambiantes es aumentar la flexibilidad. Incluso es lógico deducir que el hecho de contratar solo especialistas en determinadas áreas generará muchos mayores costos económicos e incluso de comunicación dentro del equipo, lo que puede atentar contra el desarrollo exitoso del producto.
¿Qué se espera de un desarrollador? El desarrollador es básicamente quien aunque no hace TODO al mismo tiempo (eso sería un absurdo), conoce el proceso de principio a fin y por eso logra detectar “a tiempo” cualquier “contratiempo” que pudiera surgir. En otras palabras, sería como esas nuevas cámaras digitales que obtienen una imagen panorámica que ofrece una visión completa de la escena fotografiada.
Entre las tareas de un desarrollador se encuentran:
- Entender el negocio y los objetivos que se están persiguiendo
- Colaborar con el Product Owner para identificar las historias de usuario y sus criterios de aceptación
- Ser parte protagonista a la hora del armado y mantenimiento del entorno de trabajo
- Garantizar las prácticas ágiles de desarrollo de software como Integración Continua, TDD, ATDD
- Participar en el diseño de la solución, tanto lógico como arquitectónico
Por un mundo mejor, las responsabilidades del desarrollo del producto deben estar compartidas entre todos los involucrados en el proyecto, con la salvedad de que el Product Owner no requiere, en la mayoría de los casos, tener conocimientos técnicos. Sí, percibo que la siguiente pregunta es: ¿y el Scrum Master? Mi respuesta es otra pregunta ¿Cómo podría el Scrum Master remover impedimientos y garantizar al equipo un adecuado entorno de trabajo si no tiene los conocimientos técnicos necesarios de los desarrolladores? Cito:
“Un conocimiento íntimo y detallado de cómo algo funciona incrementa las posibilidade de que el líder ayude al equipo a descubrir las cuestiones técnicas más sutiles que deban ser tratadas” (LaFasto & Larson, When teams work best, 2001, p. 133).
En el fondo, aunque el equipo sea el encargado principal de desarrollar el producto y naturalmente es quien mejor conoce su desarrollo, el Scrum Master no debería desconocer los aspectos del desarrollo y en algunos casos, hasta debería ser quien mejor los conozca si es que se quieren evitar problemas de comunicación, interpretación y estimación; pero sobre todo, si se pretende alcanzar un objetivo exitoso.
Volviendo al comienzo: lo que necesitamos son verdaderos desarrolladores, personas que cuenten con las herramientas y prácticas necesarias para lograr un proceso de desarrollo exitoso y un producto de alta calidad. Esto no quiere decir que no se necesite también de los programadores, pero no confundamos un desarrollador o “developer” con un simple programador. Incluso un excelente programador podría ser un pésimo desarrollador y un Scrum Master que no ha adquirido estas herramientas a lo largo de su formación podría eventualmente ser percibido por el equipo de desarrollo como falto de las habilidades necesarias para cumplir su función.
Si apenas podemos entender estas diferencias fundamentales, habremos dado un paso más hacia un mundo de trabajo mejor.
¿Es ésta la perspectiva Ágil del PMI?
3Actualización: El artículo al que hacía mención este post ya no existe en el sitio del PMI. Gracias a la comunidad Ágil dentro del Project Management Institute y a su esfuerzo por promover la esencia de las metodologías ágiles, hoy podemos decir que la perspectiva del PMI sobre la agilidad es mucho más objetiva.
A continuación mi publicación original:
En la edición de Agosto de “PM Network” se publicó una pequeña presentación sobre lo que es Agile y si conviene adoptarlo. Para esto recorre varios de los principios y sugiere (en una forma un tanto tendenciosa a mi entender) las situaciones donde aplicaría y las situaciones donde no aplicaría. Quien esté interesado en verla, lo puede hacer aquí:
http://www.pmi.org/resources/pages/agile.aspx
También se publicó una respuesta de la comunidad ágil hacia este artículo:
Video: http://www.xtranormal.com/watch/6973505
Espero que en algún momento logremos superar este tipo de cosas. Por cierto, repito, el artículo del PM Network me parece tendencioso y demasiado escueto como para que de por sentadas sus sugerencias.
Las Leyes de Mariana para implementar Scrum
0¿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/
31 de Agosto – Desarrollo Ágil con Scrum
0Los beneficios de Scrum están ampliamente comprobados, pero ¿cómo implementar Scrum? ¿de qué se trata ser un verdadero equipo Ágil?¿cuáles son las prácticas y herramientas ágiles de gestión de proyectos e ingeniería de software que debo conocer?
Para responder a estas preguntas, este martes 31 de agosto a las 18.30hs estaremos presentamos la nueva certificación de desarrollo ágil de la Scrum Alliance: CSD cuya novedad principal es la comprensión práctica de los valores y principios de Scrum y su aplicación en situaciones reales, lo que permite conocer y experimentar Scrum por dentro para luego poder trasladarlo a la ejecución de proyectos concretos.
Esta charla informativa te servirá para entender aspectos fundamentales de Scrum referidos a su implementación, cuáles son las prácticas ágiles de desarrollo y cómo aplicar los principios ágiles en el día a día, los roles, los errores más comunes y cómo evitarlos, el proceso de adaptación en contextos de negocio cambiantes, y más.
CSD: LA CERTIFICACIÓN DE DESARROLLO ÁGIL DE LA SCRUM ALLIANCE
Sacate todas las dudas y descubrí tu potencial ágil y el de tu equipo de trabajo.
Martes 31 de Agosto
18.30 hs
Av. Córdoba 679, 4º piso, oficina 403
Capital Federal
Te esperamos!
Inscripciones: hello@kleerer.com
(Cupos limitados)
Instalación de RVM (Ruby Version Manager)
0Ruby Version Manager (RVM) es una herramienta muy útil a la hora de trabajar con diferentes versiones de ruby en un mismo entorno.
Para ilustrar la instalación y operación de RVM, hemos grabado el siguiente video, que podés encontrar también en Vimeo.
Scrum en Rosario!
0En una nueva visita a la bella ciudad ribera, esta vez de la mano de Fundación Libertad, tuve la oportunidad de charlar algunas horas de lo que significa Scrum y de poder acercarnos un poco más a las Metodologías Ágiles.
Tuvimos la suerte de aprovechar una fresca mañana de invierno, en un piso alto de un edificio del centro de la ciudad que ofrece al espectador una impactante vista del río Paraná. Bellísimo.
Para empezar, nos valimos de una “dinámica de tribus” a través de la que identificamos los distintos grupos de profesionales y su grado de conocimiento y utilización de Metodologías Ágiles en sus proyectos (es increíble como este tipo de ejercicio siempre funciona, sea cual fuere el contexto o el grupo de personas).
Ya adentrados en la presentación de la temática, estuvimos conversando acerca de los Principios, el Manifesto Ágil, Historias, Sprints, Product Backlog, Release Plan, Task Board, Daily Standup Meetings, Retrospectivas… en fin, intentando entender en profundidad qué es lo que hace que la aplicación de las Medologías Ágiles mejore la calidad de lo que se entrega al cliente y las prácticas de nuestro trabajo cotidiano.
Aunque para algunos escuchar lo que proponemos desde las Metodologías Ágiles pueda sonar llamativo y fuertemente contrastante con lo que conocieron hasta ahora, existen muchos otros que se interesan positivamente y que buscan aprender más del tema para poder llevarlo a su trabajo. Ya el solo hecho de participar de esta experiencia es un gran paso para lograrlo!
Aquí dejo la presentación que utilizamos:
Hasta la próxima, Rosario!
CSD – Certified Scrum Developer en Bs As
2Durante la semana pasada -de Lunes a Miércoles- tuve la oportunidad de facilitar un workshop intensivo de 24 horas de Desarrollo Ágil de Software perteneciente a la certificación CSD (Certified Scrum Developer).
Dejo aquí un video que ilustra la jornada:
Para más información sobre estos workshops de certificación CSD podés visitar la página de Kleer dedicada a este tema en: http://www.kleerer.com/es/CSD




