SCRUM Y XP: Los roles en un equipo scrum
Despues de comentar como es el proceso de desarrollo con Scrum vamos a ver quienes son los participantes en este proceso y que roles cumple cada uno. Como todos sabemos Scrum es una metodología ágil, y el primer principio del manifiesto ágil dice:
Valorar más a los individuos y su interacción que a los procesos y las herramientas
No se trata solo de tener un proceso que seguir, se trata de tener la gente adecuada para desempeñar cada uno de los roles definidos, y aunque Scrum en definitiva define un proceso de trabajo, como metodología ágil que es valora más la capacidad y el talento de los miembros del equipo que el seguimiento a pies juntillas de un proceso.
Incido en esto para que nadie se sienta "engañado", la aplicación de Scrum no ejerce ningún tipo de acción mágica en tu equipo que convierta a becarios o recién titulados en M. Fowler o Robert C. Martín. Lo primordial es tratar de reunir el mejor equipo que puedas y asegurarte de que este motivado, si quieres hacer buen software esta debe ser sin ninguna duda la primera prioridad.
Quiero resaltar con esto que independientemente de Scrum o cualquier otra metodología que decidamos aplicar lo más importante es la gente, esto confronta directamente con la orientación a procesos de otros enfoques, como el modelo CMMI por ejemplo. Estos enfoques orientados a procesos tratan de definir un método de trabajo que permita que la gente sea fácilmente sustituible, afirman que la calidad del producto depende de la calidad de los procesos aplicados en su elaboración. En mi opinión la calidad de un producto software depende prioritariamente del talento y la capacidad de sus desarrolladores y en mucha menor medida de la calidad del proceso.
Dicho esto vamos a ver que roles define Scrum y que cometidos tiene cada uno
Entre gallinas y cerdos
En primer lugar Scrum divide a las personas que están alrededor de un proyecto en dos categorías, las gallinas y los cerdos, hay una viñeta muy famosa al respecto:
- Las gallinas son todos aquellos interesados en el proyecto, gente que espera obtener algo a partir de los resultados del producto pero que no están directamente implicados en su desarrollo. Por ejemplo comerciales o mandos intermedios de la compañía
- Los cerdos son aquellas personas que participan activamente en el día a día del desarrollo de un producto, tanto en su definición como en la elaboración del mismo. Vamos que según Scrum los desarrolladores somos algo así como una piara de cerdos :P
A partir de ahora vamos a centrarnos en los cerdos, Scrum define distintos roles para los participantes en el desarrollo de un producto, la organización de las gallinas será algo que dependa de cada empresa y queda fuera del alcance de Scrum que se limita simplemente a hacer esta distinción inicial.
3 tipos de cerdos
El product owner
El nombre ya es muy explicativo, es el dueño del producto, vamos la persona que decide que se tiene que hacer y cuando se tiene que hacer. Su cometido principal es encargarse del product backlog, es responsabilidad suya definirlo y priorizarlo. También es el responsable de verificar que el producto que sale de un sprint cumple con los objetivos marcados, es el principal responsable de la reunión de planificación donde debe junto con el resto del equipo definir el trabajo a realizar en el siguiente sprint.
Una tarea importante del product owner es canalizar todas las peticiones de las gallinas y construir el product backlog en función de estas, debe ser por tanto alguien que tenga claro la dirección que debe seguir el proyecto y que conozca bien el negocio a donde va dirigido el mismo. Ejerce como filtro para el equipo lo que en la practica es importantisimo para evitar interferencias al equipo de desarrollo, no puede llegar cualquiera con corbata y solicitar esto o aquello sin pasar por el filtro del product owner. Su misión más importante es servir de punto de unión entre los distintos interesados en el proyecto y el equipo de desarrollo, digamos que es el nexo de unión entre gallinas y cerdos
En nuestro caso particular desarrollamos un framework que luego se usa en la empresa para servir como base a otros proyectos, hay por tanto muchas gallinas interesadas en que el framework haga esto o lo otro, cada uno en su proyecto tiene distintas necesidades y el framework en la medida de lo posible debe dar cabida a todas ellas, en nuestro caso la figura del producto owner es fundamental para canalizar y priorizar todas las peticiones de mejoras al framework y para definir la dirección en la que vamos. El equipo de desarrollo sabe que a quien tiene rendir cuentas es al product owner y no estamos constante mareados por peticiones de unos y otros.
El Scrum master
Es el "experto en Scrum", es la persona que se encarga de asegurarse que se sigue el proceso de Scrum. Entre sus responsabilidades están organizar las reuniones necesarias (cosas como reservar una sala y asegurarse de que todos los implicados asistan), moderar las distintas reuniones, actualizar la grafica burndown con las reestimaciones diarias, resolver o ponerse en contacto con quien pueda resolver los problemas que se detecten en la reunión de Scrum diaria.
La principal tarea del scrum master no es dirigir o organizar al equipo (scrum sigue la premisa de equipos que se autorganizan) sino eliminar los obstáculos que impiden el avance del equipo y asegurarse del cumplimiento de la metodologia. Más que como un líder de proyecto "clásico" se puede ver al scrum master como un facilitador que se encarga de vigilar que el equipo avanza adecuadamente.
En nuestro caso particular la labor de scrum master no es suficiente como para tener una persona dedicada a ello a tiempo completo, vamos que para mandar unos cuantos correos, actualizar un gráfico y moderar las reuniones tampoco necesitamos a nadie a tiempo completo. Actualmente soy yo quien ejerce de Scrum master al mismo tiempo que también soy developer, quizás en organizaciones mayores donde existan varios grupos haciendo scrum puede ser interesante tener un solo scrum master que se ocupe de varios equipos, pero en nuestro caso nos parece suficiente con que este rol lo asuma un miembro del equipo.
developer
Lo recomendado en scrum es un equipo este compuesto por entre 7 y 3 developers. Es decir esta es una metodología para equipos de trabajo pequeños, no obstante siempre es posible subdividir el trabajo entre varios equipos y realizar lo que se conoce como Scrum de scrums. Nosotros actualmente somos un sólo equipo de 4/5 desarolladores pero esta previsto para un futuro no muy lejano formar nuevos equipos y subdividir el trabajo, ya os contaré en entradas futuras como nos va :P
¿Y que hacen los developer?, pues esta bastante claro ¿no?, son los que desarrollan el producto, nada más y nada menos que eso. Lo primero que puede llamar la atención si estamos acostumbrados a otras metodologías es la ausencia de roles como: arquitecto, analista funcional, analista orgánico, analista programador, programador senior, programador junior, programador bla,bla,bla.... En scrum solo hay desarrolladores, aunque por supuesto en función de su experiencia y conocimientos habrá algunos que sean los que decidan sobre la arquitectura, los que tomen decisiones de diseño de más alcance, y otros con menos experiencia que vayan aprendiendo, pero algo importante es que el propio equipo el que se auto-organiza y define internamente estas responsabilidades de común acuerdo, aquí la figura del Scrum master es importante para poner "paz" en determinadas situaciones y hacer que la comunicación en el equipo sea lo más fluida posible.
Otra característica importante de los developers en scrum es que no se trata de equipos de especialistas sino de equipos de "todoterrenos", es decir, no hay un especialista en diseño de BBDD, otro en interfaces de usuario, otro en tal o cual framework. En un equipo scrum todo el mundo tiene que saber hacer de todo, y lo más importante todo el mundo tiene que estar dispuesto a aprender nuevas cosas constantemente y encargarse hoy del diseño de la BBDD y mañana de un UI en javascript. Por supuesto que luego siempre habrá gente que sepa de mas de un área determinada, pero la idea es que ese conocimiento no quede solo en la persona experta sino que el equipo entero vaya creciendo aprendiendo unos de otros, es importante tratar de que las tareas no se asignen luego en función de "quien sabe más de esto", sino que cualquiera se pueda hacer cargo de cualquier parte del proyecto, en algunos casos puede ser muy interesante la practica del pair programming para ir haciendo que miembros del grupo con pocos conocimientos en algún área los vayan adquiriendo paulatinamente.
Muchos afirman que Scrum solo funciona con equipos de cracks, tampoco estoy del todo de acuerdo con esta afirmación, no es necesario que todos los miembros del equipo sean auténticos cracks, lo que si es importante es que todos tengan como mínimo buena disposición para aprender y no tengan miedo a enfrentarse a nuevos problemas, estudiar este o aquel nuevo framework o leerse una o dos especificaciones. Si cuentas con gente para la que pasar de utilizar .net para usar java o viceversa supone un suplicio insufrible por tener que abandonar sus hábitos o herramientas conocidas, pues entonces tienes un problema, pero no es que tu problema sea que no puedes aplicar Scrum, sencillamente tu problema es que no tienes buenos desarrolladores, y eso no lo arregla ni CMMI, ni Scrum ni la virgen de Lourdes.
En nuestro caso particular nuestro equipo esta formado por gente con una experiencia de 5 años o más y con una disposición excelente para aprender nuevas cosas, en este aspecto desde luego tenemos mucha suerte, pero esto no quiere decir que no se pueda aplicar en otros equipos con menos experiencia si estos están dispuestos a hacer el esfuerzo y consigues motivarlos adecuadamente. Y no siempre es la experiencia lo que cuenta, en nuestro caso por ejemplo a pesar de tener todos varios años de experiencia jamas habíamos realizado unit testing en serio, ni tampoco integración continua, ni siquiera todos los miembros tenían experiencia en java que es el lenguaje en el que desarrollamos actualmente, sin embargo todos los obstáculos se han ido resolviendo y hemos ido aprendiendo todos durante el camino. No creo que seamos unos cracks ni mucho menos, pero eso si, todos somos desarrolladores a los que nos gusta nuestra profesión y tenemos ganas de seguir aprendiendo y mejorando, esto es lo realmente importante en mi opinión.
Con esto por hoy esta bien que me pongo a escribir y suelto siempre unos rollos tremendos jeje, en sucesivas entradas ire entrando en materia de la mecánica que seguimos en las distintas reuniones de scrum y de como aplicamos las tenicas de XP.