Plantilla del CIO para la Adopción del Método ... - Rally Software

Plantilla del CIO para la Adopción
del Método Scrum para Obtener
Agilidad en Software
Whitepaper
Con Dean Leffingwell y Hubert Smits
Las presiones de una economía verdaderamente global hacen que
las empresas de hoy dependan cada vez más de su habilidad para
producir software como su principal ventaja competitiva. Sea software
para gestionar procesos de manufactura o entrega de productos, o
software que mejore la eficiencia de las actividades diarias, el impacto
de este software se extiende a todas las áreas de los negocios.
Este documento describe como implementar Scrum en una
organización, inclusive como escalar Scrum en proyectos de gran
envergadura y/o en proyectos con un sin número de equipos,
los desafíos que puedan surgir , y los beneficios de Scrum. Este
documento también provee una plantilla para la adopción de Scrum
en organizaciones en las que el desarrollo de software es primordial
para obtener una alta ventaja competitiva.
www.rallydev.com
©2013 Rally Software Development
1

Índice
INTRODUCCIÓN.................................................................................................................................4
VISIÓN GENERAL DE SCRUM Y DE LA AGILIDAD DEL SOFTWARE.............................................5
PRINCIPIOS SCRUM.................................................................................................................................................... 6
ADOPCIÓN DE UN PROCESO EMPÍRICO X DE UN PROCESO PLANIFICADO........................................................ 7
ELIMINE LOS OBSTÁCULOS PARA QUE EL EQUIPO PUEDA HACER SU TRABAJO.............................................. 7
MEJORES RESULTADOS, PERO MENOS PREDECIBLES X FALSA SEGURIDAD.................................................... 8
SCRUM Y LA AGILIDAD DE LOS SOFTWARE............................................................................................................. 8
PREPARÁNDOSE PARA SCRUM.......................................................................................................9
“SCRUMMING” TANTO EN EL PROCESO DE SOFTWARE COMO EN LA ORGANIZACIÓN.................................. 10
EL PAPEL DEL CIO COMO SCRUMMASTER ORGANIZACIONAL PARA LA MEJORA CONTINUA....................... 10
CUIDADO: CAMBIAR ES UN TRABAJO DURO......................................................................................................... 11
UNA PLANTILLA PARA LA ADOPCIÓN DE SCRUM.......................................................................13
PLAY 0 - DESCRIPCIÓN, EVALUACIÓN Y PREPARACIÓN DEL PILOTO................................................................. 13
PLAY 1 - PROYECTO(S) PILOTO................................................................................................................................ 14
PLAY 2 – EXPANSIÓN ORGANIZACIONAL................................................................................................................ 15
PLAY 3 – CAUSANDO IMPACTO................................................................................................................................ 16
PLAY 4 - MIDA, EVALÚE Y AJUSTE........................................................................................................................... 17
PLAY 5 – EXPANDA Y CONQUISTE........................................................................................................................... 18
IMPEDIMENTOS ORGANIZACIONALES PARA LA ADOPCIÓN DE SCRUM.................................19
EXPONIENDO LOS IMPEDIMENTOS CON SCRUM.................................................................................................. 19
CARACTERIZANDO LOS IMPEDIMENTOS............................................................................................................... 20
ESCALAMIENTO DE SCRUM..........................................................................................................22
ESCALAMIENTO DE LA ORGANIZACIÓN: EQUIPOS DE EQUIPOS DE SCRUM.................................................... 22
LA ORGANIZACIÓN SIGUE LA ARQUITECTURA...................................................................................................... 23
COORDINANDO EQUIPOS DE EQUIPOS.................................................................................................................. 23
COMUNICACIÓN DIARIA: SCRUM OF SCRUMS...................................................................................................... 24
PLANIFICACIÓN Y MONITOREO DEL RELEASE AL NIVEL DE SISTEMA............................................................... 24
INFRAESTRUCTURA DE HERRAMIENTAS PARA AGILIDAD CORPORATIVA......................................................... 25
PERSONAS Y COMUNICACIÓN................................................................................................................................. 25
OPORTUNIDADES DE LA INFRAESTRUCTURA DE HERRAMIENTAS.................................................................... 26
EVOLUCIONANDO LA INFRAESTRUCTURA EN SPRINTS....................................................................................... 28
CONCLUSIÓN...................................................................................................................................29
BIBLIOGRAFIA.................................................................................................................................30
www.rallydev.com
©2013 Rally Software Development
2

APÉNDICE A - RECURSOS..............................................................................................................31
LECTURAS SELECCIONADAS................................................................................................................................... 31
ENTRENAMIENTO ÁGIL............................................................................................................................................. 31
OTROS......................................................................................................................................................................... 31
APÉNDICE B – EL MANIFIESTO ÁGIL.............................................................................................32
PRINCIPIOS DETRÁS DEL MANIFIESTO ÁGIL......................................................................................................... 32
DELIVERABLES Y CAMBIOS...................................................................................................................................... 32
PERSONAS Y COMUNICACIÓN................................................................................................................................. 33
FEEDBACK.................................................................................................................................................................. 33
CRÉDITO A LOS LÍDERES DE LOS MÉTODOS ÁGILES........................................................................................... 33
APÉNDICE C – MÉTRICAS DE SCRUM..........................................................................................34
TABLA 1 – MÉTRICAS DEL PROCESO SCRUM (HARTMANN, STALLINGS)........................................................... 34
TABLA 2 – MÉTRICAS DEL PROYECTO SCRUM (RALLY SOFTWARE DEVELOPMENT CORP.)............................ 36
www.rallydev.com
©2013 Rally Software Development
3

Introducción
Las presiones de una economía verdaderamente global hacen que las empresa de hoy
dependan cada vez más de su habilidad para producir software como su principal ventaja
competitiva. Sea software para gestionar procesos de manufactura o entrega de productos,
o software que mejore la eficiencia de las actividades diarias, el impacto de este software se
extiende a todas las áreas de los negocios.
Pese a estas presiones, para muchas organizaciones, las prácticas de desarrollo de
software continúan siendo similares a las utilizadas en la decada de los años ochenta. La
dependencia en métodos del tipo cascada (waterfall), normativos y basados en planes a
largos plazos, a pesar de las evidencias de que estas prácticas normalmente no logran
proveer valor real en tiempo adecuado y, por consiguiente, dificultan la capacidad de
respuesta de nuestras instituciones a las necesidades de cambios rápidos de los clientes y
de las condiciones de los mercados. Y esto situación tiende a agravarse.
Las organizaciones de TI de hoy también
necesitan coordinar de forma eficaz
Gestionar organizaciones
a equipos de desarrollo de software
distribuidas y migrar de forma
distribuidos por el mundo entero enofcados
eficaz para arquitecturas orientadas
en regernera sistemas legacy en arquitecturas
a servicios exige un nuevo enfoque
más flexibles y orientadas a servicios. Es
de desarrollo de software
evidente que necesitamos de un nuevo
enfoque para gestionar y desarrollar software
para mantener las competitividad de nuestras instituciones.
Para resolver estos desafíos, están siendo adoptadas varios métodos de desarrollo de
software más ágiles y adaptables que permiten a las organizaciones suministrar software de
mejor calidad en formar más rápida. Scrum es uno de estos métodos comprovados que ha
tenido un alto nivel de adopción en muchas organizaciones de software. Este documento
técnico describe como un CIO u otro gerente del área de informática puede implementar
Scrum en toda la organización, incluso pudiendo escalarlo para aplicaciones mayores y
equipos de equipos - los desafíos que él o ella irán a enfrentar, así como también los frutos
que podrán obtener- y suministra una plantilla para la adopción de Scrum en empresas
donde el software, muchos software, es primordial para tener una ventaja competitiva en el
mercado.
Esta es una plantilla de ideas sobre como implementar Scrum en una empresa. La
consideramos una plantilla y no un manual porque cada organización tiene características
diferentes. La implementación de Scrum dentro de una determinada empresa puede ser
significativamente diferente de su implementación en otra. Los tipos de impedimentos, los
elementos que requieran cambios, la dificultad del cambio y las personas que harán los
cambios son diferentes, así como los calendarios, las prioridades y el esfuerzo.
www.rallydev.com
©2013 Rally Software Development
4

Visión General de Scrum y de la Agilidad del Software
Superficialmente, Scrum es un proceso muy simple: una técnica de administración
de software que tiene un conjunto relativamente pequeño de prácticas y reglas
interrelacionadas, no es demasiado prescriptiva, se puede aprender rápidamente y es capaz
de producir ganancias de productividad casi inmediatamente.
Scrum foca naturalmente una organización entera en la creación de productos de éxito.
Suministra funcionalidades útiles a intervalos regulares a la medida que los requisitos, la
arquitectura y el diseño van emergiendo, mismo cuando se utilizan tecnologías inestables.
Ud. puede implementar Scrum en el comienzo o en medio de un proyecto y Scrum ahorrará
muchos esfuerzos de desarrollo que estaban en dificultades.
Scrum funciona porque optimiza el ambiente de desarrollo, reduce los gastos generales de
organización y sincroniza rigurosamente los requisitos del mercado con la rápida entrega
de funcionalidades. Fundamentado en una moderna teoría de control de procesos, Scrum
produce el mejor software posible con los recursos disponibles, los niveles de calidad
aceptables y las fechas de release exigidas.
En su esencia, Scrum es un proceso iterativo e incremental para desarrollo de cualquier
producto o gestión de cualquier trabajo que produzca un conjunto potencialmente
entregable de funcionalidades al término de cada de iteración. Sus atributos son:
• Un proceso ágil para gestionar y controlar el trabajo de desarrollo.
• Un envoltorio para las prácticas de ingeniería existentes.
• Un enfoque basado en el equipo de desarrollo de sistemas cuando las necesidades están
cambiando rápidamente.
• Controla el caos generado por los conflictos de intereses y necesidades.
• Mejora la comunicación y maximiza la cooperación.
• Detecta y elimina cualquier cosa que se interponga en el camino del desarrollo y entrega
de productos.
• Una forma de maximizar la productividad.
• Se puede escalar desde proyectos individuales hasta organizaciones enteras y se ha
aplicado a la gestión del desarrollo de productos y proyectos interrelacionados en que
participaron más de mil miembros del equipo.
• Una forma de hacer que todos se sientan bien con su trabajo sus contribuciones, y saber
que hicieron lo mejor que podrían haber hecho.
www.rallydev.com
©2013 Rally Software Development
5

Aunque la descripción de las prácticas de Scrum en detalle está más allá del alcance de
este documento técnico (véase Schwaber Schwaber 2004 y 2002), el método se caracteriza
por la producción de un Backlog del Producto en el que las características requeridas
están organizadas por prioridad (Figura 1). Un Product
Owner se encarga de aprobar los cambios en el backlog
del producto. La ejecución se produce en interacciones de
aproximadamente
30 días, llamadas
Sprint, que se
centran en las más
altas prioridades del
Backlog del Producto.
El objetivo de cada
Sprint es la entrega
de un incremento de
1
2
3
4
Product Backlog
prioritized product features
desired by the customer
1
Sprint Backlog
features assigned
to a sprint
Sprint backlog items
expanded by
the team
30-day sprint
Scrum
15-minute daily meeting,
each team member reviews:
1. What did you do since the
last Scrum meeting?
2. Do you have any obstacles?
3. What will you do before
next meeting?
new functionality is
demonstrated at the
end of the Sprint
producto potencialmente entregable. Durante el Sprint, se observan los puntos de control
en una reunión de “Scrum”, que informa de los progresos y actividades diarias dentro del
equipo y se comparten problemas que puedan “bloquear” el progreso de un individuo o un
equipo. Esto permite al ScrumMaster determinar el progreso de los compromisos del Sprint
y ayudar a corregir el rumbo para asegurar la conclusión exitosa del Sprint.
Principios Scrum
Aunque estos sean algunos de los mecanismos de Scrum, lo más importante es que el CIO
entienda que el método Scrum es guiado por algunos principios generales:
• La convicción de que el desarrollo de software eficiente se implementa mejor a través de
un proceso empírico de que a través de un proceso planificado;
• La convicción de que, una vez eliminados los obstáculos de organización, un equipo
auto-organizado y autogestionado, naturalmente, va a producir mejor software que lo
haría en la situación contraria;
• La premisa que se puede producir software más valioso dentro de un plazo y
presupuesto determinado, pero definitivamente no se puede predecir la funcionalidad
exacta de lo que un equipo va a entregar
La afirmación de Scrum es que el reconocimiento de estos principios fundamentales libera
una organización de muchas de las restricciones que impiden el desarrollo de software
eficiente. Sin embargo, los CIOs también tienen que reconocer que estos principios implican
cambios potencialmente significativos en la organización que decide adoptarlos. Dado que
estos principios constituyen la base fundamental de Scrum, cada uno merece una discusión
adicional.
every
24
hours
Figura 1: Un Modelo de proceso empírico que caracteriza el Scrum
www.rallydev.com
©2013 Rally Software Development
6

Adopción de un Proceso Empírico x de un Proceso Planificado
El método Scrum considera que la mayoría de los sistemas de desarrollo de hoy en día
tienen una base filosófica incorrecta, es decir, mediante una planificación mayor y mejor
se pueden lograr resultados más predecibles de mayor calidad. Scrum reconoce que el
proceso de desarrollo de aplicaciones es impredecible y extraordinariamente complicado
(imagine cientos de miles de líneas de código creadas manualmente) cuyo valor sólo se
puede medir empíricamente. Después de todo, la aplicación en desarrollo probablemente
nunca ha sido desarrollada por cualquier equipo en cualquier lugar, y mucho menos por
su equipo en su contexto, por lo que los métodos de planificación de la clase de libros de
cocina, paso a paso, no pueden resolver la imprevisibilidad inherente de manera efectiva.
Scrum define el proceso de desarrollo de sistemas como un conjunto de actividades
libres, que combina las herramientas y técnicas conocidas y ejecutables con un equipo
capacitado que está firmemente vinculada al Cliente/Product Owner. Dado que muchas de
estas actividades están sueltas, se aplican controles - como la inspección y demostración
constante - para gestionar el riesgo y proporcionar evidencia empírica de la situación del
proyecto en tiempo real, todo el tiempo.
La opción por Scrum es simple:
Sepas dónde estás cada día con Scrum
- o -
Creas que sabes donde estás en tu plan bien formado y descubras que estás muy
equivocado, mucho más tarde
Elimine los obstáculos para que el equipo pueda hacer su trabajo
Con los años, los procesos de negocio de una empresa y sus prácticas de desarrollo de
software generalmente aumentan de peso, a menudo haciendo la creación de software un
gran esfuerzo. Cuando se implementa Scrum, estos “impedimentos organizacionales” para
la distribución eficiente de software se hace muy evidente, porque obstaculizan la capacidad
del equipo con respecto al cumplimiento de la rápida naturaleza iterativa e incremental de
Scrum. Eliminar o cambiar estos procesos y prácticas puede mostrar que un proyecto de
grandes cambios debe ser iniciado, dirigido y supervisado por el CIO o ejecutivo campeón
(más sobre este tema más adelante).
Además, en Scrum, el equipo es la cosa. Al final de cuentas, ellos son los que de hecho
proyectan, desarrollan y suministran la aplicación, así, cuando optimizamos su desempeño
eliminando obstáculos, optimizamos el desempeño de la empresa para suministrar valor a
sus usuarios. La gerencia cumple con su papel cuando elimina impedimentos. El Equipo
cumple con su papel cuando honra sus compromisos según lo descrito en el Backlog de
cada Sprint.
www.rallydev.com
©2013 Rally Software Development
7

En otras palabras, en Scrum, el equipo es tanto capacitado como responsable de
suministrar los bienes. Hace su trabajo cuando auto-organiza, auto-genera y auto-cumple
los objetivos del Sprint. Para muchas organizaciones, esto significa cambiar las cosas al
revés. El abordaje jerárquico-técnico-gerencial-directivo es esencialmente eliminado por el
Scrum. El Product Owner ahora define los objetivos y prioridades, el equipo piensa como
atenderlos y nadie tiene que enseñarlos como hacerlo durante el proceso.
Mejores Resultados, Pero Menos Predecibles x Falsa Seguridad
El Scrum comienza con la premisa de que la creación de software es un negocio complicado
que opera en un ambiente técnico y altamente fluido y que nadie puede prever con
seguridad o planificar definitivamente qué exactamente un equipo irá a entregar, cuando va
a hacerlo y cual será la calidad y el coste. En su lugar, el Scrum entiende que los equipos
pueden estimar estos ítems, informar las estimaciones, negociar un plan de corto plazo
de acuerdo a los varios riesgos y ajustarse conforme avanza. El acuerdo es que el equipo
deberá suministrar el mejor software posible dado las circunstancias y que la adopción de
cualquier abordaje “libro de cocina” no va a mejorar la definición de “el mejor” y sólo va a
comprometer la rapidez de respuesta del equipo a la complejidad e imprevisibilidad real
existente.
Históricamente, la ignorancia de esta filosofía crea varios problemas de organización:
• La gerencia realmente cree que puede prever el costo, la programación de entrega y la
funcionalidad que será entregue y planifica en consecuencia.
• Los desarrolladores y gerentes de proyecto son forzados a vivir en la mentira: fingen que
pueden planificar, prever y entregar. Crean en un cierto modo, pero necesitan fingir que lo
hacen de otro modo. En el final, acaban esencialmente sin controles.
• En el momento en que se entrega el sistema, a menudo se vuelve irrelevante o requiere
cambios significativos. Una de las causas fundamentales es que los costos elevados de
la iteración limitan nuestra visibilidad de la utilidad de lo que el equipo está realmente
desarrollando, incluso cuando ya es demasiado tarde.
El reconocimiento de estas realidades no es nada fácil - por ejemplo, ¿qué gerente desea
decir a su ejecutivo que no sabe exactamente lo que el equipo va a entregar en una fecha
determinada? Pero los beneficios de este abordaje son que las organizaciones se vuelven
realmente autónomas: la empresa finalmente se libera para producir mejores resultados
para sus usuarios finales y ahora podrá hacerlo más rápido, creando una clara ventaja
competitiva para los negocios.
Scrum y la Agilidad de los Software
Scrum se ha utilizado desde mediados de los noventa y actualmente está siendo aplicado
en miles de proyectos en todo el mundo. Además de Scrum, varias de las nuevas
metodologías iterativas también han recibido atención durante este período. Al igual que con
www.rallydev.com
©2013 Rally Software Development
8

Scrum, cada una de ellas resulta de una combinación de ideas viejas con nuevas ideas, pero
todas destacan:
• La estrecha colaboración entre el equipo de desarrollo y expertos de negocios;
• La comunicación cara a cara (como más eficiente que la documentación escrita);
• La entrega frecuente de nuevos software con valor comercial aplicable;
• Equipos auto-organizados y cohesionados;
• Formas de crear el código, y el equipo para permitir una adaptación continua a las
nuevas exigencias.
En 2001, varios idealizadores y practicantes de estas metodologías, incluso líderes de
Scrum, lograron entender lo que tenían en común. Escogieron la palabra “ágil” como
el término comprensivo y elaboraron el “Manifiesto para el Desarrollo Ágil de Software”
(Apéndice B), siendo su aspecto más importante una especificación de valores compartidos:
Estamos descubriendo mejores maneras de desarrollar software haciéndolo y ayudando a
otros a hacerlo. A través de este trabajo, aprender a valorar más:
• Individuos e interacciones que procesos y herramientas
• Software en funcionamiento que documentación comprensiva
• Colaboración con el cliente que negociación de contratos
• Reaccionar a cambios que seguir un plan
Es decir, a pesar de que hay valor en los ítems de la derecha, valoramos más los ítems de la
izquierda.
El Manifiesto ha impactado y desencadenado a miles de nuevos proyectos ágiles. Los
resultados y las experiencias de estos proyectos mejoraron las técnicas aplicadas por
las diferentes formas de prácticas ágiles. Como con cualquier intento humano, algunas
tuvieron éxito, otras no. Pero lo que más impacto tuvo en los éxitos fue el vinculo que los
empresarios y los técnicos tenían con su proyecto. Ésta era la manera que ellos deseaban
que los software fuesen desarrollados - y los clientes y usuarios finales concordaron.
Proyectos exitosos han generado más entusiastas y tal como un Sprint exitoso, el ciclo ágil
virtuoso continúa hasta hoy.
Preparándose para Scrum
Después de haber adquirido un entendimiento básico de los beneficios comerciales y
culturales de Scrum y de la agilidad, los CIOs normalmente desean dar el paso siguiente y
ver como este método de desarrollo puede incrementar su organización.
Durante sus primeros quince años de vida, la mayoría de las implementaciones de
Scrum fueron conducidas en el esquema bottom-up. En otras palabras, un equipo de
proyectos experimentaba el Scrum y los resultados eran impresionantes. Otro equipo lo
www.rallydev.com
©2013 Rally Software Development
9

experimentaba y rápidamente los proyectos de Scrum aparecían en la organización entera.
Más recientemente, sin embargo, muchas organizaciones desean implementar Scrum en el
esquema top-down, como parte de una directiva para aumentar la rapidez de respuesta de
la empresa y aumentar la productividad.
Como Scrum representa autonomía para el equipo y “dejar el equipo decidir”, una
implementación top-down exige consideración y preparación ponderadas, como iremos a
describir en esta sección.
“Scrumming” tanto en el Proceso de Software Como en la
Organización
Muchas organizaciones tienen ineficiencias e impedimentos tolerados durante años;
Scrum los identifica rápidamente y exige su resolución. Afortunadamente, el aumento de
productividad y de valor derivado de proyectos Scrum hace el esfuerzo valer la pena, pero
sigue siendo una lucha.
Para implementar Scrum, una organización necesita asumir dos obras: la primera consiste
en proyectos en los cuales los equipos de desarrollo son orientados a crear software
utilizando Scrum; la segunda, eliminar impedimentos a la creación y distribución de software
optimizado que los equipos de Scrum encuentran. La primera obra mejora la distribución del
software y la segunda resuelve los impedimentos a la productividad y al ROI identificado en
la primera.
Ambas obras son difíciles y requieren mucho trabajo por encima y más allá del desarrollo
actual del software; una implementación completa de Scrum puede durar hasta dos años.
No importa cuál sea la intensidad o el compromiso de la gerencia, no se puede reducir este
horario debido a que el núcleo del proyecto es el cambio organizacional.
Los ciclos diarios y mensuales de inspección y adaptación de Scrum hacen todo visible -
el código, el proceso y los impedimentos de la empresa. Los proyectos que utilizan Scrum
regularmente identifican impedimentos que se deben registrar, evaluar, priorizar y resolver.
La velocidad de implementación de Scrum está directamente relacionada con:
• El grado de cambio requerido dentro de la organización;
• La urgencia dentro de la organización para mejorar su proceso de desarrollo y entrega de
software;
• La efectividad de liderazgo dentro de la organización.
El papel del CIO como ScrumMaster Organizacional para la
Mejora Continua
En Scrum, el ScrumMaster es responsable de asegurar que un equipo Scrum adopte
plenamente los valores y prácticas de Scrum. El ScrumMaster protege el equipo asegurando
que él no se comprometa mas allá del límite de lo que puede lograr en un Sprint y es su
www.rallydev.com
©2013 Rally Software Development
10

papel eliminar continuamente los obstáculos que puedan impedir el equipo de entregar los
resultados del Sprint con éxito.
Al nivel de impedimento organizacional, esta tarea
cabe al CIO o a otro patrocinador ejecutivo cuya
función sea trabajar fuera del equipo y eliminar las
barreras organizacionales que puedan impedir el
éxito de un modelo de desarrollo ágil.
El CIO es el ScrumMaster para
Cambios Organizacionales
La función del ScrumMaster Organizacional es percibir, identificar y trabajar dentro de la
organización para causar los cambios que eliminan los impedimentos, es decir, el CIO
como ScrumMaster Organizacional es principalmente un agente de cambios y la lista de
impedimentos es su Backlog de Producto. El patrocinador del Scrum del CIO - procediendo
como “Product Owner” con relación a estos impedimentos - define las prioridades de estos
ítems. Este Backlog de Producto de impedimentos es trabajado por la organización a través
de los equipos que utilizan el proceso Scrum, teniendo como deliverables la remoción del
impedimento. Este backlog de cambios organizacional inicia durante los proyectos pilotos y
continúa mientras los cambios necesarios sean identificados durante el ciclo de inspección
y adaptación de Scrum.
El ScrumMaster Organizacional si encuentra periódicamente con todos los ScrumMasters,
con el Product Owner y el patrocinador para seguir desarrollando el Backlog de Producto de
Cambio Organizacional. Se forman equipos que conducen los cambios en la organización
dentro de un Sprint. En la fase de Revisión del Sprint, el cambio es analizado así como la
métrica que se puede usar para monitorizar el progreso de la implementación del cambio.
De esa manera, el CIO se hace cargo de un proceso continuo de mejora organizacional
específicamente orientado para aumentar la productividad y la calidad de los equipos de
desarrollo de software.
Cuidado: Cambiar es un Trabajo Duro
El cambio es un trabajo duro y no hay forma de evitar el trabajo duro. Las organizaciones
que implementan el Scrum a veces identifican el trabajo duro de forma equivocada, como
fallo de alguien, algo que se puede hacer para eliminar si el grupo que falló simplemente
“corregir su hecho”. Este tipo de culpa organizacional puede matar una implementación
de Scrum, y con ella, también la capacidad de la organización para crear software mejor.
Cuando algo es penoso, cuando algo sale mal, reconocer esto es sólo parte del cambio que
se está produciendo; es una oportunidad para que todos se reúnan para imaginar como
resolver el problema, juntos.
No se puede planificar e implementar Scrum con listas de verificación, procedimientos y
formularios. Scrum es sólo una estructura simple que puede identificar en una organización
todo lo que dificulta la creación de software optimizado. El trabajo para gestionar y eliminar
estos impedimentos es la parte más difícil de implementar Scrum y es diferente para cada
organización, ya que cada organización es diferente.
www.rallydev.com
©2013 Rally Software Development
11

A nadie le gustan los problemas y dificultades. Muchos de los impedimentos son tan
inherentes al modo de pensar y operar de una organización que se vuelven muy difíciles
de eliminar. Ningún volumen de planificación anticipada irá a reducir esta dificultad; él solo
podrá ayudar a alertar todo el mundo para el trabajo duro que necesita ser realizado para
convertirse en un competidor de clase mundial. El Scrum exige que la alta administración
esté vitalmente involucrada en la tría y remoción de los impedimentos y, así, exige que el
CIO que esté adoptando el Scrum se convierta en el principal agente de cambio.
De esa manera, el CIO asume un proceso de mejora organizacional continuo, totalmente
enfocado en el aumento de la productividad y de la calidad de los equipos de software. No
es fácil y el liderazgo que el CIO ofrece será un factor crucial para el éxito, como ilustra la
siguiente nota de Ken Schwaber para un CEO:
De: Ken Schwaber
Para: XXX XXXXX, CEO de XXXXXXX Corporation
“Por un lado, Scrum ofrece algunas posibilidades muy atractivas
- una mayor productividad, un mejor ambiente de trabajo, una
mayor competitividad y un producto de calidad superior. Por otro
lado, es difícil de implementar. La cantidad de cambio generado
por una implementación de Scrum es significativa y difícil.
Aunque el cambio sea difícil para desarrolladores y clientes
(product owners), ellos obtienen una respuesta inmediata a
través de una satisfacción más grande en el trabajo. Esto los
ayuda en tiempos de tensión y ansiedad. La administración
intermediaria, sin embargo, sufre estrés sin recompensa inmediata.
Se les pide a ayudar en la transición de una organización de
abordajes tradicionales a abordajes más enjutos, sin la visión
clara de un punto final personal… ¿que voy a hacer y adonde
voy a me encajar en la nueva organización? Ésta pregunta es
particularmente difícil y llena de peligro, pues la administración
intermediaria va a moldear la nueva organización. El potencial para
conflictos y políticas es desalentador.
Mi experiencia con implementaciones top-down corporativas
de Scrum me llevaron a creer que la diferencia entre el éxito y
el fracaso es Ud. Su capacidad para imaginar el futuro y ayudar
a transmitir esto a su gerencia, su habilidad para orientarla
pacientemente durante el cambio y para convencer a su gerencia
intermediaria de lo cuanto es valerosa y transformarla en un
equipo va a distinguir su habilidad para absorber el cambio y
darse cuenta de los beneficios, o no.”
www.rallydev.com
©2013 Rally Software Development
12

Una Plantilla para la Adopción de Scrum
Una vez que Ud. decida implementar Scrum en su organización, se inicia un viaje con la
creencia de que el esfuerzo será recompensado con un proceso de software más eficaz y
una empresa más ágil y competitiva. También se reconoce que una cantidad significativa de
cambio organizacional se encuentra ahora en el pronóstico.
A medida que el CIO contempla este compromiso, la comprensión del comportamiento
organizacional conduce a un conjunto racional de los pasos a seguir para lograr un cambio
real. Estos pasos incluyen:
• Encontrar un evangelista y un patrocinador local;
• Dar pequeños pasos iniciales para tantear el terreno;
• Reflexionar sobre los éxitos y fracasos y avanzar paso a paso.
La próxima sección describe algunos ejemplos típicos de como Ud. podría implementar
Scrum en toda la organización; una plantilla con ejemplos de técnicas que Ud. puede aplicar
para realizar el cambio necesario.
Play 0 - Descripción, Evaluación y Preparación del Piloto
El objetivo del primer play es preparar el terreno para las actividades futuras: a) evaluar el
grado de preparación de las organizaciones para la agilidad, b) suministrar entrenamiento
inicial para los primeros participantes y c) preparar el Backlog de Producto para los
proyectos iniciales. Los detalles de este play son los siguientes:
Descripción y Evaluación
Descripción: Sesión funcional de dos días que consiste en
• Prueba de Aptitud de Scrum - expone la gerencia a los tipos de cambio que se producen
con Scrum y ayuda a determinar si desea proceder.
• Presentaciones de Scrum - despertar concienciación general y presentar conceptos para
la organización entera.
• Evaluar la prontitud organizacional y definir los próximos pasos.
• Definir planes; identificar los posibles pilotos, programar entrenamientos y providenciar
recursos para el proyecto piloto.
• Cenar con la alta gerencia para examinar los próximos pasos.
Duración: 2 días
Suporte: Externo
Preparación del Piloto
La organización está lista para proseguir con el entrenamiento y la estructura necesaria para
soportar el primero proyecto piloto. Las actividades en esta fase incluyen:
www.rallydev.com
©2013 Rally Software Development
13

Entrenamiento del ScrumMaster
Descripción: Entrenar los ScrumMasters para ejecutar los pilotos
Duración: 2 días
Suporte: Externo
Entrenamiento del Product Owner
Descripción: Entrenar los Product Owners para maximizar el ROI utilizando Scrum.
Duración: 1 día
Soporte: Externo
Establecer Métricas
Descripción: Analizar y cambiar métricas que monitorean el uso de Scrum en la
organización y definir el valor resultante de los pilotos. Establecer procesos primordiales de
Scrum y las métricas del proyecto.
Duración: 1 semana
Suporte: Externo
Establecer Backlog de Producto para Cambios
Descripción: Establecer backlog de producto para realizar un seguimiento y evaluar los
impedimentos que surgen durante los proyectos piloto. Esta será la base para la iniciativa de
cambio dentro de la organización.
Duración: 1 día
Soporte: Externo
Play 1 - Proyecto(s) Piloto
El objetivo de este play es experimentar el Scrum en un o más proyectos reales para
demostrar los beneficios positivos de la agilidad mejorada del software dentro de la
organización. Un o más proyectos piloto son ejecutados en esta fase. Los ScrumMasters
y la gerencia acompañan los pilotos con mucha atención para identificar obstáculos e
impedimentos organizacionales al Scrum. Cuando estos impedimentos son identificados,
ellos son corregidos en el lugar donde es posible, o simplemente son registrados en el
Backlog de Cambios Organizacionales y categorizados para tratamiento posterior.
Proyectos Piloto
Duración: 3 a 6 meses
Soporte: ScrumMaster Externo / Interno
Descripción: Ejecute de 3 a 6 iteraciones de los proyectos piloto. Los proyectos piloto
entregan incrementos de funcionalidad e identifican los impedimentos al desarrollo de
software optimizado. Evalúe y ajuste el plan, evalúe y priorice los impedimentos.
www.rallydev.com
©2013 Rally Software Development
14

Retrospectiva
Duración: 2 días
Soporte: ScrumMaster Externo / Interno
Descripción: Analice los proyectos piloto, las métricas y los impedimentos. Evalúe lo
que funcionó y lo que podría ser mejorado e identifique el ROI. Evalúe el impacto en
las operaciones de negocio, incluso en las relaciones dentro de los departamentos
organizacionales y con los clientes.
Replanificación
Duración: 1 día
Soporte: ScrumMaster Externo / Interno
Descripción: Modifique el plan piloto para la implementación de Scrum, mantenga el alto
nivel y deje que los planes de proyectos y el plan de los cambios organizacionales sean
conducidos por sus propios backlogs de producto específicos.
Play 2 – Expansión Organizacional
Basado en pilotos exitosos, el objetivo de este play es ampliar la utilización de Scrum y de
sus beneficios a un subconjunto significativo de la organización de desarrollo. Hasta ahora,
existe un entendimiento de cuales prácticas benéficas están integradas, qué impedimentos
estaban en el camino de una adopción más amplia y donde había más necesidad de
entrenamiento. Por ejemplo, los programas de entrenamiento más amplios siguientes ahora
pueden ser eficaces:
• Entrenamiento del ScrumMaster: Antes de escalar la implementación a proyectos
adicionales y mayores, Ud. necesita aumentar el número de Scrum Masters. Los
candidatos con habilidades apropiadas deben ahora ser reconocidos en la organización.
Los ScrumMasters que irán a comandar el Scrum of Scrums (vea abajo) ahora pueden
ser entrenados en habilidades avanzadas, como Facilitación de Equipos y Colecta de
Mediciones.
• Entrenamiento en Desarrollo de Productos: Optimizamos la transferencia entre los
analistas y los equipos de desarrollo cuando estas dos funciones usen un abordaje
común. Un abordaje muy común es la adopción de métodos de desarrollo de producto
en el estilo Lean o Toyota. Las referencias enumeran varios libros que suministran
informaciones acerca de estos temas.
• Entrenamiento de los desarrolladores: Los equipos de desarrollo de proyectos ágiles
habrán aprendido cuando van a necesitar las habilidades para trabajar en una forma más
ágil. El aprendizaje de las habilidades Extreme Programming (XP), como el desarrollo
dirigido a pruebas (TDD), etc., pueden ahora ser garantizada. (Beck 2004)
www.rallydev.com
©2013 Rally Software Development
15

• Entrenamiento en Scrum/Agilidad: Una aplicación exitosa de Scrum, dependerá en
gran parte de un vocabulario común a todas las personas involucradas. Esto puede
lograrse mediante cursos introductorios de 2 a 4 horas para 30 a 50% de la organización.
Además, se pueden aplicar otras actividades para aumentar la visibilidad y el nivel de
aceptación de Scrum en la organización:
• Radiadores de información: Informe el estado de los proyectos de Scrum a través de
radiadores de información simple y de gran eficacia, como whiteboards exhibiendo las
tareas (Task Board), Backlogs de Producto y de Release y los gráficos BurnDown de
proyectos y programas.
• Lecturas: Una sugerencia de artículos y libros puede ser ofrecida para todas las
personas de la organización para incentivar la mayor difusión del conocimiento.
• Seminarios/brownbags suministrados por el CIO: El(los) líder(es) de cambio debe(n)
informar con frecuencia y de forma franca sobre lo que está pasando en la organización.
Reuniones informales, como brownbags y pizza hours tienden a tener un impacto
positivo sobre los cambios.
• Charlas / experiencias difíciles / feedbacks sobre piloto(s): Los resultados de los
proyectos piloto deben se poner disponibles a todos. Esto aumentará los debates y la
participación en todos los niveles de la organización.
Play 3 – Causando Impacto
Como los proyectos piloto probaron que el valor real será entregue a través de un abordaje
ágil de la gestión de proyectos de software, el objetivo de este play es causar un impacto
más significativo en el resultado que solo podrá ser demostrado a través de más y mayores
proyectos. A través de los plays anteriores, la organización habrá colectado conocimiento
explícito y tácito suficiente para ser capaz de enfrentarlos con una alta probabilidad de
éxito. En este punto, por lo menos 25% de la organización deberá estar involucrada en la
implementación del Scrum.
Un cambio efectivo ya deberá estar ocurriendo dentro y fuera de la organización de
desarrollo. Dentro del desarrollo, el trabajo se realiza mejor por el equipo de desarrollo.
Fuera de los equipos de desarrollo, el trabajo de eliminar impedimentos es conducido por el
ScrumMaster Organizacional e implementado por los departamentos afectados.
Proyectos de Desarrollo
Duración: Para siempre
Soporte: Interno
Descripción: Proyectos de desarrollo monitoreados por el ROI.
www.rallydev.com
©2013 Rally Software Development
16

Proyectos de Cambio
Duración: La mayor parte del trabajo en los primeros 1 a 2 años; conforme necesario
Soporte: Interno
Descripción: Proyectos de cambio organizacional dentro de varios departamentos eliminan
impedimentos emergentes y variables.
Evalúe y Adapte
Duración: A Cada Sprint
Soporte: ScrumMaster Externo / Interno
Descripción: Analice las métricas cualitativas y cuantitativas. Agregue otras métricas y
analice los procesos de captura siempre que haya ocurrido una sorpresa.
Play 4 - Mida, Evalúe y Ajuste
El objetivo de este play es evaluar el progreso de la organización y establecer un
conjunto más amplio de métricas para servir como base para una mayor expansión. El
CIO deberá tener en cuenta de que la discusión inminente sobre las métricas podrá ser
tanto controversial como perturbadora, ya que muchas de las métricas tradicionales que
podrían estar en vigor antes de la adopción del Scrum (ejemplo: medidas de “integridad de
documento”) no son más relevantes. Afortunadamente, el Scrum y las prácticas ágiles son
realmente interpretables y mensurables y los practicantes están convergiendo un conjunto
de métricas que suministran feedback cualitativo y cuantitativo tanto al nivel de procesos
cuanto de proyectos. Pero, antes de entrar en esta discusión, es necesario hacer una
distinción importante entre los diversos procesos tradicionales de desarrollo de software y el
Scrum y el ágil:
El principal indicador para el desarrollo ágil de software es si el software funcional en
realidad existe y es demostrablemente adecuado para uso en los fines previstos. En Scrum
este indicador clave se determina empíricamente, mediante demostración, al final de cada
individuo Sprint.
Esta medición primaria de la calidad y productividad del software es la esencia del desarrollo
ágil. Así, con Scrum, Ud. no podrá desviarse mucho de su objetivo sin darse cuenta.
Todas las otras métricas se subordinan a ese objetivo y a su eterno mantra de “suministrar
software funcional con mayor frecuencia”.
En este punto del play de adopción de Scrum, una parte significativa de la organización ya
está operando de manera ágil. Los resultados de Sprint de los proyectos iniciales son la
principal medida de la eficacia de los nuevos comportamientos del equipo y de sus nuevos
procesos. Estos datos deben ser publicados y analizados.
Además, ahora es el momento apropiado para definir un conjunto de métricas secundarias
usadas para guiar a su organización en la forma como implementar Scrum. Por lo tanto, hay
dos tipos de métricas que se pueden aplicar:
www.rallydev.com
©2013 Rally Software Development
17

Métricas de Procesos – indicadores principalmente cualitativos de la eficacia de los
equipos y de la organización en la adopción de Scrum. Incluyen ítems tales como la eficacia
de los equipos en la gestión del Backlog del Producto, la eficacia de los procesos de Scrum,
como la reunión diaria de Scrum, reunión de Planificación de Sprint, etc. En cooperación con
la ScrumAlliance, Hartman y Stallings han desarrollado un template de métricas de procesos
que puede ser utilizado por cualquier organización que esté implementando Scrum. Estas
métricas son presentadas como la Tabla 1 del Apéndice 2.
Métricas del Proyecto – Al nivel del proyecto, se puede aplicar un conjunto de métricas
adicional para medir los resultados de un equipo de Scrum particular y el servicio,
componente o sistema sobre los cuales es responsable. El conjunto pueden incluir algunas
métricas tradicionales, como conteo de defectos, porcentaje de código con cobertura de
test unitario, porcentaje de código cubierto por tests de regresión automatizados, etc.,
así como también métricas específicas de Scrum, como número de historias de usuario
concluidas y demostrables al final de cada Sprint. Un ejemplo de un conjunto de estas
métricas aparece como Tabla 2 en el Apéndice 2.
Una Nota sobre Calidad y Scrum
Los clientes suelen presionar las organizaciones de desarrollo para que entreguen
funcionalidades más rápidamente de lo que es posible. Algunas organizaciones logran
contornar eso reduciendo la calidad del producto, abandonando la refactorización,
reduciendo esfuerzos en pruebas y otras prácticas sólidas de ingeniería. Esto no es tolerable
dentro de las prácticas de Scrum, puesto que el sistema o producto es un bien corporativo,
continuamente refinado y medido objetivamente, no un activo de proyecto único. Las
organizaciones de ingeniería que sucumben a esta presión acaban por crear sistemas con
“design muerto”, que no pueden ser mantenidos o incrementados de forma eficaz. La
organización sufre el enorme costo de una significativa reformulación y re-release del código
fuente. Para evitar esto, sólo los niveles mayores de una organización pueden tomar una
decisión de activos para reducir la calidad.
Play 5 – Expanda y Conquiste
Con estas actividades por detrás de la organización y con un conjunto definido de métricas
para guiar y evaluar el progreso futuro visando la organización entera, ahora es el momento
de ampliar el uso de Scrum en el ambiente entero. Las actividades de esta fase de
implementación son enfocadas en el escalamiento mayor del Scrum en la organización.
En incrementos de quizá 25 a 30% del número de funcionarios, el Scrum es presentado a
los demás equipos de la organización. Las prácticas ya existentes son refinadas todavía
más y compartidas entre los equipos para que se obtenga la absorción organizacional de las
prácticas ágiles. Solo ahora las reglas rígidas con que Scrum opera pueden ser ajustadas
para corresponder mejor a las necesidades de la organización. Los clientes pueden ser
www.rallydev.com
©2013 Rally Software Development
18

invitados a participar de la implementación a través de entrenamientos como Product
Owners o ScrumMasters. Esta fase continúa hasta que todos los equipos estén involucrados
con Scrum y los mecanismos de inspección y adaptación de Scrum tomen cuenta de las
mejoras adicionales de sus procesos y prácticas.
En este punto, la organización estará recibiendo la productividad substancial y los beneficios
comerciales y culturales de Scrum.
Antes de que prosigamos para el Escalamiento de Scrum para ambientes de proyectos
mayores, sin embargo, necesitamos analizar los tipos de impedimentos organizacionales
que pueden estorbar las prácticas eficaces de Scrum.
Impedimentos Organizacionales para la Adopción de
Scrum
Las aplicaciones desarrolladas en cualquier organización son proyectadas para optimizar
la capacidad de la empresa de cumplir su misión en los negocios. Sin embargo, con el
paso del tiempo, las organizaciones evolucionan de formas que ni siempre conducen a
la productividad del equipo de software que desarrolla y mantiene esas aplicaciones. De
hecho, algunas organizaciones evolucionaron al punto en que las prácticas de software
son en gran parte disfuncionales y, a pesar de los repetidos esfuerzos para mejorarlas, la
estructura organizacional, las políticas y las restricciones impiden un cambio eficaz. Esta
sección describe el origen y la naturaleza de estos impedimentos para mejor preparar el CIO
para el trabajo que vendrá.
Exponiendo los Impedimentos con Scrum
La propia naturaleza de Scrum; sus demandas incesantes por software de calidad que
debe ser entregue más rápido; su demanda continua de trabajar con usuarios finales para
asegurar una implementación eficaz, sus mecanismos de inspección y de adaptación
continua exponen las prácticas disfuncionales y “problemas impeditivos” muy rápidamente.
Este efecto se vuelve todavía más pronunciado cuando Scrum también es usado como un
proceso para implementar y dimensionar Scrum en la organización.
Es imposible identificar todos los
esfuerzos organizacionales de
antemano
Usted no puede identificar todos los
impedimentos de antemano, ya que se
han integrado en la organización y por lo
tanto son muy familiares para que puedan
ser fácilmente identificados. Sólo cuando
se comienza a utilizar Scrum es que los
obstaculos se vuelven obvios. El plan de implementación surge cuando existe una evidencia
de lo que necesita ser cambiado y la voluntad de la organización para realizar el cambio.
www.rallydev.com
©2013 Rally Software Development
19

Caracterizando los Impedimentos
Los impedimentos se encuentran generalmente en cuatro áreas:
En el Propio Proceso Scrum – ¿Qué impedimentos se están produciendo e interrumpiendo
el proceso de Scrum?
Prácticas Personales – ¿Qué prácticas personales están obstaculizando el desarrollo, la
distribución, el soporte y el uso de productos para maximizar la satisfacción de todos los
involucrados?
Prácticas de la Ingeniería de Productos – ¿Qué prácticas están impidiendo la optimización
de retorno sobre la inversión, o la maximización de la misión de la organización bajo la
perspectiva del producto y qué impedimentos existen contra el desarrollo optimizado del
producto y su entrega?
Cuestiones Organizacionales – ¿Qué problemas organizacionales sistémicos - claramente
fuera del control del equipo - están impidiendo los equipos de que entreguen software más
rápidamente a sus usuarios?
Queremos categorías separadas en el Backlog de Producto de Impedimento Organizacional
porque estas exigen habilidades exclusivas para su solución. Además, ellas deben ser
priorizadas para causar impacto, y se debe pensar un poco en quien en la organización tiene
más capacidad para mejor solucionar el impedimento.
La Tabla 1 abajo exhibe ejemplos de impedimentos encontrados en organizaciones que
adoptaron el Scrum. Esta lista podría funcionar como un punto de partida y un sistema
de advertencia anticipada sobre algunos de los impedimentos que su organización podría
encontrar. Pero, de nuevo, ¡cada empresa es diferente y toda implementación es única, así
que, afortunadamente o lamentablemente, el proceso Scrum irá seguramente descubrir
algunos nuevos impedimentos para que el CIO los trate!
Proceso Scrum
Las personas llegan tarde al Scrum diario y no toleran disciplina básica
Las reuniones de Scrum son muy demoradas - el equipo se queda
aburrida y considera el tiempo improductivo
ScrumMaster dicha las decisiones de design o administra
meticulosamente
Los equipos son muy grandes para Scrum diario eficaz y planificación
del Sprint
Los equipos no relatan tiempo restante de las tareas para análisis de
BurnDown
Impacto Costo Owner
www.rallydev.com
©2013 Rally Software Development
20

Prácticas Personales
Individuos interrumpidos y encargados de trabajar fuera del Sprint
Equipos separados en cubículo y no en área de Scrum abierta
Miembros del equipo no responsables de compromisos personales
del Sprint
Individuos divididos entre muchos proyectos y equipos
Impacto Costo Owner
Prácticas de Ingeniería de Productos
Los recursos interdisciplinarios para definición, design, implementación y
pruebas no están presentes en el equipo
Los Sprints no implementan ni testan completamente incrementos
potencialmente aplicables de funcionalidades valiosas para el cliente
El Product Owner no está siempre disponible / no está íntegro en el
equipo
La integración de sistemas no es forzada a cada Sprint
El Product Owner no divide ítems voluminosos del backlog de producto
para ajustarlos dentro de un Sprint
Los equipos tienen recursos ineficaces para automatizar creaciones e
integraciones
Las funcionalidades son cargadas en el Sprint después que el Sprint
empieza
Cuestiones Organizacionales
Políticas de procesos de software ineficaces para regular procesos
La gerencia presupone precio fijo, tiempo fijo, postura fija de entrega de
funcionalidades
Pruebas de Software o CQ de Sistemas es una organización separada y
no integrada con el equipo
La organización recompensa individuos en vez de recompensar el
comportamiento del equipo
Las reglas ya existentes o la capitalización de software demandan
adherencia a abordajes tipo cascada, orientadas por documentos
Los equipos no son colocadas en el mismo espacio cuanto posible
Los equipos no consiguen tomar pequeñas decisiones organizacionales
de espacio y de gastos necesarios para que ejecuten su trabajo
www.rallydev.com
©2013 Rally Software Development
21

Subtítulo:
Impacto de este impedimento en el proyecto (de 0 a 9 siendo 0 = bajo, 9 = alto),
Costo para resolver este impedimento (de 0 a 9 siendo 0 = bajo, 9 = alto)
Owner: Punto en una organización para resolución:
C – CEO/CTO/COO/CFO,
V – VP,
D – Director,
P – Gerencia de Producto,
E – Gerencia de Ingeniaría,
T – Equipo
Escalamiento de Scrum
Los beneficios empresariales de Scrum y de la agilidad son más prontamente obtenidos
con equipos pequeños, situados en el mismo local e integrados, consistiendo idealmente
en ocho personas o menos (incluso Product Owner, ScrumMaster, Desarrolladores y
Probadores) siendo que cada equipo de Scrum es owner de un producto específico o de
una determinada aplicación que ella pueda definir, desarrollar, testar y entregar sin mucha
ayuda externa.
Sin embargo, es inevitable que el éxito de Scrum resulte en su aplicación en programas
mayores, sistemas de sistemas y aplicaciones que demandan muchos (probablemente
distribuidos) equipos para desarrollarlas y entregarlas. Afortunadamente, Scrum ha mostrado
su eficacia en proyectos involucrando cientos de desarrolladores, por lo tanto, pudiendo ser
proporcionalmente dimensionado para atender las mayores empresas de software. Estos
casos, sin embargo, involucran un conjunto exclusivo de obstáculos que necesitan ser
resueltos, específicamente:
1. Escalamiento de la organización: Equipos de Equipos de Scrum
2. Infraestructura de herramientas para promover agilidad corporativa
3. Coordinación de equipos de equipos
Cada uno de estos desafíos es abordado en las sesiones abajo.
Escalamiento de la Organización: Equipos de Equipos de Scrum
Consistente con su filosofía de que “menos es más”, Scrum tiene un número muy pequeño
de normas. Sin embargo, la mayoría de las normas que existen son fijas y relativamente
inviolables. Una norma básica es el equipo consistir en ocho o menos miembros que
trabajan en una misma área física. Éste es el modelo más eficaz y productivo, puesto que a)
soporta el requisito de la comunicación informal y constante entre los miembros del equipo,
www.rallydev.com
©2013 Rally Software Development
22

) promueve un alto grado de corporativismo y c) permite un compromiso común con las
metas del Sprint entre los miembros del equipo que de hecho conocen un al otro y tienen de
trabajar juntos diariamente. Además, ciertos mecanismos de Scrum, como planificación de
Sprint y la reunión Diaria de Scrum pueden deteriorarse muy rápidamente si el tamaño del
equipo pasar de 8 a 10 individuos.
El escalamiento de Scrum para aplicaciones mayores mantiene este principio clave en
vigor. Por eso, el escalamiento hacia una aplicación involucrando 300 personas requiere
la organización de cerca de 30 equipos de Scrum. Conforme discutido anteriormente, la
formación del equipo debe ser totalmente equilibrada y capaz de desarrollar segmentos
potencialmente aplicables de funcionalidad a cada Sprint. Para la mayoría de las
organizaciones, esto exige reorganizar equipos alrededor de funcionalidades de productos,
servicios, componentes o subsistemas, en lugar de hacerlo por función individual (por
ejemplo, pool de desarrolladores, recursos de pruebas, etc.). Aunque ya hayamos discutido
este impedimento organizacional anteriormente, vemos que él se vuelve más complejo a la
medida que nuestro proyecto aumenta de tamaño.
La Organización Sigue la Arquitectura
Además, no podemos formar equipos de
Scrum prontamente sin entender cómo cada
equipo individual puede, de forma relativamente
holística, entregar funcionalidades para
usuarios finales. Por otro lado, esto nos obliga a
descomponer la arquitectura de las aplicaciones
en componentes o subsistemas que posean
integridad conceptual y puedan suministrar
valor de negocio por su propia cuenta. El
Scrum permite esta actividad de factorización
arquitectónica en la fase de organización del Sprint y en los Sprints iniciales, por los
Figura 2: Un Sistema Siendo Creado por tres
Equipos de Scrum en tres Sprints
equipos avanzados de Scrum. Este método funciona particularmente bien en un período
de expansión de Scrum y su implementación en un proyecto grande. Aquí, los equipos de
frente crean puntos de pruebas de valor para el cliente mientras factorizan la arquitectura de
las aplicaciones simultáneamente para aceptar equipos adicionales cuyo entrenamiento en
Scrum irá probablemente ocurrir al mismo tiempo. A la medida que cada nuevo equipo es
formada, su función en el sistema mayor se pone más clara y surge una situación como la
descrita en la Figura 2.
Coordinando Equipos de Equipos
Claro que, la presencia de un número grande de equipos trae desafíos significativos
en términos de coordinación y comunicación entre equipos y también implica en que,
probablemente, surgirán varios problemas al nivel del sistema que exigirán las mismas
www.rallydev.com
©2013 Rally Software Development
23

prácticas de inspección diarias y mensuales aplicadas al nivel de equipo local. Experiencias
de escalamiento de Scrum para equipos mayores generaron un pequeño conjunto de
prácticas útiles para coordinar equipos discrepantes y solucionar los desafíos mayores de
planificación de Sprints, planificación de releases y monitoreo de la integración al nivel del
sistema y de las actividades de test.
Comunicación Diaria: Scrum of Scrums
En la misma manera en que Scrum obliga una comunicación diaria en el Scrum diario, los
equipos mayores y distribuidos normalmente coordinan sus actividades en un Scrum of
Scrums diario. En esta reunión, los líderes de equipo de cada equipo componente usan el
mismo formato de reunión diaria que de un único equipo:
• ¿Qué hizo mi equipo ayer para avanzar en los objetivos de Sprint?
• ¿Qué va a hacer mi equipo hoy?
• ¿Qué impedimentos están presentes y que podrían impedir a mi equipo de cumplir su
compromiso de Sprint?
Idealmente, esta reunión debería tener lugar inmediatamente después del Scrum diario
del equipo individual. Cuando los equipos están dispersos, normalmente se la hace por
teléfono, en un momento oportuno para maximizar la participación de los miembros del
equipo del Scrum of Scrums.
Planificación y Monitoreo del
Release al Nivel de Sistema
La Figura 2 podría implicar que se trata
de una cuestión bastante simple dividir la
organización en grupos de funcionalidades,
servicios o subsistemas, habilitar estos
equipos para realizar su trabajo, y esperar que
un sistema muy bien integrado vaya a surgir
naturalmente. La experiencia ha demostrado
que esto es poco probable. Porque aun
cuando los equipos están capacitados tanto
para satisfacer las necesidades de Sprint
como para coordinar la integración entre
los equipos / subsistemas, un conjunto más
amplio de problemas aparece. Es el desafío
de crear un sistema de manera holística en
el que implementamos y probamos nuestras
Figura 3: Sistema de Três Subsistemas com Sprints
no Nível do Sistema
integraciones a través de todos los subsistemas, los subsistemas trabajan juntos para
satisfacer los requisitos más comprensivos del cliente y el sistema global satisface sus
www.rallydev.com
©2013 Rally Software Development
24

equerimientos de calidad, rendimiento y fiabilidad.
Para resolver estos desafíos, muchos equipos han añadido una función de liderazgo
técnico ejercida al nivel del sistema. Arquitectos, jefes de equipo, gerentes de producto y
profesionales de garantía de calidad en general se juntan en un equipo de Scrum adicional
para pensar y actuar al nivel del sistema. Por otra parte, ellos también pueden aplicar el
proceso de Scrum al nivel del sistema para establecer objetivos de Sprint y crear ítems
de backlog de integraciones de sistema forzadas, demostraciones al nivel del sistema,
checkpoints de calidad, distribuciones experimentales y otros milestones para asegurar
que el sistema siga en el buen camino. De esa forma, la situación de la Figura 3 empieza a
emerger.
Infraestructura de Herramientas para Agilidad Corporativa
Incluso con este nivel de estructura y coordinación, los proyectos mayores y los equipos
distribuidos aún pueden carecer de coordinación interna e interequipos, y de la visibilidad
de los proyectos necesaria para entregar, con seguridad, software en iteraciones rápidas
y totalmente testadas. Aunque el Scrum suministre una estructura ya comprobada para
los aspectos de gestión de proyectos de desarrollo de software, él no prescribe prácticas
específicas de ingeniería de software y tampoco recomienda herramientas específicas para
soportar el proceso de Scrum. La filosofía de Scrum, en ese sentido, es de “mantener la
cosa simple y dejar que los equipos decidan”.
De hecho, en caso de un equipo ideal de menos de diez personas trabajando en el mismo
local, los artefactos básicos de gestión de proyectos utilizados para planificar el Sprint
e informar el status de funcionalidades individuales, tareas y progreso del equipo se
pueden normalmente administrar usándose una planilla desarrollada y mantenida por el
ScrumMaster. Los artefactos de ingeniería para requisitos, casos de prueba y defectos
pueden ser igualmente simple y escritos en tarjetas, whiteboards, o mantenidos en un wiki
del equipo.
Personas y Comunicación
Sin embargo, dimensionar prácticas de Scrum para equipos distribuidos y equipos de
equipos impone ciertos desafíos especiales de comunicación. La coordinación entre equipos
de como implementar requisitos compartidos, monitorizar el status de funcionalidades e
identificar problemas impeditivos se vuelve una preocupación prioritaria. En estos casos
“se debe crear e implementar un mecanismo para sincronizar su trabajo con frecuencia.
Además, es necesario crear un producto más detallado y una arquitectura técnica para que
El escalamiento de Scrum trae
desafíos especiales de uso de
herramientas
el trabajo pueda ser perfectamente dividido
entre los equipos”. (Schwaber 2004)
Aunque las herramientas de gestión de
proyectos tradicionales puedan haber
funcionado para mostrar fechas idealizadas
www.rallydev.com
©2013 Rally Software Development
25

de iniciar/finalizar tareas y efectuar - quizá inútilmente - análisis críticos de trayectorias
de largos proyectos del tipo cascada, estas actividades basadas en planes pierden su
relevancia cuando se trabaja con iteraciones en las cuales el equipo entero esta centrado
en hacer que las pocas funcionalidades de prioridad más alta sean aceptadas. En lugar
de tener una persona manteniendo un banco de datos de tareas separado y desasociado
de los artefactos diarios que el equipo está efectivamente planificando e implementando
(por ejemplo, historias de usuarios y pruebas), los programas mayores necesitan de un
ambiente de colaboración en tiempo real que soporte la señalización natural que se produce
entre los miembros del equipo a medida que hacen una funcionalidad avanzar del Backlog
del Producto a los procesos de desarrollo, pruebas e integración. Para emular un equipo
trabajando en el mismo local, este ambiente de gestión de proyectos ágiles tiene que
permitir que todos vean y se actualicen rapidamente cuando una funcionalidad está en su
ciclo de vida, cuanto esfuerzo aún será necesario antes de su conclusión y que problemas
específicos están bloqueando su progreso.
Además de necesitar de nuevos modos para planificar y monitorizar nuestras iteraciones,
los recursos de las herramientas aplicados para definir, organizar y compartir nuestros
artefactos de sistema también tienen nuevas exigencias. La gestión de los requisitos, de
sus pruebas de aceptación y de sus defectos exige soporte que sea horizontal para todas
las actividades del ciclo de vida dentro de un Sprint, y no vertical, con silos profundos de
informaciones sobre artefactos deficientemente relacionadas con los compromisos que
los equipos asumieron. En verdad, en las iteraciones rápidas, las relaciones entre estos
artefactos es que realmente dan más preocupación a los equipos. Al final de cuentas, cada
Sprint está produciendo muchos segmentos de código testado funcional, por lo tanto, los
equipos necesitan entender exactamente como estos artefactos de ingeniería se relacionan
unos con los otros y lograr ver su status a todo el momento.
Oportunidades de la Infraestructura de Herramientas
Al final, siendo desarrolladores de software, los equipos naturalmente van a querer organizar
mejor sus artefactos y automatizar los aspectos del proceso Scrum que se prestan al
soporte de software. Específicamente, los equipos probablemente van a querer agregar
soporte de infraestructura para las actividades y los tipos de artefacto del ciclo de vida del
software descritos adelante:
• Gestión de Backlogs – Con el aumento de la complejidad del sistema, el equipo
deseará soporte mejor para la captura y mantenimiento de las listas de funcionalidades,
de requisitos funcionales y no funcionales, casos de uso e historias de usuarios, así
como también de las prioridades, estimaciones, status y owners de estos ítems. Como
el Scrum puede ser aplicado a proyectos mayores, estos artefactos pueden alcanzar la
casa de los miles, y poder contar con un medio para organizarlos, soportarlos y verlos a
través de sistemas o subsistemas se vuelve crucial.
www.rallydev.com
©2013 Rally Software Development
26

• Informes de Proyectos - El Scrum evita planes de proyectos tradicionales, del tipo
cascada, pero la naturaleza táctica de la gestión diaria de proyectos de Scrum es
intensa y constante. El equipo necesitará de un modo simple de permitir a cada miembro
informar sus estimaciones de tareas, su status y el esfuerzo restante de forma que los
Gráficos de BurnDown sean automatizados y permanezcan continuamente disponibles.
Además, la infraestructura deberá soportar la señalización natural que los equipos utilizan
a la medida que los ítems de backlog van pasando por su ciclo de vida. Los funcionarios
graduados van a tener que observar los equipos y entender sus iteraciones y planes de
release individuales para poder evaluar el status de sus programas como un todo.
• Elaboración de Requisitos Just-in-time – Muchos proyectos menores de Scrum
obtienen éxito con mecanismos informales de requisitos, como discusión directa entre
el Product Owner y el Equipo, pero, a la medida que aumenta la complejidad de los
proyectos y el grado de criticidad crece, puede haber necesidad de mayor profundidad
y riqueza de expresión de requisitos y de control de sus versiones. Por ejemplo, la
documentación de las Interfaces que afectan diversos equipos se vuelve crucial.
Cambios en las Interfaces o nuevas funcionalidades que extrapolan los límites del
equipo pueden tener un impacto significativo en el proyecto. Estos requisitos deben ser
elaborados en el esquema just-in-time, es decir, durante o poco antes del Sprint que
implementará la nueva funcionalidad. Para resolver este problema, los equipos podrán
desear un soporte centralizado para formas más elaboradas de expresión de requisitos,
su compilación para análisis y notificación automatizada de cambios.
• Prueba Preliminar – Dado que todo Sprint entrega potencialmente código utilizable
en la baseline del producto, el desarrollo de casos de pruebas y la automación de
pruebas preliminares permiten a los equipos soportar los requisitos de iteraciones
rápidas de Scrum. El grupo de herramientas que genera casos de test directamente
desde requisitos o story cards va a acelerar el proceso de desarrollo y proporcionar la
rastreabilidad inherente necesaria para demostrar la aceptación de la funcionalidad. Sepa
que la gestión continua de las cientos y miles de pruebas de regresión resultantes irá,
probablemente, convertirse el factor crucial para determinar la velocidad y el éxito de sus
Sprints.
• Planificación del Release – La filosofía de Scrum foca en la “arte del posible en el plazo
más corto”, en oposición a la magia negra de supuestamente predecir exactamente lo
que será entregue en las 6 a 12 Sprints más adelante. Esta filosofía representa un gran
progreso en términos de colaboración, pues permite a los equipos de Scrum centrar
profundamente por 30 días en cada ciclo y, de esa manera, producir software funcional
con más seguridad. Sin embargo, conforme los equipos van creciendo y se expandiendo,
la aplicación de más análisis y rigor a los Sprints además del horizonte inmediato ayuda a
evitar las arquitecturas que exigen refactorizaciones significativas más adelante. Aunque
la refactorización sea altamente incentivada en la metodología ágil, ella se vuelve menos
práctica a la medida que el alcance de la aplicación y el número de implementaciones ya
www.rallydev.com
©2013 Rally Software Development
27

existentes aumentan. Una mejor planificación del release que nos proporcione una pista
de despegue arquitectónico normalmente es apropiado. Por lo tanto, el arte de planificar
el Sprint puede incluir funciones de planificación del tipo “retirar algunos Sprints “ e “y
si” que ayuden los equipos a hacer intercambios de backlogs y transmitir una visión y un
Roadmap de producto razonables a los patrocinadores.
Además, estos equipos normalmente van a querer organizar todos estos activos en un
repositorio central, donde cualquier miembro del equipo podrá accederlos, en el esquema
24x7, en ámbito mundial y que permita visualizar instantáneamente el status de los
proyectos y programas, con notificación de cambios automatizado en caso de alteraciones
cruciales en los proyectos.
Evolucionando la Infraestructura en Sprints
En Scrum, la implementación de este nivel de infraestructura no es un evento raro o único,
hecho “de antemano” por un equipo de herramientas. Al contrario, los equipos de Scrum
asumen la tarea de identificar lo que ellas irán a comprar y construir para resolver sus
problemas con base en las lecciones que aprendieron en los Sprints anteriores. Además,
estas inversiones son hechas en el contexto de los Sprints en progreso. Por lo tanto, el
equipo trata de la creación de la infraestructura añadiendo ítems al Backlog de Producto
para resolver los ítems de la infraestructura, como muestra la Figura 4 abajo. Es claro
que el cliente que está delante de una funcionalidad aún tiene prioridad, pero el equipo
experimentado reconoce que necesita ser capaz de programar continuamente el trabajo de
la infraestructura de forma a mantener su velocidad y productividad conforme el alcance de
la aplicación y el número de equipos van creciendo.
Figura 4: Análisis de la Infraestructura de Escalabilidad en un Sprint
www.rallydev.com
©2013 Rally Software Development
28

Conclusión
Scrum es una práctica de desarrollo de software comprobada y eficaz, que puede
rápidamente aumentar la productividad, la velocidad de entrega y la calidad de los equipos
de software.
¿Qué departamento de TI no podrá obtener estos atributos comúnmente experimentados
por miles de instituciones a través de implementaciones exitosas de Scrum?
• Reducción del tiempo del ciclo de desarrollo
• Mayor valor de procesamiento para los usuarios finales
• Mayor calidad
• Reducción de riesgos de desarrollo
• Mayor satisfacción del usuario
• Alza de la moral de los empleados y la empresa
Aunque parezca simple a primera vista, la implementación de Scrum normalmente exige
un cambio organizacional significativo para eliminar los impedimentos que obstaculizan el
desarrollo y la entrega eficaz del mismo. Como principal agente de cambios, el CIO u otro
sponsor ejecutivo, tiene la responsabilidad primordial de eliminar estos impedimentos. Este
el compromiso perenne del CIO, que puede ser la diferencia entre el éxito y el fracaso de la
implementación de Scrum. Aunque esto no es fácil, el CIO que se compromete a mejorar
el rendimiento de los equipos de desarrollo de software utilizando el Scrum habrá dado el
primer paso para asegurarse que la empresa está en el camino adecuado para obtener los
beneficios comerciales de una entrega de software más rápida y de mejor calidad.
Además, Scrum es altamente eficaz en el desarrollo de aplicaciones corporativas de gran
escala y capaz de soportar las necesidades de cientos de desarrolladores trabajando en
aplicaciones compartidas. El dimensionamiento de Scrum impone una serie de desafíos a
la infraestructura y al grupo de herramientas que los propios equipos tendrán que resolver -
pero al superar estos desafíos se irá probablemente a obtener una alta ventaja competitiva,
en relación a los rivales de negocio.
www.rallydev.com
©2013 Rally Software Development
29

Bibliografia
Agile Manifesto: www.agilealliance.org
Beck, Kent. Extreme Programming Explained: Embrace Change (2ª Edición). Boston:
Addison-Wesley, 2004.
Schwaber. Ken. Agile Project Management with Scrum. Redmond, WA: Microsoft Press,
2004.
Schwaber, Ken, and Mike Beedle. Agile Software Development with Scrum. Upper Saddle
River, N.J.: Prentice Hall, 2002.
www.rallydev.com
©2013 Rally Software Development
30

Apéndice A - Recursos
Lecturas Seleccionadas
Beck, Kent. Extreme Programming Explained: Embrace Change 2nd Edition. Boston:
Addison-Wesley, 2004. Cockburn, Alistair. Agile Software Development. Boston: Addison-
Wesley, 2002.
Cohn, Mike. User Stories Applied. Boston, MA: Pearson Education, 2004.
Highsmith, Jim. Agile Project Management: Creating Innovative Products. Boston: Pearson
Education, 2004. Nonaka, Ikujiro and Hirotaka Takeuchi. The Knowledge-Creating Company.
Oxford University Press, 1995. Poppendieck, Mary and Tom Poppendieck. Lean Software
Development. Addison-Wesley, 2003.
Schwaber. Ken. Agile Project Management with Scrum. Redmond, WA: Microsoft Press,
2004.
Schwaber, Ken, and Mike Beedle. Agile Software Development with Scrum. Upper Saddle
River, N.J.: Prentice Hall, 2002. Larman, Craig. Agile and Iterative Development: A Manager’s
Guide, Boston: Addison Wesley 2004
Entrenamiento Ágil
SCRUM Master Class - www.controlchaos.com/certifiedscrum/
EXtreme Programming - www.xprogramming.com/xpmag/services.htm
Herramientas y Entrenamiento Ágil
Rally Software Development: www.rallydev.com
Otros
Agile Alliance: www.agilealliance.org
ScrumAlliance: http://www.scrumalliance.org/
Posibles newsgroups para interesados en Scrum / Agile:
Desarrollo en Scrum : http://groups.yahoo.com/group/scrumdevelopment/
Gestión Ágil: http://groups.yahoo.com/group/agilemanagement/
Tests Ágiles: http://groups.yahoo.com/group/agile-testing
Desarrollo en Lean: http://groups.yahoo.com/group/leandevelopment/
www.rallydev.com
©2013 Rally Software Development
31

Apéndice B – El Manifiesto Ágil
En 2001 se celebró en Snowbird, Utah, EE.UU., un workshop en el que varios creadores y
practicantes de metodologías ágiles se reunieron para entender lo que tenían en común. Se
eligió la palabra “ágil” como un término general y se elaboró el Manifiesto por el Desarrollo
Ágil de Software, cuyo pilar es una afirmación de valores compartidos:
“Estamos descubriendo mejores maneras de desarrollar software haciéndolo y ayudando a
otros a hacerlo. A través de este trabajo, hemos aprendido a valorar:
• Individuos e interacciones sobre procesos y herramientas
• Software de Trabajo sobre la documentación completa
• Colaboración con el cliente sobre negociación de contratos
• Respuesta ante el cambio sobre seguir un plan
Es decir, mientras que hay valor en los elementos de la derecha, valoramos más los
elementos a la izquierda”.
El Manifiesto ha tenido un impacto y provocó la creación de varios proyectos ágiles nuevos.
Como con cualquier intento humano, algunos otros no tuvieron éxito. Pero lo que más
impacto tuvo en los éxitos fue el vínculo que los empresarios y los técnicos tuvieron con
su proyecto. Esta era la forma en que ellos querían que el software fuese desarrollado. Los
proyectos exitosos han generado más entusiastas.
Principios detrás del Manifiesto Ágil
Los firmantes del Manifiesto Ágil acordaron 12 principios que subscriben y refuerzan el
manifiesto. Estos principios se centran en los resultados y los cambios, en las personas y la
comunicación y feedback:
Deliverables y Cambios
En lugar de prescribir o asesorar a un gran número de artefactos que deben ser entregados
como resultado de una finalización exitosa del proyecto, los métodos ágiles se remontan al
principio entregable: software funcional.
• Acoger los requisitos variables, incluso en el final del desarrollo. Los procesos ágiles
exploran los cambios para dar ventaja competitiva al cliente.
• Los mejores proyectos, arquitecturas y requisitos emergen de equipos que se autoorganizan.
• Sencillez - el arte de maximizar la cantidad de trabajo no hecha - es esencial.
• La atención continua con la excelencia técnica y el buen design aumenta la agilidad.
www.rallydev.com
©2013 Rally Software Development
32

Personas y Comunicación
Crear sistemas funcionales de software es, en primer lugar, tratar con la gente.
• Cree proyectos en torno a individuos motivados. Dales el entorno y el soporte que
necesitan y confía en ellos para realizar el trabajo.
• Los hombres de negocios y los desarrolladores deben trabajar juntos diariamente a lo
largo del proyecto.
• El método más eficiente y eficaz de transmisión de información hacia y dentro de un
equipo de desarrollo es la interacción cara a cara.
• Procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores
y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida.
Feedback
Ningún proceso o método puede ser estático, así, feedback y auto-ajuste necesitan ser
integrados.
• A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz y sintoniza y ajusta
su comportamiento de acuerdo con esta reflexión.
Crédito a los líderes de los métodos ágiles
Un gran número de líderes intelectuales ha participado en el desarrollo de varios métodos
ágiles, siendo imposible reconocerlos todos. Entre ellos citamos: Kent Beck (XP), Mike
Beedle, Ken Schwaber & Jeff Sutherland (Scrum), Alistair Cockburn (Crystal), Ward
Cunningham (FIT), Martin Fowler (XP), Jim Highsmith (Agile Project Management), Marie &
Tom Poppendieck (Lean Software Development) y Ron Jeffries (XP).
www.rallydev.com
©2013 Rally Software Development
33

Apéndice C – Métricas de Scrum
Tabla 1 – Métricas del Proceso Scrum (Hartmann, Stallings)
Proyecto: Puntuación (0-5) Sprint 1 Sprint 2
1. Product Owner
Backlog del Producto desarrollado poseído y gestionado por el
Product Owner
Proceso del Product Owner es flexible; colaboración con equipo
es continua
Participación del Product Owner y del stakeholder en el Análisis
del Sprint
Product Owner gestiona proyecto por valor
Puntuación Total de “Product Owner”
2. Planificación
Backlog del Producto es descriptivo, priorizado y tiene
estimaciones eficaces
Equipo desarrolla y gestiona el Backlog del Sprint
Equipo involucra stakeholders y dependencias de forma eficaz
Progreso del proyecto puede ser monitoreado por backlog
BurnDown y burnup de valores
Ritmo sostenible
Puntuación Total de “Planificación”
3. Programación
Planificación de Sprint regular, en el momento oportuno,
totalmente asistido
Análisis de Sprint regular, en el momento oportuno, totalmente
asistida
Scrum Diario ocurre en el momento oportuno, es totalmente
asistido
Equipo cumple sus compromisos con el Sprint
Puntuación Total de la “Programación”
4. Proceso
Equipo se autovigila y refuerza el uso de proceso y reglas
Organización es capaz de cumplir reglas de Scrum
ScrumMaster es eficaz en hacer seguir proceso
Equipo está se autogerindo
Sorpresas no ocurren
Equipo es interdisciplinar
Equipo y Product Owner colaboran y trabajan unidos
Equipo trabaja para mejorar a sí y a sus procesos
Equipo gestiona dependencias adecuadamente
Puntuación Total de “Proceso”
www.rallydev.com
©2013 Rally Software Development
34

Proyecto: Puntuación (0-5) Sprint 1 Sprint 2
5. Equipo
Miembros del equipo son dedicados y honran compromisos
Equipo efectivamente actúa sobre indicadores en Sprint
BurnDown
Comunicaciones entre miembros del equipo son eficaces
Equipo gestiona conflicto de forma eficaz dentro del equipo
Equipo mejora procesos de desarrollo internos
Puntuación Total de la “Equipo”
6. Informes
Backlog del Producto es mantenido y transmitido de forma
eficaz
Backlog del Sprint es mantenido y transmitido de forma eficaz
Informes del Proyecto y del Sprint son eficaces y
comprendidos
Valor es utilizado para gestionar el Backlog del Producto
Puntuación Total de “Informes”
7. Prácticas de Ingeniería / Infraestructura
Por lo menos creación diaria
Biblioteca común de código fuente
Métrica para calidad de incremento
Métrica de incremento cumplida
Prácticas de desarrollo dirigidas a pruebas
Prácticas de refactorización
Prácticas de análisis de design
Prácticas de análisis de codificación
Padrones de codificación
Equipo de test unitario automatizado
Equipo de test de aceptación automatizado
Puntuación Total de la “Ingeniería”
www.rallydev.com
©2013 Rally Software Development
35

Tabla 2 – Métricas del Proyecto Scrum
(Rally Software Development Corp.)
Proyecto: Sprint 1 Sprint 2
Funcionalidad
Nuevas Funcionalidades Planificadas
Nuevas Funcionalidades Concluidas
Story cards
En iteración
Aceptados
% de Aceptados
Nº no aceptados
Nº empujados para la próxima
Nº empujados posteriormente
Nº agregados/apagados
Cualidad y Automación de Pruebas
% de SC con prueba disponible / pruebas automatizadas
Open Defect Count (P1 + P2)
Total Open Defect Count
Nº de casos de prueba
Nº de casos de prueba manuales exigidos para retroceder
Code coverage %
Arquitectura
Refactors concluidos
Refactors en progreso
Refactor backlog
Customer debt features
Débito de funcionalidades del cliente aceptado
Plan del Release
Seguridad de que el plan del release fue comprendido
Seguridad en el cumplimiento del plan
Fecha de Release Planificada
Fecha de Release Real
www.rallydev.com
©2013 Rally Software Development
36