Modelo original de Scrum para desarrollo de software

Scrum es el término dado por Nonaka y Takeuchi al método de desarrollo de nuevos productos realizado con equipos reducidos, multidisciplinares, que trabajan con comunicación directa y empleando ingeniería concurrente, en lugar de ciclos o fases secuenciales.

Esta forma 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¹ analizaron esta forma de producción, observando cómo trabajaban los equipos de las empresas tecnológicas que lograban mayores niveles de eficiencia y valor en sus productos(New New Product Development Game): 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 la implementación de Scrum para software que él empleaba en el desarrollo de Delphi.

Las implementaciones de Scrum para desarrollo de software se vienen enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken. Ahora es muy raro que alguien configure un campo de 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 añadió 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.

También la prácticas se han enriquecido. En 2001 apareció el gráfico burndown, más tarde empezó a ser habitual el uso de estimación de póquer, luego tableros de control visual kanban...

Para tener una visión de retrospectiva, este es el "paper" de Ken Schwber 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.

Como adelanto, esta sería la traducción 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 en cada fase

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.

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.

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.

Referencias

¹ Ikujiro Nonaka & Hirotaka Takeuchi (1986) "New New Product Development Game", Harvard Business Review Jan, 1.
Schwaber, Ken (1995) Scrum Development Process, OOPSLA.
Scrum Development Process.
Living on the Edge.

Véase también