Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

El Scrum Master y el Product Owner

El rol de Scrum Master en un equipo Scrum no es el de jefe de proyecto como suele suponerse equivocadamente. Es más bien el de un guía que ayuda a todos a entender cómo funciona Scrum y que intentan asegurar que las prácticas de Scrum son bien entendidas y funcionan de la mejor forma posible.

El Scrum Master ayudará a los Interesados y a otras personas fuera del equipo Scrum a entender cuáles con las mejores formas de interaccionar con el Equipo Scrum, por ejemplo, si un Interesado tienen una solicitud de mejora que hacer, el Scrum Master deberá hacerle saber que es mejor si se la comunica al Product Owner para que este la meta en la pila de trabajo y la priorice si así lo cree necesario.

El Scrum Master es un líder al servicio del Equipo Scrum. En concreto, el trabajo que realizará el Scrum Master para el Product Owner será:

  • Ayudarle a gestionar la Pila del Producto de manera efectiva, por ejemplo, facilitándole herramientas para gestionar los elementos de la pila (MS Excel, Trello, JIRA, etc.) o indicándole cómo y cuando debe priorizar entre las tareas.
  • Explicarle cuando debe entrar en más detalle en ellas para que el Equipo de Desarrollo las pueda entender correctamente con especificaciones claras y concisas.
  • Ayudarle a entender las estimaciones empíricas que haga el Equipo de Desarrollo, es decir las basadas en datos reales y experiencias pasadas y no sólo en predicciones.
  • Asegurarse de que el Dueño del Producto sabe cómo priorizar las tareas y funcionalidades a realizar basándose en el Retorno de Inversión y en el coste que tienen. Es decir si una funcionalidad tiene un coste o tiempo de realización de 5 y un valor para la organización de 8 quizás convendría hacerla después de una funcionalidad de coste 2 y valor 6 porque conseguiríamos un valor similar para la organización (6) en menos de la mitad de tiempo, tan sólo 2 (y la organización la disfrutaría antes también).
  • Entender y practicar la agilidad, es decir, explicarle las principios ágiles que hay detrás de Scrum como los del manifiesto ágil. Algunos de ellos son: Nuestra mayor prioridad es la de satisfacer al cliente, Aceptamos que los requisitos cambien, Entregamos software funcional frecuentemente entre dos semanas y dos meses, Los responsables de desarrollo y el equipo de desarrollo colaboran juntos estrechamente durante todo el proyecto, etc.
  • Facilitar los eventos Scrum según se requiera: Organizarlos, reservar las salas, convocar las reuniones, llevar los artefactos que sean necesarios, comunicar el orden del día y los puntos de la reunión, etc.
Estos son los servicios que el Scrum Master presta al Product Owner, en próximos posts explicaré los servicios que el Scrum Master presta al equipo de desarrollo y a la organización en su conjunto.

El tamaño del Equipo de Desarrollo

Lo que nos indica la guía de Scrum como mejor tamaño del Equipo de Desarrollo (no el Equipo de Trabajo, sólo el Equipo de Desarrollo, es decir, sin contar con Scrum Master y Product Owner) es de tres miembros cuando menos y nueve como tamaño máximo.

La idea es tener un equipo lo suficientemente pequeño para ser ágil pero que puedan entregar al final de cada Sprint una cantidad de trabajo que merezca la pena como para ponerlo en producción. En cambio no se quiere que tenga un tamaño tan grande, mayor de 9, que haga que se multipliquen las interacciones en el equipo y que haga difícil la coordinación entre ellos.

¿Para un Equipo de Desarrollo de sólo una o dos personas merece la pena Scrum? Estaríamos añadiendo un overhead o sobrecarga de reuniones y ceremonias que podría dificultar la normal marcha del trabajo haciendo perder tiempo al equipo. En mi caso personal, para equipos de estos tamaños aún así he intentando ser ágil siguiendo sólo cuatro principios básicos de Scrum para obtener el máximo de sus ventajas sin sobrecargar de reuniones que podrían ser inútiles al ser tan pequeños. Por ejemplo, mantener la reunión diaria, la reunión de demo, el Sprint y las Pilas de Producto y de Sprint.

En cambio, yendo hacia el lado contrario, tener 10, 11, 12 o más miembros en un Equipo de Desarrollo podría requerir demasiada coordinación y demasiadas reuniones para ponerse de acuerdo entre todos. Si se van a auto-organizar ese tamaño va a llevar demasiada complejidad como para repartirse tareas y coordinarse sin que haya un seguimiento estricto de qué hace cada uno o las dependencias entre el trabajo entre unos y otros y qué tiene que estar listo primero para que el otro pueda avanzar.

El Dueño del Producto y el Scrum Master no cuentan como miembros del equipo de desarrollo a menos que también estén trabajando en la lista de cosas pendientes a acabar dentro del Sprint. En ese caso sí son contados como miembros del Equipo de Desarrollo sumando una o dos personas más según sea el caso.

Hay estrategias para el escalado de Scrum (estrategias para cuando el proyecto es tan grande que un sólo equipo no puede con todo) como DAD (Disciplined Agile Delivery) que no son tan estrictos con los tamaños de los equipos y no prescriben unos tamaños límites mínimo o máximo tan cerrados como estos.

El Equipo de Desarrollo

Son las personas que trabajan en el producto durante el Sprint para entregar una versión Terminada al final del mismo. Deben trabajar para que esa versión lista al final de cada Sprint pueda ser subida a producción. No quiere decir que al final de cada Sprint haya que subir obligatoriamente una nueva versión sino que está lista, probada y preparada (Terminada) para que potencialmente pueda ser desplegada en producción si alguien así lo decidiese. Son los miembros del Equipo de Desarrollo los que trabajan en la creación de esa nueva versión o Incremento del producto que se prepara cada Sprint.

Los Equipos de Desarrollo se estructura y organizan de tal forma que puedan gestionar su propio trabajo. Para conseguir esto los equipos de desarrollo deben cumplir estas características:

  • Son autoorganizados: Ellos mismos se asignan las tareas según su conocimiento y la preparación o la disponibilidad que tenga cada uno. No es el Scrum Master ni el Product Owner quién reparte las tareas, ni les indican cómo deben hacer su trabajo. Son ellos los profesionales que trabajan en esto y quienes mejor conocen cómo hacer las cosas para terminar el Sprint con una versión que podría ser subida a producción.
  • Son multifuncionales: Esto suele causar confusión con frecuencia. Equipos multifuncionales son aquellos en los que se pueden encontrar en su interior a miembros del equipo con todas las habilidades necesarias para trabajar en la nueva versión, es decir, que tendremos dentro del equipo a alguien capaz de realizar análisis funcional si es necesario analizar algún aspecto en este Sprint y a alguien con conocimientos de DBA si es necesario realizar alguna tarea de administración de base de datos. Tener un equipo completamente multifuncional es una cosa difícil pero nos dará bastante ventaja a la hora de desarrollar ya que no habrá que asignar la tarea a otro departamento, que tendrá sus propias prioridades, para luego mantener a la espera todo el trabajo del Sprint hasta que este departamento pueda llevarla a cabo y entregarla.
  • No existen títulos dentro del Equipo de Desarrollo: Todos son desarrolladores, no existe un miembro que tiene el título de Analista y por tanto sólo desarrolla esas tareas. Lo mismo para el Tester y sólo él o ella testean, podrían hacerlo todos aunque haya miembros del equipo que por sus habilidades y conocimientos estén más especializados para hacer algún tipo de tareas sobre otras pero la responsabilidad cae dentro de todo el Equipo de Desarrollo.
  • No hay sub-equipos dentro de los Equipos de Desarrollo: Esto quiere decir que no hay un sub-equipo de testers o de analistas que sólo se encargan de esto, tampoco los hay de dominios específicos dentro del producto, por ejemplo, no hay un sub-equipo que trabaje sólo con las funcionalidades que tienen que ver con la facturación y otro con las funcionalidades de control de almacén. Todos trabajan en todas las partes del producto.

Los Interesados

Los Stakeholders tienen un nombre bastante feo en su traducción al español para Scrum: Los Interesados. Se les llama así por que tienen algún interés en el producto que se está construyendo. Pueden que sean los dueños o accionistas de la empresa que está pagando por el desarrollo, el jefe del departamento de ventas que quiere un nuevo módulo para la facturación o simplemente los usuarios de la aplicación que se está desarrollando y que tienen particular interés (de ahí lo de Interesado) en que la aplicación o el producto (recordemos que Scrum no se usa sólo para el desarrollo de Software) funcione lo mejor posible.

Estos Interesados han nombrado a un Dueño del Producto para que los represente y a él deben dirigirse siempre que quieran alguna modificación, recordarle alguna prioridad o añadir nuevas características al producto. No deberían dirigirse directamente al equipo de desarrollo para explicarles lo importante que es que la nueva exportación a Excel esté incluida en la próxima versión que se lance. De priorizar estas cosas y darles el valor oportuno debe encargarse el Dueño del Producto. En él estarán centralizados todas las peticiones de cada Interesado.

El jefe de ventas está interesado en la integración de la facturación con los móviles, el jefe de almacén quiere un nuevo sistema de avisos cuando cae el stock, un usuario de administración quiere que los listados puedan exportarse a Excel con sólo un botón porque le ahorraría un montón de clics de ratón. Todos tienen interés en que el producto salga lo mejor posible pero alguien tiene que decidir qué se construye ahora. Los presupuestos tampoco son infinitos y hay algunas cosas a las que hay que decir ‘No, ahora no puede hacerse’ o simplemente ‘No’.

De esta gestión de los Interesados y sus intereses debe hacerse cargo el Dueño del Producto que tendrá que anotar o tener en cuenta cada solicitud y ver si es factible hacerse o no y si va a dar mayor valor al producto final construyendo eso antes que cualquier otra cosa.

Si el Equipo de Desarrollo está en una empresa externa habrá que gestionar también los cambios en la Lista de Producto y los nuevos requerimientos. Será necesario hacer caer de esa lista de cosas por hacer otras funcionalidades ya acordadas que ahora se estiman menos importantes pero que tendrían un coste de desarrollo similar, o bien aumentar el presupuesto (pero recordemos que los presupuestos no son infinitos).

El Dueño del Producto

El Dueño del Producto (Product Owner) es el responsable de gestionar la Lista o Pila del Producto (Product Backlog) con la lista de funcionalidades que deberá tener el producto. La gestión de esa Pila del Producto implica que es también el responsable de que el producto final tenga el mayor valor posible y para ello deberá obtener el máximo valor del trabajo del Equipo de Desarrollo.

Para gestionar esa Pila del Producto deberá:

  • Expresar claramente los elementos de la Lista para que queden claros para todos y que esa Lista muestre  en qué estará trabajando el equipo en los próximos Sprints.
  • Asegurarse de que el Equipo de desarrollo entiende los elementos de la Lista con el detalle suficiente. El Dueño del Producto conoce bien su producto y lo que se quiere conseguir con él, por tanto es el responsable de que cada funcionalidad a implementar está bien detallada y explicada para el Equipo de Desarrollo.
  • Ordenar los elementos de la Lista de Producto para obtener los objetivos que tiene el producto lo antes posible, priorizando para ello los de más valor para el producto en el mercado o en su organización.
  • Optimizar el valor del trabajo del Equipo de Desarrollo. Para ello deberá hacer que mediante la Pila del Producto debidamente ordenada y priorizada el Equipo de Desarrollo trabaje en las funcionalidades de más valor en cada momento, evitando trabajo redundante o inútil en tareas de poco valor añadido.

Es además la única persona responsable de gestionar esa Lista de Producto. Eso implica que puede estar representando a varias personas o a un comité de Interesados (Stakeholders) en el producto en la empresa cliente que nos contrata o de la propia empresa que desarrolla el producto pero es sólo el Dueño del Producto el único responsable de expresar, detallar, optimizar y priorizar la Pila del Producto. Los Interesados en el producto pueden querer cambiar la Lista, añadir nuevas funcionalidades o darles otra prioridad pero deberán hablar primero con el Dueño del Producto para expresarle sus deseos y sólo él podrá cambiarla.

El rol del Dueño del Producto es un rol fundamental en todo proyecto (se llame como se llame según la metodología) por lo que toda la organización que contrata el desarrollo del producto debe respetar sus decisiones. Él es quién decide qué va a hacerse con el producto y que funcionalidades tendrá por lo que tiene un peso muy grande en que el producto final sea un éxito o no.

No se permite acceder al Equipo de Desarrollo para pedirle que realice funcionalidades distintas a las indicadas en la Lista de Producto. El Equipo de Desarrollo deberá actuar siempre en función de lo que diga el Product Owner y no cualquier otro Interesado en el producto.

Suscríbete