Los roles de los equipos ágiles

No hay metodología ni modelo de desarrollo, por bueno que sea que sustituya a lo más importante que es el equipo de personas que van a desarrollar el producto. En cualquier entorno de cierta complejidad el equipo es fundamental. Es prácticamente imprescindible que el equipo funcione bien para que el desarrollo tenga un final feliz.

Un equipo trello está formado por todas aquellas personas que tienen que ver con el desarrollo de una tarea, tanto de forma activo como aquellos que deben estar informados del grado de cumplimiento del desarrollo de la misma. Las metodologías ágiles como SCRUM incorporan una serie de roles que definen las acciones que deben o pueden realizar cada uno de ellos

Scrum aporta una serie de aspectos que potencian el grupo, que potencian el trabajo en equipo, porque todo es importante en un desarrollo software, pero no tanto como la gestión de las personas.

En los desarrollos software se identifican una serie de roles que son los responsables de que determinadas tareas se realicen. Las propuestas de Scrum al respecto de la organización del equipo varían en la definición de unos nuevos roles y un nuevo comportamiento entre ellos.

Tradicionalmente habremos escuchado los roles de Project manager, Program Manager, jefe de Desarrollo, gestor de Calidad, responsable de pruebas y gestor de versiones entre otros. Cada uno tiene sus responsabilidades muy específicas dentro del equipo.

Scrum hace una primera división (muy curiosa) de los miembros del equipo en base a su implicación con respecto al proyecto, y lo hace con un chiste sobre las ansias emprendedoras de un cerdo y una gallina, cuenta lo siguiente

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice, “Oye, ¿por qué no abrimos un restaurante?” El cerdo mira a la gallina y le dice, “Buena idea, ¿cómo se llamaría el restaurante?” La gallina piensa un poco y contesta, “¿Por qué no lo llamamos “Huevos con jamón?” “Lo siento pero no”, dice el cerdo, “Yo estaría comprometido pero tú solamente estarías involucrada”.

Ilustración 1 Filetes de cerdo y huevo frito

La diferencia de compromiso es obvia, mientras en el plato de filetes de cerdo y huevos fritos, el cerdo pone su vida, la gallina se limita a poner huevos. Así en SCRUM tenemos equipos (SCRUM team) formados por cerdos y gallinas, o sea implicados e interesados, todos son tienen su importancia en el proyecto pero no la misma.

Dentro de los cerdos o implicados tenemos:

• Product Owner
• Scrum Master
• Development Team

 

Dentro de las gallinas o interesados tenemos

• Stakeholders (Interesados)

 

El Product Owner (el Dueño del producto)

El sueño de todo analista y/o desarrollador es tener al cliente disponible las 24 horas del día para que le pueda solucionar cualquiera de las dudas que surgen durante el proceso de análisis y desarrollo. Obviamente cuando hablo del cliente me refiero al responsable de la aplicación, no al responsable del equipo de desarrollo. Este es el Product Owner,  la persona responsable de fijar que es lo que es el producto, cuales son las partes que lo van a formar e incluso fijar las prioridades dentro de la Lista de Producto (se verá más adelante).

Es importante destacar que siempre el Product Owner es una única persona, es la persona que asume la responsabilidad de determinar qué es ese producto, aunque obviamente pueda tener que hacer las consultas correspondientes a otras personas. Es decir, si es un comité el que decide los requerimientos de un producto, el interlocutor del comité respecto al resto del equipo  es el Product Owner. La importante ventaja de este modelo es que se aísla al equipo de desarrollo de los pensamientos de cada uno de los miembros de un comité,  pero por otro lado hace recaer todo el peso de la responsabilidad en el Product Owner.

En realidad el Product Owner realmente puede ser un miembro de la empresa que solicita el producto  o puede ser alguien de la empresa de desarrollo que haga de interfaz con el cliente.  En cualquier caso es la persona responsable de fijar los requerimientos del producto. Debe estar accesible por parte del Scrum Team en (casi) cualquier momento y debe formar parte activa de las reuniones en los que su presencia es requerida.

Entre otras sus tareas son:

• Conseguir maximizar el valor del producto y del trabajo del Scrum Team. O sea maximizar especificaciones del producto al menor coste en número de horas del Scrum Team.
• Conocer y validar los requerimientos del producto.
• Asegurarse que los miembros del Scrum Team le han entendido perfectamente.
• Marcar las prioridades y orden en el que los diferentes componentes del producto deben ser implementados.
• Hacerse respetar. Si la organización no respeta el criterio del Product Owner los anteriores ítems carecen de sentido, e incluso si perdiera la confianza del Scrum Team sobre la importancia de su criterio, inevitablemente dificultaría las posibilidades de éxito del desarrollo.
• Ante cualquier duda que surja en el equipo es el que actúa como árbitro.

 

Además se debe cumplir una máxima “Ninguna otra persona que sea el Product Owner puede modificar o añadir requerimientos al producto, el Scrum Team solo puede desarrollar en base al criterio fijado por el Product Owner”.

Scrum Master

Tenemos un equipo preparado (Scrum Team), tenemos al Product Owner que fija objetivos (controla costes) y solo falta el miembro del equipo que debe conseguir organizar al equipo para poder cumplir los objetivos fijados, este es el Scrum Master.

El Scrum Master es el responsable de que el equipo pueda trabajar según las reglas Scrum y también es el responsable de que así sea. Esto debe conseguirlo fundamentalmente:

• Favoreciendo la auto-organización del equipo impidiendo interferencias y/o distracciones externas.
• Resuelve problemas e impedimentos que puedan surgir (ya sean informáticos o de intendencia).
• Debe mantener visibles los artefactos Scrum (más adelante comentaremos lo que son)
• En cierta forma es el líder del equipo, lo que no implica la autoridad sobre el resto de miembros del equipo. Aunque inevitablemente el concepto de líder conlleva cierta autoridad sobre el resto.
• Es el responsable de definir (o aplicar) los Timeboxes o límites de tiempo máximos para determinadas tareas.
• Debe gestionar la Lista de Producto (lista de tareas que engloba un proyecto)  de manera efectiva cumpliendo las peticiones del Product Owner, por ello debe ser capaz de hacerle entender la mejor forma de priorizar tareas.
• Es el máximo responsable de que todos los eventos Scrum se realicen en tiempo y forma.
• Debe conseguir que la lista de Producto sea  clara y no tenga ningún tipo de ambigüedad.
• Debe ser capaz de explicar el modelo Scrum al resto de la organización, haciéndole ver sus ventajas.
• Y por supuesto, debe motivar al equipo, facilitando que consiga sus metas.

 

Development Team o equipo de desarrollo

El Equipo de Desarrollo está formado por un grupo de profesionales responsables en último plazo de diseñar e implementar el producto a realizar. Son los que llevan el peso de la realización de todos y cada uno de los Sprints, son los responsables de que el trabajo que realizan se pueda poner en producción.

La estructura del equipo de desarrollo les permite organizar y gestionar su propio trabajo. Esto rompe el esquema tradicional en el que cada uno de los miembros del equipo recibía por parte de un superior las órdenes concretas que determinaban el desarrollo que debía realizar. Las características principales que los definen son:

• Los equipos son autoorganizados y son dirigidos desde el mismo equipo.
• Los equipos son multifuncionales, es decir tiene miembros con diferentes habilidades desde desarrollo puro a testing e incluso análisis.
• El equipo es autónomo, no dependen de nadie externo al equipo a la hora de tomar decisiones (algo a veces difícil de asumir). Es el mismo equipo el que toma las decisiones que afectan al proyecto que están desarrollando.
• Se basa en el trabajo colaborativo. Es fundamental el trabajo en equipo abandonando el concepto de francotirador solitario.
• Funciona mejor si físicamente se halla en el mismo lugar, lo que favorece además de las relaciones personales, ayudas puntuales y el propio seguimiento del proyecto.
• Lo ideal es que los equipos Scrum se mantengan en el tiempo, en varios proyectos, lo que contribuye al conocimiento profesional y personal de los miembros del equipo.
• Scrum no reconoce títulos para los miembros de un equipo de desarrollo, todos son desarrolladores, independientemente del trabajo que realice cada persona. No hay excepciones a esta regla.
• Cada miembro del equipo puede estar especializado o destacar en algún tema en concreto, pero siempre la responsabilidad recae sobre todo el equipo como un todo.
• No se deben definir sub-equipos de desarrollo especializados en alguna tarea, no hay excepciones a esta regla. Por ejemplo definir el equipo de análisis o de pruebas.
• Los tamaños de equipo no deberían superar las 9/10 personas y quizá tengan poco sentido con menos de 4/5 personas.
• Es ideal que todos los miembros del equipo tengan habilidades transversales imprescindibles en el desarrollo de proyectos informáticos  (análisis, diseño, desarrollo, pruebas, documentación, etc).

Stakeholders (Clientes, Proveedores, Vendedores, etc)

Se refiere a la gente que hace posible el proyecto en el sentido de la financiación o solicitud así como aquellos para quienes el proyecto producirá el beneficio acordado (usuarios de la aplicación). Solo participan directamente durante las revisiones del producto que va finalizando el equipo de desarrollo.

 

Creando el equipo Trello

 

En la esquina superior derecha, justo al lado de nuestra foto aparece un signo “+” que nos permite acceder a una serie de opciones. Una de ellas es la creación de equipos. Si la seleccionamos nos pedirá el nombre del equipo y una pequeña descripción del mismo.

 

Ilustración 2 Menú de opciones

Ilustración 3 Dando de alta el equipo

 

Como no podía ser de otra manera, el equipo podemos configurar los aspectos gráficos de la foto que lo ilustre, así como lo importante de indicar las personas que forman parte de él.  Para ello de vemos o bien introducir su nombre o (si no están dados de alta en trello) realizar una invitación a su correo para que así lo hagan.

Cada vez que se incorpora a un nuevo usuario al equipo, éste recibe un correo en el que se le informa de tal acción. Un usuario puede abandonar un equipo siempre que lo desee.

Todos los usuarios pueden actuar como usuario administrador o usuario normal. El primero es el único que puede gestionar los cambios en el equipo.

Ilustración 4 Equipo Trello

 

Ya tenemos el equipo, ahora ya sólo toca empezar a trabajar.  3, 2 1, ya¡¡