Así era el marco original de scrum para software

Scrum es el nombre dado por Nonaka y Takeuchi al método de trabajo empleado por equipos pequeños y multidisciplinares para desarrollar nuevos productos. Equipos que trabajan juntos en el mismo espacio y construyen el resultado de forma iterativa, empleando ingeniería concurrente en lugar de fases secuenciales.

Este marco de trabajo logra niveles de eficiencia y valor en el producto superiores a los obtenidos con ingeniería secuencial y producción basada en procesos. En los 80, Nonaka y Takeuchi observaron esta forma de trabajo en los equipos de las empresas tecnológicas que lograban mayores niveles de eficiencia y valor en sus productos (“New New Product Development Game“[caché]): Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.

Diez años más tarde Ken Schwaber presentó en OOPSLA (1995) la descripción de un marco para implementar Scrum en el desarrollo de Delphi, en el que él trabajaba.

Las prácticas para aplicar Scrum en proyectos de software se vienen enriqueciendo desde entonces y poco tienen que ver las guías actuales de scrum con la original de Ken. Ahora es muy raro que usar Scrum con los controles originales (paquetes, cambios, riesgos, soluciones…) el “backlog único” ha evolucionado a Backlog de producto y Backlog de Sprint. También es habitual usar un backlog estratégico o “Epics” de producto. La evolución ha incorporado a la reunión de revisión de sprint, otra de inicio; y más tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre, etc.

En 2001 apareció el gráfico burndown, más tarde empezaron a ser habituales protocolos para los equipos que estiman el esfuerzo de las tareas: estimación de póker, tallas de camisetas… También se han ido integrando tableros de control visual kanban…

Para tener una perspectiva del enriquecimiento que aporta la comunidad profesional, este es el “paper” de Ken Schwaber presentado en 1995 su implementación de Scrum en OOPSLA: “SCRUM Development Process ” y este otro su artículo del mismo año “Living on the Edge” en el que describía su implementación de Scrum para Software.

Un resumen de la “metodología” y su fases:

Los primeros en observar diferentes implementaciones de SCRUM para el desarrollo de nuevos productos con alto rendimiento fueron Takeuchi y Nonaka (1) en Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, y Hewlett-Packard.
Coplien ha seguido y documentado un enfoque similar para el desarrollo de software en Borland, logrando la mayor productividad con C++ (1). Recientemente, Jeff Sutherland ha aplicado un enfoque más refinado de SCRUM en Smaltalk, y Schwaber en el desarrollo de Delphi.
…
Llamamos a este enfoque metodología SCRUM (véase Takeuchi y Nonaka, 1986) por el uso del término SCRUM en rugby –la formación cerrada que forman los delanteros para realizar el avance-
…
Scrum es una metodología para mejora y mantenimiento de un sistema existente o la producción de un prototipo. Se asume la existencia de diseño y código en su mayor parte orientado a objetos, basado en librerías y clases. SCRUM gestionará la reingeniería completa posterior de sistemas heredados.
…..

FASES DE SCRUM

SCRUM comprende las siguientes fases:

1.- Pre-juego

Planificación: Definición de una nueva versión basada en la pila actual, junto con una estimación de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto la visión como el análisis. Si se trata de la mejora de un sistema existente comprende un análisis de alcance más limitado.
Arquitectura: Diseño de la implementación de las funcionalidades de la pila. Esta fase incluye la modificación de la arquitectura y diseño generales.

2.- Juego

Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con respeto continuo a las variables de tiempo, requisitos, costo y competencia. La interacción con estas variables define el final de esta fase. El sistema va evolucionando a través de múltiples iteraciones de desarrollo o sprints.

3.- Post-juego

Preparación para el lanzamiento de la versión, incluyendo la documentación final y pruebas antes del lanzamiento de la versión.

Pasos de la planificación

Desarrollo de un backlog completo.
Determinación de la fecha de entrega y la funcionalidad de una o más versiones.
Selección de la versión más adecuada para desarrollo inmediato.
Trazado de los “paquetes del producto” (objetos) sobre los elementos del backlog de la versión elegida.
Selección del equipo o equipos para desarrollar la nueva versión.
Evaluación y control adecuado de los riesgos.
Estimación del coste de la versión, incluyendo desarrollo, material, marketing, formación y despliegue.
Conformidad de la dirección y financiación del proyecto.

Pasos de diseño y arquitectura

Revisión de los elementos del backlog incluidos en la versión.
Identificación de los cambios necesarios para implementar el backlog.
Análisis del dominio para incluir los requisitos que incluye el desarrollo mejora o actualización.
Acotar la arquitectura del sistema para apoyar el nuevo contexto y necesidades.
Identificar problemas del desarrollo o modificaciones.
Reunión de revisión de diseño. Cada equipo presenta los cambios para implementar los elementos del backlog, e identificar posibles reasignaciones.

Pasos del desarrollo (Sprint)

La fase de desarrollo es un ciclo de trabajo repetitivo. La gestión determina el cumplimiento de los tiempos, funcionalidad y calidad. Este enfoque es conocido también como ingeniería concurrente.

El desarrollo consiste en los siguientes macro-procesos:

Reunión con los equipos para revisar los planes de lanzamiento de versión.
Distribución, revisión y ajuste de los estándares de conformidad para el producto.
Sprints iterativos hasta que el producto se considera listo para su distribución.

Un sprint es un conjunto de actividades de desarrollo llevado a cabo durante un periodo predefinido, por lo general entre una y cuatro semanas. Duración basada en la complejidad del producto, evaluación de riesgos y grado de supervisión deseado.
El tiempo determinado para el sprint establece su velocidad e intensidad.
El riesgo se evalúa de forma continua a través de las respuestas a los controles adecuados establecidos.

Cada sprint consiste en uno o varios equipos realizando:

Desarrollo: Definición de los cambios necesarios para la implementación de los requisitos del backlog en módulos, la apertura de los módulos, análisis del dominio, diseño, desarrollo, implementación, pruebas y documentación de los cambios. El Desarrollo consiste en el micro proceso de descubrimiento, invención e implementación.
Envoltura: Cierre de los módulos, creación de una versión ejecutable con los cambios que implementas los requisitos del backlog.
Revisión: Reunión de todos los equipos para presentar el trabajo y revisar el progreso, identificando y resolviendo posibles cuestiones y añadiendo nuevos elementos al backlog. Se revisan los riesgos y las respuestas apropiadas.
Ajuste: Consolidación de la información de la revisión de los módulos afectados.

Cada sprint es seguido de una revisión cuyas características son:

Está presente y participa el equipo al completo.
La revisión puede incluir a clientes, personal de ventas y otros.
La revisión cubre los sistemas funcionales y ejecutables abarcados por el equipo e incluye los cambios que se han realizado para implementar los elementos del backlog.
En la revisión se pueden evidenciar cambios en la forma en la que se han implementado los elementos del backlog.
La revisión también puede introducir elementos nuevos en el backlog, cambiando de esta forma los contenidos y dirección de las versiones previstas.
Se determina la fecha de la siguiente revisión en base al progreso y complejidad. La duración normal de los sprints es de 1 a 4 semanas.

Cierre

Cuando el equipo de gestión siente que las variables de tiempo, parte completada, requisitos, coste y calidad están alineadas para producir una nueva versión, declaran cerrada la versión, dando paso a esta fase.
En esta fase se prepara el producto generado para producir una nueva versión. Entre las tareas de cierre se encuentran: integración, pruebas del sistema, documentación de usuario, preparación del material de formación y marketing.

Controles de SCRUM

Al trabajar bordeando el caos (complejidad e imprevisibilidad) se requiere la gestión de controles que eviten la caída en el caos.

La metodología SCRUM incorpora estos controles generales para evitar la pérdida de control, utilizando las técnicas de Orientación a Objetos para la construcción de las entregas.

El principal control es el del riesgo. La gestión de riesgos da lugar a cambios en los controles y respuestas del equipo.

Los controles de la metodología SCRUM Son:

Backlog: Requisitos que el producto en su versión actual no gestiona de forma adecuada. Errores, defectos, peticiones del cliente, incorporación de mejoras competitivas o tecnológicas son elementos del backlog.
Los elementos del backlog que comprenden una nueva versión comprenden variables de fechas, calidad y funcionalidad viables.
Paquetes: componentes del producto que deben cambiarse para implementar la nueva versión.
Cambios: cambios que deben producirse en un paquete para implementar una nueva versión.
Problemas: problemas técnicos presentes que deben resolverse para implementar un cambio.
Riesgos: Para lograr el éxito del proyecto se revisan de forma continua los riesgos y las respuestas previstas. La gestión de riesgos afecta a otros controles.
Soluciones: respuestas a problemas y riesgos, que suelen ser cambios.
Temas: Cuestiones generales del proyecto que no se definen en términos de paquetes.

Estos controles se emplean en diversas fases de SCRUM. La dirección los emplea para gestionar el backlog. Los equipos los usan para gestionar cambios y problemas.
Ambos, dirección y equipos, gestionan los temas, riesgos y soluciones. Estos controles son revisados, modificados y consolidados en la revisión de cada Sprint.

Scrum Development Process
Ken Schwaber