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.

2 comentarios:

Jose Luis Manrique dijo...

"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." En algunos proyectos en los que he trabajado ya que no se tenia un buen Proxy del Product Owner se tendia a aceptar muchas cosas que al final agrandaban el proyecto sumado a las malas estimaciones. En resumen muy buenos tips!!

Saludos.

Christian Eduardo Palomares Peralta (ShinjiDev) dijo...

Muy buenos tips en verdad Gustavo. Tal como te comenté el otro día, sería bueno un tipo de "best practices" para la parte de requerimientos. Y no olvidar algunos términos que de repente no se entiendan pa todos xD. Chévere :3