Ajedrez - antoniomartel.com

Archivos por Etiqueta: teoría

Transparencia en Scrum

Como dice la guía de Scrum, Scrum se basa en la transparencia. La lista del producto o la lista del Sprint debe ser conocida por todos los miembros del equipo de trabajo y los interesados. Todos deben saber qué está pasando en el proyecto y por qué para poder tomar las decisiones más correctas.

Si Scrum se basa en la transparencia, la transparencia es también la base de la confianza. Si no conocemos el estado de las cosas, se oculta información al dueño del producto que no sabe si las cosas están correctamente terminadas o no, en qué estado está su producto o si es tan robusto como le están diciendo, terminará fallando la confianza en el proyecto y en las personas. Puede que el proyecto se cancele, que deje de haber flexibilidad cuando algo ha fallado y que perdamos toda credibilidad. El proyecto pasará a ser una marcha tortuosa hasta el final del mismo.

Para esto están las listas del producto, para decirnos cuántas cosas quedan por hacer en el proyecto, las listas del sprint, para que veamos qué estamos haciendo justo ahora y las reuniones de demo, para que el cliente pueda ver el resultado de las últimas semanas de trabajo y el producto por el que está pagando. Esta transparencia, si no la falseamos ni ocultamos la verdad será de gran valor en el proyecto.

A veces, por temor a llevarnos una reprimenda o evitar el enfado del cliente, del dueño del producto o del propio Scrum Master tendemos a ocultar la verdad convirtiendo la transparencia en una palabra hueca carente de todo sentido. Si una funcionalidad falla en ocasiones pero no se ve en la demo es mejor decirlo y explicar que queda este problema atrás. Si no hemos podido tener a todo el equipo de trabajo al 100% en el proyecto, es mejor decirlo también y que no falle la confianza. La transparencia será una gran aliada cuando las cosas pinten mal y necesitemos de la confianza de todos en que el proyecto saldrá bien.

La lista del sprint o Sprint backlog

La lista del sprint es la lista de elementos que hemos escogido para realizar durante el sprint actual. El equipo de desarrollo habrá seleccionado de entre los elementos de la lista de todo el producto un subconjunto de historias de usuario o tareas que cree que puede terminar en este sprint.

La diferencia con la lista del producto es que esa es la lista de todas las cosas previstas a hacer e incorporar a nuestro producto o aplicación, en cambio, la lista del sprint es sólo la lista de cosas que el equipo de desarrollo se compromete a tener terminadas en este sprint. Normalmente, en la lista del producto tendremos historias de usuario o una descripción de las funcionalidades a realizar y en la lista del sprint tendremos una descomposición de esas historias de usuario en tareas que pueden realizarse en un máximo de dos días y en un mínimo de dos horas.

Para el sprint podríamos haber escogido dos historias de usuario como las que pueden verse en el siguiente ejemplo que para la pila del sprint habremos descompuesto en tareas más pequeñas y abordables:

Historias de usuario y tareas para la lista del sprint

A veces el equipo de trabajo se ha comprometido a demasiadas cosas para el sprint o a demasiado pocas por lo que terminan antes. En esos casos el equipo se comprometerá a hacer más o tendrá que quitar elementos de la lista si no pueden terminar con todos.

Cuantas tareas debe acometer un equipo por sprint

No hay una única respuesta para esto. Podemos estimar en horas cuanto nos llevará cada tarea y calcular cuantas de ellas podemos acometer en las semanas que tengamos de sprint. Podemos también ver cuál ha sido la velocidad (número de tareas y horas estimadas resueltas) que hemos tenido en sprints anteriores para calcular cuantos puntos u horas podemos terminar en este sprint. Hay incluso quien no hace estimaciones (no-estimates movement) en horas de cada tarea sino que hace un cálculo rápido de cuantas tareas puede completar en el sprint y si le cabe alguna tarea más o no.

En mi caso particular, yo no le pido al equipo una estimación en horas de cada una de las tarjetas que acometemos sino que les pregunto por cuántas y cuáles de esas tarjetas podríamos tener terminadas en el sprint. Tenerlas terminadas en el sprint no significa estar trabajando hasta el último día en desarrollar hasta la última tarea sino que paramos nuevos desarrollos 3 días antes de la reunión de demo para hacer un despliegue en desarrollo de lo que tengamos en ese momento. A partir de ahí comenzamos todos los miembros del equipo a probar cada una de las tareas y a subir nuevas versiones con las correcciones que hayamos hecho hasta tener una versión en el entorno de demo que podamos mostrar en la reunión de revisión del sprint el último día del mismo.

Seguimiento del progreso en Scrum

Existen varias formas de medir el progreso del trabajo total hasta acabar el proyecto. Al menos una vez por sprint el dueño del producto mide cuánto ha sido trabajo que se ha terminado y cuanto queda para acabar el proyecto y lo anota.

Esta forma de contar el trabajo restante para acabar el proyecto se le llama Burndown y si se pinta en una gráfica será la llamada gráfica de Burndown. Se le llama así porque se va anotando la cantidad de trabajo que queda pendiente en lugar de la cantidad de trabajo o puntos que vamos sumando al realizar más trabajo. El trabajo va disminuyendo o quemándose hasta llegar a 0 horas o puntos de trabajo pendiente, momento en el cuál toca suelo en el eje horizontal.

La línea roja en esta imagen de ejemplo es la línea del plan inicial en la que acabaríamos el proyecto en 9 sprints si en cada sprint acabamos el mismo número de puntos. La línea azul en cambio muestra la línea real que lleva nuestro proyecto. Como vamos algo más lentos sumamos menos puntos que la planificación inicial por lo que nuestra línea lleva menos pendiente de lo que quisiéramos y acabará en el sprint 12 o 13 si no mejora y avanzamos más rápidos.

En cada sprint el dueño del producto seguirá anotando la suma de puntos estimados para las tarjetas que nos quedan pendientes. Si en próximos sprints logramos terminar muchas tarjetas o historias de usuario quedarán menos puntos restantes y la gráfica tendrá una mayor pendiente hacia el cero, señal de que vamos más rápidos.

En muchos proyectos se lleva una actualización de esta gráfica día a día, revisando cada día lo que se ha terminado para restárselo al trabajo pendiente. Yo encuentro esto un poco complicado de mantener y en mi trabajo suelo llevar una única gráfica para todo el proyecto y no una gráfica por cada sprint, de forma que pongo en el eje horizontal los sprints que me está llevando el proyecto y no los días transcurridos en el sprint. Cuando llevo unos cuantos sprints puedo ver la pendiente media que tiene mi gráfica lo que me permite calcular en qué sprint aproximadamente va a tocar suelo la gráfica y acabaremos por tanto el proyecto.

La Lista del Producto o Product Backlog

La Lista o Pila del Producto es una lista ordenada por prioridad de todas las funcionalidades que pueden ser necesarias para incorporar al producto. Tendremos ahí todos los requisitos del proyecto y de esa lista tomaremos un subconjunto para los requisitos que implementaremos en un Sprint. Ese subconjunto de tareas es la que compondrá la Lista del Sprint.

El Dueño del Producto, que es quién paga o quien representa a quien paga el producto, es quién conoce lo que quiere para su producto y quién, por tanto, nos dirá lo que hay que hacer. El definirá los requisitos del proyecto por lo que es él el responsable del contenido de la Lista del Producto y de su priorización.

La Lista del Producto no tiene que estar completa desde el principio, de hecho, nunca está completa. Más requisitos pueden ir llegando a medida que se va avanzando en el proyecto. Al principio sólo contendrá los requisitos conocidos y que están más claros o mejor entendidos.

Si nuestro proyecto proviene de un contrato con nuestro cliente en el que ya se definen las funcionalidades que tendrá el producto podremos comenzar con estas funcionalidades como germen de nuestra Lista del Producto. Pero no de sólo funcionalidades viven los proyectos, hay muchas otras tareas que deberemos realizar y que también van en la Pila del Producto. Tareas como estas compondrán nuestra lista:

  • Funcionalidades o características del software, por ejemplo: Permitir pago con Paypal
  • Bugs: Corregir error de certificado no autorizado al acceder a la aplicación
  • Trabajo técnico: Instalar la base de datos o Preparar los entornos de desarrollo y pruebas con Docker
  • Adquisición de información: Tomar requisitos más detallados sobre cómo se debe recoger la información de los clientes que pagan a crédito.
La forma habitual en la que se expresan los requisitos en cada una de las tarjetas o elementos que componen la Lista del Producto es como historias de usuario que son descripciones breves del requerimiento. Por ejemplo: «Cómo usuario de la banca online, quiero poder ver una lista de las transferencias periódicas que ya tengo creadas para poder revisarlas antes de crear una nueva«.

Cada poco tiempo y de forma continua el equipo de trabajo deberá acometer una revisión de estas tarjetas o historias de usuario de la Pila del producto para añadirles el detalle suficiente para poder comenzar a trabajar. Esta tarea de revisión se llama Refinamiento (refinement). Podemos tener una tarjeta que diga «Permitir el pago con Paypal» pero no podemos pasar esto así a los desarrolladores, deberemos analizar esto un poco más para añadir «Cuando un cliente está en el sitio web, quiero tener la opción de pagar con PayPal después de haber establecido el pedido, de forma que pueda confirmar la compra«.

Pero aún así, cuando lleguemos al Sprint en el que queramos acometer este trabajo, deberemos de tener esta historia de usuario descompuesta en otras más pequeñas:

  • «Como usuario de la banca online, quiero tener un enlace a registrarme como usuario de PayPal después de haber realizado el pedido«
  • «Como usuario de la banca online, quiero poder introducir mi número de tarjeta, fecha de caducidad y número CCD para identificar mi tarjeta después de haberme registrado como usuario de PayPal«
  • «Como usuario de la banca online, quiero poder hacer clic en un botón ‘Pagar con Paypal’ debajo del subtotal de mi compra para poder confirmar mi pedido«

Los elementos de la Lista del Producto de prioridad más alta estarán normalmente más detallados y más refinados mientas que los de prioridad más baja tienen un nivel de detalle más bajo y son más vagos en su descripción. Debemos trabajar más en el refinamiento de las funcionalidades de más alto nivel que son las que van a ser acometidas en los próximos sprints y evitar dar un detalle muy alto en tarjetas de muy baja prioridad que no sabemos si van a ser acometidas o si tenemos ya toda la información que necesitamos para acometerlas.

Será el equipo de trabajo el que se encargue de proporcionar una estimación para los elementos de la Lista del Producto ya que son quienes van a hacer el trabajo y quienes se están comprometiendo a tenerlo terminado para el final del Sprint. No será necesario que estimen todos los elementos de la Pila del Producto de una sola tacada sino que estimen los que se van a acometer ahora. De este modo tendremos estimaciones más precisas porque los elementos de la lista están más claros y detallados y evitamos perder el tiempo estimando elementos muy abajo en la lista para los que no tenemos suficiente información y que puede que ni siquiera se lleven a cabo.

Retrospectiva del sprint

Esta reunión se realiza después de la reunión de demo con el cliente y tiene una duración de tres horas para sprints de un mes. Se trata de una reunión en la que queremos que el equipo Scrum se revise a si mismo y dé feedback de cómo han ido las cosas, por qué no pudieron conseguirse todos los objetivos del sprint, si fue así, y qué podemos hacer para mejorar en el siguiente sprint.

A esta reunión asistirán el Dueño del Producto, el Scrum Master y el equipo de desarrollo. El Scrum Master como siempre se encargará de que la reunión tenga lugar. de que se mantenga dentro de los tiempos máximos definidos y que se traten al menos los siguientes aspectos en la reunión:

  • Qué cosas han funcionado bien
  • Qué cosas no han funcionado tan bien y evitaron que pudiéramos demostrar al cliente todo lo que se esperaba de este sprint que acaba de terminar
  • Qué problemas han impedido o pueden impedir que no consigamos nuestra meta del sprint y que el cliente por tanto no obtenga lo esperado. El Scrum Master se encargará de anotarlas para luego ponerse a resolverlas.

De esta reunión de retrospectiva debería salir un plan, ordenado por prioridad, con las distintas mejoras que podrían implementarse para evitar los problemas detectados.

Existen diversas causas por las que las reuniones de retrospectiva resultan poco provechosas o no todo lo útiles que deberían:

Las reuniones son aburridas y monótonas

La gente puede perder la confianza en las retrospectivas y verlas como una perdida de tiempo si no se toma ninguna acción después de analizados los problemas que se están teniendo. Se están identificando los problemas y se están declarando pero no se hace nada al respecto o tarda mucho en tomarse consciencia de lo que están suponiendo. Debemos tomar buena nota de cada una de las mejoras propuestas y de los impedimentos que están impidiendo avanzar y hacer algo con ellos. Tener una reunión de retrospectiva para luego no tomar ninguna medida va a hacer que se pierda la fe en estas reuniones.

La gente tiene miedo de las retrospectivas

Miembros del equipo de desarrollo pueden sentirse temerosos de comentar los problemas reales que están viendo y sólo dicen vaguedades o pequeños impedimentos pero no la causa que ellos ven como la más importante y por la que no se consiguen los objetivos del sprint. Quizás por temor a herir los sentimientos del Scrum Master o del Dueño del Producto si no están haciendo bien su trabajo, quizás por no molestar al analista que no recoge bien los requerimientos, quizás por temor a ser represaliados si son demasiado directos con lo que se piensa.

Recordemos que la reunión de retrospectiva no es una reunión formal en la que buscar culpables a lo que está pasando. Debe crearse un ambiente en el que todos deben sentirse libres de dar su opinión sin temor a que alguien se moleste. Se trata de una reunión para aprender no para echar las culpas. De ella deberemos salir con un listado de mejoras y no de nombres. Es bueno recordar estos puntos antes de comenzar cada reunión si comenzamos a pensar que el equipo de trabajo no se siente libre para decir lo que piensa.

Suscríbete

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad