viernes, 6 de marzo de 2020

Scrum: Incremento de Producto



En el Manifiesto por el Desarrollo Ágil de Software, hoy más conocido como el Manifiesto Ágil, hay 4 valores y 12 principios, uno de los cuales dice:
El software funcionando es la medida principal de progreso.
En Scrum, ese principio está representado por el Product Increment. Es importante notar que Scrum ya no habla de software, pero la definición del incremento en la Scrum Guide dice (mi traducción):
El incremento es la suma de todos los ítems del Product Backlog completados durante un Sprint y el valor de los incrementos de todos los previos. Al final del Sprint, el nuevo incremento debe estar "Terminado", lo que significa que debe estar en condición de ser utilizado y cumplir con la definición de "Terminado" del Equipo Scrum.
Podríamos decir que en Scrum, la principal medida de progreso es el Incremento de Producto funcionando.
Este incremento es entonces, una versión actualizada y funcionando del producto que se entrega al final del Sprint (agregando valor sobre los incrementos previos).

El Product Owner es quien tiene la responsabilidad de decidir si ese incremento se libera al mercado (se pasa a producción, se pone en marcha o su equivalente de acuerdo al tipo de producto), más allá de que sea usable.

Que el Incremento deba estar "terminado" significa que debe poder ser liberado sin trabajo adicional del Scrum Team.

Atención 
La Guía Scrum no especifica qué sucede con esfuerzo adicional fuera del equipo para entregar el producto a su público objetivo. Por ejemplo, en muchas organizaciones el equipo entrega un producto de software terminado, pero para pasarlo a producción el esfuerzo de otras áreas puede ser enorme. La comunidad ágil alienta a trabajar en reducir esa brecha, por ejemplo, a través de prácticas de DevOps (que NO es un rol ni un área, sino un estilo de colaboración entre desarrollo y operaciones).

La Definición de Terminado

La DoD (del original en inglés, Definition of Done) es creada por el Scrum Team com una manera de evaluar si su trabajo en un ítem del Product Backlog ó en el Incremento está completo.
Definición de Terminado
El objetivo de esta definición es brindar transparencia sobre el nivel de calidad que se considera suficiente para entregar el Incremento de Producto.

La definición es dinámica, y a través de los Sprints será inspeccionada y adaptada, en colaboración entre el Scrum Team y los Stakeholders.

Es importante que el Development Team tenga esta definición en cuenta a la hora de determinar cuánto comprometer durante la Sprint Planning. Una buena Definición de Terminado balancea el nivel de calidad esperado con el esfuerzo requerido.

Es común que la definición varíe mucho entre diferentes equipos, ya que depende mucho del tipo de producto, el contexto y la madurez en diferentes aspectos.

Cuando múltiples equipos trabajan sobre el mismo producto, usualmente colaboran para tener una Definición de Terminado mínima, compartida por todos, sobre la que cada equipo puede agregar sus propias condiciones.

Tips

En mi experiencia, es preferible comenzar con una definición humilde pero alcanzable, y trabajar con el Scrum Team en seleccionar qué prácticas pueden elevar el nivel de calidad del producto, priorizándolas. Es usual que esas prácticas tengan una curva de aprendizaje, que hace que el equipo deba inicialmente invertir más esfuerzo en cada ítem.

La buena noticia es que las prácticas de calidad, una vez que tienen impacto, ahorran esfuerzo en la medida en que el producto se vuelve más estable y el equipo las incorpora como propias. En el momento en que el equipo ya está acostumbrado a esa nueva práctica, puede agregar la condición correspondiente como parte de la Definición de Terminado, y comenzar con la adopción de la próxima práctica de calidad que sea más prioritaria.

Para ayudar a pensar en posibles ítems de la Definición de Terminado de un equipo, en Kleer creamos una guía ágil y las DoD Cards,  con ejemplos y sugerencias.

DoD Cards

jueves, 5 de marzo de 2020

Scrum: Sprint Backlog

El Sprint Backlog es el subconjunto de ítems que un equipo "toma" del Product Backlog como compromiso de trabajo para un Sprint, con algunos agregados.
Sprint Backlog
Esta selección de ítems se realiza durante la Sprint Planning, y los agregados que el equipo hace representan la estrategia para cumplir con esos ítems y alcanzar el Objetivo del Sprint y entregar el Incremento de Producto.

La Guía de Scrum no entra en detalle específico de esa estrategia, pero en muchos casos se trata de una desagregación de tareas para cada ítem, de acuerdo a diversas perspectivas como componentes, especialidades, áreas de trabajo, u otras que el equipo determine.

Es recomendable tener en cuenta que aunque cada ítem se descomponga en tareas, el equipo tiene como objetivo principal lograr ítems completos, que ayuden a alcanzar el objetivo, y tiene que evitar caer en la trampa de dedicarse a completar tareas en cualquier orden, según la especialidad de cada uno, sino en colaborar activamente para terminar ítems, respetando el orden de prioridad original.

El Sprint Backlog usualmente se hace visible a través del uso de un tablero, físico o electrónico, y es importante que esté disponible para todos los interesados y permita ver claramente el estado de cada ítem, de manera transparente.

También es recomendable que junto a los ítems del Sprint Backlog, el tablero mantenga altamente visible al menos un elemento de mejora decidido en la última retrospectiva.

Es común que el equipo modifique y complete detalles del Sprint Backlog a medida que avanza en el Sprint, posiblemente como resultado de la Daily Scrum. Todo ajuste tiene por objetivo mejorar las posibilidades de alcanzar el Objetivo del Sprint.


El Development Team es el único que puede alterar el Sprint Backlog, agregando, actualizando o removiendo detalles. El resto del Scrum Team y los Stakeholders sólo tienen acceso a éste para ver el estado de avance, sobre el que pueden pedir más detalles al equipo. En mi opinión no es bueno tomar el estado de actualización del Sprint Backlog como única fuente de información, sobre todo en caso de notar algo fuera de ciertas expectativas. En un ambiente colaborativo como el de Scrum, la comunicación cara a cara siempre brinda detalles que nos dan una visión más clara de las cosas.

miércoles, 4 de marzo de 2020

Scrum: Product Backlog

Para poder desarrollar un producto con Scrum, un equipo necesita tener un Product Backlog.

Product Backlog

Se trata de una lista priorizada de todo lo que el producto debe tener, y representa el entendimiento actual del alcance del producto. Como el Product Backlog es dinámico, a medida que se descubran nuevas características, su contenido irá evolucionando.

Esa evolución se da a través de los Sprints, a medida que:
  • Se pasan ítems al Sprint Backlog, durante la Planning.
  • Se agregan nuevos ítems que sean valiosos para el producto
  • Se eliminen ítems cuyo valor ya no es relevante
  • Se descompongan ítems grandes en otros más pequeños
  • Se cambian las prioridades de los ítems, al reconsiderar su valor actual
Una idea central es que el Product Backlog es la única fuente de trabajo relativa al producto para el equipo. Sus ítems contienen todas las características, funcionalidades, mejoras, correcciones o extensiones que el producto necesite, y por lo tanto, todas se priorizan en conjunto, para ser desarrolladas por el mismo equipo ó equipos de producto.

Cuando un producto es muy grande, el esfuerzo puede distribuirse entre más de un equipo, con un único Product Backlog (y un único Product Owner), que representa la prioridad actual para el producto completo, en vez de prioridades parciales por componentes o áreas.

El Product Owner es el responsable por su contenido, visibilidad y priorización.

El Product Backlog sirve para responder a la pregunta "¿qué es lo próximo a desarrollar?" y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.

Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.

Refinamiento del Product Backlog

Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:

  • Con su valor establecido (y ordenados en consecuencia)
  • Divididos en los ítems más pequeño posibles
  • Estimados (el equipo debe saber al menos que puede desarrollar varios en un Sprint)
  • Detallados (suficiente como para que nada se bloquee en la Planning)
Los ítems que tienen menor prioridad (aún lejos de ser considerados en un Sprint o dos) pueden tener menos nivel de detalle, y aún no estar divididos en partes más pequeñas. Casualmente en Scrum diferimos estratégicamente esa tarea, para:
  • Aprovechar todo el aprendizaje previo al momento de analizar un ítem, sobre todo el ver el incremento más reciente del producto, lo que influye muchísimo sobre próximas decisiones.
  • Evitar analizar ítems que pueden variar (o desaparecer)
La actividad de agregar estos detalles al Product Backlog  no es un "evento" sino una tarea permanente del Product Owner, llamada Product Backlog Refinement, que realiza colaborativamente junto a los Stakeholders y resto del Scrum Team.

Product Backlog Refinement

La recomendación de involucramiento del Development Team en esta actividad es que no exceda el 10% del tiempo disponible del Sprint, pero eso es usualmente bastante tiempo.

Más allá de esa recomendación no hay ningún proceso ni límite de tiempo establecido, y cada equipo Scrum decide y mejora continuamente cómo realiza el refinamiento.

Es importante entender que los ítems que se refinan durante un Sprint no son los que ya están en el Sprint Backlog (y por ende, durante la Planning, se fueron del Product Backlog), sino los que siguen en prioridad, y pueden ser incluidos en el próximo Sprint (y un poco más, ya que no se puede predecir con exactitud lo que sucederá en la siguiente Planning).

También es importante, en mi opinión, que las actividades de Refinamiento no se conviertan en una Planning anticipada. Si se baja a demasiado detalle, sobre todo con el Development Team, estaríamos causando una sobrecarga cognitiva, ya que están trabajando en una serie de ítems (el Sprint Backlog actual) y no queremos distraerlos con detalles que pueden quedar para la Planning, cuando ya están liberados y listos para comenzar otro ciclo.