Monday, 27 March 2017

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).

Monday, 20 March 2017

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.

Sunday, 12 March 2017

El equipo de trabajo Scrum

En un proyecto gestionado con Scrum el equipo de trabajo estará formado por tres perfiles: el Dueño del Producto (Product Owner), el Scrum Master y el Equipo de Desarrollo (Development Team).

Ninguno de esos perfiles es el de jefe de proyectos o rol similar ya que estos equipos Scrum son autoorganizados. Esto quiere decir que ellos mismos deciden cómo llevar a cabo el trabajo y se reparten las tareas ¿Quién mejor que el Dueño del Producto para saber lo que hay que hacer y lo que se quiere conseguir? ¿Y quién mejor que el Equipo de Desarrollo para saber cómo hay que las tareas? Ellos dividirán las funcionalidades en tareas más pequeñas, las priorizarán y se las asignarán a si mismos. Ellos mismos se organizan el trabajo cada dos o tres semanas, lo que dure el Sprint.

Los equipos de trabajo también son multifuncionales. Esto significa que dentro del mismo equipo de trabajo encontraremos todos los perfiles necesarios para hacer el trabajo. Si hay que analizar algo lo hará algún miembro del equipo de trabajo. Si hay que realizar una tarea de administración de base de datos lo hará algún otro miembro del equipo (como en DevOps).

Por ejemplo, si necesitamos que se realicen frecuentemente este tipo de tareas de base de datos en el trabajo diario tendremos que contar con alguien con formación de DBA en el equipo. De esta forma el equipo de trabajo puede también autoorganizarse al no depender de otro departamento que tendrá sus propias prioridades y por el que habría que esperar a que realice la tarea. Mientras espera el equipo de desarrollo tendría que dedicarse a otras cosas, quizás menos importantes, hasta que se lleve a cabo la tarea por otro departamento o área de negocio.

Este modelo de equipos de trabajo de Scrum mejora la flexibilidad y la productividad al no estar tan encorsetado y tener un equipo más creativo e independiente.

Al realizar entregas iterativas e incrementales, es decir, realizar una entrega del producto cada vez mayor al finalizar cada Sprint, el equipo de trabajo obtiene feedback de la opinión de los usuarios y los interesados de forma frecuente. Este feedback le permitirá priorizar las próximas tareas y corregir la línea a seguir si es necesario. Estas entregas incrementales son de producto "Terminado" y probado. De esta forma siempre hay disponible una versión plenamente funcional del producto lista para ser usada.

Sunday, 5 March 2017

Teoría de Scrum

Scrum es un marco de trabajo basado en el control de procesos empírico y por tanto no basado en predicciones o suposiciones. Esto quiere decir que el conocimiento procede de la experiencia, la observación de los hechos y de tomar decisiones basándose en lo que se conoce. Las decisiones se toman en base a los resultados que se están viendo en el proyecto y no en base a planificaciones a largo plazo y a fechas de entrega supuestas al principio del proyecto.

Si en un proyecto tenemos que decidir si eliminamos o no una característica nueva de un producto o si es necesario dedicar más esfuerzo al desarrollo de una parte del proyecto para llegar a cumplir los límites establecidos, esta decisión la tomaremos basándonos en los datos sobre el esfuerzo que ya nos ha costado construir esta característica o similares o en los datos reales del tiempo que nos ha llevado construir las tareas ya realizadas. No nos basamos en un diagrama de Gantt con la predicción realizada al inicio del proyecto con lo que supuestamente iba a costarnos realizar estas tareas y con los límites que tenemos para cumplir la planificación, sean estos ya reales o no.

Todos los proyectos intentarán ser lo más previsibles posible y predecir cuando estarán acabadas las cosas pero, si con el objetivo de mejorar la previsibilidad usamos diagramas de Gantt, estimaciones y fechas de entrega a largo plazo con la información que teníamos al empezar el proyecto, podríamos estar teniendo el efecto contrario y volver al proyecto más imprevisible de lo que debería.

Si en lugar de trabajar y trabajar para que los planes sean exactos, asumimos que esos planes pueden estar equivocados y que son sólo eso, planes, podemos tomar las decisiones basándonos en los datos reales que vamos conociendo del proyecto para intentar ser lo más previsibles posible con los que tenemos actualmente.

Para mejorar la predictibilidad del proyecto y poder prever más fácilmente cuando vamos a acabar un conjunto de tareas o todo el proyecto, Scrum se basa en tres pilares:

Transparencia

Scrum entrega de forma iterativa pequeños incrementos del producto de forma que va añadiendo nuevas funcionalidades o características al producto final. La lista de cosas pendientes de terminar es pública, la lista de cosas terminadas y su estado es pública también. Se comparte además un lenguaje común entre todos los participantes en el proyectos de forma que sea claro y transparente para todo el mundo en qué estado está todo.

Cuando se dice que algo está 'terminado' debe significar lo mismo para todo el mundo y que no se barren dejabo de la alfombra con tal de hacer una marca en su casillero funcionalidades hechas pero que no han sido lo suficientemente probadas o no son prácticas. Las cosas están en estado 'Hecho' o 'Terminado' de forma transparente para todo los usuarios de Scrum sin ocultar nada a ninguno. Por eso se habla de tener una definición de 'Hecho' o de cuando algo puede decirse que está terminado.

Inspección

Otro pilar básico de Scrum, lo que se ha entregado y el estado en el que están las cosas se puede inspeccionar por los interesados en el proyecto o el dueño del producto (Product Owner) de forma que compruebe que está en perfecto funcionamiento y que el estado es real. Esto se hace en parte con la reunión de demo, con la transparencia de los entregables que se entregan de forma iterativa para que puedan ser probados y con las revisiones de lo que queda por hacer.  Estas revisiones no deben realizarse de forma tan frecuente que la inspección ralentice el trabajo.

Adaptación

Si en las revisiones de la inspección se comprueba que el producto, el plazo para construir o la nueva característica que se está construyendo se desvían de límites aceptables, o que el producto resultante no será aprobado, deben hacerse cambios para intentar volver a límites dentro de lo aceptable. Estos ajustes deberán hacerse cuanto antes para evitar mayores desviaciones sobre lo que quede por realizar.

Adaptaciones o ajustes como estos son los que hacen que Scrum no sea predecible y no puedan darse largos plazos de predicción porque siempre se está adaptando el producto para mejorarlo y evitar mayores desviaciones sobre el producto ideal con el presupuesto que tenemos.

Para poder realizar estas inspecciones y sus correspondientes adaptaciones Scrum prescribe cuatro eventos o sucesos dentro de cada Sprint. Estos eventos son descritos con más detalle en otros post de este blog:
  • Reunión de Planificación del Sprint (Sprint Planning Meeting)
  • Scrum Diario (Daily Scrum)
  • Revisión del Sprint (Sprint Review)
  • Retrospectiva del Sprint (Sprint Retrospective)