Para ir más lejos

Introducción

La idea de este capítulo es darle las pistas para llegar más lejos que la implementación "sencilla" de Scrum y empezar a responder a determinadas preguntas que posiblemente se esté haciendo:

¿Cuáles son los métodos para desplegar (escalar) Scrum en equipos múltiples?
He oído hablar de Kanban y ScrumBan: ¿cuáles son las relaciones entre Scrum y estos métodos?
También hablamos mucho de DevOps: desmitificamos rápidamente este asunto para entender sus relaciones con Scrum.
Scrum y la subcontratación.

Voluntariamente, no profundizaremos demasiado en los diferentes temas, pero veremos la mejor manera de abrirle la puerta a aquellos aspectos en los que debe profundizar si así lo desea.

Escalamiento de Scrum

Es fácil darse cuenta de que en un proyecto muy grande en el que varios equipos trabajan en el mismo "sistema", la aplicación directa de Scrum no aporta todas las soluciones.

Sepa que no hay un método único para hacer esto, pero vamos a presentarle varios enfoques que de manera indiscutible están entre los más extendidos:

el framework LeSS,
SAfe,
el método "Spotify".

Por supuesto, en el marco de este libro, el objetivo no es detallar todos estos métodos (haría falta un libro entero para cada uno), sino darle un vistazo global.

1. LeSS

a. Los principios básicos

Observe en primer lugar que LeSS se presenta en dos versiones: LeSS hasta 8 equipos y "LeSS Huge" más allá (hasta varios miles de personas en el mismo producto: no vamos a centrarnos en esta versión). Podrá encontrar todos los detalles en el sitio web: http://less.works.

LeSS parece ser el más cercano a los principios básicos de Scrum (de ahí su nombre, en forma de juego de palabras: "More with LeSS") y conserva una buena parte de las prácticas y conceptos:

Un único Backlog de Producto (común a todos los equipos).
Una definición de "Terminado" también común a todos los equipos.
Un único Product Owner.
Solo equipos multidisciplinares (y por lo tanto nada de equipos especializados, este es un aspecto importante).
Un ritmo de Sprints común y un único incremento de producto potencialmente entregable al final de cada Sprint (por lo tanto, los trabajos de los diferentes equipos se deben haber integrado antes del final del Sprint).

b. ¿Qué es diferente de Scrum en LeSS?

Evidentemente, es necesario adaptar el modo de funcionamiento al contexto "multi-equipo" y por lo tanto repartir y coordinar el trabajo.

En primer lugar, esto tiene un impacto en la organización del Sprint planning, que se hace en dos partes:

Parte 1: además del PO, esta parte de la reunión incluye a los representantes de todos los equipos, que deciden de manera conjunta el reparto de las Stories entre los equipos para el Sprint. También es la ocasión de identificar el trabajo que puede ser común y las oportunidades de cooperación entre los equipos.
Parte 2: esta parte se hace para cada equipo independientemente...

Scrum y Kanban

Hemos hablado algo de Kanban en un marco general, porque es un buen origen de inspiración de Scrum, pero al mismo tiempo nos ha parecido útil ofrecerle un vistazo general de las diferencias y similitudes entre Scrum y Kanban aplicados a proyectos de software.

1. Diferencias entre los dos métodos

La siguiente tabla resume las diferencias entre los dos métodos:

Scrum	Kanban
Establece iteraciones de duración limitada (Sprints).	La noción de iteración de duración definida es opcional (la noción de iteración puede ser "eventual").
El equipo se compromete a entregar un determinado contenido funcional durante el Sprint.	El compromiso es opcional.
Utiliza la Velocidad como métrica de planificación y avance.	Utiliza por defecto la noción de "lead time" como métrica (el "tiempo de fabricación" de una funcionalidad).
Establece equipos multi-competenciales.	Permite equipos especializados (pero no prohíbe los equipos multi-competenciales).
Una Story se debe descomponer para desarrollarse en un Sprint.	No hay tamaño particular para un "ítem" de desarrollo (esto es lógico porque no hay Sprints por defecto).
Se limita el trabajo en curso indirectamente (por el contenido de un Sprint).	Se limita el trabajo en curso por etapa del ciclo (por ejemplo: no más de N ítems en curso).
Se debe estimar/planificar las Stories (como mínimo en el marco del Sprint planning).	No es necesaria una estimación o planificación.
No se puede modificar el contenido de un Sprint en curso.	Se pueden añadir/eliminar aspectos a tratar en cualquier momento, siempre que nos mantengamos en los límites permitidos de cada etapa del proceso.
El Backlog del Sprint pertenece a un equipo y solo a uno.	El "Kanban Board" se puede compartir.
Define 3 roles concretos (PO/Scrum Master/Equipo).	No establece ningún rol.
El "Scrum Board" (tablero de las tareas del equipo durante un Sprint) se reinicializa en cada Sprint.	El "Kanban Board" es persistente.
Se necesita un Backlog de Producto priorizado.	La priorización es opcional.

2. Mezclar o no los enfoques

a. Algunas consideraciones generales

Aunque ambos métodos son parecidos, rápidamente vemos que tienen diferencias importantes.

Scrum es mucho más restrictivo que Kanban...

Scrum y DevOps

DevOps es un tema candente del que todos hablan pero pocos entienden realmente. No vamos a entrar en una explicación completa de DevOps (el tema merece al menos un libro completo), pero la idea es darle algunas pistas si empezamos diciendo que su proyecto Scrum debería estar también en modo DevOps.

Primera dificultad: al contrario de lo que sucede con Scrum, DevOps no tiene definición estandarizada.

La nuestra es la siguiente:

"DevOps es una combinación de culturas, prácticas y herramientas destinadas a mejorar la capacidad de una empresa para entregar aplicaciones y servicios a un ritmo rápido, alineando los equipos de desarrollo (Dev) con un objetivo común encargados de hacer evolucionar el sistema de información y los encargados de las infraestructuras (Ops), que colaboran durante todo el ciclo de vida de las aplicaciones, desde el diseño hasta la explotación."

Hay un concepto erróneo muy común, porque DevOps no designa un rol o un equipo específico, ya que tiene como objetivo romper las barreras entre los silos existentes, no crear un nuevo silo en forma de un equipo "DevOps".

De hecho, DevOps implica muchos conceptos, que también podemos representar:

En este caso, es el eje "Cultura y organización" lo que nos permitirá hacer el enlace con Scrum.

DevOps se basa principalmente en prácticas ágiles...

Scrum y subcontratación

Estamos frente a un tema sensible, pero que se presenta hoy en día con asiduidad durante la aplicación de Scrum: ¿Cómo conciliar el método Ágil (Scrum en nuestro caso) y la subcontratación?

Mientras que Scrum normalmente se aplica a proyectos internos, algunos intentan utilizarlo en el marco de contratos de externalización con un proveedor de servicios encargado de realizar la aplicación. Pero esto va plantear problemas.

1. Contradicción

Recuerde que al inicio de este libro, le hemos presentado los doce principios del Manifiesto Ágil.

Uno de ellos dice que: "favorecer la colaboración con el cliente, en lugar de la negociación contractual". Por lo tanto, se basa en la noción de colaboración entre los actores del proyecto, en lugar de la aplicación de contratos.

Vayamos más adelante en el análisis. Cuando se establece un contrato de tarifa plana habitual, en el momento de la firma se congela el conjunto de necesidades del cliente, añadiendo las especificaciones funcionales detalladas redactadas por este y sobre los que la empresa prestataria se responsabiliza, con una cantidad determinada. Este procedimiento deja poco espacio a los cambios: si son necesarias ciertas evoluciones, estas se estiman y forman parte de anexos al contrato.

Esto también entra en contradicción con el principio ágil: "Aceptar el cambio de necesidades aunque sea tarde durante el desarrollo".

Por principio, Scrum permite hacernos responsables en términos de coste y plazo, pero ciertamente no lo permite en términos de funcionalidades desarrolladas, ya que evolucionan a medida que avanza el desarrollo.

En este estado, entenderá que la mayor parte de las empresas sean reticentes a fijar un precio para el desarrollo de sus proyectos en un marco Ágil.

Además, todo contrato que estipula un precio fijo, tiene al menos una línea que describe las penalizaciones incurridas por el prestatario en caso de sobrepasar el plazo, no respetar las funcionalidades descritas en las especificaciones funcionales, etc. La función principal de todo esto es dar garantías al cliente frente a su proveedor de servicios: "Si le aplico muchas penalizaciones, megarantizo de que estará trabajando al 100% en mi proyecto".

Hemos visto que la responsabilidad...