Primer Curso Certified ScrumMaster en español en Lima

Durante los días 6 y 7 de Julio de 2009 se dictará por primera vez en Lima el Curso de Certificación de Scrum (CSM) en idioma español, oficialmente reconocido por la Scrum Alliance.

Esta es una excelente oportunidad de llevar este curso, pagando la tercera parte de lo que cuesta en Estados Unidos o Europa. Será dictado por Alan Cyment, el único Certified Scrum Trainer nativo hispanoparlante en el mundo.

Toda la información sobre el curso, así como el formulario de inscripción, la pueden encontrar en la página de la empresa organizadora, Open Edge Technologies, de la cual formo parte.

Espero verlos allí!

Fundamentos de la Agilidad: Gente y Colaboración

Comparto con ustedes la presentación que brindé en el Lima Agile Day 2009, que por cierto fue un evento muy exitoso, y todo un orgullo para mí co-organizar y ser parte del mismo.

Mi objetivo durante la presentación fue tratar de responder las siguientes preguntas:

• ¿Por qué es importante la gente en el desarrollo de software?
• ¿Cómo cultivar un ecosistema ágil?
• ¿Cómo reconocer en qué fase de madurez se encuentra un equipo de desarrollo?

Realmente es un tema amplio, por lo que el tiempo me quedó bastante corto. Espero poder profundizar algunos conceptos en las reuniones de Agile Perú, en este blog y en futuras charlas que organicemos.

Fundamentos de la Agilidad: Gente y Colaboración

View more presentations from gquiroz.

Lima Agile Day 2009

[ACTUALIZACIÓN: La fecha confirmada del evento es el Sábado 18 de Abril de 2009]

La comunidad Agile Perú los invita al Lima Agile Day 2009. Este evento está dirigido a todos aquellos interesados en conocer y entender cómo aplicar las llamadas Metodologías Ágiles de Desarrollo de Software (tales como Scrum y Extreme Programming) de boca de algunos de sus más fervientes practicantes en nuestro país.

Acompáñanos a intercambiar conceptos, experiencias y buenas prácticas relacionadas a esta nueva manera de desarrollar software que tanta conmoción está causando en el mundo entero por los beneficios obtenidos mediante su aplicación: mejoras drásticas en tiempos de entrega, calidad, trabajo en equipo y satisfacción de los usuarios.

Fecha: Sábado 18 de Abril de 2009
Hora: 8:30 am a 1:00 pm
Lugar: Auditorio Cibertec, Av Salaverry 2255, San Isidro

INGRESO LIBRE (capacidad 150 personas) previo registro:

Agenda:

• 8:30 - Registro
• 9:00 - Presentación del Evento
• 9:20 - Scrum, una nueva forma de desarrollar software (Deusdit Correa)
• 10:05 - Fundamentos de la Agilidad: Gente y Colaboración (Gustavo Quiroz)
• 11:00 - Cómo enfrentar la resistencia al uso de Metodologias Agiles (Raúl Uribe y Gustavo Véliz)
• 11:45 - ¿Por dónde comenzar? - Primeros pasos aplicando técnicas ágiles (Abner Ballardo)
• 12:25 - Retrospectiva y Cierre del Evento

Esperamos contar con tu participación!

Como hacemos Scrum: Requerimientos

Algunos piensan que ser ágil quiere decir que no se tienen requerimientos escritos, que toda la comunicación entre usuarios/clientes y desarrolladores es verbal y que si no están usando User Stories, no se puede hablar de desarrollo ágil. Bueno, tengo que discrepar de estas tres creencias.

Hablaré en el contexto de un proyecto que desarrollamos, el cual consistía en construir una aplicación para una entidad del sector financiero. Esta entidad, como muchas otras similares, tiene procesos un tanto rígidos (por no decir burocráticos ni pesados) que guían sus proyectos de desarrollo.

Cuando iniciamos el proyecto, nos fue entregado un documento de casi 150 páginas en donde se describían en detalle requerimientos, mediante especificaciones de casos de uso y pantallazos de un prototipo previamente construido. ¿Qué hacer en estos casos?

El principio básico en todo esto es algo que les sonará familiar a muchos: LA COMUNICACIÓN. Es decir, debe existir un entendimiento común entre aquéllos que desean resolver un problema (usuarios) y aquellos que pueden resolver el problema (desarrolladores).

Para lograr ese entendimiento debe existir un canal amigable entre ambos frentes. En nuestro caso, lo que hicimos fue acordar reuniones dos veces por semana entre nuestro equipo y los analistas del cliente para conversar acerca del documento de requerimientos. Teníamos como objetivos:

1. Compredener de qué diablos trataba la lógica de negocio a un nivel suficiente para que uno de nosotros actuara como Proxy del Product Owner en nuestras reuniones de planeamiento.
   
2. Poder definir un Product Backlog en base a este documento.
3. Priorizar el Product Backlog con los representantes del cliente.
   

El Analista Funcional del cliente se convirtió, casi sin darse en cuenta, en nuestro Product Owner y acompañó a nuestro equipo a lo largo de todo el proyecto, estando siempre dispuesto a absolver dudas y repriorizar ítems, cuando fuera necesario.

Aquí un punto clave es descomponer los casos de uso para poder llegar a un nivel de granularidad suficiente que permita planificar los ítems del Product Backlog dentro de cada iteración o sprint. La técnica que usamos fue considerar a cada escenario como un requerimiento o ítem distinto. Por ejemplo, si hablamos de un mantenimiento de países, los ítems (o stories) serían:

• Consultar países por nombre
• Consultar países por código internacional
• Crear país
• Modificar país
• Inactivar País
• Reactivar País

Otro punto importante son las demos o reviews del producto que se realizan al finalizar cada iteración. En nuestro caso, además de los analistas del cliente y de nuestro equipo, participaban los usuarios finales de la entidad financiera. Como es normal, al interactuar o apreciar el incremento de funcionalidad que se está presentando, a un usuario se le van a ocurrir muchas ideas de cómo mejorar o cambiar el producto. Es básico el poder manejar su expectativa y guiarlo sobre cuáles se van a poder incorporar y cuáles no (por razones de tiempo, costo y/o complejidad).

Lo que hicimos nosotros fue recoger todas las sugerencias e ideas, para posteriormente (o a veces durante la reunión misma) conversarlas con nuestro Product Owner. Aquellas que el equipo consideraba sencillas las incorporamos sin ningún problema. Pero aquéllas que se estimaba iban a tomar más tiempo, quedaron en el tintero para futuras versiones del producto.

Cómo hacemos Scrum

Cuando la gente comienza a aplicar métodos ágiles en un proyecto u organización, las preguntas más comunes son: ¿por dónde empiezo? y ¿cómo realizo esto o aquello? Entiéndase "esto o aquello" como algo que saben que se tiene que hacer pero no tienen mucha idea de dónde encaja dentro un entorno ágil: documentación, estimación, planificación, etc.

Es por eso que en esta serie de posts voy a contar un poco acerca de cómo usamos Scrum/Agile en los proyectos que desarrollamos en la empresa donde trabajo y de cómo aplicamos principios emparentados con agile o lean en la organización de nuestra área.

Trataré de tocar temas como: planeamiento, estimación, capacitación, gestión del talento, retrospectivas, documentación, requerimientos, testing, espacio de trabajo, etc.

Disclaimer: Las opiniones vertidas en esta serie de posts no representan la posición oficial de la empresa ni de los clientes involucrados (según el caso).

LinkedIn usa Spring y Tomcat

Hoy encontre esta excepción mientras navegaba por LinkedIn:



Al menos están usando Spring!

Agile y software embebido

Al menos un par de veces cuando he dado una charla o curso de Scrum/Agile, me ha sucedido que surgen preguntan acerca de si el desarrollo iterativo-incremental puede aplicarse a sistemas embebido o que involucren Hardware. Si bien sé que es algo que se hace en diversos lugares alrededor del mundo, lo que me faltaban eran casos concretos para mencionar y mostrar.

En este enlace se resume el éxito del proyecto AGILE del programa ITEA de la red de investigación europea EUREKA, el cual se desarrolló entre los años 2004-2006 a un costo de 20 millones de euros. El balance de esta iniciativa fue que se logró producir sistemas embebidos de alta calidad con tiempos y costos menores (hasta 70% menos) en comparación con técnicas tradicionales.

El programa se llevó cabo en 68 proyectos dentro de unas 20 empresas, entre ellas Philips, Nokia y DaimlerChrysler. Algo que vale la pena destacar es la opinión del Dr Pekka Abrahamsson, líder del proyecto, quien afirma que si los resultados obtenidos pudieran sostenerse a lo largo de todo Europa, sería más barato hacer outsourcing de desarrollo desde India hacia Europa que en el sentido inverso!

Durante el evento Ágiles 2008, me enteré de otro caso digno de resaltar. Conversando con Matt Gelbwaks, pude conocer acerca de su experiencia como director de Product Management & Development del famoso Segway. Para desarrollar este producto, Matt empleó un mix de Agile y Critical Chain Scheduling, con muy buenos resultados.