Embedded Files
Esta es, después de XP, la metodología ágil mejor conocida y la que otros métodos ágiles
recomiendan como complemento, aunque su porción del mercado (3% según el Cutter
Consortium) es más modesta que el ruido que hace. La primera referencia a la palabra
“scrum” en la literatura aparece en un artículo de Hirotaka Takeuchi e Ikujiro Nonaka,
“The New Product Development Game” en el que se presentaron diversas best practices
de empresas innovadoras de Japón que siempre resultaban ser adaptativas, rápidas y con
capacidad de auto-organización [TN86].
Otra palabra del mismo texto relacionada con modelos japoneses es Sashimi, el cual se
inspira en una estrategia japonesa de desarrollo de hardware con fases solapadas utilizada
por Fuji-Xerox. La palabra Scrum, empero, nada tiene que ver con Japón, sino que
procede de la terminología del juego de rugby, donde designa al acto de preparar el
avance del equipo en unidad pasando la pelota a uno y otro jugador (aunque hay otras
acepciones en circulación). Igual que el juego, Scrum es adaptativo, ágil, autoorganizante
y con pocos tiempos muertos.
Como metodología ágil específicamente referida a ingeniería de software, Scrum fue
aplicado por Jeff Sutherland y elaborado más formalizadamente por Ken Schwaber
[Sch95]. Poco después Sutherland y Schwaber se unieron para refinar y extender Scrum
[BDS+98] [SB02]. En Scrum se aplicaron principios de procesos de control industrial,
junto con experiencias metodológicas de Microsoft, Borland y Hewlett-Packard.
19
Schwaber, en particular, había trabajado con científicos de Du Pont para comprender
mejor los procesos definidos de antemano, y ellos le dijeron que a pesar que CMM se
concentraba en hacer que los procesos de desarrollo se tornaran repetibles, definidos y
predecibles, muchos de ellos eran formalmente impredecibles e irrepetibles porque
cuando se está planificando no hay primeros principios aplicables, los procesos recién
comienzan a ser comprendidos y son complejos por naturaleza. Schwaber se dió cuenta
entonces de que un proceso necesita aceptar el cambio, en lugar de esperar
predictibilidad.
Al igual que Agile Modeling, Scrum no está concebido como método independiente, sino
que se promueve como complemento de otras metodologías, incluyendo XP, MSF o
RUP. Como método, Scrum enfatiza valores y prácticas de gestión, sin pronunciarse
sobre requerimientos, implementación y demás cuestiones técnicas; de allí su deliberada
insuficiencia y su complementariedad. Scrum se define como un proceso de management
y control que implementa técnicas de control de procesos; se lo puede considerar un
conjunto de patrones organizacionales, como se verá en un capítulo posterior (p. 60).
Los valores de Scrum son:
• Equipos auto-dirigidos y auto-organizados. No hay manager que decida, ni otros
títulos que “miembros del equipo” o “cerdos”; la excepción es el Scrum Master que
debe ser 50% programador y que resuelve problemas, pero no manda. Los
observadores externos se llaman “gallinas”; pueden observar, pero no interferir ni
opinar.
• Una vez elegida una tarea, no se agrega trabajo extra. En caso que se agregue algo, se
recomienda quitar alguna otra cosa.
• Encuentros diarios con las tres preguntas indicadas en la figura. Se realizan siempre
en el mismo lugar, en círculo. El encuentro diario impide caer en el dilema señalado
por Fred Brooks: “¿Cómo es que un proyecto puede atrasarse un año?: Un día a la
vez” [Bro95].
• Iteraciones de treinta días; se admite que sean más frecuentes.
• Demostración a participantes externos al fin de cada iteración.
• Al principio de cada iteración, planeamiento adaptativo guiado por el cliente.
El nombre de los miembros del equipo y los externos se deriva de una típica fábula
agilista: un cerdo y una gallina discutían qué nombre ponerle a un nuevo restaurant; la
gallina propuso “Jamón y Huevos”. “No, gracias”, respondió el cerdo, “Yo estaré
comprometido, pero tú sólo involucrada”.
Scrum define seis roles:
Scrum define seis roles:
1. El Scrum Master.
Interactúa con el cliente y el equipo. Es responsable de asegurarse
que el proyecto se lleve a cabo de acuerdo con las prácticas, valores y reglas de
Scrum y que progrese según lo previsto. Coordina los encuentros diarios, formula las
tres preguntas canónicas y se encarga de eliminar eventuales obstáculos. Debe ser
miembro del equipo y trabajar a la par.
2. Propietario del Proyecto.
Es el responsable oficial del proyecto, gestión, control y
visibilidad de la lista de acumulación o lista de retraso del producto (product
backlog). Es elegido por el Scrum Master, el cliente y los ejecutivos a cargo. Toma
las decisiones finales de las tareas asignadas al registro y convierte sus elementos en
rasgos a desarrollar.
3. Equipo de Scrum.
Tiene autoridad para reorganizarse y definir las acciones
necesarias o sugerir remoción de impedimentos. El equipo posee la misma estructura
del “equipo quirúrgico” desarrollado por IBM y comentado en el MMM de Brooks
[Bro75], aunque Schwaber y Beedle [SB02] destacan que su naturaleza autoorganizadora
la hace distinta.
4. Cliente.
Participa en las tareas relacionadas con los ítems del registro.
5. Management.
Está a cargo de las decisiones fundamentales y participa en la
definición de los objetivos y requerimientos. Por ejemplo, selecciona al Dueño del
Producto, evalúa el progreso y reduce el registro de acumulación junto con el Scrum
Master.
6. Usuario.
La dimensión del equipo total de Scrum no debería ser superior a diez ingenieros. El
número ideal es siete, más o menos dos, una cifra canónica en ciencia cognitiva [Mil56].
Si hay más, lo más recomendable es formar varios equipos. No hay una técnica oficial
para coordinar equipos múltiples, pero se han documentado experiencias de hasta 800
miembros, divididos en Scrums de Scrum, definiendo un equipo central que se encarga
de la coordinación, las pruebas cruzadas y la rotación de los miembros. El texto que
relata esa experiencia es Agile Software Development Ecosystems, de Jim Highsmith
Ciclo de Scrum
El ciclo de vida de Scrum es el siguiente:
El ciclo de vida de Scrum es el siguiente:
1. Pre-Juego: Planeamiento.
El propósito es establecer la visión, definir expectativas y
asegurarse la financiación. Las actividades son la escritura de la visión, el
presupuesto, el registro de acumulación o retraso (backlog) del producto inicial y los
ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los
prototipos. El registro de acumulación es de alto nivel de abstracción.
2. Pre-Juego: Montaje (Staging).
El propósito es identificar más requerimientos y
priorizar las tareas para la primera iteración. Las actividades son planificación, diseño
exploratorio y prototipos.
3. Juego o Desarrollo.
El propósito es implementar un sistema listo para entrega en una
serie de iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son
un encuentro de planeamiento de corridas en cada iteración, la definición del registro
de acumulación de corridas y los estimados, y encuentros diarios de Scrum.
4. Pos-Juego: Liberación.
El propósito es el despliegue operacional. Las actividades,
documentación, entrenamiento, mercadeo y venta
Usualmente los registros de acumulación se llevan en planillas de cálculo comunes, antes
que en una herramienta sofisticada de gestión de proyectos. Los elementos del registro
pueden ser prestaciones del software, funciones, corrección de bugs, mejoras requeridas y
actualizaciones de tecnología. Hay un registro total del producto y otro específico para
cada corrida de 30 días. En la jerga de Scrum se llaman “paquetes” a los objetos o
componentes que necesitan cambiarse en la siguiente iteración.
Ciclo de Carrera (Sprint) de Scrum
La lista de Acumulación del Producto contiene todos los rasgos, tecnología, mejoras y
lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del
producto. Los rasgos más urgentes merecerán mayor detalle, los que pueden esperar se
tratarán de manera más sumaria. La lista se origina a partir de una variedad de fuentes. El
grupo de mercadeo genera los rasgos y la función; la gente de ventas genera elementos
que harán que el producto sea más competitivo; los de ingeniería aportarán paquetes que
lo harán más robusto; el cliente ingresará debilidades o problemas que deberán
resolverse.
El propietario de la administración y el control del backlog en productos comerciales bien
puede ser el product manager; para desarrollos in-house podría ser el project manager, o
alguien designado por él. Se recomienda que una sola persona defina la prioridad de una
tarea; si alguien tiene otra opinión, deberá convencer al responsable. Se estima que
priorizar adecuadamente una lista de producto puede resultar dificultoso al principio del
desarrollo, pero deviene más fácil con el correr del tiempo.
Product backlog de Scrum, basado en [http://www.controlchaos.com/pbacklog.htm]
La lista de acumulación de corrida sugerida tiene este formato:
Sprint backlog de Scrum, basado en [http://www.controlchaos.com/sbacklog.htm]
deben estar fuera del círculo. Todos tienen que ser puntuales; si alguien llega
tarde, se le cobra una multa que se destinará a obras de caridad. Es permitido usar
artefactos de los métodos a los que Scrum acompañe, por ejemplo Listas de Riesgos si se
utiliza UP, Planguage si el método es Evo, o los Planes de Proyecto sugeridos en la
disciplina de Gestión de Proyectos de Microsoft Solutions Framework [MS02b]. No es
legal, en cambio, el uso de instrumentos tales como diagramas PERT, porque éstos parten
del supuesto de que las tareas de un proyecto se pueden identificar y ordenar; en Scrum el
supuesto dominante es que el desarrollo es semi-caótico, cambiante y tiene demasiado
ruido como para que se le aplique un proceso definido.
Algunos textos sobre Scrum establecen una arquitectura global en la fase de pre-juego;
otros dicen que no hay una arquitectura global en Scrum, sino que la arquitectura y el
diseño emanan de múltiples corridas [SB02]. No hay una ingeniería del software
prescripta para Scrum; cada quien puede escoger entonces las prácticas de
automatización, inspección de código, prueba unitaria, análisis o programación en pares
que le resulten adecuadas.
Es habitual que Scrum se complemente con XP; en estos casos, Scrum suministra un
marco de management basado en patrones organizacionales, mientras XP constituye la
práctica de programación, usualmente orientada a objetos y con fuerte uso de patrones de
diseño. Uno de los nombres que se utiliza para esta alianza es XP@Scrum. También son
viables los híbridos con otros MAs.
Page updated
Google Sites
Report abuse