En 1986, Nonaka y Takeuchi , en el artículo «The New New Product Development Game» bautizaron con la expresión «campos de scrum» a los entornos de desarrollo de nuevos productos, en los que equipos reducidos y multidisciplinares, trabajaban en el mismo espacio físico, compartiendo el conocimiento y empleando ingeniería concurrente, en lugar de ciclos o fases secuenciales.
En estos ambientes de trabajo se logran niveles de eficiencia y valor para el producto desarrollado, mayores que los obtenidos empleando 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: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.
Diez años más tarde Ken Schwaber presentó en OOPSLA (1995) el modelo de campo de scrum que empleaba en su equipo de programación.
Las implementaciones de campos de scrum para desarrollo de software se vienen enriqueciendo desde entonces y las implementaciones actuales se parecen ya poco a 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 ha añadido 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 el inventario de prácticas posibles se ha enriquecido. En 2001 apareció el gráfico burndown, más tarde de generalizó el uso de estimación de póker, luego la incorporación de 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.
Esta es la traducción de algunos fragmentos de la descripción original.
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:
Continuar leyendo «Así era la primera implementación de Scrum para Software»