El product backlog de Enterprise Library 5.0: cómo empieza a trabajar un buen equipo ágil

Como todos sabréis, Enterprise Library es un conjunto de componentes reutilizables que podemos usar para ahorrarnos trabajo en diversas tareas comunes de desarrollo, ya sea mediante su utilización directa, o viendo cómo han sido resueltos los distintos escenarios que aborda y aplicando ese conocimiento en nuestros propio código. La librería va por su versión 4.1 y es desarrollada por un equipo del área de  patterns & practices, la cual se ocupa de proporcionar guía ante problemas comunes de desarrollo y de mostrar cómo han sido abordados en Microsoft.

En este post no voy a contar nada acerca de detalles concretos de Enterprise Library (para eso hay gente mucho más capaz que yo); simplemente quiero hablar un poco de cómo han enfocado una actividad tan importante en todo proyecto de desarrollo como es la definición de los requerimientos. Los principios que han aplicado son los que están en el corazón de cualquier proyecto ágil, y si funcionan para un software y/o código que es utilizado por decenas de miles de desarrolladores en todo el mundo, imaginad hasta qué punto pueden ser aplicables en los proyectos en los que cualquiera de nosotros trabaja a diario.  

 

La construcción del product backlog

De cara al desarrollo de la próxima versión 5.0 de la Enterprise Library, el equipo (como buen equipo ágil), se dio cuenta de que el primer paso antes de poder a plantearse cualquier otra actividad, es construir una primera versión de la lista de requerimientos, que describa a alto nivel qué funcionalidad y características van a ser cubiertas por el producto. La forma más óptima de recoger estos requerimientos es en un backlog de producto; el propósito y las características de un buen backlog ya han sido detallados en muchas ocasiones, por ejemplo por mi compañero Rodrigo. Una de las premisas fundamentales del backlog es que refleje de forma clara las necesidades del cliente, por lo que para construirlo es imprescindible la colaboración y la comunicación continua con el cliente.

¿De dónde obtiene el equipo esta información? ¿quién determina qué características nuevas va a incorporar la siguiente versión de la Enterprise Library? Se podría pensar a priori, que alguien con el suficiente poder dentro de Microsoft decide estas cuestiones, y determina de esta forma el conjunto de características en las que trabajará el equipo. Esto es algo que se da en muchas organizaciones, pero que si nos paramos a valorar con calma, se revela como una aproximación claramente errónea, o al menos que no reflejará de forma fiel las verdaderas preferencias del cliente.

Pero entonces, ¿quién es el cliente para el equipo de la Enterprise Library? ¿quién determina si se ha producido el retorno de la inversión (ROI) que debería justificar la existencia de cualquier proyecto de desarrollo?

Como os podéis imaginar, el verdadero cliente para el equipo de Enterprise Library es la comunidad de desarrolladores que a diario utilizan los Application Blocks y se benefician de consultar los detalles de su implementación. Y el retorno de la inversión para esta comunidad de desarrolladores, no es otro que ver una siguiente versión de la librería que contenga las modificaciones y mejoras más utilizadas y solicitadas por todos.

Con el objetivo de incentivar la comunicación con el cliente y de obtener un product backlog que maximizase el ROI, el equipo de Enterprise Library publicó un post hace unos meses, en el cual invitaba a la comunidad a proporcionar el feedback necesario para llevar a cabo la construcción del backlog. Como podéis ver en el enlace, las respuestas obtenidas proporcionaron una información valiosísima al equipo para la construcción del backlog, y que difícilmente podría haberse obtenido por otros medios distintos a la comunicación directa con la comunidad de usuarios.

Como dato útil podéis ver que pidieron a la gente que utilizasen la técnica de «dinero en el backlog», consistente en asignar un «presupuesto» simbólico (en este caso fueron 100$) y asignar parte del dinero a cada una de las características que se desee incluir en la siguiente versión. Por poner un ejemplo corto extraído de la misma lista de comentarios, sería algo así:

 

$70 – Activerecord  implementation.

$20 – remove the policy injection block and merge it with the unity block.

$10 – make config administration less painful.

 

En los comentarios del post podéis encontrar muchos otros ejemplos bastante interesantes. Como resultado de este proceso de recogida de información, y combinando esta información con otras encuestas, mails recibidos y consultas, se obtuvo el backlog que guiará el desarrollo de Enterprise Library 5.0, formado por más de 100 elementos.

 

La estimación y priorización del product backlog

 EntLib_voting_thumb El siguiente paso en el proceso de construcción de un buen product backlog es la estimación y la priorización del mismo. La estimación permite tener en todo momento definido el estado del proyecto y el horizonte temporal del mismo, y su proceso de obtención nos proporciona datos valiosos que nos ayudan a entender mejor los requerimientos y cómo afrontar su implementación. La priorización garantiza que se va entregando valor según lo determinado por el criterio del cliente y guiándose por el ROI perseguido.

Es importante además tener una estimación a alto nivel cuanto antes, pues además de las ventajas ya mencionadas, permitirá que el cliente pueda guiar la priorización de determinados requerimientos en base al coste que supone implementarlos. Es posible que un requerimiento que en principio puede parecer poco importante, suba bastante en la clasificación si se determina que el coste de implementarlo es bajo; y lo contrario podría llegar a aplicarse para requerimientos muy costosos de implementar.

El equipo de Enterprise Library ha estimado el backlog en base a un procedimiento muy simple pero bastante útil, que les ha permitido que el cliente (la comunidad de desarrolladores) se pueda hacer una idea rápidamente del coste relativo que puede suponer la implementación de cada elemento del backlog. Se refieren al procedimiento como «T-shirt sizing» y consiste en asignar a cada requerimiento una «talla» de camiseta (S, M, L, XL o XXL), que de una idea de la magnitud relativa del coste de implementación del mismo con respecto al de los demás. Un ejemplo en el que se pueden ver casi todas las «tallas» es el fragmento del backlog correspondiente a los requerimientos del Application Block de configuración:

 

Config

CFG01 : Config decentralization (support for config stored in multiple sources) (S)

CFG02: Improved Config API (XL)

CFG03: Support for different sections of config in different media (not just files) (XL)

CFG04: Support for multiple pieces of config for a single block in multiple places (XXL)

CFG05: Making Unity configuration less verbose (M)

CFG06: Support other config schemas for Unity config (e.g. XAML-based config)

CFG07: Unity config auto-registration: expanded conventions and helper classes to reduce need for explicit configuration (M)

 

El coste de las historias o requerimientos que han utilizado es: S=1, M=2, L=4, XL=8 y XXL=20 (en lugar de una historia de usuario XXL se correspondería con lo que se puede denominar como épica). Se trata de medidas relativas que en principio no dan información del coste final; éste sería obtenido en posteriores revisiones del backlog.

Como se puede apreciar, basta un vistazo para que el cliente pueda hacerse una idea del coste relativo de implementación de cada elemento, y en base a esa información poder ser más específico en la priorización. Además como podéis ver el backlog está expresado en un lenguaje que cualquier usuario de Enterprise Library puede entender, sin entrar en ningún momento en detalles internos de la implementación o del funcionamiento de los distintos módulos.

En cuanto a la priorización, como no podía ser de otra forma para un equipo ágil, el encargado de definirla es el cliente, en este caso la comunidad de desarrolladores que utilizan Enterprise Library. El equipo ha utilizado una vez más el recurso de obtener información de la misma fuente, y para ello ha publicado otro post, en el que se invita a todo aquel que quiera a opinar en la priorización de los requerimientos, a participar en una encuesta orientada a recabar dicha información. Para completar la encuesta se recuerda que el presupuesto es de 100 $ o puntos que deben distribuirse entre los elementos del backlog.

La votación está abierta desde ya y cualquiera que desee aportar su opinión puede hacerlo. El equipo se ha comprometido a publicar los resultados y a utilizarlos para priorizar el backlog que será finalmente utilizado en el proyecto de desarrollo.

 

Conclusiones

¿Qué podemos sacar en claro de toda esta historia? (además de poder influir en la próxima versión de Enterprise Library, claro…) Voy a intentar hacer un pequeño resumen de lo que más me ha llamado la atención a mí; algunas de las cosas os parecerán evidentes pero no os podéis ni imaginar la cantidad de veces que no se cumplen en la vida real, al menos por lo que respecta a mi experiencia (y os puedo asegurar que he visto unos cuantos proyectos de desarrollo en los 10 años que llevo trabajando en esto…)

  • Lo primero y más importante en todo proyecto de desarrollo es construir una lista de requerimientos o product backlog de partida, tener su contenido claro, y que el cliente también lo tenga: en el ejemplo que nos ocupa, qué es lo que se quiere incorporar o mejorar en los application blocks de configuración, acceso a datos, seguridad, etc. Comenzar a trabajar, y no digamos escribir una sola línea de código, sin un product backlog o lista de requerimientos, es como subirse en un coche y comenzar a conducir sin saber a dónde nos dirigimos. Y en muchas ocasiones nos damos cuenta de que estamos en la dirección equivocada cuando llevamos recorridos cientos de kilómetros!!!
  • El cliente o interesado último en el resultado de lo que se está desarrollando, debe de ser también el que determine qué es lo que se desarrolla. Para la Enterprise Library está claro que son los usuarios de la librería los que tienen más criterio para decidir esto
  • El desarrollo debe siempre ir guiado por el retorno de la inversión. En este caso por las características que más agradecerán los usuarios de la Enterprise Library, que van a ser convenientemente priorizadas
  • La elaboración de estimaciones sirve, entre otras cosas, para dar mucha información útil para la priorización de los elementos del backlog

 

Pero aparte de toda la base teórica de la que ya se ha hablado de sobra, lo que más me gusta del caso que nos ocupa es, que sin ser el objetivo principal del mismo, nos está dando ejemplos, técnicas y herramientas que son de gran valor y que podemos aplicar en nuestros propios proyectos desde ya mismo. Por ejemplo:

  • La comunicación con el cliente es fundamental y en ocasiones hay que ser creativos y hacer uso de todo tipo de recursos para mejorarla; en este caso se ha hecho uso del blog, el correo electrónico, las encuestas on-line…
  • Tenemos técnicas que nos ayudan a estimar el backlog de una forma bastante sencilla e intuitiva; por ejemplo el «T-shirt sizing» es algo que no conocía pero que me ha parecido excelente y que pienso utilizar en cuanto tenga la oportunidad
  • Tenemos técnicas que nos ayudan a priorizar también de forma sencilla e intuitiva y que podemos utilizar con nuestros clientes para simplificar el proceso, en este caso el «dinero en el backlog» (ésta sí la conocía 😉 )
  • El backlog preparado por el equipo de Enterprise Library nos puede servir para compararlo con los nuestros y coger ideas. Por el tipo de proyectos en los que suelo estar involucrados mis backlogs suelen ser algo más detallados e incluyen una descripción en forma de historias de usuario, pero también hay que tener en cuenta que el backlog que hemos visto en el ejemplo aún será más elaborado y refinado en el futuro próximo

Por último me gustaría resaltar que todo lo que he comentado en las conclusiones debería ser tenido en cuenta también en la preparación de propuestas o presupuestos que vayamos a presentar a clientes, una actividad en la que suelo estar bastante involucrado (muy a pesar mío jeje)… ¿Cómo vamos a saber cuánto tenemos que cobrar por algo o qué equipo es necesario, si no sabemos con un mínimo detalle qué necesita el cliente? Pero bueno, esto puede dar para varios artículos, quizá un día me anime a escribir mi opinión sobre ello más detenidamente 😉

Si os interesa Enterprise Library animaos a votar  en la priorización. Cuando se publiquen los resultados seguramente tendremos mucha más información útil del proceso así que seguramente os vuelva a obsequiar con otro ladrillo similar a este post 🙂

 

Un saludo!!!