{"id":283,"date":"2010-12-25T16:18:23","date_gmt":"2010-12-25T15:18:23","guid":{"rendered":"https:\/\/www.scrummanager.com\/blog\/?p=283"},"modified":"2022-11-06T16:02:05","modified_gmt":"2022-11-06T15:02:05","slug":"asi-era-la-primera-implementacion-de-scrum-para-software","status":"publish","type":"post","link":"https:\/\/www.scrummanager.com\/blog\/2010\/12\/asi-era-la-primera-implementacion-de-scrum-para-software\/","title":{"rendered":"As\u00ed era la primera implementaci\u00f3n de Scrum para Software"},"content":{"rendered":"

En 1986,\u00a0 Nonaka<\/a> y Takeuchi<\/a> , en el art\u00edculo \u00abThe New New Product Development Game<\/a>\u00bb bautizaron con la expresi\u00f3n \u00abcampos de scrum\u00bb a los entornos de\u00a0 desarrollo de nuevos productos, en los que equipos reducidos y multidisciplinares, trabajaban en el mismo espacio f\u00edsico, compartiendo el conocimiento y empleando ingenier\u00eda concurrente, en lugar de ciclos o fases secuenciales.<\/p>\n

En estos ambientes de trabajo se logran niveles de eficiencia y valor para el producto desarrollado, mayores que los obtenidos empleando ingenier\u00eda secuencial y producci\u00f3n basada en procesos. En los 80, Nonaka y Takeuchi analizaron esta forma de producci\u00f3n, observando c\u00f3mo trabajaban los equipos de las empresas tecnol\u00f3gicas que lograban mayores niveles de eficiencia y valor en sus productos: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.<\/p>\n

Diez a\u00f1os m\u00e1s tarde Ken Schwaber present\u00f3 en OOPSLA<\/a> (1995) el modelo de campo de scrum que empleaba en su equipo de programaci\u00f3n.<\/p>\n

Las implementaciones de campos de scrum para desarrollo de software se vienen enriqueciendo desde entonces y\u00a0 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<\/em> \u00fanico ha evolucionado a backlog<\/em> de producto y backlog<\/em> de sprint. Tambi\u00e9n es habitual usar un backlog<\/em> estrat\u00e9gico o \u00abepics<\/em>\u00bb de producto. La evoluci\u00f3n ha a\u00f1adido a la reuni\u00f3n de revisi\u00f3n de sprint, otra de inicio y m\u00e1s tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre, etc.<\/p>\n

Tambi\u00e9n el inventario de pr\u00e1cticas posibles se ha enriquecido. En 2001 apareci\u00f3 el gr\u00e1fico burndown<\/em>, m\u00e1s tarde de generaliz\u00f3 el uso de estimaci\u00f3n de p\u00f3ker, luego la incorporaci\u00f3n de tableros de control visual kanban…<\/p>\n

Para tener una visi\u00f3n de retrospectiva, este es el \u00abpaper\u00bb de Ken Schwber presentado en 1995\u00a0 su implementaci\u00f3n de Scrum en OOPSLA: \u00abSCRUM Development Process<\/a> \u00bb y este otro su art\u00edculo del mismo a\u00f1o \u00abLiving on the Edge<\/a>\u00bb en el que describ\u00eda su implementaci\u00f3n de Scrum para Software.<\/p>\n

Esta es la traducci\u00f3n de algunos fragmentos de la descripci\u00f3n original.<\/p>\n

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.
\nCoplien 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\u00e1s refinado de SCRUM en Smaltalk, y Schwaber en el desarrollo de Delphi.<\/em>
\n\u2026
\nLlamamos a este enfoque metodolog\u00eda SCRUM (v\u00e9ase Takeuchi y Nonaka, 1986) por el uso del t\u00e9rmino SCRUM en rugby \u2013la formaci\u00f3n cerrada que forman los delanteros para realizar el avance-<\/em>
\n\u2026
\nScrum es una metodolog\u00eda para mejora y mantenimiento de un sistema existente o la producci\u00f3n de un prototipo. Se asume la existencia de dise\u00f1o y c\u00f3digo en su mayor parte\u00a0 orientado a objetos, basado en librer\u00edas y clases. SCRUM gestionar\u00e1 la reingenier\u00eda completa posterior\u00a0 de sistemas heredados.<\/em>
\n\u2026..<\/p>\n

\"\"<\/a><\/p>\n

FASES DE SCRUM<\/h3>\n

SCRUM <\/strong>comprende las siguientes fases:<\/p>\n

<\/p>\n

1.- Pre-juego<\/strong><\/p>\n

Planificaci\u00f3n: Definici\u00f3n de una nueva versi\u00f3n basada en la pila actual, junto con una estimaci\u00f3n de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto la visi\u00f3n como el an\u00e1lisis. Si se trata de la mejora de un sistema existente comprende un an\u00e1lisis de alcance m\u00e1s limitado.
\nArquitectura: Dise\u00f1o de la implementaci\u00f3n de las funcionalidades de la pila. Esta fase incluye la modificaci\u00f3n de la arquitectura y dise\u00f1o generales.<\/p>\n

2.- Juego<\/strong><\/p>\n

Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versi\u00f3n con respeto continuo a las variables de tiempo, requisitos, costo y competencia. La interacci\u00f3n con estas variables define el final de esta fase. El sistema va evolucionando a trav\u00e9s de m\u00faltiples iteraciones de desarrollo o sprints.<\/p>\n

3.- Post-juego<\/strong><\/p>\n

Preparaci\u00f3n para el lanzamiento de la versi\u00f3n, incluyendo la documentaci\u00f3n final y pruebas antes del lanzamiento de la versi\u00f3n.
\n<\/a><\/p>\n

Pasos de cada fase<\/h3>\n

Pasos de la planificaci\u00f3n<\/strong><\/p>\n