La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para la implementación de modelos Agile. Hoy os contamos como era su primera versión.

Scrum es el término que dieron 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.

Con este sistema de trabajo obtenían altos niveles de eficiencia y valor en el producto superiores a los obtenidos con métodos secuenciales y de producción basada en procesos. En los años 80, Nonaka y Takeuchi estudiaron 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.

Unos cuantos años más tarde, 10 para ser exactos, Ken Schwaber presentó en OOPSLA (1995) su implementación de Scrum para software, que empleaba en el desarrollo con Delphi.

Desde entonces las diferentes versiones de Scrum para el desarrollo de software han ido evolucionando, y poco tiene que la versión actual con la original de Kent. Es muy improbable que encontremos una implementación de Scrum con los mecanismos originales (paquetes, cambios, riesgos, soluciones…), el Backlog único ha evolucionado a Backlog de producto y Backlog de Sprint. Se ha convertido en algo habitual tener un backlog estratégico o «Epicas» de producto. Las sesiones de Review y Retrospectiva se añadieron posteriormente. Y tampoco se suele usar ya la fase de cierre. Scrum incluso está traspasando la frontera del software, para aplicarse a otro tipo de industrias.

Las prácticas que ahora acompañan y complementan a Scrum, fueron apareciendo con el tiempo. En 2001 apareció el gráfico burndown, más tarde empezó a ser habitual el uso de estimación relativa (de con cartas de póker), posteriormente los tableros de control visual estilo kanban…

Te dejo aquí los enlaces a lo que presentó Ken Schwber en 1995 en OOPSLA, con su implementación de Scrum: “SCRUM Development Process, y el artículo original del mismmo año en el que describía su forma de implementr Scrum «Living on the Edge».

SCRUM version 1

Para que puedas comparar con el Scrum actual, te dejo traducida parte de la versión original de Kent.

Fases de Scrum

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.
    • 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 respetando las variables de tiempo, requisitos, costo y competencia. La interacción con estas variables define el final de esta fase. El sistema irá 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.

Controles de SCRUM

Al trabajar en entornos de mucho caos (complejidad e imprevisibilidad) se hace necesaria 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.

También te puede interesar.

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

¿Quién debe priorizar el Product Backlog en Scrum?

Agile y Scrum nacen principalmente del mundo del Software, aunque en los últimos años se han llevado a otros ámbitos de las empresas. Scrum plantea al Product Owner como una única persona. La realidad de la empresa nos empuja a implementar algún tipo de escalado de Scrum, en el que aparecen, de una forma y otra, Product Owners de Product Owners. ¿Significa esto que se está haciendo una mala implementación de Scrum? ¿O nos estamos adaptando a las necesidades tal y como indica Agile? ¿Tiene que de verdad ser una única persona? ¿O hay otras posibilidades manteniendo la cultura Agile?

Multiplica los resultados de tu Sprint Planning

Hoy es día de Sprint Planning. Miras hacia tu equipo y… sólo ves pacas de paja rodar de un lado a otro. ¿Qué ha pasado con tus compañeros? ¿Dónde se esconderán? ¡Te han dejado solo! Te traigo 5 consejos para multiplicar los resultados de tu Sprint Planning.

Definition of Ready y Definition of Done

¿Qué necesitas para poder comenzar una tarea? ¿Cuándo podemos dar una tarea por terminada? Para resolver estas dudas, en este vídeo te traemos el Definition of Ready y el Definition of Done

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Beneficios de la automatización en los equipo Scrum

La automatización, cada vez más, forma parte del desarrollo del software. ¿Qué beneficios tiene para los equipos Scrum?

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies