Durante el último tiempo he estado analizando los roles que resultan imprescindibles a la hora de encarar un proyecto de desarrollo utilizando un proceso ágil. Resulta necesario hacer una aclaración preliminar para poner en contexto mi visión. Yo trabajo actualmente en una organización dedicada al desarrollo de software y por lo general nuestros clientes son organizaciones que se dedican a alguna actividad X que NO es el desarrollo de software. Continuando con el tema de interés, todos los métodos ágiles hacen hincapié en la participación de los usuarios, pero más allá de eso, dentro del paraguas de métodos ágiles la cantidad de roles propuesta por los distintos métodos es variable. De acuerdo a mi experiencia personal y a la cultura/procesos de la organización donde trabajo actualmente creo que en todo proyecto más allá de ser ágil o no, es necesario identificar claramente los siguientes roles:

• Sponsor: quien está pagando por el proyecto, generalmente es algún gerente de la empresa cliente.
• Dueño del producto: quien conoce las funcionalidades que debe tener el producto final. Tiene un amplio conocimiento del negocio y por ello puede priorizar las funcionalidades del producto. Es quien lidia con los usuarios y luego de filtrar sus opiniones las transmite al equipo de desarrollo.
• Líder del proyecto: quien se encarga de la gestión del proyecto y de que el mismo llegue a buen puerto en tiempo y forma.

Los roles de sponsor y dueño de producto deben ocupados por personas de la organización cliente, mientras que el rol de líder de proyecto es ocupado por alguien de la empresa de desarrollo. Obviamente siempre hay presente en el proyecto un equipo de desarrollo conformado por técnicos y que es el que lleva a cabo la actividades de construcción. Los roles que conforman dicho equipo suelen variar dependiendo del proceso que se utilice para llevar a cabo el proyecto. Este equipo suele estar conformado por personal de la empresa de desarrollo, aunque es recomendable que también cuente con técnicos de la empresa cliente. Ahora enfocándonos en proyectos ágiles, me es posible decir que ocasiones resulta necesario/recomendable contar adicionalmente con los siguientes roles:

• Líder de proyecto cliente: es el facilitador que se encarga de destrabar todas cuestiones surgidas en el ambiente cliente para las cuales el líder de proyecto no tiene la autoridad suficiente por ser una persona externa. Su presencia resulta mucho más relevante cuando el proyecto se lleva a cabo en las oficinas del cliente. A diferencia del sponsor debe estar en el día a día del proyecto. Dependiendo de la organización puede que el rol sea ocupado por el propio sponsor.  Es necesario aclarar que si bien es deseable que el sponsor esté en el día a día del proyecto es común que por su responsabilidades dentro del negocio no tenga disponibilidad para estarlo, lo cual da cabida al surgimiento de este rol.
• Administrador de infraestructura: en quien se encargará de la administración de todo el ambiente de desarrollo y prueba. Esto implica la instalación configuración y mantenimiento del software de base (sistema operativo, service packs, base de datos) y aplicativos como entornos de desarrollo, herramientas de integración continua y herramientas colaborativas (wiki, mail, blog, CMS, etc)
• Gerente de cuenta: este rol es parte del la organización de desarrollo y tiene a su cargo las cuestiones de índole comercial entre las organizaciones. Si bien en ocasiones dichas cuestiones suelen recaer en el líder de proyecto, resulta mucho más saludable que no sea así. El líder de proyecto está enfocado en su proyecto y estas cuestiones contractuales suelen establecerse entre organizaciones (al menos es como NOSOTROS acostumbramos trabajar), es por ello que resulta necesario que sean manejadas por alguien que tenga la visión de todos los proyectos realizados junto a la organización cliente. Para despejar cualquier duda, el tipo de cuestiones al que me refiero tiene que ver con: cambios de tarifas, relaciones entre las organizaciones a mediano y largo plazo, alianzas, etc.

En cuanto al equipo de desarrollo de desarrollo, como ya se mencionó está conformado por técnicos, entre los cuales podemos distinguir en el caso de desarrollos ágiles distinguimos:

• power developers: que hemos dado en llamarlos de esta forma dado que cuentan con ciertas responsabilidades y capacidades adicionales a las entender especificaciones técnicas y escribir código. Entre estas capacidades se encuentran: la capacidad de análisis e interacción directa con los usuarios y el criterio/conocimiento para diseñar el software e implementarlo entre otros.
• solution architect: quien es el encargado de definir las bases de la solución y es el referente técnico del proyecto. Si bien su principal participación es al comienzo del proyecto, tiene una dedicación parcial constante para asistir a los developers en cuestiones que estos se sientan superados o simplemente requieran de una opinión más experimentada.

Si digo que esto es todo, alguien podría preguntar:

1. ¿quien trabaja junto al cliente/usuario para especificar los requerimientos?
2. ¿quien realiza el diseño?
3. ¿quien realiza las pruebas?

Y dado que estamos hablando de un proceso ágil, particularmente basado en principalmente en XP con algunos condimento de FDD, las respuestas serian:

1. Los power developer que dada sus habilidades pueden perfectamente lidiar con este tipo de actividades. Pero ojo no perdamos de vista el contexto del proceso que estamos utilizando. No existen extensas y detalladas especificaciones de casos de uso, generalmente serán historias de usuarios o similares.
2. Los power developers. Aunque hay que destacar que inicialmente los mismos realizan un modelo de dominio en conjunto con los usuarios y el arquitecto. Con lo cual la base del diseño queda establecida desde un comienzo.
3. Los power developers realizan las pruebas de unidad y demás pruebas técnicas (de ser necesarias) mientras que es el usuario quien se encarga de escribir y ejecutar las pruebas de aceptación. Obviamente para que el usuario pueda lleva a cabo esta tarea es previamente capacitado por los power developers.

Bien, esto es todo. Creo que los roles han quedado claramente descriptos. Obviamente no es necesario que cada persona ocupe un solo rol, pero si bien hay roles compatibles (que pueden ser ocupados por una misma persona) hay otros que no lo son.

Espero que les resulte útil y me hagan llegar sus comentarios.