Nexus: Introducción al framework de escalado de Scrum.

Qué es Nexus

Nexus según lo define su guía oficial es al igual que Scrum, un framework, con la diferencia de que está orientado al desarrollo y soporte de productos escalables y desarrollo software. El componente principal de este framework como no cabría esperar de otra manera es Scrum y también ha sido desarrollado por Ken Schwaber y la comunidad de Scrum.org.

A quién está orientado

Nexus está enfocado a integrar el trabajo de entre 3 y 9 equipos Scrum que trabajen sobre un mismo Product Backlog, siendo su principal finalidad la integración del trabajo de estos equipos al final de cada Sprint.

En qué consiste

  • Roles: se introduce un nuevo rol, el Equipo de Integración Nexus, que se encarga de coordinar, entrenar y supervisar la aplicación de Nexus y que está formado (al igual que Scrum) por un Product Owner, un Scrum Master y los Nexus Integration Team Members. Este equipo será el responsable principal de que se produzca un Incremento Integrado al final de cada Sprint.
  • Artefactos: todos los equipos Scrum utilizarán el mismo Product Backlog y se incorporará un nuevo artefacto, el Nexus Sprint Backlog a fin de que exista la mayor transparencia posible durante cada Sprint. A su vez cada equipo Scrum tendrá su propio Sprint Backlog.
  • Eventos: algunos eventos se adicionan a, se ubican alrededor de, o reemplazan a (en el caso de la Revisión del Sprint) los eventos regulares de Scrum para servirles de suplemento o para mejorarlos.

Objetivos y beneficios

– Detección de inter-dependencias y resolución de las mismas
– Aumenta de la transparencia
– Reducción de la deuda técnica
– Permite la auto-organización de un gran número de desarrolladores

En resumen

Nexus es un exoesqueleto que descansa sobre múltiples equipos Scrum cuando se combinan para crear un incremento integrado.

Dónde puedo encontrar más información

La guía del framework se encuentra publicada en la página de scrum.org donde podéis obtenerla en varios idiomas, además podréis encontrar algunos test “abiertos” para poner a prueba vuestro grado de entendimiento del framework.

Otros planteamientos para la adopción de Agile en grandes corporaciones

  • SAFe (Scaled Agile Framework). Iniciativa de Ivar Jacobson
  • LeSS (Large Scale Scrum). Iniciativa de Craig Larman
  • DAD (Disciplined Agile Delivery). Iniciativa de Scott Ambler

Scrum: User Stories Efectivas.

En este breve post revisaremos las pautas generales que se establecen para conseguir realizar/redactar User Stories efectivas:
  • Independiente: No debe depender de otra user story.
  • Negociable: Las user stories son simplemente descripciones de funcionalidades, que pueden cambiar en cualquier momento. En sí misma, una User Story no es lo suficientemente explícita como para considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación.
  • Valiosa para el Cliente o el Usuario: En muchos casos el criterio de valor es diferente para cliente que para el usuario, no obstante se debe conseguir que al menos para uno de los dos la historia sea valiosa.
  • Estimable: La funcionalidad que describe tiene que tener el suficiente detalle como para que un desarrollador pueda estimarla. Si una historia de usuario es demasiado grande para estimarse, deberá dividirse en otras User Stories (ver Epic User Stories) más pequeñas que faciliten esta labor. La función de estimar permite obtener la visión del “tiempo total” del proyecto.
  • Pequeña: Como ya hemos visto en los puntos anteriores, a mayor tamaño más compleja es la labor de estimación.
  • Testeable: Deben poder ser probadas para que los desarrolladores puedan asegurar que la funcionalidad está completa y se comporta correctamente.

Un consejo para que os acordéis mejor de esto, una sencilla regla nemotécnica I.N.V.E.S.T. (independent, negotiable, valuable, estimable, small, testeable).

Podéis encontrar más detalles al respecto en el libro de Mike Cohn: User Stories Applied For Agile Software Development.

Scrum: Epic User Story.

Cuando una User Story es demasiado grande, se dice que es una historia de usuario épica. Programar una user story de este tipo podría conllevar una duración superior a la establecida por scrum (más de un mes); la cuestión es que seguro que nos llevará más tiempo que la duración del máximo de un sprint por lo que va a resultar imposible estimarla. Por eso las user story épicas deben ser dividirlas.
Los criterios por los que podemos realizar esta división pueden ser:
  • Por datos: Pongamos el caso de un formulario web, podríamos comenzar construyendo el formulario por los campos mínimos obligatorios como Nombre, Teléfono y Email. De esta manera podríamos haber dividido la User Story en dos más pequeñas, una con los campos mencionados y otra que abordaríamos más adelante con los campos que falten.
  • Por casos especiales: Para este caso imaginemos por ejemplo los impuestos a los que pueden estar sujetos dos paises distintos, el IVA por ejemplo, podríamos considerar esto como un caso especial. Imaginad que tenemos un carrito de la compra y que en base al país que se seleccione se calculará un IVA u otro, podríamos utilizar esto para dividirlo en tantas user stories diferentes como países existan.
  • Por operaciones: Imaginad de una aplicación que o web que os permita realizar Alta y Modificación de un usuario, en este caso podríamos dividirlo en dos user stories diferentes.
  • Por temas cross no funcionales: Por ejemplo, podríamos empezar con una implementación que no maneje seguridad, log, manejo de errores… e irlos agregando en siguientes iteraciones.
  • Por prioridad: Imaginad el caso de un carrito de la compra, al finalizar la compra tendrémos distintas opciones: solicitar una factura, realizar el pago, imprimir el pedido… Como es lógico realizar el pago será imprescindible, pero solicitar una factura o imprimirla, quizás pueda realizarse más adelante. De esta manera estamos realizando las tareas por prioridad.
Lo que siempre hay que tener en cuenta a la hora de dividir una user story son los Minimum Marketable Features del producto o lo que es lo mismo, el conjunto de mínimas funcionalidades con la que el producto puede instalarse en producción.