viernes, 23 de enero de 2009

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).

jueves, 8 de enero de 2009

LinkedIn usa Spring y Tomcat

Hoy encontre esta excepción mientras navegaba por LinkedIn:



Al menos están usando Spring!