Scrum To Scrum - En.es

Publicado por
Microsoft Press
Una división de Microsoft Corporation One
Microsoft Way
Redmond, Washington 98052-6399 Copyright
© 2007 por Ken Schwaber
Todos los derechos reservados. Ninguna parte del contenido de este libro puede ser reproducida o transmitida en cualquier forma o por cualquier
medio sin el permiso por escrito del editor. Biblioteca del Congreso de control el número: 2007926318
Impreso y encuadernado en los Estados Unidos de América.
1 2 3 4 5 6 7 8 9 QWT 2 1 0 9 8 7
Distribuido en Canadá por HB Fenn y Company Ltd.
Un registro de catálogo CIP para este libro se encuentra disponible en la Biblioteca Británica.
Microsoft Press libros están disponibles a través de libreros y distribuidores en todo el mundo. Para más infor- mación sobre las ediciones internacionales,
póngase en contacto con su oficina local de Microsoft Corporation o ponerse en contacto con Microsoft Press Internacional directamente al fax (425)
936-7329. Visite nuestro sitio Web en www.microsoft.com/mspress. Envíe sus comentarios a mspinput@microsoft.com.
Microsoft, Microsoft Press, Excel, MS-DOS, Outlook y Windows son marcas registradas o marcas comerciales de Microsoft
Corporation en los Estados Unidos y / o otros países. Otros productos y nombres de compañías aquí mencionados pueden ser
marcas comerciales de sus respectivos dueños.
Los ejemplos de compañías, organizaciones, productos, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares y eventos
descritos aquí son ficticios. Ninguna asociación con ninguna compañía, organización, producto, nombre de dominio, dirección de correo electrónico,
logotipo, persona, lugar o evento se pretende ni se debe inferir.
previsto
sin ningún tipo expresas, implícitas o garantías estatutarias. Ni los autores, Microsoft Corporation, ni sus revendedores o distribuidores
serán responsables por cualquier daño causado o presuntamente causado directa o indirectamente por este libro.
Adquisiciones Editor: Ben Ryan

Project Editor: Kathleen Atkins
Editor de copia: Roger LeBlanc
Servicios editoriales y de producción: CPI Macmillan Inc.
Ilustración de la cubierta por John Hersey
Parte del cuerpo Nº X13-24184

Dedicado a ScrumMasters
Doy las gracias a las personas que revisaron el libro mientras estaba en progreso y hizo que muchos
sugerencias útiles. Son Mike Cohn, Pete Deemer, Bas Vodde, Colin Bird, Kate
VanBuren, Alan Buffington, y Clinton Keith. Agradezco especialmente a mi
esposa, Christina, que leyó, comentó:
y editado hasta altas horas de muchas noches.
iii
Mapa de contenidos
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
parte I La adopción de Scrum
1 ¿Que Tenemos que hacer para adoptar Scrum? . . . . . . . . . . . . . . . . . . . . . . . . 0.3 2 Scrum qua
Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.9 3 El primer año. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4 Contra-Memoria el músculo fricción del cambio. .
. . . . . . . . . . . . . . . 21 5 Empresas en transición. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Parte II Empezar a usar Scrum de Empresa Trabajo

6 Prácticas de la organización. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7 Prácticas de
Ingeniería. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 8 personas prácticas. . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 9 La relación entre la gestión del producto /
cliente
y el equipo de desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Parte III Apéndices
Un scrum 1, 2, 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 B más Acerca de

Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 C Ejemplo Scrum Agenda Kickoff
Meeting. . . . . . . . . . . . . . . . . . . . . . . . 119 Initial D Cartera Empresa transición Producto. . . . . . . . .
. . . . . . . . . . . . 123 E Scrum Reflexiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
127
v
Tabla de contenido
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
parte I La adopción de Scrum
1 ¿Que Tenemos que hacer para adoptar Scrum? . . . . . . . . . . . . . . . . . . . . . . . . 0.3

Scrum requiere de una cultura nueva empresa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 probarte a ti mismo
que vale la pena el esfuerzo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 evaluar el tipo de cambio que se producirá.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 advertencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
...................7
2 Scrum qua scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.9

Reunión inicial scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 El primer año . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
El primer mes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 El segundo mes. . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Las fuentes de los impedimentos de la Pila de transición. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 ¿Qué pasa si?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 El tercer mes y más allá. . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Memoria-La fricción contra el músculo del cambio. . . . . . . . . . . . . . . . . 21

Pensando en cascada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Mando y Control. . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Compromiso con desafiando las leyes de la naturaleza. . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Cómo ocultar la realidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 26 Resumen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
¿Qué opinas de este libro? ¡Queremos escuchar de ti!
Microsoft está interesado en escuchar sus comentarios para que podamos mejorar continuamente nuestros libros y recursos de aprendizaje para usted. Para
participar en una breve encuesta en línea, por favor visite:
www.microsoft.com/learning/booksurvey/
vii
viii Tabla de contenido
5 Empresas en transición. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Contoso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Situación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Aplicación de Scrum.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Resultado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 comentarios adicionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 31 enorme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Situación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Aplicación de Scrum,
la Fase 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Resultado, la Fase 1. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Situación, Fase 2.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 34 Aplicación de Scrum, la Fase 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Resultado, la Fase 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 comentarios
adicionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Woodgrove Bank. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Aplicación de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Litware. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Situación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Aplicación de Scrum.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Resultado. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 comentarios adicionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 40
Parte II Empezar a usar Scrum de Empresa Trabajo
6 Prácticas de la organización. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
# 1: La organización de la empresa Trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
# 2: La organización de la empresa para un trabajo de alta tecnología-empresa de productos. . . . . . . 46
# 3: La organización de la empresa el trabajo en otras empresas. . . . . . . . . . . . . . . . . . . . . . . . . . 51
# 4: La organización de la empresa de trabajo para nuevos sistemas que

Automatizar una operación de la empresa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
# 5: La organización de la complejidad de múltiples vistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
# 6: La organización para optimizar el producto de software Arquitecturas familia. . . . . . . . 55
7 Prácticas de Ingeniería. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
# 1: multicapa sistema de trabajo organizado por la funcionalidad. . . . . . . . . . . . . . . . . . . . . . . 60
# 2: Integración de Sistemas de múltiples capas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
# 3: La integración de la Obra de Equipos de Scrum y equipos que no usan Scrum. . . . . . . . . . 66 Resumen. . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Tabla de contenido ix
8 Prácticas de personas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
# 1: La organización de personas para hacer el trabajo para empresas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
# 2: Equipo de Creación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
# 3: Equipo de Trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
# 4: ¿Cómo se administran personas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
# 5: experiencia funcional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
# 6: Compensación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
# 7: Los gestores extra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
# 8: Los equipos con miembros distribuidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
# 9: Habilidades escasos que se necesitan por muchos equipos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9 La relación entre la gestión del producto / cliente y el equipo de desarrollo. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . 85
# 1: Acortar el tiempo de liberación a través de Gestión de Valor. . . . . . . . . . . . . . . . . . 86
Valoración relativa con Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
# 2: Just Do It. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
# 3: La Infraestructura, o Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
# 4: Los aceleradores de la recuperación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
# 5: La madre de todos los problemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Parte III Apéndices
Un scrum 1, 2, 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
La ciencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Control de proceso empírico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Desarrollo de
software complejos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Scrum: Esqueleto y corazón. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Scrum: Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 106 Scrum: Flujo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Scrum: Los artefactos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Pila de Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Pila del Sprint. . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Incremento de la funcionalidad del producto
potencialmente entregable. . . . . . . . . . . . . . . . . 112
B más Acerca de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Terminología scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Scrum y ágiles Libros. .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Libros de scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Libros de técnicas
utilizadas en Scrum para la gestión

Desarrollo de productos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
X Tabla de contenido
Libros sobre la gestión de una Empresa ágil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Libros en teoría
relacionada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Los libros que proporciona una visión
ágil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Libros sobre Técnicas Agile Software Engineering. . . . . . . . .
. . . . . . . . . . . . . . 118 Scrum y ágiles Sitios Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
118
C Ejemplo Scrum Kickoff agenda de la reunión. . . . . . . . . . . . . . . . . . . . . . . . 119

Realizar Kickoff Meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Initial D Cartera de Transición Empresa Producto. . . . . . . . . . . . . . . . . . . . . 123

Establecer las condiciones previas de un proyecto debe cumplir para utilizar Scrum. . . . . . . . . . . . . . . . . . . . 123 Establecer nuevas
métricas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Las métricas subóptima. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Cambio de Información
del Proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Establecer un centro de Scrum. . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
E Scrum Reflexiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Valor-Driven Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Proyecto de obtención de beneficios temprana. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 comer sólo cuando tiene hambre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 a la
clientela. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 El trabajo de la licitación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 133 Gestión del trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Una alternativa rentable para el
Desarrollo Marino. . . . . . . . . . . . . . . . . . . . . . . . 136 Cómo utilizar Scrum y Desarrollo Marino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Equipos demasiado
grande. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 equipos virtuales En lugar de Desarrollo Marino. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 140 La formación de equipos multi-funcionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Equipos 142 de funciones cruzadas y una
cascada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 139 equipos virtuales En lugar de Desarrollo Marino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
La formación de equipos multi-funcionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Equipos 142 de funciones cruzadas y una cascada. . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 139 equipos virtuales En lugar de Desarrollo Marino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 La formación de
equipos multi-funcionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Equipos 142 de funciones cruzadas y una cascada. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 143
Índice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
¿Qué opinas de este libro? ¡Queremos escuchar de ti!
Microsoft está interesado en escuchar sus comentarios para que podamos mejorar continuamente nuestros libros y recursos de aprendizaje para usted. Para
participar en una breve encuesta en línea, por favor visite:
www.microsoft.com/learning/booksurvey/
Introducción
Este libro es para aquellos que quieren usar Scrum en toda la empresa para el desarrollo de productos. En este momento, es
posible que tenga bolsillos dentro de su empresa que utilizan Scrum, y son más efectivos que otros lugares. Tiene por lo menos
parcialmente convencido de que el uso de Scrum en toda la empresa podría ser una manera de hacer que toda la empresa más
eficaz, pero se puede usar un poco de ayuda en encontrar la manera de hacerlo. Este libro es para ti. Hay muchas razones por
las que su empresa no puede desarrollar y desplegar productos y sistemas tan rápidamente, a bajo costo, y con la calidad que le
gustaría. Usted y su personal probablemente ya puede enumerar muchos de ellos. Scrum no los resolverá. Scrum es
simplemente una herramienta que sin descanso y sin piedad se exponerlos. Como se intenta generar productos en el marco de
Scrum, cada vez que uno de estos impedimentos se alcanza, estará expuesto de una manera un tanto dolorosa. A continuación,
puede priorizar y eliminar sistemáticamente. Cuando los impedimentos son en su mayoría han ido, Scrum es un marco que
permitirá el desarrollo de productos que desea. Y continuará siendo el organismo de control contra cualquier nueva impedimento
o impedimentos viejos que vuelven a casa para una visita.
He reunido un buen número de experiencias e historias que he trabajado con empresas que adoptan Scrum. En este libro, los
he organizado en orientación en las áreas que son más problemáticos. A veces esto es descriptivo; otras veces que relacionan
la orientación a través de historias. Está bien que no hay una orientación en las otras áreas. La empresa debe averiguar lo que
es probable que funcione mejor para sí mismo y tratar de usarlo. En la medida en que este enfoque no funciona, cambiarlo y
cambiarlo de nuevo para que funcione mejor y continúa trabajando mejor.
Scrum no prescribe. Scrum incluye pautas generales sobre cómo hacer desarrollo y los principios que han de aplicarse cuando estas
recomendaciones son insuficientes. ¿Qué significa esto? Esto significa que la gente tiene que aprender a pensar de forma diferente.
Queremos reglas a seguir, pero la vida y el desarrollo de productos son demasiado complejas para un único conjunto de reglas para ser
suficiente en todas las circunstancias. Usted tiene que confiar en la toma de decisiones descentralizada, porque probablemente no hay
una respuesta para todos los equipos de más de lo que hay para cada empresa.
Los tres primeros capítulos diseñar el plan para la adopción de Scrum. Los siguientes dos capítulos proporciona una visión de
algunos hábitos que impiden la adopción y cómo algunas empresas han hecho frente a ellos. Los capítulos restantes proporcionan
técnicas para resolver algunos de los problemas knottier. Estos le ayudarán, pero la adopción de su empresa serán diferentes de la
adopción de ninguna otra persona. El único ingrediente común es la gente, para bien y para mal. Cuando la gente altura de las
circunstancias y trabajan heroicamente en los equipos, no hay nada mejor. Cuando prefieren tumbarse, jugar a la política, y socavar
uno al otro, no hay nada peor. Tendrá la oportunidad de ver a ambos, porque Scrum sin descanso exponer todo a medida que
avanza.
xi
xii Introducción
No todas las empresas que trata de adoptar Scrum tendrá éxito. A veces, usted y su gente odiará a Scrum. Sin embargo, no se
toma la fotografía. Es sólo el mensajero. En la medida en que usted y su empresa a tener éxito, sin embargo, usted siempre
sabe dónde está parado. Usted sabrá lo que puede hacer y no puede hacer. A veces esa transparencia de vamos a ver cosas
que no son lo que deseamos ver. Sin embargo, me parece preferible a la incertidumbre del conocimiento y la ignorancia. El
objetivo es que usted y todos los miembros de su empresa a despiertas con ganas de trabajar, y para sus competidores para
desear que nunca se había despertado.
Capítulo 4
Contra Muscle Memory-La fricción del

Cambio
En este capítulo:
Pensando en cascada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.21 Mando y Control. . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.23 Compromiso con desafiando las leyes de la
naturaleza. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.24 Cómo ocultar la realidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 0.26 Resumen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . 0.27
Si usted se encuentra diciendo que los desarrolladores de su grupo han cumplido con más del 29 por ciento de sus clientes con proyectos
exitosos, 1 es probable que se basan en las mejores prácticas, habilidades sobresalientes, la calidad de vanguardia, y un legado de los
hábitos que forman la memoria muscular intelectual.
Memoria muscular es un hábito profundamente nuestros músculos se desarrollan mediante el trabajo conjunto. Cuando la empresa utiliza Scrum,
la memoria muscular de los desarrolladores es inadecuado y perjudicial. Esperar que la memoria muscular para ejercer en sí. Cuando un
proyecto va bien, todo el mundo está contento con Scrum. Sin embargo, cuando se produce el estrés, un problema o un fallo inesperado, todo el
mundo tiende a tirar Scrum y volver a su memoria muscular. Los equipos no quieren autogestionar. Ellos quieren que se les diga qué hacer. Los
gerentes no quieren dejar que los equipos de auto-gestionar. Ellos quieren mandar a los equipos en todos los asuntos, hasta el más mínimo
detalle. El trabajo en equipo se dejó por actos heroicos individuales. La calidad se abandonó. Todo el mundo se basa en lo que ellos creen que
ha funcionado mejor en el pasado.
Cuatro grandes memorias musculares obstaculizan el potencial de Scrum para efectuar el cambio. Que socavan el esfuerzo para construir
mejor los productos. Veamos ellos.
Pensando en cascada
El proceso en cascada surgió de los deseos del gestor de proyectos para superar la complejidad con la previsibilidad. Ha sido el
proceso de desarrollo predominante usado en los últimos 25 años. Cascada se enseña en las universidades, con el descrito en
la mayoría de los libros de proceso y otra literatura como el enfoque correcto, y el Instituto de Gestión de Proyectos ha
formalizado. Cada jefe de proyecto sabe cascada profunda en sus huesos y siente que es correcto. Hábitos acumulados desde
el desarrollo de la cascada están incrustados en las empresas. A esto lo llamo “la tiranía de la cascada”; es
1 Jim Johnson, Mi vida es la insuficiencia, El Standish Group International, Inc., 2006, p. 2
21
22 Parte I La adopción de Scrum
ineludible. Incluso las personas que no lo conocen como el proceso en cascada piensa en él como la “correcta” o “la forma en que siempre
hemos hecho las cosas.”
Cuando se pide a algunas personas a usar Scrum, son profundamente incómodo. Que va contra la corriente y se siente arriesgado.
Ellos responden: “Sí, pero ...”, porque su respuesta es entrenado a preferir las prácticas cascada. Por ejemplo, los requisitos son
manejados de manera muy diferente con Scrum. Alrededor del 50 por ciento de un proyecto típico se gasta el desarrollo de requisitos,
arquitectura y diseño. Durante el mismo proyecto, el 35 por ciento de los requisitos de cambio y más del 65 por ciento de la
funcionalidad descrita por los requisitos se utiliza nunca o casi nunca. De todos modos, en cascada, todos los requisitos, la
arquitectura y la infraestructura están completamente detallados antes de que el equipo construye funcionalidad.
Scrum ve requisitos y arquitecturas como inventario. El inventario es un pasivo porque si algunos requisitos cambian o no se utilizan,
el tiempo dedicado a entenderlos o el diseño para ellos es un desperdicio. La reserva de pedidos de productos, que enumera los
requisitos de Scrum, sólo tiene que ser definido en el tiempo para una reunión de planificación de Sprint; el trabajo para comprender
plenamente que sólo se realiza como se produce el Sprint que lo transforma en producto. Los requisitos se desarrollan y la
arquitectura emerge en el sprint para los que el propietario del producto así lo solicite. Para alguien inmerso en el pensamiento
cascada, esta práctica es imprudente, arriesgado y temerario. Para desarrollar el código de requisitos incompletos, saben, está
metiendo en problemas. Un arquitecto de la cascada le dijo a un arquitecto Scrum que la única manera de construir una arquitectura
sólida era para pensar en ello desde el principio, antes de que se construyó ningún código. El segundo arquitecto dijo que pensaba
que la construye como requisitos surgió podría crear una arquitectura más estable porque se demostraría, pieza por pieza.
Veamos las implicaciones de otro hábito cascada, la especialización funcional. El propietario del producto analiza la reserva de
pedidos de productos con el equipo Scrum. Juntos, los miembros del equipo discuten los requisitos y crean diseños, código,
pruebas y documentación. Un tradicionalista cascada cree, sin embargo, que sólo un diseñador puede diseñar, solamente un
programador puede codificar, a la garantía de calidad (QA) persona puede poner a prueba, y sólo un escritor técnico puede escribir
documentación!
Estaba asistiendo a una reunión de Revisión del Sprint. El Equipo Scrum había seleccionado cinco elementos de la Pila de Producto para
el sprint. Sólo un elemento se terminó. Los miembros del equipo dijeron que la gente de control de calidad (pruebas) en el equipo no
habían completado sus pruebas. Sin embargo, un equipo Scrum es multi-funcional. Todo el equipo es responsable de la construcción de
piezas terminadas de la funcionalidad de cada Sprint. No era la gente de control de calidad que no terminaron la prueba del equipo Scrum
no terminó la prueba. Scrum cuenta con todos astillado en su mejor esfuerzo para hacer el trabajo. Cuando es necesaria experiencia
funcional, las personas con esas habilidades de gol, pero cualquier persona puede hacer el trabajo.
Trey Research (TR), nuestra primera empresa hipotética, desarrolla productos acústicos. TR estaba listo para introducir una nueva
radio. Miles estaban en el almacén listo para su envío. El Dr. Trey es el fundador y CEO. Como el Dr. Trey leer el manual del
usuario en su oficina, su ceño se hacía más profunda y
Capítulo 4 contra el músculo de la memoria-La fricción del Cambio 23
Más adentro. Finalmente, llamó al gerente de la escritura técnica, Matthias Berndt. El Dr. Trey dijo que estaba muy decepcionado con
la documentación; era inutilizable. Berndt de acuerdo, pero dice que refleja con precisión la forma en la radio funcionaba. El Dr. Trey
mantuvo su calma lo que le pedía Berndt para ir al almacén, abrir una caja de radio, y ver si funcionaba el camino de la documentación
para el usuario indicado. Dos horas más tarde, Berndt apareció en la consulta del doctor Trey con una caja abierta y el manual de
usuario. Berndt dijo: “Por mucho que me gusta decir esto, el Dr. Trey, el manual refleja con precisión el funcionamiento de la radio.”
El Dr. Trey perdió los estribos. Se preguntó Berndt cómo podía haber dejado un terrible radio tal construirse. Berndt no sabe que
la radio era inaceptable? Berndt estuvo de acuerdo, pero dijo que no tenía nada que ver con la radio hasta después de su
construcción. El Dr. Trey creció aún más problemático y le preguntó: “¿Quieres decir que, a pesar de que ha trabajado aquí 23
años y conocer nuestras radios de adentro hacia afuera, que no tiene nada que ver con su diseño? Sólo sí el documento después
de que se construyen?”Berndt confirmó esto. Este enfoque disfuncional fue el impulso para TR adoptar Scrum. Ahora todo el
mundo en un equipo multi-funcional en TR diseña las radios. El Dr. Trey sabe que si el diseño de la radio no cumple con la
aprobación de los ingenieros, escritores técnicos, y los probadores, no debería ser construido.
Comando y control
Los trabajadores son más capaces de encontrar la manera de hacer su trabajo, no sus gestores. El trabajo es complejo y tiene matices
inesperados. Si los trabajadores están sujetos a instrucciones de otra persona, que no son libres de hacer el trabajo de la mejor manera
posible.
Los asistentes a la clase certificado ScrumMaster examinan la productividad de la autogestión a través de un ejercicio. En primer lugar, se
establece un espacio confinado de aproximadamente 400 pies cuadrados. Sillas, mesas, y otros obstáculos son rociados generosamente
por todo el espacio Todo el mundo se coloca en un par, cada par formado por un jefe y un trabajador. El ejercicio es para los patrones para
obtener sus trabajadores a tomar 60 pasos completos en dos minutos utilizando los comandos de inicio, parada, izquierda, derecha, más
rápido y más lento. Al final de dos minutos, alrededor del 50 por ciento han ido 60 pasos. El resto han ido un menor número de pasos. En
la segunda parte del ejercicio, los pares se rompen. Todo el mundo es un trabajador que maneja sus propias actividades. Cada uno es
libre de utilizar los comandos anteriores o llegar a los comandos más apropiadas. Se pidió a todos que tomar 60 pasos completos y luego
se detiene. Todo el mundo se lleva a cabo dentro de un minuto. La autogestión del segundo ejercicio se ha duplicado la productividad. Y
debido a que los administradores están ahora también a los trabajadores, la productividad se ha multiplicado por cuatro.
ScrumMasters certificados saben que los equipos de Scrum de autogestión son más productivos. El frente 10 por ciento de su
mente se vende en la autogestión. Pero la parte posterior 90 por ciento sabe que todavía están a cargo. Si algo va mal, van a
intervenir y decirle al equipo qué hacer. Hemos sido entrenados que esta es la mejor manera de estar absolutamente seguro
que las cosas van bien. El hábito de mando y control es muy difícil desprenderse.
Toma tiempo para que los equipos de Scrum a Gel y comenzar a realizar. Algunos equipos requieren más apoyo que
otros. El ScrumMaster es responsable de enseñar el trabajo en equipo de auto-gestión para el equipo. Por ejemplo, si el
equipo llega a la ScrumMaster diciendo: “Este artículo Pila de Producto es demasiado grande para una Sprint! ¿Qué
hacemos?”, No se dio la respuesta. En cambio, el ScrumMaster lleva al equipo a través del proceso de encontrar la
manera de deconstruir el retraso. El ScrumMaster enseña; el equipo aprende y termina el ejercicio. La próxima vez que se
presenta una situación similar, el equipo va a saber cómo actuar de forma independiente. En el momento en el
ScrumMaster le dice al equipo qué hacer y cómo hacerlo, él o ella ejerce el mando y control. En el mando y control, el
ScrumMaster cree que él o ella es responsable de la productividad y la resolución de problemas. En la autogestión,
Un proyecto que inicié incluye más de 50 desarrolladores. El nuevo desarrollo que había que hacer en conjunto con el
mantenimiento del sistema existente. Un razonablemente buena reserva de pedidos del producto estaba en su lugar. Pasé varios
días revisando los archivos y las hojas de vida de los empleados, así como hablar con los gerentes, tratando de decidir la mejor
composición del equipo. Después de esos varios días, tenía un dolor de cabeza. Así que llamé a todos los desarrolladores en la
habitación. El propietario del producto revisado con los desarrolladores el próximo proyecto y la cartera de productos. He descrito las
reglas para la composición de los equipos de Scrum y determinar su tamaño. A continuación, pidió a los desarrolladores a
organizarse en equipos. Les dijo a los equipos no tienen que ser permanentes, sino que deben dar su mejor esfuerzo. Al cabo de
cuatro horas, se habían formado sus propios equipos. Los equipos crearon acuerdos entre ellos sobre cómo cooperarán los equipos.
Durante el próximo Sprint, varios miembros del equipo desplazado a otros equipos. Al final de ese Sprint, los desarrolladores nos
dijeron que estaban muy contentos con la composición del equipo. Ellos preguntaron si podían seguir cambiando, según sea
necesario, sin embargo. Nosotros, por supuesto, dio permiso-que no tienen una idea mejor!
Compromiso con desafiando las leyes de la naturaleza
Yo vivo en Boston y trabaja a menudo en la ciudad de Nueva York. En sólo 45 minutos, el servicio de transporte Delta
Airlines me puede tomar desde el aeropuerto Logan de Boston al aeropuerto LaGuardia de Nueva York. A veces empacar
más de una reunión en un día a causa de esta comodidad. Un día, estaba a primera hora de la mañana y hasta Nueva York
para una reunión. Llegué a La Guardia de 2:00 pm a 2:30 coger el autobús a Boston. Tenía una reunión de fin de día en el
centro de Boston a las 4:30 PM Este horario hubiera funcionado, excepto LaGuardia fue empañado y todos los vuelos de la
tarde se retrasa o se cancela. Me acerqué al mostrador de Hertz. Me dijeron que el recepcionista de Hertz que tenía que
estar en Boston en 90 minutos y quería un coche. Ella me miró de forma extraña. Al parecer, mi necesidad no se pudo
cumplir. Las leyes de la carretera, la velocidad máxima de los vehículos disponibles, y la distancia entre Boston y Nueva York
hizo que mi requisito lamentable e imposibles de satisfacer. Las leyes de la física frustraron mis deseos.
Consideremos ahora un propietario del producto en picada (nuestra próxima empresa hipotética) que se ha reunido con su equipo
Scrum antes del primer Sprint. Ella entregó una presentación con 12 elementos de viñeta. Ella le dijo al equipo de los 12 artículos que
había que hacer y la liberación necesaria para el envío dentro de seis meses. El equipo observó fijamente al propietario del producto y
le dijo que, aun sin conocer más detalles sobre el proyecto, que era imposible hacerlo. El propietario del producto contestó: “Si no
cumplimos estas características para entonces, no se puede vender el producto, por lo que tiene que hacer.” Al igual que yo en Nueva
York, el propietario del producto necesitaba algo que no era posible. El negocio funciona con los compromisos. Cuando usted hace un
compromiso con otra persona, usted ha dado su palabra. La otra persona organiza su negocio en consecuencia, contando con
ustedes para hacer lo que usted dice. Esta comprensión se basa en la confianza y es una enorme fuente de eficiencia. Vamos a
darnos un breve ensayo sobre el compromiso. Lee los siguientes ejercicios y ver si puede comprometerse a cumplir con las
necesidades de la otra persona.
■ Alguien le pide que se comprometan a tener algún elemento construido para ellos. Ella le pide la fecha en que se
terminó y por el precio que va a costar. Pasar algún tiempo con ella tratando de entender exactamente lo que quiere,
pero los detalles son difíciles de alcanzar. Además, vas a tener que artesanal esta cosa. No está seguro de las
habilidades exactas de sus trabajadores o su disponibilidad. Además, la gripe se ha extendido la ciudad, y que podría
llegar a su equipo. La tecnología para la construcción de este artículo ha funcionado hasta ahora, pero una nueva
versión está saliendo con críticas mixtas. La persona que solicita el compromiso también le dice que ella podría tener
que cambiar algunas cosas en el camino. ¿Se compromete?
■ Alguien te dice que quiere un producto en una fecha específica. Debe hacer esto porque ya ha cometido el
producto antes de esta fecha a otra persona. Él te quiere ahora para respaldar su compromiso con su compromiso.
No está seguro exactamente lo que todo el compromiso es, pero la otra persona tiene poder sobre su carrera y el
salario. ¿Se compromete?
Por supuesto, es imposible comprometerse abiertamente en cualquiera de las circunstancias. Usted simplemente no sabe. Usted puede
sentir que no tiene más remedio que confiar en el segundo caso, pero mejor que tengas algunos trucos bajo la manga en caso de que se
meten en problemas.
Presionar a alguien que se comprometan a un resultado, independientemente de lo que él o ella cree que es posible es un
mal hábito. Si la persona bajo presión es honesto, que no promete nada. Si ella es arrinconado, se podría hacer un
compromiso de entregar. Ninguna de las alternativas, la falta de compromiso o un falso compromiso es útil si necesita algo
suceda. Nuestra memoria muscular nos dice que podemos pedir a nuestro equipo de ingeniería de un compromiso. memoria
muscular del equipo de ingeniería es proporcionar una, independientemente de las circunstancias. Donde el proceso de
cascada está de moda, no tenemos más remedio que hacerlo. Pero tenemos otras opciones cuando se utilizan Scrum y,
procesos iterativos incrementales. Estas alternativas Scrum se presentan en detalle en el capítulo 9, “La relación entre la
gestión del producto / cliente y el equipo de desarrollo.”
La realidad que oculta
Nuestra siguiente hipotética empresa es Coho, uno de los mayores distribuidores de coches en Europa. La alta dirección fue el
despliegue de Scrum para mejorar su capacidad para introducir nuevas capacidades a los clientes. En el primer Sprint del primer
proyecto, los equipos de Scrum entregan más funcionalidad que se habían comprometido. Todo el mundo, desde la alta dirección a
los clientes, estaba emocionado y satisfecho.
Para el segundo Sprint, los equipos de Scrum comprometidos con una gran cantidad de la Pila de Producto. Dos semanas en el
Sprint, los equipos se dieron cuenta de que estaban en problemas. Cuando los equipos se reunieron, todos tenían la misma
historia: la funcionalidad fue significativamente más complejo y difícil que la primera Sprint. De las 24 piezas de funcionalidad los
equipos habían comprometido a, se dieron cuenta de que pudieran completar 7 u 8. Después de la forma en que todos ellos
habían vitoreado en la primera revisión de Sprint, que temían que pasaría si sólo el 33 por ciento de su segundo Sprint eran
hecho. Los equipos decidieron que la única manera en que podría entregar todo estaba a prueba de caída y refactorización; que
simplemente una palmada a la nueva funcionalidad en la parte superior de la edad. Se dieron cuenta de que al comprometerse a
mucho menos de la tercera Sprint tendrían tiempo para volver atrás y corregir todo. Uno de sus ScrumMasters les preguntó lo que
estaban haciendo. El ScrumMaster se dio cuenta de que Scrum es empírica sobre el progreso y la transparencia, por lo que el
propietario del producto siempre sabe lo que está pasando y puede tomar las mejores decisiones. no era el enfoque del equipo
decidió tomar ocultar las cosas desde el propietario del producto? No estaban pretendiendo que se hacían las cosas cuando no lo
eran? Los equipos, después de expresar sus temores de que el propietario del producto podría disparar todos ellos, fueron al
dueño del producto y le mostró dónde estaban y qué problemas se estaban quedando en. El propietario del producto, mirándolos,
les dijo: “Yo sabía que sobrecargadas. Iba a preguntar lo que estaba pasando. Tenía la esperanza de que tal vez sabía algo que
no lo hice. Bien, estoy muy contenta de que vino a mí.”El propietario del producto y los equipos reducen los compromisos para que
coincida con sus nuevos hallazgos y procedieron,
Cuando discuto este tipo de miedo en cursos que imparto, propio miedo de los asistentes es palpable. Los usuarios pronto-a-ser
Scrum no piensan que la transparencia, o la verdad, es aceptable en la que trabajan. Me dicen que van a ser despedidos si dicen la
verdad. La verdad no es lo que sus clientes quieren oír. Me dicen que sus clientes van a encontrar a otra persona que va a mentir a
ellos si no lo hacen. He visto esto en clase después de clase durante cinco años. La gente en el desarrollo de productos piensan
que sus clientes quieren oír noticias sólo si es una buena noticia y prefieren escuchar una mentira que la verdad. “La mentira” es
una palabra dura. Pero lo que más se puede llamar diciendo que algo es verdad cuando se sabe que no es verdad? ¿Qué más se
llama a engañar a alguien con la información o retener la información que les habría dado lugar a mejores decisiones? Los
propietarios de producto quieren creer en la magia, y los desarrolladores apoyan la creencia por mentir. “¿Puede usted hacer este
proyecto antes de esa fecha?” “Claro, no hay problema.”
Los desarrolladores son conscientes de las complejidades que causan cambios en sus estimaciones originales. Son conscientes de
que el cliente no está contento. Si un jefe de proyecto es abordado por una

al cliente 60 por ciento del camino a través de un proyecto y le preguntó cómo va el proyecto, el director del proyecto no
sabe realmente. Ella sabe que algunas cosas van bien. También sabe que algunas cosas no van tan bien. También sabe
que ella no ha comprobado en algunas cosas que podrían resultar crítico. Sin embargo, decir “no sé” es inaceptable, por lo
que los gerentes de proyecto han aprendido a decir: “Muy bien,” “Justo en el blanco”, “Pedazo de pastel”, o algo
equivalente que hará que el cliente se vaya y dejar que se trate de sacar todo el tiempo, en el precio. Básicamente,
mienten. Es más simple que la exposición de todos los matices y complejidades que se suman a “No sé.”
Los gerentes de proyecto también podrían creer que la mentira ahorra tiempo. Pero debido a Scrum se basa en la transparencia, la
tergiversación socava toda la aplicación de Scrum. Si los propietarios de producto no saben exactamente dónde están las cosas en
cualquier punto en el tiempo, no estarán en condiciones de tomar las mejores decisiones posibles acerca de cómo lograr sus
objetivos. Ellos necesitan la mejor información posible, ya sea que lo ven como bueno o malo.
Resumen
El carácter iterativo e incremental de Scrum causa el cambio dentro de la empresa. La empresa debe adaptarse a los cambios mensuales de proyectos, no
sólo cambiar al final. Un proyecto produce incrementos potencialmente utilizables de todo el sistema cada mes. Equipos producen piezas completas de ese
incremento diario. Esta frecuencia de trabajo realizado provoca el cambio. comportamiento disfuncional que estaba oculto se hace visible. Los problemas
causados por el comportamiento disfuncional se magnifican. Como a resolver el comportamiento disfuncional, no creo que la solución es completa. Desde
hace 25 años, todo hábito se describe en este capítulo ha proporcionado mejores soluciones a las personas en su empresa que cualquier otra cosa tiene.
Ahora bien, estas personas van a intentar algo mejor, algo que incluso se siente bien. Pero cuando surgen los problemas de desarrollo y gestión de
productos, su gente se va a sentir desnudo. No se han acumulado memoria muscular en estas nuevas formas aún. Por lo tanto, debido a que se siente
seguro, sólo por ahora-regresan a estos hábitos, los viejos hábitos-fiable. Su empresa y su gente van a dar cuatro pasos hacia adelante y tres atrás, dos
pasos adelante y uno atrás. Ellos progresar continuamente, pero van a lamentar su incapacidad para ignorar y trascender los viejos hábitos. Scrum, sin
embargo, no les deje pasar por alto las consecuencias de estos hábitos. pero van a lamentar su incapacidad para ignorar y trascender los viejos hábitos.
Scrum, sin embargo, no les deje pasar por alto las consecuencias de estos hábitos. pero van a lamentar su incapacidad para ignorar y trascender los viejos
hábitos. Scrum, sin embargo, no les deje pasar por alto las consecuencias de estos hábitos.
Capítulo 6
Prácticas de la organización
En este capítulo:
# 1: La organización de la empresa Trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.46
# 2: La organización de la empresa para un trabajo de alta tecnología-empresa de productos. . . . 0.46
# 3: La organización de la empresa el trabajo en otras empresas. . . . . . . . . . . . . . . . . . . . . . . 0.51
# 4: La organización de la empresa Trabajo para los nuevos sistemas que automatizan

una operación de la empresa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.52
# 5: La organización de la complejidad de múltiples vistas. . . . . . . . . . . . . . . . . . . . . . . . . . 0.54
# 6: La organización para optimizar el producto de software Arquitecturas familia. . . . . 0.55
Cuando la empresa utiliza Scrum, puede supervisar todo el desarrollo de cada Sprint. Puede redirigir el trabajo de la empresa para
aprovechar las nuevas oportunidades y maximizar el retorno de la empresa de inversión (ROI). toda la empresa puede cambiar de
rumbo rápidamente. Para ser capaz de hacer estas cosas, debe tener todo el trabajo de su empresa en una sola Pila de Producto. La
creación de una cartera de pedidos de este tipo puede tomar más de un año y es muy difícil. Una vez hecho esto, sin embargo, se
preguntará cómo le hizo previamente. Sin una visión integrada de toda la obra de la empresa, es imposible evaluar el progreso y realizar
análisis de impacto. En este capítulo, voy a explicar cómo crear una cartera de dicha empresa de productos. Una visión general se
presenta en el “# 1: La organización de la empresa de trabajo” sección. La estructura de la empresa Cartera del producto es algo
diferente para las empresas de productos de alta tecnología que es para una empresa que despliega la tecnología para hacer sus
operaciones más competitivo. Pronto nos ocuparemos de pedidos pendientes hightechnology de producto en el “# 2: La organización de
la empresa para un trabajo de alta tecnología de la empresa de productos” sección. En “# 3: La organización de la empresa el trabajo en
otras empresas,” vamos a ver en la creación de una reserva de pedidos de productos de otras empresas.
Otra variante de la Pila de Producto está organizando el trabajo cuando se está desarrollando una nueva operación de la empresa, incluyendo
los sistemas que automatizan la misma. Este escenario se discute en “# 4:. La organización de la empresa Trabajo para los nuevos sistemas
que automatizan una operación de la empresa” una acumulación del producto es el trabajo de la empresa. A menudo se requieren muchos
puntos de vista de este trabajo. El “# 5: La organización de la complejidad de múltiples vistas” sección muestra cómo correlacionar y gestionar
múltiples puntos de vista. La información de esta sección le ayudará a manejar algunas complejidades de mantener múltiples puntos de vista.
45
46 Parte II Empezar a usar Scrum de Empresa Trabajo
Por último, vamos a ver cómo organizar el trabajo si su empresa está utilizando una arquitectura familia de productos de software para
optimizar la reutilización en “# 6: La organización para optimizar el producto de software Arquitecturas familia.”
# 1: organizar el trabajo de la empresa

Scrum parece organizar el trabajo en pedidos pendientes de producto. Pero ¿cómo organizar el trabajo de toda mi empresa en una Pila de
Producto y cuáles son los beneficios de hacerlo?
Podemos realizar todo el trabajo de desarrollo de una empresa en una reserva de pedidos de productos de la empresa. Para crear una cartera
de productos de la empresa, crear una visión empresarial de todos los proyectos y programas. Estos puntos de vista son descomposiciones de
arriba hacia abajo que organizan la reserva de pedidos de productos de arquitectura de la empresa de productos, organización o programas. Si
la empresa vende productos de alta tecnología, utilizar un producto de descomposición que consiste en la siguiente información: familia de
productos, producto, características, función y tarea. Si la empresa utiliza la tecnología para automatizar sus productos, al igual que lo hace una
entidad financiera, utilice los detalles de la estructura organizativa. El resto de este capítulo se presentan formas de crear estos puntos de vista y
su vinculación a la Pila de Producto de cada proyecto. A medida que nos relacionamos y enlace la reserva de pedidos de productos detallada de
los proyectos Scrum a la vista de la empresa, la reserva de pedidos de productos de la empresa comienza a tomar forma. A continuación,
rellenar la reserva de pedidos de productos de la empresa que se inician más proyectos. Debe, finalmente, identificar, organizar y priorizar todo
el trabajo actual y prevista.
En la medida en que todo el trabajo de la empresa se encuentra en una reserva de pedidos de productos de la empresa, se puede
seguir el progreso de todos los programas, la liberación y proyectos a través de burn-down. Para cualquier área de interés, un gráfico
de burn-down seguimiento del progreso hacia una meta de liberación a través del tiempo. Con burn-down, puede evaluar los diversos
proyectos de impacto y programas tienen el uno del otro y en la empresa. Es probable que sea una sorpresa desagradable. Los
programas que usted pensó que estaban en marcha podría estar detrás. Puede encontrarse con que la gente se dividan entre muchos
proyectos se ha ralentizado de trabajo general en lugar de permitir a la empresa a tomar más. Obtendrá una gran cantidad de
información, algunos confirman sus esperanzas y demás aplastarlas. Usted, sin embargo, tener información sólida con la que
gestionar la empresa.
# 2: La organización de la empresa para un trabajo de alta tecnología de la empresa de

productos
Mi empresa fabrica productos que se venden a los clientes externos. Scrum organiza el trabajo en pedidos pendientes de producto. ¿Cómo
puedo organizar el trabajo de mi empresa? En particular, si tengo la oportunidad de hacer algo nuevo, ¿cómo reorganizar rápidamente para
hacerlo?
Un atasco de producto puede representar todo el trabajo de desarrollo conocido para los productos de una empresa. Los productos se
descomponen en características, funciones, actividades y tareas, lo que refleja la estructura del producto y la terminología. Un atasco de
producto define los cambios que son necesarios en este

Capítulo 6 Prácticas de la organización 47
nivel más bajo. Esta descomposición se pueden agregar en las familias de productos y todo el trabajo de desarrollo de las empresas,
como se muestra en la Figura 6-1.
Familia de
productos Producto Característica Actividad función Reserva CARNÉ DE IDENTIDAD
Finanzas
personales ......
Impuestos
corporativos ......
Whirl- Personal
impuestos viento Información acerca de ti
personales Deluxe
Estado Personal Información
Personal Localización
El usuario debe ser capaz
de escribir en diferentes
números de teléfono de
Dirección de Correo / formato
Teléfono C413
Estado de residencia
Figura 6-1 La cartera de productos de la empresa
Una arquitectura de producto o sistema consta de módulos o componentes en el nivel más bajo de descomposición. Uno o más de
estos componentes serán transformados para satisfacer un elemento de la Pila de Producto. Podemos organizar una acumulación del
producto separado para la funcionalidad del producto comunes a más de un producto. estructura de este Pila de Producto refleja la
arquitectura del sistema, como se muestra en la Figura 6.2. priorización general por el bien de la empresa es obligatoria. El
propietario del producto de la funcionalidad común tiene que ser alguien con retorno de la inversión responsabilidad (ROI) para todos
los productos de la empresa.
SPF SPF
Prty
Aspecto Tarea actividad Módulo tamaño CIprty
CARNÉ DE IDENTIDAD CI tamaño
Interfaz de usuario Número de teléfono
de pantalla Controles con Entrada
formato numérico doméstico C413 72 2 61 1
La lógica de
negocio Base de
datos controla la
Base de Datos
Figura 6-2 La cartera de productos de infraestructura común de requisitos

Veamos cómo podemos responder a un cliente que requiere una funcionalidad mejorada en la familia de productos Impuesto sobre
Sociedades. Se valoran los esfuerzos para hacer que la mejora en 100 puntos de trabajo. (A punto de trabajo es una medida
arbitraria.) El cliente necesita un plazo de seis meses. Estamos en el quinto mes del plan anual de nuestra empresa. Un gráfico de
burn-down empresa muestra el plan de línea de base anual, como se muestra en la Figura 6-3.
Anual Hoja de Ruta
2000
1500
Trabajo 1000
500
0
11 10 9 8 7 6 5 4 3 2 1 12
Meses
Figura 6-3 Burn-abajo de la hoja de ruta del plan de línea de base
Evaluamos el progreso contra el plan. El plan se mantiene en una cartera de productos de la empresa. La medida es en
contra del plan actual más, que es generalmente diferente del plan de línea de base. En el quinto mes, podemos comparar
la funcionalidad prevista actualmente en contra de lo que ya ha sido entregado, como se muestra en la Figura 6-4.
La diferencia entre los dos planes representa el grado en que la empresa está por delante o por detrás del plan. La figura
6-4 muestra que estamos detrás de nuestro plan y detrás de nuestros compromisos.
Empresa Real vs. trabajo planificado
2000
1800
1600
1400
1200
Trabajo 1000
800
600
400 Plan de Planificación de la funcionalidad de línea de
200 base-Entregado funcionalidad real
0
11 10 9 8 7 6 5 4 3 2 1 12
Hora
Figura 6-4 Burn-abajo del plan de reales frente a la empresa

Al final del quinto mes, el plan nos ha comprometido a tener 1214 puntos de izquierda trabajo. En cambio, hay 1320 puntos de
trabajo que quede por realizar. Si añadimos los nuevos 100 puntos de trabajo solicitado en la línea de productos impuestos
corporativos, la programada versus medición real se vuelve peor, como se muestra en la Figura 6-5.
Tomando un trabajo adicional
2000
1800
1600
1400
1200
Trabajo 1000
800
600 Real con el plan previsto nuevo trabajo
400 El rendimiento real hasta la fecha
200
0
11 10 9 8 7 6 5 4 3 2 1 12
Meses
Figura 6-5 Burn-down del plan en comparación con el nuevo trabajo real añadido
El trabajo planificado es la línea de tendencia inferior. El trabajo real dejado sin el trabajo adicional que tener en cuenta es la línea de
tendencia central. La línea de tendencia superior muestra el trabajo real que queda si el nuevo trabajo se ha comprometido a. Todas
estas líneas de tendencia se han proyectado a fin de año para mostrar la probable brecha entre el trabajo previsto y real.
Para asumir los impuestos corporativos mejoras adicionales, tenemos que liberará a otros trabajos. Podríamos aumentar los costos a través de
nuevas contrataciones adicionales, pero la productividad disminuye a medida que las personas nuevas son llevados a bordo y aumenta sólo
después de seis meses o así. Tenemos que encontrar algún otro trabajo que podemos aplazar. En primer lugar, vamos a añadir el nuevo
trabajo a la parte Impuesto de Sociedades de la Pila de Producto. Es la quinta fila de la figura 6-6. Luego estimamos y priorizamos que en
comparación con todas las demás tareas de la cartera de productos de la empresa. Para las técnicas de estimación de Scrum, véase el
reciente libro de Mike Cohn, Estimación ágil y Planificación ( Prentice Hall, 2004). La reserva de pedidos de la empresa priorizado Producto
(resumido) se parece a la Figura 6-6.
Necesitamos dar cabida a 206 nuevos puntos de trabajo (100 nuevos puntos de trabajo añaden al déficit actual de 106 puntos).
Podemos liberará de trabajo de menor prioridad. El primer punto de poner en espera es la prioridad más baja en la fila inferior:
Impuestos Personales, estado de residencia, Punto 6. Los 148 puntos restantes de trabajo que se diferido (206 necesita menos los
58 puntos de punto 6) tiene que venir de el Personal Finances producto, la siguiente prioridad más baja. la totalidad de su carga de
trabajo tiene 1048 puntos de trabajo previstas para el año.
empresa ProductoFamilia Producto Característica Actividad función Reserva Tamaño

CARNÉ DE IDENTIDAD de dominio Prty
impuestos torbellino Deluxe La información personal sobre Estado de

personales Tú residencia artículo 5 90 33
impuestos torbellino Deluxe La información personal sobre Dirección de Correo / Teléfono Tema
personales Tú 3 82 47
impuestos torbellino Deluxe La información personal sobre Dirección de Correo / Teléfono artículo
Impuestos
corporativos Nuevo trabajo 72 100

personales Tú residencia artículo 7 29
sesenta y cinco
impuestos torbellino Deluxe La información personal sobre Dirección de Correo / Teléfono artículo
El usuario debe
ser capaz de
escribir en
diferentes
números de
impuestos torbellino Deluxe La información personal sobre Dirección de Correo / teléfono de
personales Tú Teléfono formato C413 Común 62 20
Impuestos trabajo com-
corporativos prometidos 42 432

Finanzas trabajo com-
personales prometidos 12 1048

Figura 6-6 La cartera de productos de la empresa con el nuevo trabajo
Cuando los detalles y observamos la quemadura hacia abajo para la línea de productos finanzas personales, es antes de lo previsto. A
continuación, profundizar en su trabajo para ver dónde podemos liberar un poco de esfuerzo y reducir al mínimo el impacto. En la Figura 6-7,
que profundiza para ver justo en el trabajo para las finanzas personales.
Las finanzas personales Plan de Real vs.
400
La funcionalidad real suministrado plan
350
previsto de funcionalidad que se
300 entregarán
250
Trabajo 200
150
100
50
0
11 10 9 8 7 6 5 4 3 2 1 12
Meses
Figura 6-7 Las finanzas personales plan en comparación real

El trabajo Finanzas Personales es antes de lo previsto. Al final del quinto mes, habíamos planeado tener 217 puntos de trabajo izquierda,
pero sólo 160 permanecen. Estamos 57 puntos antes de lo previsto. Podríamos ser capaces de utilizar esta capacidad para el nuevo trabajo
en la línea de productos impuestos a las empresas. Profundizando en las finanzas personales funciona, podemos ver qué áreas específicas
antes de lo previsto. A continuación, podemos evaluar si la gente que hace que el trabajo calificado y son capaces de ayudar a los impuestos
a las empresas de productos. Si lo están, podríamos ser capaces de volver a implementarlas. Vamos a pedir al propietario del producto de la
línea de producto de Finanzas Personales si él o ella puede formar un nuevo equipo que puede ser reasignado durante cuatro meses.
Este ejercicio se hizo cargo de la nueva obra y nos permitió conseguir el negocio del nuevo cliente. Se evaluó el trabajo en curso
de la empresa para identificar el exceso de capacidad. Podríamos hacer lo mismo cada mes para detectar deficiencias y
desviaciones.
A medida que cambian las prioridades y se producen nuevas oportunidades, podemos alinear nuestro trabajo para maximizar el retorno de la inversión de la
empresa. Los propietarios del producto en todos los niveles de la empresa son capaces de realizar un seguimiento de su trabajo en contra de sus compromisos.
Podemos cambiar la empresa para aprovechar las nuevas oportunidades mientras que la evaluación y luego el seguimiento del impacto.
# 3: La organización de la empresa el trabajo en otras empresas

Mi compañía utiliza nuestra organización tecnología de la información para desarrollar software para mis operaciones de línea. Este
software hace que las operaciones sean más eficaces. ¿De qué manera la gestión de estas operaciones utilizan Scrum, o debo dejar
esto al departamento de Tecnología de la Información?
Los propietarios de los productos son los responsables de sus operaciones. Definen el trabajo para mejorar sus productos en la reserva de pedidos de
productos. El trabajo de desarrollo puede ser para mejorar los sistemas automatizados o manuales de operaciones. La formación y el trabajo de ejecución
es también parte de la reserva de pedidos de productos. La reserva de pedidos de productos está ordenada por prioridad del sistema y para organizar el
trabajo dentro de la organización de Tecnología de la Información (IT). Los equipos de TI se forman sobre la base de producto y los identificadores del
sistema.
Podemos utilizar el siguiente ejemplo de una empresa bancaria para ver cómo hacer esto. Un banco vende productos financieros
a sus clientes. Se organiza en líneas de negocio (LOB). Cada línea de negocio consiste en las operaciones que venden productos
y servicios financieros. Estas operaciones están automatizadas a través de los sistemas internos. Por ejemplo, un banco puede
tener un fideicomiso LOB, un LOB Banca Comercial, Banca de Consumo y una LOB. Dentro del Consumidor Bancario LOB es
una operación Teller, una operación de creación del préstamo, y así sucesivamente. Estos son accesibles en Desarrollo de
Producto y Gestión de que maquina los diversos productos financieros. Cada operación es apoyada por uno o más sistemas
informáticos. A medida que nuevos productos son concebidos, las operaciones y los sistemas de apoyo que deben desarrollarse
o mejorarse. El producto
La cartera, o requisitos, para ello están organizados por LOB, el funcionamiento, la actividad y tarea. Figura 6-8
representa una descomposición tal.
Línea de la empresa
Operación de Negocios Producto Actividad Sistema componente Requisito Tamaño prty
Banco Confianza ......
Banca
corporativa ......
Banca de
consumo Cajero Hipoteca
El cliente puede hacer

un depósito a través de
Ahorros depósitos Teller31 C524 cuentas 33 13
El cliente puede realizar

depositarse usando
nuevo terminal de cajero
automático
C325 42 21
Retiros
Comprobación
Plataforma IRA Estado civil
Informacion
401K personal
Hipoteca Ubicación préstamo
personal Ahorros Comprobación
Figura 6-8 La cartera de productos de la empresa financiera
# 4: La organización de la empresa Trabajo para los nuevos sistemas que automatizan

una operación de la empresa
Estamos construyendo un nuevo sistema para una división en nuestra empresa. Se reemplazará un mosaico, más viejo sistema. ¿Cómo puede
la obra será dirigida por el jefe de operaciones de esa división de manera que tenga sentido para ella, mientras es organizada y priorizada de una
manera que tenga sentido desde un punto de vista arquitectura de sistemas?
Los datos son el negocio de algunas empresas, tales como informes de crédito, enciclopedias, noticias, y la cartografía. Estas empresas
adquieren, el formato, y venden los datos. Las empresas necesitan a veces para construir sistemas completamente nuevos para este tipo de
operaciones. Los responsables de estas operaciones necesitan para correlacionar y priorizar el desarrollo de una nueva operación de negocios
con la construcción de nuevos sistemas de automatizarlo.

La operación comercial está organizada en varias funciones primarias. Los datos se adquiere. La técnica ha sido preparado
continuamente para ofrecer un valor adicional a través de nuevas relaciones y atributos. Los datos se gestiona para la exactitud y
calidad. Los datos se extraen para su venta a los clientes. Algunos extractos son periódicas, mientras que otros son continuas. En
el nivel más bajo de la operación del negocio, se realizan actividades y tareas. Estas tareas son manuales, manual automatizada
con asistencia, o completamente automatizado. El sistema automatizado está organizado como una arquitectura que tiene
atributos no funcionales tales como el rendimiento, la escalabilidad, seguridad y flujo de trabajo. La persona que dirige esta
operación es el propietario del producto. Él o ella es responsable de la rentabilidad global y la inversión a largo plazo en el nuevo
sistema. Él o ella es responsable de dar prioridad al desarrollo para apoyar una implementación por fases, seguro, así como para
cumplir con las dependencias técnicas. Como ejemplo de las dependencias técnicas, el marco de flujo de trabajo podría ser
esencial tener en su lugar antes de la implementación de adquisición y funcionalidad de edición. La intersección de
descomposición operativa y sistemas se muestra en la Figura 6-9. El trabajo Product Backlog se produce en la intersección.
Pila de Producto
divisiones departamentos secciones Subsección Actividades Tareas Componente módulo Sub- sistema Sistema
operaciones de Adquisición TCX01
Aseo TCZ01
Gestión de datos
TDX01
Gestión de datos
Seguridad TDX01-01 TDX01
Control de
Gestión de datos Calidad e
Integridad TDX01-02 TDX01
Control de
Integridad Nueva Referencial de Datos
Integridad TDX01-03 TDX01
Control de
Integridad
Control de
Integridad
Control de
Gestión de datos Calidad e Configurar
Integridad Área CSetup02 Reflnteg TDX01-04 TDX01
Control de
Gestión de datos Calidad e Seleccionar
Integridad Población CSetup03 Reflnteg TDX01-05 TDX01
Control de
Gestión de datos Calidad e Seleccionar Ver zonas a ser seleccionados
Integridad Población CSetup04 Reflnteg TDX01-05 TDX01
Control de mesas de exhibición y

Gestión de datos Calidad e Seleccionar los índices de área
Integridad Población seleccionada CSetup05 Reflnteg TDX01-05 TDX01
Control de
Gestión de datos Calidad e Comprobar
Integridad iniciar CSetup04 Reflnteg TDX01-06 TDX01
Control de
Integridad Nuevo Campo de Datos
Integridad TDX01
Extracción
Figura 6-9 Intersección de puntos de vista operativos y del sistema en una Pila de Producto
La partida de la Pila de Producto “áreas de pantalla para seleccionar” forma parte de la función de gestión de datos de la operación. Se
utiliza por el supervisor de la sección de integridad referencial para inspeccionar y comprobar los datos de integridad referencial
frecuencia. El nuevo sistema tiene un componente, CSetup04 (que es parte del subsistema de TDX01-05 y Sistema TDX01), para
automatizar este. El punto de vista operativo también utiliza elementos de la Pila de Producto para describir el trabajo para mejorar una
actividad de trabajo, incluyendo la creación de la documentación y el reciclaje. Incluye columnas que reflejan las prioridades de
ejecución operativos y esfuerzos. La visión de los sistemas incluye una columna para el esfuerzo de construir el componente y la
prioridad en la que se desarrollará. La visión de los sistemas también incluye elementos de la Pila del producto para los sistemas que
proporcionan la infraestructura utilizada por los otros sistemas, como el flujo de trabajo. Otro trabajo, como la construcción de entornos
de desarrollo distribuidos y actualizar el entorno de producción, tienen sus propios elementos de la Pila de Producto. Dicha cartera de
productos se prioriza de acuerdo a la secuencia más lógica para el desarrollo del sistema.
# 5: La organización de la complejidad de múltiples Vistas

He visto cómo crear varias vistas de una reserva de pedidos de productos de la empresa. Sin embargo, hay algunas complejidades no se han
analizado. ¿Puede describir cómo manejarlos?
La cartera de productos es una lista priorizada de trabajo. Podemos relacionarlo con tres áreas: su presencia en un producto o
sistema, su incidencia en la mejora de una operación de negocios, y su ocurrencia en la arquitectura de sistemas. Podemos
entonces crear vistas complejas mediante la intersección de estas relaciones. Figura 6-9, visto en la sección anterior, muestra un
ejemplo de varias vistas de una Pila de Producto. Se muestra la relación de un punto de vista operacional negocio (Divisiones,
Departamentos, Secciones, subsección, actividades y tareas columnas) a la obra en una Pila de Producto (columna Pila de
Producto), que a su vez se relaciona con la vista de la arquitectura de sistemas (Sistema, Subsistema Módulo, columnas, y
componente).
elementos de la Pila de productos van desde pequeñas a grandes. Los artículos pequeños por lo general se refieren a las operaciones comerciales,
componentes de la arquitectura del sistema, o tareas de productos de grano fino, como se muestra en la Figura 6-9 anterior. A medida que los
artículos aumentan de tamaño, los elementos correspondientes se refieren a aumentar de tamaño. Por ejemplo, un elemento de la Pila de Producto
conoce como “fluir automáticamente las aplicaciones de la investigación a la aceptación y la notificación” se refiere a los subsistemas, actividades
comerciales, productos y temas. Es de gran nivel y alta.
Módulos o componentes menudo son utilizados por más de una actividad de tarea o producto operacional. El elemento Pila de Producto
para cambiar un componente continuación, se debe introducir una vez por cada
tiempo que automatiza la tarea o actividad. Sin embargo, se estima que sólo una de las ocurrencias. Todos los casos heredan la
necesidad más alta prioridad y están programados en consecuencia. A veces múltiples ocurrencias de un elemento de la Pila de
Producto se indican en una columna en la hoja de cálculo.
# 6: La organización para optimizar el producto de software familia

Arquitecturas
Algunas empresas desarrollan productos y familias de productos. Algunas de las funcionalidades es producto específico, pero otras partes
son compartidos entre todos los productos. ¿Cómo está organizado este trabajo con Scrum?
Muchas empresas tienen más de un producto. A menudo se separan funcionalidad común en una biblioteca de componentes de infraestructura para simplificar la
definición de nuevos productos o mejorar un producto existente. Cuando los productos son desarrollados, algunos componentes son peculiares del producto, pero
otros componentes ya podrían estar en la infraestructura, reduciendo el tiempo y los costes de desarrollo en general. Si algunas funciones potencialmente común
no está ya en la infraestructura, se desarrolla allí para reducir los costes para los futuros productos. Al mantener la infraestructura en buen estado y bien
catalogado, desarrollo de nuevos productos se simplifica. El papel de la reserva de pedidos del producto tiene que ampliarse para hacer frente a esta
infraestructura común. La reserva de pedidos de productos por lo general sólo se enumeran los requisitos de trabajo a realizar para un producto. Ahora la reserva
de pedidos del producto reflejará la estructura de toda la familia de productos. La familia de productos se descompone en productos, características, funciones y
actividades, como se muestra en la figura 6-10. Cuando se necesita algo nuevo, se añade el requisito. Algunos de los requisitos de la Pila productos serán
satisfechos por los componentes o bases de datos en la infraestructura común. Figura 6-10 demuestra esto mediante el uso del designador “Common” en la
columna de dominio. Si se trata de un componente existente que hay que mejorar, el ID para el componente existente se registra. Cuando la reserva de pedidos de
productos está ordenada por prioridad requerimiento y exigencia, que comienza con una lista priorizada de trabajo a realizar. Algunos de los requisitos de la Pila
productos serán satisfechos por los componentes o bases de datos en la infraestructura común. Figura 6-10 demuestra esto mediante el uso del designador
“Common” en la columna de dominio. Si se trata de un componente existente que hay que mejorar, el ID para el componente existente se registra. Cuando la
reserva de pedidos de productos está ordenada por prioridad requerimiento y exigencia, que comienza con una lista priorizada de trabajo a realizar. Algunos de los
requisitos de la Pila productos serán satisfechos por los componentes o bases de datos en la infraestructura común. Figura 6-10 demuestra esto mediante el uso
del designador “Common” en la columna de dominio. Si se trata de un componente existente que hay que mejorar, el ID para el componente existente se registra.
Cuando la reserva de pedidos de productos está ordenada por prioridad requerimiento y exigencia, que comienza con una lista priorizada de trabajo a realizar.
La infraestructura común es compatible con todos los productos. Tiene su propia reserva de pedidos de productos. Esta es organizado por
aspecto. Este retraso se rellena con los trabajos de mantenimiento y todo el trabajo requerido para cada familia de productos y producto,
como se muestra en la figura 6-11.

Producto Característica Función Actividad Reserva Dominio

CARNÉ DE IDENTIDAD Tamaño prty
torbellino Informacion
Especial personal Acerca de ti
Estado Personal Información
Personal Localización
Dirección de Correo / formato
Teléfono C413 Común 72 2
Estado de residencia
múltiple Residencia Otro
Estado de Ingresos
Ocupación
formato
Opción de teléfono listado C413 Común 72 2
Crear ID de usuario del
huracán Katrina situaciones
especiales
dependientes dependientes
Información de
importación Importar desde el año pasado
Los dependientes
importar su
información
Impuestos federales Ingresos Los salarios y sueldos
Figura 6-10 La familia de productos de software Pila de Producto de requisitos
SPF SPF Prty

Aspecto Actividad Tarea Módulo CARNÉ DE IDENTIDAD tamaño CIprty CI tamaño
Interfaz de usuario de Entrada numérica con formato Número de teléfono

pantalla controles doméstico C413 72 2 61 1
La lógica de negocio Base de
datos controla la Base de Datos
Figura 6-11 La cartera de productos de infraestructura común de requisitos

El propietario del producto para todas las familias de productos prioriza la reserva de pedidos de productos de infraestructura. Sólo que esta
persona puede evaluar todas las prioridades de la familia de productos de unos contra otros y contra la necesidad de mantener y sostener la
infraestructura común. Esta prioridad se mantiene en la columna de la infraestructura común (CI) Prty. El tamaño relativo de la obra, según lo
evaluado por los equipos de infraestructura, se mantiene en la columna de la CI tamaño. Este trabajo podría ser diferente en tamaño que la
estimada por el equipo de productos. Tenga en cuenta que los requisitos de reserva de pedidos de productos duplicados de la figura 6-11 se
han fusionado en una sola.

Índice
UNA do
rendición de cuentas, compensación y, 81 cambio
organizaciones de nivel de actividad, 70-71, 77 de evaluar, 5-7 conflicto y, 6 empresas en transición,
adaptación, 103, 105, 113 adoptan Scrum 29-41 y funcionalidad, 90-91 en las responsabilidades
del trabajo, 6-7 memorias musculares que dificultan,
aspectos, 3 21-27 priorización, 17, 54-55, 73 revisión de código
evaluar los cambios, 5-7, 7-8 en el control de procesos , 103 compromisos, 25,
advertencias esfuerzo requerido, 5 86-89 ancho de banda de comunicación, 136-137
servicios financieros, 32-36, 13-15 políticas de compensación, 6, 14, gráfico de
primer mes impedimentos, 17 evaluación 81 complejidad, 104 conflicto, 6, 16-17
resolución de conflictos, la funcionalidad de 76
núcleo, 90-97
proveedores de software independientes, 37-41 reunión
inicial, el 11 de proceso para, 9-11 razones, 5
segundo mes, 15-17 tercer mes y más allá,

18-19 productos de tarjetas de valor añadido, Cuerpo de negocios ( Freedman), 135 costes
29-32 Deportes de aventura, 4
controlan a través de proyectos, 86, 5
Gestión de proyectos ágil con Scrum extrapolación cambios en la infraestructura,
(Schwaber), 86 técnicas ágil, 92-93 de solicitudes fuera del rotador, 19, 94
117-118 predecir equipos multi-funcionales
API (interfaz de programación de aplicaciones), 92
arquitecturas
en descomposición, de 47 años Definido, 113 de conformación, 142-143
integrar los sistemas de capas múltiples, responsabilidades de, 22, 106 proceso en
63-66 optimización, 55-57 proceso en cascada y, 143-145 gestión de carga de trabajo
cascada, los equipos de proyectos de auditoría y, 135 cultura. Ver cultura de la empresa CVS
22, 125 Automatización de las operaciones, paquete de software, 74
52-54
segundo re
la comunicación de ancho de banda, Scrums diarias
136-137 definido, 113 membresía equipo distribuido, 82
planes iniciales iniciando Scrum, 10 de desarrollo offshore y, 138
burn-down carta, 48-49 valor gestionar, 87 organizar el trabajo de la empresa, 72 en el flujo de
finalidad, 4, 106 banco, 73, 79 trabajos de Scrum, 107-108 ScrumMaster, la formación del
licitación, 133-134 impedimentos de intercambio de equipo 15, 75 sala de equipo, la transparencia y la
ideas, de 16 errores, la velocidad de desarrollo y, 124, 117 defectos, la velocidad de desarrollo y, 96
96 gráfico de burn-down de control de proceso definido, 102 fechas de
entrega, 86, 94 dependencias, externos, 62, 83
de los planes de referencia, 48-49, 87 del
Product Backlog, 109-111, 114 Sprint Backlog,
115 seguimiento del progreso, 124
147
148 los equipos de desarrollo
los equipos de desarrollo etapa de formación (equipos), 75

colaboración en, 132 Forrester Research, 129 Freedman,
funcionalidad básica, 90-92 David H., 135 especialización
creación, 73 definido, 115 funcional, 22 funcionalidad
Determinar los impedimentos, 17 control de proyectos a través de, 86 de núcleo,

iniciando Scrum, la gestión de personas 90-97 determinar ROI, 87 documentar, 112
9-11, 78-79 costes extrapolación, 5 realidad escondite y, 26
organización para el trabajo de la empresa, gestión de incrementos de, 112 cambios de infraestructura
productos y 70-73, 85-97 Transición cartera de y, 90-93 integración de múltiples capa
proyectos, la velocidad de desarrollo 15
funcionalidad del núcleo, 91

núcleos muertos y, 94-96
definida, 39, 86, 117 sistemas, 63-66 y calidad, las
documentación responsabilidades del equipo 90, 106 de
modificaciones básicas y, 91 prácticas los costes variables, procesos 130-131
de ingeniería, 60, 68 para la cascada y, 22 trabajadas organizado por,
funcionalidad, 112 prácticas de la 60-62
organización, 54 desarrollo del proceso,
16 proceso en cascada, 22-23
sol
Gmail, Google
mi 80, 80
proceso empírico control, 26, 102-103, 114 prácticas de
ingeniería
yo
la integración de los sistemas de capas múltiples, 63-66 integración de
impedimentos
trabajo de los equipos, 66-68 información general, 59
la adopción de Scrum, 17 decisiones con
respecto a las responsabilidades de gestión, 4,

trabajo organizado por la funcionalidad, 60-62 Cultura de la
7 Observando en TPB, 15-16 solicitudes fuera
empresa
de la manga, 18-19, 16-17 fuentes de
cambiante, 4-7, 18-19 mando y control,
transparencia del 18 de desarrollo incremental
23-24 administradores adicionales y,
ocultando la realidad 81-82, 26-27,
24-25 exigencias imposibles iniciar
Scrum, 9
definido, 114 de la funcionalidad del producto, 112 en el
proceso de Scrum, 127-128, 130 transparencia y, 117
memoria muscular que dificulta el cambio, 21-27 transiciones,
proveedor de software independiente (ISV), 37-41 de equipos
29-41 proceso en cascada, 16 ETC (equipo de transición de la
de infraestructura, 57, 60-62 inspección, 103, 105, 114
empresa)
industria de seguros, 97 integrar los sistemas de capas
múltiples, 63-66 reducción de inventario, 129 ISV (proveedor
Definido, 9, 120-121 iniciar Scrum, 9-11
de software independiente),
impedimentos tomando nota de, 15
organigrama, 10 Reunión de Planificación
Sprint, 13-14 dependencias externas, 62, 83
37-41 desarrollo
iterativo
F la comunicación de ancho de banda y, 137 definen, 114
Los campos, Marcos, 15 cambio de empresa y, 27 ETC equipo Scrum, 9-10 en
productos financieros / servicios, 32-36, 51-52, 114 proceso Scrum, 105-106, 127-128, 130 gestión de carga
producto terminado de trabajo, 134
los Cinco disfunciones de un equipo ( Lencioni), 10 Ford Motor
Company, 15
Los pedidos pendientes de productos 149
K visión general, 69 la creación de
Kalz, Joris, 4 equipo, trabajo en equipo 73-75, 75-76
reuniones iniciales, 11, 119-121 Krulak, habilidades de la gente
Charles C., 135

experiencia funcional, 80-81 mejorar, 3 cambios
en la infraestructura y el desarrollo iterativo, 92 y
L 106, necesidad de habilidades escasas, 83-84
prácticas de Lean Thinking, 31, 36 Lencioni, desarrollo de software y, 103-104 consideraciones
Patrick, 10 se extiende a los clientes, 26-27 de rendimiento, 6, 79, 81 al realizar el paso
(equipos), 75- 76 puntos de trabajo, 48 condiciones
previas, proyecto, 14, 123-124 cambios priorización,
17, 54-55, el control 73 proceso
METRO
mantenimiento de núcleos muertos, 96
gestión
mando y control, 23-24 iniciar Scrum, 9
personas prácticas, 76-80 producto, 6,
los requisitos de adaptación, 103, 105
85-97 cambios de responsabilidad, 7, 7
advertencias, 7-8 definido, 102-103 empíricos,
en rotación
26, 102-103, 114 requisitos de inspección, 103,
105 requisitos de visibilidad, 105 de flujo de
procesos
carga de trabajo, 127-129, 134-136 valor gestionar,
86-89 métricas, estableciendo, 14, 19, 124 memoria
muscular que dificulta el cambio, 21-27
Diagrama de proceso de adopción, 14 de ancho de banda y la
comunicación, 136-137 iniciar Scrum, 9 iterativo, 105 personas
que manejan, descripción 76-80, 106-108 papeles, 106 pedidos
norte pendientes de producto
paso Normalización (equipos), 75-76
O
desarrollo offshore, 132-133, 136-139 Ogunnaike, Babatunde direccionamiento, 123-125 Automatización de las
A., 102 movimiento Open Source, 141 operaciones, la operaciones, 53-54 funcionalidad del núcleo, 92 creando,
automatización, 52-54 cultura de la organización. Ver prácticas 45-46 definida, 114 que define, 22 determinar el valor
de la organización Cultura de la empresa relativo, 87-89 velocidad de desarrollo, 86 se establece, de
14 experiencia funcional, 81 funcionalidad y, 5 aseo, 114
para las empresas de productos de alta tecnología,
Automatización de las operaciones, 52-54 creación de la reserva de
pedidos de productos, 45-46 empresas de productos de alta
tecnología, optimizando 46-51 arquitecturas, 55-57 organizar el
trabajo de la empresa, 46, 51-52 organizan múltiples puntos de vista,
54-55
46-51 iniciar Scrum, 9-10 integración de sistemas multicapa,

PAG
64-65 integrar el trabajo de los equipos, 66, 68 la gestión de
ritmo de trabajo, sostenibles, 4, 39 personas
personas, 76, 78 necesidad de habilidades escasas, 83
prácticas
optimización de las arquitecturas de la familia de productos,
compensación, 81
los miembros del equipo distribuido, 82-83 administradores
adicionales y, 81-82, 80-81 experiencia funcional personas
que manejan, 76-80 necesidad de habilidades escasas,

55-57
83-84 de organización para el trabajo de la empresa, 70-73
organizar el trabajo de la empresa, 46, 51-52 organizan múltiples
puntos de vista, 54-55 organizar a la gente para el trabajo de la
empresa, 70-73
150 desarrollo de productos
Los pedidos pendientes de productos, continuado la gestión, como métrica 79, 124 de control de calidad
visión general, 109-110 valor relativo, 87-89 en el flujo de y, 6 a través de la autogestión, 23-24 organizaciones a
Scrum, 106-107 equipos de autogestión, 24 Pila del Sprint, nivel de producto, 70-72, 78 programas. Ver proyectos
111-112 creación de equipo, la formación del equipo 73, 75 Proyecto Goal, 114 Project Management Institute, 21
seguimiento del progreso, el desarrollo 124 impulsado por el equipos de proyecto. Ver proyectos Equipos
valor, el trabajo organizado 129 por la funcionalidad, el
desarrollo del producto 61-62
equipos de auditoría, 125

de control, 86 definen, 114
la adopción de Scrum, 3
desarrollo de software complejo, 103-105, 16-17 el establecimiento de condiciones previas, 14, 123-124
conflictos y cultura de la empresa, 4 identificativos, 14 reuniones iniciales, 11, 119-121, 86 de
control de calidad realizando beneficios de seguimiento,
la integración de los sistemas de capas múltiples, 63-66 integración de 129-130, 124 probar Scrum, proceso de 5 cascada, 16
equipos de trabajo, 66-68 optimización de arquitecturas de familias de prototipos, 18-19, 68
productos, descripción 55-57, 101-102 exposición problema y, 3 proceso
en cascada, 16 de gestión de productos, 6, 85-97 dueño del producto
Q
colaboración con, 134 funcionalidad del
control de calidad
núcleo, 92 definen, 106, 114 equipo de
equipos multi-funcionales, 22
desarrollo y, 85 miembros equipo distribuido,
núcleos muertos y, 94-95 de
82 experiencia funcional, 81 que oculta la
funcionalidad y, 90 La memoria del
realidad desde, 26 identificación, 14
músculo y, 21 proyectos y, 86 en
Sprints, 6
la identificación de obstáculos, 17 incrementos de la

funcionalidad del producto, 112 iniciar Scrum, 9-10
R
Ray, W. Harmon, 102 valor relativo de los productos
la integración de los sistemas de capas múltiples, 63-64 integrar el
pedidos pendientes,
trabajo de los equipos, cambios de trabajo, 66-67 6
87-89
requisitos
la gestión de personas, 76-80 de valor
definido, 114 velocidad de desarrollo, 39 de
gestionar, 86-89 necesidad de
desarrollo iterativo y, 106 de análisis
habilidades escasas, 83
sintáctico, 140 prevalencia de los cambios
organizar el trabajo de la empresa, 51-53, 57, 71 Cartera de
en, desarrollo de software 94 y,
producto, gerentes de producto como 109-110, 6 eliminación,
79, 62 responsabilidades responsabilidad ROI, 47, 78, 86 en el
flujo de Scrum, 106-108 creación del equipo, 73-74 de

103-104 proceso en cascada, 16, 22
formación , 123
responsabilidad, indemnización y, 81
retrospectiva, 114-115 ROI (retorno de la
inversión)
funcionalidad y, maximización 87, 51, como

impulsado por el valor de desarrollo, 127-129 trabajo
métrica, 124 Producto responsabilidad del
organizado por la funcionalidad, la productividad 61
propietario,
el desarrollo de infraestructura, 92-93 en el

47, 78, 86
desarrollo iterativo, 106
creación de equipo y, 73
equipos 151
roles, 6, 106 equipos gerentes adicionales, 81-82 manipulación de

de despliegue dependencias externas, que inician el 62 Scrum,
composición de, 17 iniciar 10-11 gestión de personas, 78 necesidad de
Scrum, 9-11 presionar, 17 habilidades escasas, 83 participantes, 13 en el flujo de
Scrum, 107-108 Sprint Backlog, 111 probar Scrum, 5
Reunión de Planificación del Sprint, Cartera 13-14 equipos virtuales y, 142 Reunión retrospectiva de
Proyecto de Transición, 15-16 Sprint, Sprint 108 Comentario
S
Schwaber, Ken, 86 Scrum, 115 Scrum Alliance, 5 Scrum Centro, 14, 125
equipos de desarrollo de Scrum. Ver equipos de desarrollo Scrum equipos
de despliegue. Ver equipos de despliegue de equipos scrum. Ver equipos
funcionalidad del núcleo, 92 definido, 116 de miembros
Scrumeteria, 32 ScrumMaster
equipo distribuido, 82-83 prácticas de ingeniería, 61 inician
Scrum, 11 integración de los sistemas de capas múltiples,
63-64 solicitudes fuera de la manga, 19 en el flujo de Scrum,
107-108 seguimiento del progreso, 124 equipos virtuales y,
142 Sprints
definido, 106, 115 experiencia

funcional, 81 identificación, 14
iniciar Scrum, 9-10
la integración de sistemas multicapa, 64 cambios de trabajo,

definido, 107, 115 alcance definición de “hecho” 113 de
la gestión de 6 personas, el trabajo de la empresa
miembro equipo distribuido, 82 incrementos de la
organizadora 76-80, 72 de control de calidad, la eliminación
funcionalidad del producto, 112 que inician Scrum, 9-11
de 6, 79
integración de trabajo, 79 control de calidad, 6 revisar, la
formación 17 equipo, 75 de trabajo organizado por
funcionalidad, 61-62 rotación de personal, 6 partes
informar a los impedimentos, 17, 15,
interesadas
responsabilidades 125 Scrum Center, 125
equipos de autogestión, 23-24 de creación
de equipo, la formación 73, 5, 123, 141
de trabajo organizado por la funcionalidad, 60-61 equipos

Definido, 116 iniciar Scrum, 9 de
de autogestión
desarrollo iterativo, 105 en el flujo de
definido, 106, 113, 115 gestores adicionales y,
Scrum, 108 asaltar paso (equipos),
81-82 responsabilidades de gestión, 7 memoria
75-76 ritmo sostenible de trabajo, 4, 39
muscular y, 21 necesidad de habilidades escasas,
83 prácticas de las personas, la productividad a
través de 76-80, 23-24 y gestión de carga de trabajo,
135 equipos de auto-organización , 106 habilidades. Ver
los talentos de la gente T

Equipo de Formación de modelo, 75 equipos. Ver también prácticas de las
personas; tipos específicos
de los equipos
desarrollo de software, 55-57, 103-105 SourceForge, la adopción de Scrum, 3 auditoría, 125

141 coallocating, 137 políticas de
La cartera, 107, 111-112, 115 Sprint Gol, 115 compensación, 6 composición de, 17,
reunión de planificación de Sprint Sprint 24 creando, 73-75 Scrums diarias,
107-108, 124 núcleos muertos y, 94
llevar a cabo en primer lugar, define 13-15, define, 115
115-116 definir Pila de Producto, 22 distribuidos
los miembros del equipo, 82
152 la tecnología, el desarrollo y
equipos, continuado formación
de miembros distribuidos, los equipos de la empresa 82-83 de en el primer mes, 13 responsabilidades de gestión, 7 reserva de
transición, 9, 120-121 establecimiento de condiciones previas del pedidos de productos y, 51-52 propietario del producto, 123 en
proyecto, Scrum Center, 125 ScrumMaster, 5, 123, 141 equipos, 76 de probar
123-124 Scrum, 5 a través de Scrum Alliance, 5 TransCanada Pipelines
actividades de formación, 75-76, 123 (TCPL) , 130 Transición Pila de Producto. Ver TPB (Transición
experiencia funcional, 81 identificación, 14
mejorando, 3
infraestructura, 57, 60-62 iniciar Scrum,

9-10 integrar el trabajo de, 66-68
desarrollo iterativo, 105-106 cambios de
trabajo, 6 Pila de Producto) transparencia en el proceso de Scrum,
18, 26, 103, 116 Tuckman, Bruce, 75
la necesidad de habilidades escasas, 83-84
solución de problemas en, 6 en el flujo de
Scrum, 107 tamaño de, 137, 139-140 Pila del

T
Sprint, 111 virtual, 140-142
Infantería de Marina (USMC), 135
la tecnología, el desarrollo y, 103-104, 106 proceso de prueba,

V
22, 92 ThoughtWorks, 129-130 “tres bloque de la guerra,” 135
valor, gestión, 86-89 desarrollo impulsado por el valor, 86-89,
de 3M, 80
127-129 velocidad. Ver velocidad de desarrollo Scrum Virtual,
142 equipos virtuales, 140-142 requisitos de visibilidad en el
control de procesos, 105
tiempo boxes en el flujo de Scrum, 107-108, 114-116 TPB
(Transición Pila de Producto)
iniciar Scrum, 10-11 impedimentos
tomando nota de, 15-16 enviando, 17
W
fuentes de impedimentos, 16-17 reunión de proceso, 16, 21-23, 143-145 gestión de carga de trabajo,
planificación de Sprint, 14 127-129, 134-136 cascada
Sobre el Autor
Ken Schwaber co-desarrollado Scrum con Jeff Sutherland hace dieciséis años. Desde
entonces, ha dirigido su propia compañía de software utilizando Scrum y ayudado a
muchos otros utilizan Scrum. Él es signatario del Manifiesto Ágil, y fundador de la Alianza
ágil y Scrum Alliance. Ken ha estado en el negocio del software por más de 35 años. Vive
en Lexington, Massachusetts.

Scrum To Scrum - En.es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Scrum To Scrum - En.es

Cargado por

Copyright:

Formatos disponibles

Publicado por

© 2007 por Ken Schwaber

Impreso y encuadernado en los Estados Unidos de América.

Distribuido en Canadá por HB Fenn y Company Ltd.

logotipo, persona, lugar o evento se pretende ni se debe inferir.

Adquisiciones Editor: Ben Ryan

Ilustración de la cubierta por John Hersey

Parte del cuerpo Nº X13-24184

VanBuren, Alan Buffington, y Clinton Keith. Agradezco especialmente a mi

esposa, Christina, que leyó, comentó:

y editado hasta altas horas de muchas noches.

parte I La adopción de Scrum

Parte II Empezar a usar Scrum de Empresa Trabajo

Parte III Apéndices

Un scrum 1, 2, 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 B más Acerca de

parte I La adopción de Scrum

1 ¿Que Tenemos que hacer para adoptar Scrum? . . . . . . . . . . . . . . . . . . . . . . . . 0.3

que vale la pena el esfuerzo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 evaluar el tipo de cambio que se producirá.

2 Scrum qua scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.9

Las fuentes de los impedimentos de la Pila de transición. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 ¿Qué pasa si?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 El tercer mes y más allá. . . . . . . . .

4 Memoria-La fricción contra el músculo del cambio. . . . . . . . . . . . . . . . . 21

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Compromiso con desafiando las leyes de la naturaleza. . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Cómo ocultar la realidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

¿Qué opinas de este libro? ¡Queremos escuchar de ti!

participar en una breve encuesta en línea, por favor visite:

Situación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Aplicación de Scrum.

Situación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Aplicación de Scrum,

la Fase 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Resultado, la Fase 1. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Situación, Fase 2.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . 34 Aplicación de Scrum, la Fase 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Resultado, la Fase 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 comentarios

adicionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Woodgrove Bank. . . . . . . . . . . . . .

Aplicación de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Litware. . . . . . . . . . . . .

Situación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Aplicación de Scrum.

Parte II Empezar a usar Scrum de Empresa Trabajo

# 2: La organización de la empresa para un trabajo de alta tecnología-empresa de productos. . . . . . . 46

# 3: La organización de la empresa el trabajo en otras empresas. . . . . . . . . . . . . . . . . . . . . . . . . . 51

# 4: La organización de la empresa de trabajo para nuevos sistemas que

# 5: La organización de la complejidad de múltiples vistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

# 6: La organización para optimizar el producto de software Arquitecturas familia. . . . . . . . 55

# 2: Integración de Sistemas de múltiples capas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

# 3: La integración de la Obra de Equipos de Scrum y equipos que no usan Scrum. . . . . . . . . . 66 Resumen. . . . . . . . .

# 1: La organización de personas para hacer el trabajo para empresas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

# 4: ¿Cómo se administran personas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

# 7: Los gestores extra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

# 8: Los equipos con miembros distribuidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

# 9: Habilidades escasos que se necesitan por muchos equipos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

9 La relación entre la gestión del producto / cliente y el equipo de desarrollo. . . . . . . . .

Valoración relativa con Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

# 4: Los aceleradores de la recuperación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

# 5: La madre de todos los problemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Parte III Apéndices

Control de proceso empírico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Desarrollo de

software complejos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Scrum: Esqueleto y corazón. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Scrum: Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . 106 Scrum: Flujo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Scrum: Los artefactos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Pila de Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Pila del Sprint. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Incremento de la funcionalidad del producto

potencialmente entregable. . . . . . . . . . . . . . . . . 112

B más Acerca de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Libros de scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Libros de técnicas