Agile and Lean Program Management

AGILEAN LEAN
Gestión de Programas
Escalado de la colaboración en toda la organización
* A.
Gestión ágil y ajustada de programas
Escalado de la colaboración en toda la organización
Johanna Rothman
ISBN 978-1-943487-04-2
Ninguna parte de este libro puede ser reproducida o transmitida en

por cualquier medio, electrónico o mecánico, incluyendo
fotocopias, registros o por cualquier
sistema de recuperación, sin el permiso por escrito del autor.
Se tomaron todas las precauciones en la preparación de este libro.
Sin embargo, el autor y editor no asume ninguna responsabilidad por
errores u omisiones, o por los daños que puedan resultar del uso de
información contenida en este libro.
Muchas de las designaciones utilizadas por los fabricantes y

vendedores para deshorarsus productos se reivindican como Marcas.
Donde los
designaciones aparecen en este libro, y Practical Ink era consciente de
una reclamación de marca, las designaciones han sido impreso en
inicial
mayúsculas o en todas las mayúsculas.
© 2016 Johanna Rothman

Para mi familia.Graciasqueparasuapoyo.
Contenido
Cotizaciones de alabanza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
............................................ Ⅰ
Reconocimientos...................... . Ⅳ
Prólogo...................... . . . . . . Ⅴ
Introducción.......................... Vii
1. Definición de la gestión ágil y ajustada de programas . . . 1

1.1 Revise los Doce Principios del Software Agile
Desarrollo.................... 3
Revise los Siete Principios Lean . . . . . . . . . . . . . . . . . . . . .
1.2 . . . . . . . . . . . . . . . . . . . . 4
1.3 Agile y Lean Together Crean programas adaptativos 4
1.4 Un programa es una colección estratégica de varios
Proyectos...................... . 5
1.5 La Gestión del Programa Facilitaes el Programa para
Lanzamiento...................... . Tome un
1.6 1.10 . . . . . . . .
La Gestión de Programas Coordina el Negocio 1
Valor........................ .
1
1.7 1
La gestión de programas ágiles escala la colaboración
P
1.8 Cambio de efecto ágil y magro a nivel de programa r
Qué hacen los administradores de programas . . . . . . . . i
n
1.9 ................................... c
ipios de gestión ágil y ajustada de programas 6
2. Considere el contexto de su programa . . . . . . . . . . . . . . . 6

....................... 7
9
9
1
0
1
1
1
2
Contenido No podem
4.3 ........
Cynefin ayuda con las decisiones . . . . . . . . . . . . . . . . . Liderar el

2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 ........
2.2 Comprender la complejidad de su producto. . . . . . . . .
.......................... 4.5 Cree su p
4.6 Iterar en
Saber qué equipos de programa necesita . . . . . . . . . . 4.7 Cree la ho
........
2.3 . . . . . . . . . . . . . . . . . . . . . .
El equipo principal proporcionaa los líderes Cree la ho
2.4 empresariales 4.8 ........
Valor........................ Principios
2.5 ¿Necesita un equipo principal? . . . . . . . . . . . . ........
4.9
Principios de considerar el contexto de su programa .
5. U
2.6 . . t
i
3. Organice los equipos de programa . . . . . . . . . . . . . . . . . . . . . l
.......................... i
Cree su núcleo Te am . . . . . . . . . . .. . . . . . . . . . . . . . . . c
3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e
Tenga cuidado con la olvido de los miembros P
3.2 principales delequipo.. . . l
a
El rol de propietario del producto es clave para el
n
3.3 programa i
Éxito...................... . f
3.4 Organice el equipo del programa de software . . . . . . . i
....................... c
a
3.5 No administremás de un equipo de programa c
Tú mismo...................... . i
Principios de organización de los equipos de ó
n
3.6 programa . . c
4. Inicie suderecho de programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
................................. n
Una Carta del Programa Establece la Estrategia . . . . . t
4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Desarrollar la Carta del Programa con el n
u
4.2 EquipoPrincipal
a
.............................................. ...
5.1 Diferenciar entre reinterna y externa
Arrendamientos .........................
............................................. 1
........ 2
¿Qué quieres liberar este mes? ... 1
Crear releasables mínimos . . . . . . . .......... 6
............................... 1
8
Planificar para liberaciones externas . . . . . . . . . . . . . .
............... ......
2
3
2
4
2
5
2
6
2
6
2
8
2
9
3
1
3
3
3
4
3
5
35
36
37
38
39
45
46
48
50
52
52
53
54
56
Contenido
La planificación de ondas de entrega y rodadura ayuda

5.5 .. 57
Pequeño es hermoso para programas . . . . . . . . . . . . . . .
5.6 ........................... 58
¿Con qué frecuencia puede replanificar? . . . . . . . . . . . .
5.7 ....................................... 59
5.8 Separar la hoja de ruta del producto del proyecto
Cartera...................... . 61
Formas de clasificar elementos en la hoja de ruta o
5.9 trabajos pendientes . 62

Decida cómo valorará elvalor . . . . . . . . . . . . . . . . . . . . . .
5.10 . . . . . . . . . . . . . . . . . . . . . . 67
Actualizar las hojas de ruta A menudo . . . . . . . . . . . . . .
5.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Principios de planificación continua . . . . . . . . . . . . . . . . .
5.12 . . . . . . . . . . . . . . . . . . . . . 68
6. Crear un entorno de entrega. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9 Principles

.................
6.1 Visualizar el trabajo en equipo del programa . . . . . . . . . 7. F
....................... o
6.2 Mantenga el trabajo del equipo del programa pequeño
m
................................. e
Cómo fluyen las características a través de los equipos . n
t
6.3 .............................. a
6.4 ¿Con qué frecuencia puede liberar su producto? . . . .
r
Liberar internamente, incluso con hardware . . . . . . . . . . l
a
6.5 .....................
a
6.6 ¿Está integrando Chunks o productos de u
¿Otros? . . . . . . . . . . . . . . . . . . . . . . . t
Gestionar los riesgos de integración de otros o
n
6.7 proveedores o
6.8 Crear una cultura de entrega a lo largo del Pro m
gramo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . í
..................................... a
, la colaboración y la exploración
70
El software es Aprendizaje, No Construcción . . . . . . . . .
7.1 . . . . . . . . . . . . . . . . . . . . . . 7
7.2 0
Escalado ágil significa escalar prácticas colaborativas
7
7.3 Crear equipos de entidades autónomos . . . . . . . .
2
Crear redes de pequeñomundos para optimizar el
7
7.4 aprendizaje 3
7.5 Las comunidades de prácticas crean conexión y
7
Colaboración....................
4
Evitar títulos jerárquicos . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 . . . . . . . . . . . . . . . . . . . 7
7.7 5
Soportes de ContinuaIntegracióny PruebasCol-
laborión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
................................. 7
Tenga cuidado con la deuda técnica . . . . . . . . . . . . . . . .
7
7.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Invitar a personas a experimentar . . . . . . . . . . . . . . . . . .
7.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
0
80
8
1
8
1
8
2
8
4
8
5
8
7
88
90
92
93
Contenido
7.10 Principios de Fomento a la Autonomía, Collabora

y Exploración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
........................ 93
8. Lleve a cabo reuniones útiles para su programa . . . . . . . . . . . . . .
............... 95
8.1 Estado explicativo: No use standups en el
Nivel de programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
................................ 96
Defina un ritmo para el equipo del programa . . . . . . . .
8.2 ...................... 97
Organice sus reuniones de equipo de programa . . . . . .
8.3 .................... 101
Reuniones de equipo de programa Resolver problemas
8.4 ........................ 103
Retrospect ióna anivel de equipo de programa . . . . . . .
8.5 ......................... 106
8.6 Principios para llevar a caboreuniones útiles para su
Programa...................... . 107
9. Estimación del programa o costo .. . . . . . . . 108

9.1 ¿Su organización quiere resiliencia or Pre
¿Dicción? . . . . . . . . . . . . . . . . . . . . . . . 109
Haga estas preguntas antes de estimar . . . . . . . . . . . . .
9.2 . . . . . . . . . . . . . . . . . . . 110
9.3 Estimaciones de beat de objetivos . . . . . . . . . . . . . . . . . .
................................ 111
9.4 Generar una estimación con un porcentaje de confianza
111
Presente su estimación como una predicción . . . . . . . . ¿Realmen
9.8
9.5 . . . . . . . . . . . . . . . . . . . . . . . . .
Tenga cuid
Espiral en una estimación . . . . . . . . . . . . . . . . . . . . . . . . 9.9 programa
9.6 .............................. Estimación
9.7 Proporcione una estimación de tres fechas . . . . . . . . . . 9.10 Programa
...................................
Principios de estimación de la programación o el costo 11
9.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Mediciones útiles en un programa ágil y ajustado 10.1Qué 11
medidasWillMean Something to 6
11
7
11
8
11
8
12
0
12
2
12
3
¿Su programa? . . . . . . . . . . . . . . . . . . . 124
Nunca use medidas basadas en equipos para unprograma
10.2 124
Medir por características, no por equipos . . . . . . . . . . .
10.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Medir características completadas . . . . . . . . . . . . . . . . .
10.4 . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Mida el registro pendiente del producto Burnup . . . . . .
10.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
10.6 Mida el tiempo a su entrega liberable 132
Contenido
Medir la frecuencia de liberación . . . . . . . . . . . . . . . . . .

10.7 ....................... 132
Medir el tiempo de compilación . . . . . . . . . . . . . . . . . . .
10.8 ................................. 133
Otras mediciones potenciales . . . . . . . . . . . . . . . . . . . . .
10.9 ..................... 133
10.10 Medir los criterios de rendimiento o liberación de fiabilidad 136
10.11 HowtoAnswerthe"WhenWillYouBeDone/How
Mucho costará su programa " Pregunta . . . . . 137
Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.12 . . . . . . . . 139
11. Desarrolle su liderazgo de siervos . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 140
Los directores de programa ya no "conducen" el programa
11.1 140
Considere su liderazgo de siervos . . . . . . . . . . . . . . . . . .
11.2 . . . . . . . . . . . . . . . . . 141
Cómo trabajan los líderes de los siervos . . . . . . . . . . . . .
11.3 . . . . . . . . . . . . . . . . 142
11.4 Algunas personas noquieren liderazgo de sirvientes . . . 143
Bienvenido malas noticias . . . . . . . . . . . . . . . . . . . . . . . .
11.5 ................................... 145
Utilice la mentalidad de crecimiento . . . . . . . . . . . . . . .
11.6 ....................................... 148
Solicitar los resultados que desea . . . . . . . . . . . . . . . . . .
11.7 .............................. 148
11.8 Principios de Desarrollar su Liderazgo Sirviente: . . 150
12.5 Lo que el A
12. Pastorear la arquitectura ágil . . . . . . . . . . . . . . . . . . . . . . . . . . .
La arquitec
........................
Los arquitectos escriben código . . . . . . . . . . . . . . . . . . . 12.6 . . . . . . . . .
12.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.7 Problemas
Muchos desarrolladores se convierten en arquitectos. Romper la
12.2 . . . . . . 12.8 . . . . . . . . .
12.3 Fomentar la arquitectura iterativa e incremental 12.9 Principios d
Los arquitectos pueden ayudar a exponer riesgos . . . . 13.
12.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Res
olver problemas de programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
................................... 151
13.1Pregunte primero 15
por los problemas o impedimentos . . . . . . . . . . . . . . . . . . . . . . . . . 2
............ 15
13.2 Las personas en elequipo principal noentregan lo que 5
prometen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
.............................................. 5
............. 15
13.3 Los propietarios de sus productos tienen feature- 7
it es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.4 Personas en Téms son multitarea . . . . . . . . . . . . . . . . . 8
..........................................
16
0
16
1
16
3
16
4
166
16
6
16
8
16
8
17
0
Contenido
13.5 Cómo iniciar un programa con más personas que

Te hace falta...................... 171
Principios de resolver problemas de programa . . . . . . .
13.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
14. Integración de hardware en su programa . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . 175 14.1 Los riesgos de hardware son diferentes de
los riesgos de software 175
Comprender el costo y el valor del hardware . . . . . . . . 17
14.2 . . . . . . . . . . . . . . . . . . . 6
Comprender el valor de cada parte . . . . . . . .. . . . . . . .
17
14.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Consulte el trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
14.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.5 Incremento de diseño e iterativamente .. . . . . . 0
Utilice La revisión continua de diseños . . . . . . . . . . . . . 18
3
14.6 . . . . . . . . . . . . . . . . . . . . . . .
18
Integrar hardware A menudo . . . . . . . . . . . . . . . . . . . .
3
14.7 . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestionar riesgos de hardware . . . . . . . . . . . . . . . . . . . 18
4
14.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
14.9 Desarrollar el software antes de que el hardware es
5
Disponible...................... 186
14.10 Principios de integración de hardware en su Pro
gramo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..................................... 189
15. Solución de problemas de equipoágil . . . . . . . . . . . . . . . . . . . . .
......................... 190
Los equipos no son equipos de características . . . . . . . . .
15.1 ............................ 190
15.2 Los equipos piensan que son ágiles, pero no lo son. 194
15.3 Los equipos tienen dependencias en otros equipos . 200
Sus características abarcan varias iteraciones . . . . . . . .
15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . 203
15.5 Usted notiene entregables frecuentes. . 203
15.6 Los equipos noterminan cuando dicen que están hechos 204
15.7 Principios de solución de problemas de equipo ágil . 206
16. Integración de equipos ágiles y no ágiles en su gramoPro . .

................................................... 20
7
................
20
Los equipos de cascada son parte de su programa . . . 8
16.1 .
Tiene equipos que producen de forma incremental,
21
16.2 pero
0
No de forma ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..............................
21
16.3 Tienes equipos que prototipo y don't Com
Características . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 0
.....................................
Contenido
16.4 Principios de integraciónAgileandNot-AgileTeams

en su programa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
............... 211
17. Qué hacer si Agile y Lean no son adecuados para usted 21
Pruebe un ciclo de vida incremental . . . . . . . . . . . . . . . 2
17.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3
Organizar por equipo de características . . . . . . . . . . . .
17.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Aprenda a liberar entregas provisionales . . . . . . . . . . . 6
17.3 . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Aprenda a reducir el tamaño de lote con un tamaño 7
17.4 grande
Programa.............. . . . . . . . . . 21
Pruebe Release Trains . . . . . . . . . . . . . . . . . . . . . . . . . . 7
17.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
17.6 Principios para qué hacer si ágil es ágil y magro 8
No es adecuado para usted . . . . . . . . . . . . . . . . . . . . . .
.........................................
22
1
Bibliografía anotada . . . . . . . . . . . . . . . . . . . 223
Glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
........................................ 228
Más de Johanna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.................................. 231
Cotizaciones de elogio
Lo que dicenlos lectores
Agile and Lean Program Management: Escalado de la colaboración en

toda la organización
"Este es el libro para todos los que están considerando cómo "escalar"
sus procesos lean/agile para trabajar en grandes programas. Johanna
proporciona consejos directos y prácticos sobre cómo pasar de una
implementación ágil de un solo proyecto/producto simple
agrandes,complexprogramasmientras
quereteniendoelnúcleodeagilidad y pensamiento magro. Ella nos lleva
de nuevo a los principios fundamentales de ágil y magro y muestra
cómo utilizar esos principios como un base para la verdadera
agilidadsational organi, construyendo productos que necesitan
múltiples equipos con diferentes flujos de trabajo interdependientes
manteniendo la adaptabilidad y capacidad de respuesta que está en el
núcleodemagra y ágil
Pensando. "
—Shane Hastie, ingeniero jefe de conocimientos y líder de práctica

ágil, educación en software
"JohannaRothman'snew bookisthe definitivo guidetoprograma de

gestión en el mundo ágil y magro. Me pareció invaluable cristalizaren
mi mente cómo combinar principios ágiles y magros con la gestión de
programas.Se'salibroquequevoluntadgireacuando alguien
preguntaqueacomplicadopregunta quequesaber voluntadsermejor
articuladoporJohanna."
—Owain Griffiths, Consultor Principal, ThoughtWorks
"En Agile and Lean Program Management, Johanna hace un trabajo de
mezcla y verdaderos conceptos de blending para el programa de
software moderno entregacon más nuevosmodelosy las
ideas.Y,comosiempre,
Ⅰ
Cotizaciones deelogio ii
hace un gran trabajo proporcionando enfoques prácticos y

pragmáticos para
usando las ideas que ella proporciona. Una lectura obligada para
cualquier persona que sea responsable o impactada por la planificación
o entrega de
iniciativas de software de equipo. "
—Matt Barcomb, Director Principal, Tidal River Consulting

"Johanna ha creado una excelente guía para gestionar grandes
proyectos (también conocidos como empresas).Portakingelgrandes,a
menudodifícil de enredo,conceptosycolocaciónellos en un
experimentadoágil/leancontexto, ellahacela información accesible
yproporcionala hoja de rutaquenecesidadamantener su
organizaciónenpistay eficaz."
—Jared Richardson, Principal Consultant, Artesanos Ágiles
"¿Cómo escalar las prácticas de software ágiles (más adecuadas para
de 5a10 desarrolladores) a programas más grandes que abarcan
múltiples disciplinas y múltiples equipos?Esteesla descripción más
útilYotienenvisto:Johannamuestracómoque cuna aplicaciónelprincipios
de LeanyAgilesoftwaredesarrollocontécnicas prácticas y
procesablesaentregarel valorsulos clientes desean."
—Ian Brockbank, Agile Architect and Program Manager, Cirrus Logic y
blogger en www.badgertaming.net
"Agile and Lean Program Management proporciona el asesoramiento
práctico y de principios para que sus grandes esfuerzos de producto sean
un éxito. Johanna evitasabiamente la confusión y la mala dirección de
las conversacionescontemporales en torno a "escalar ágiles." Ella
tambiénevitajerarquías, estrictodefiniciones de roles, y edificioun
giganteproceso
Máquina. ThisallowsAgileandLeanProgramManagementtofocus en lo
quees realmenteimportante para cualquier esfuerzo de producto
grande: eficaz
comunicación, expectativas claras, atención al cliente, colaboración y
actuación desde principios. Johanna logra un excelente equilibrio
entre lo práctico y lo teóricoaquí, y logra un tono conversacional incluso
cuando se sumerge en este último. Este libro se siente como sentarse
con un colega de confianza para charlar y obtener un pocode guía sobre
ideas, patrones y soluciones."
Cotizaciones deelogio iii
—Gary Pedretti, Entrenador y Propietario Agile, Sodoto Solutions

"La gestión ágil y ajustada de programas es una lectura obligada para
los gerentes de proyectos y programas. Johanna tejeprofundamente
personal
conocimientos, consejos prácticosy consejos personales sobre cómo
influir y motivar aotros hacia el éxito ágil del programa. Los conceptos
se presentan en un estilo nítido y fácil de leer que te deja pensando '¡Por
supuesto! ¡Ese es un enfoque tan claro y sencillo!'
Esteesalibroquewmalsorprender e inspirar. Y usted querrá referirse de
nuevo a
con frecuencia a medida que su programa ágil
evoluciona."—DeclanWhelan, Entrenador ágil,
Leanintuit
"Lee este libro y regalalo a tu jefe.Sujefe le agradecerá. Agileno se

tratasólo de un mejor programaming, o mejor stand ups.No
hay'saenterolotta cosas importantes que vaenpor adelantado,antes
deproyectos comienzan a ejecutarse, yque'sinvisibleala
mayoríapersonas.
Este libro bellamente escrito muestra cómo hacer ese trabajo de
manera inanágil."
—Clarke Ching, autor de Rolling Rocks Downhill, The Agile Busi ness
Novel (que nunca menciona Agile)
"El mundo realpresentadesafíos incómodos: equipos no ágiles
mustbeincludedinagileprograms,featureswillhavedependencies across
many teams and systems, people (even good people) will fail to cumpla
commitments, etc. Este libro ofrece una mezclaúnica
de anécdotas que provocan pensamientos y patrones exitosos para
escalar
Colaboración. Thisisagreatreadforprogrammanagersandleaders en
grandes organizaciones."
—Catherine Swetel, Principal Consulthormiga
Reconocimientos
Agradezco a mis lectores de blog de desarrollo de productos de gestión.

Tus comentarios mejoraron mis ideas. Doy las gracias a estas personas
que leyeron y revisaron el libro y me proporcionaron comentarios: Matt
Barcomb,
Arlo Belshee, Ian Brockbank, Clarke Ching, GeorgeDinwiddie, Paul
Ellarby, Lior Friedman, Owain Griffiths, Matt Heusser, Gary Pedretti,
Catherine Swetel, Michael Vizdos, Rebecca Wirfs-Brock.
Agradezco a mymyeditors, RebeccaAirmetandNancyGroth.I thankKaren
Billipp por el diseño y Jean Jesensky por indexar el libro impreso.
Portada: © Csuzda Dreamstime.com - Foto de crecimiento del equipo

Portada: Lucky Bat Books.
Ⅳ
Prólogo
Desearía que este librose hubiera publicado la última vez que dirigí un
proyecto importante; queesuna acción pragmática
ybasadoen,butenuna manera queestambién
consistente con la teoría—algo que es demasiado raro.The
Agilecomunidad,comoaentero,está plagadoconmétodos rígidos
impuestos con los religiososceloa programas de capacitación y
certificación.
En contraste, este libro entiende queel escaladoAgile se trata del
montaje de diferentes herramientas, métodos y prácticas para lograr
unaresultadodentro deaespecíficoscontexto.Setieneaenterosección
sobre quéhacercuandoAgileesno es un partido culturalparala
organización.Mientras queque
se basa en el liderazgo de los siervos, reconoce que esto no "significa
que usted es un empujón." A vecesquetienenaeliminarequipo
Miembros.
Los primeros capítulos no exigen un proceso, y hay pocos de

losdiagramas de tipo de ingeniería que estructura rinde lo que debe
considerarse como una prestación de servicios. En su lugar, hacen una
serie de preguntas con una serie derespuestas sugeridas Respuesta.
Este no es un manual único,
pero un montaje de muchas cosas-podría-trabajo, pensar antes de que
usted-acto ap roach.Críticamente,quehacenoejecutarde
distanciadeelideaque el hombre
la edad es necesaria.Unodeellas primeras frases que resalté fueron:
"Algunas personas llaman ágil la gestión de programas. Usted podría
llámalo así. El nombre reales la gestión de programas. " Gestión
un program es una mezcla de necesidades estratégicas y tácticas, y los
dos necesitan co-existir e interactuar con crear resilientes y adaptativos
Soluciones. Porcombinando LeanandAgile con una comprensión básica
de la complejidad (utiliza miframework Cynefin), el libroconjuntosa cabo
una roadmapporqueaprogramapuedeseruna asamblea
únicademétodos y herramientas apropiadasderivadodemúltiples
fuentes.
Como el mundo requiere una entrega de ciclo más corta contra
Ⅴ
Prólogo vi
necesidades mal articuladas, necesitamos más de este pensamiento

profundamente pragmatic. El escalado nose trata de grandes marcos
orientados a hacer que las personas se sientan cómodas y asegurar los
ingresos de capacitación.Seessobreconsejos sólidos, buenas preguntas,
y adaptativo yflexiblegestionar
Ment. Este libro es una gran contribución que aborda esa need y estoy
agradecido por la oportunidad de escribir este prólogo.
Profesor Dave Snowden
Director Científico
Borde cognitivo
Introducción
Escuchamos mucho rumor acerca de "escalar ágil."

En lugar de "escalado ágil",considere "escalar proyectos a un
programo."
La gestión de programas es la forma en que pasamos de coordinar el
trabajode un proyectoa coordinar el trabajo de variosproyectos ena
Programa. Cuandosuproducto requierequeacolaborar en toda la
organización,necesidadágil y ágil ymagraprogramagestión.
Lagestión de P rogram noes una idea nueva. ¿Qué
podríasernuevoparayouisla aplicaciónde la dirección de servicioael
director del programa
Papel. Si desea utilizar ágiles y leanapproaches,usted,asaprogram
manager, servir el programa. Confías en la gente para hacer lo correcto,
unad administrar por excepción.
La administración de programas se utiliza en cualquier momento que

desee escalar equipos de collabo rativos en toda la organización. Estas
son algunas posibilidades:
• Usted es un gerente de proyecto, tratando de acorralar

aalgunos equipos juntos, para lanzar un producto.
• Usted es un manáger que necesita varios equipos para
colaborar en un objetivo estratégico.
• Necesita que las personas de hardware y software trabajen
juntas para lanzar un producto.
• Necesita Marketing o Ventas o Capacitación o alguna otra(s)
función(es) para trabajar con el software liberar un producto.
Es posible que tenga una circunstancia diferenciapara su

programa.Todos
los programas tienen una cosa en común:las personas colaboran en
toda la organización para entregar el producto. Sea cual sea su
producto, usted o su equipo por sí solos no puedenasegurarseensus
lanzamientos de productos,sin importar
cómoágilomagraqueson,cuandosuequipodice,"Hecho!"
Vii
Introducción viii
Los programas son colecciones estratégicas de proyectos con un único

objetivo empresarial. Los directores de programa coordinan ese
únicoobjetivo de negocio en toda la organización.
Al coordinar en toda la organización, reconoce la necesidad de que los

otrosequipos,independientemente de su función,
su autonomía en la forma en que crean sus
entregables.Paraprogramas,todo el mundose uneaservir al
programa'snecesidades.Todo el mundooptimizaparael
programa,noparasu equipo.
Cada programa es único. Algunos de ustedes tendrán programas solo
de software. Algunos de ustedes querrán utilizar este libro para
productos que incluyen software, hardware, firmware y com ponents.
Espor eso que este libro se basa en principios, no en mandatos.
La agilidad y la magra basadas en principios también podrían ser nuevas
para ti. Recuerde, quesiqueduplicar lo
queobrasenpequeñoproyectosaprogramas más grandes, todos
losqueobtenereshinchado. Bloat no entrega—en least,
no es fácil. Tome los principios de ágil y magro, y piense: "¿Cómo puedo
aplicar esos principios a mi contexto?"
Si usted es un miembro del equipoen un equipo de características, un

miembro principal del equipoo el director del programa, este libro ha
algo para ti.¿Por qué?Porqueel ágilymagraprogramaesun sistema
adaptativo complejo. Cada uno tiene su propio papel que
desempeñar.Y,todo el mundoenel programa ágil y magro tiene
queserconscientedeeltododescansodeel
Programa. Nadie tiene éxito sin que todos los demás tengan éxito.
Este librole ayudará a ver cómo utilizar enfoques ágiles y ajustados
para administrar su programa. Portu éxito. Ahora, empecemos.
1. Definición de la gestión ágil y ajustada de programas
Imagine este escenario:
Usted're el programmanager paratodo un producto.

Llegas al trabajo y revisas tu correo electrónico. Usted
descubre que uno de los equipos de características
encontró un problema de Big Hairy, pero lo arreglaron
con la ayuda de otro equipo. ¿Necesitabas intervenir? No.
Tampoco el software
director de programas. Sí, su programa es lo suficientementegrande—
18 fe ature equipos,que también necesita un
administrador de programas de software.
Hoyse reunirán con el equipo principal. Ellie, la

representante de Marketing Communications del equipo
principal ha
estado trabajandoensusentregablesparaun parde
semanas. Elcaracterísticaequipossaberquetienen que
proporcionar per
información de formación para que MarComm pueda
terminar sus brillos. MarComm sabe que sus entregas son
clave
a un lanzamiento exitoso del producto.
Una vez que explicaste cómo configurar un kanban en Mar

Comm, todos tienen "fiebre kanban." Bueno,queparece
que de esa manera. Les encanta ver a esos stickies
moverse
en general. El equipo principal entiende cómo su
entregables se cruzan con todos los resultados de todos

los demás ahora, y por quées tan crítico que sus partes se
hacen cuandose comprometenafechas. Todo el mundo en
el equipo de coreestá hablando de "hecho.""Sonamos
al igual que los equipos de software ",dicen.
1
Definición de la gestión ágil y ajustada de programas 2
El arquitecto del programa estaba preocupado por la

evolución de ar chitecture hace apenas dos meses. Nunca
había visto evolucionar a un arcotec.El'dsiempreprevisto el
plan de la
arquitectura de antemano. Entonces la arquitectura
evolucionó de todos modos. Usted y el propietario del
producto del programa y el administrador del programa
de software se sentían como si le hablara "fuera del
acantilado."Elconcedido, yfuedispuestoatratar dea
evolve la arquitectura.
Sorprendentemente, el producto es más simple de lo que

pensaba,en estemomento. Está codificando, porprimera
vez en años. Esfeliz.Así queson los equipos de
características. Se sienten
asif theyareparta del diseño pensando,no sólo tomando
órdenes de algún guy con la cabeza en las nubes.
La alta dirección está contenta contigo, porque cada mes

demuestras algo real, incluso si es
pequeño.Se'ssólosidotres meses yquetener una
liberacióncandidato.I+Dtienenunca ha sido
capazaproduciralgo que fast. Tres meses después del
programa
y usted tiene un producto de trabajo que la empresa puede
vender. Bueno, una vez que MarComm termine sus
entregas.
¿Es una fantasía? No. Así es como funciona la gestión de programas

ágil y lean. Enhecho, conelexcepcióndeelkanprohibiciónjunta,quees
repetir estos
howsuccessfulIworkedin1988onarealproduct,programsprinciples:inare
alorganizationbuildtrustamong. Muchos
equipos en el programa; entregar a menudo para ver
comentarios;construirconfianza en toda la organización.
Vamos arevisar los principios ágiles y leanpara que pueda considerar
cómo aplicarlos a su programa.
1.1 Revisar los Doce Principios de Agile

Desarrollo de software
La siguiente lista parafrasea a los doce

desarrollo desoftware. Consulte la fuente de los principios originales en
los Principios del Manifiesto Agile.
1. Entregar temprano y a menudo para satisfacer al cliente.

2. Requisitos cambiantes bienvenidos.
3. Entregue software de trabajo con frecuencia.
4. Los empresarios y desarrolladores deben trabajar juntos.
5. Confía en las personasmotivadas para hacer su trabajo.
6. La conversación cara a cara es el método más eficiente y eficaz
para transmitir información.
7. El software de trabajo es la principal medida de progreso.
8. Mantener un ritmo sostenible.
9. La atención continua a technicalexcellence ygooddesign mejora
la agilidad.
10. La simplicidad—el arte de maximizar la cantidad de trabajo no
realizado—esesencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de los
equipos autoorganizadores.
12. Reflejar y ajustar a intervalos regulares.
El punto de los principios de ungile es que usted colabora en toda la

organización, viendo el producto de trabajo como una manera de
trabajarconel cliente y asegurarse de que estáenpista. Trabajas de una
manera que
mejora la excelencia técnicaquepuede acomodarel cambio. Usted
inspecciona y se adapta a medida que avanza, sobre el producto y el
proceso, para que pueda ajustar su equipo y producto.
1.2 Revisar los Siete Principios Lean
Desarrollo de software: Un kit de herramientas ágil, POP03,

Mary y TomPoppendiecksummarizedtheirleanapproachcon estos siete
principios.
1. Elimine los residuos.

2. Amplificar el aprendizaje.
3. Decida lo más tarde posible.
4. Entrega lo más rápido posible.
5. Empodera al equipo.
6. Construir integridad en.
7. Mira el todo.
Los principios ajustados le ayudan a ver todo el proceso (para un equipo

o un programa o cualquier cosa entre).Usted consideracuandoahacer
decisiones y aprender a medida que avanza. Lean le anima a ver todo el
producto.
Utilice los principios ágiles y magros a medida que gestiona el riesgo y
resuelve problemas en el programa. Considera cómo losaplicas a tu
programa.
Los principios leayudan a entender cómo usar ágil y apoyarse en su

programa.
1.3 Agile y Lean Together Crear

Programas adaptativos
Cuando utilizas principios ágiles y magros, puedes crear y dirigir un

program adaptable y resistente.CuandoYo
usoelpalabra,"programa,"deahoraen,por favor piensen"ágil y ágil
ymagra"o"adaptativo."
1.4 Un programa es una colecciónestratégica de

Varios proyectos
Un programa es una colección de proyectos, donde el valore está en la

entrega general. Sí, cada proyecto puede tener una entrega que
Valioso. Sin embargo, el valor para la organización es cuando todos los
proyectos se reúnen y entregan su producto. Es un programa
simultáneo. También puede tener ungramo pro serie, como la entrega
de un
series de lanzamientos a lo largo de la vida útil de un producto.
Piense en un teléfono inteligente como un ejemplo de una colección
estratégica de varios proyectos.Un proyecto podríaserla
característicaconjuntoque permite que el teléfonoahacer y responder a
una llamada. Otro project podría ser el
conjunto de funciones para acceder y dejar el correo de voz. Otros dos
conjuntos de características pueden ser la contabilidad de los datos de
voz y los datos de descarga.Elmensajes de
textocaracterísticaconjuntoseríaserotroproyecto. ¿Ves cómo cada
conjunto de características podría ser su propio project?
Cada uno de estos proyectos puede requerir uno o más equiposde
características
trabajando juntos.Elequipostrabajode manera autónoma, sin
embargo,quecomo,comosiempre y
cuandoquesonágilomagra,entregando su completa
característicasa menudo. Cadaproyecto y equipo trabaja en paralelo.
Eachproject tiene su propio ritmo y personal y trabajo pendiente. Los
proyectos ofrecen un producto de trabajo como programa.
Tenga cuidado con una colección de trabajos pendientes clasificados sin
ninguna razón estratégica detrás de la orden.Sihay'ta mayor objetivo de
negocio detrás de los atrasos, que'snoun programa. Es posible que
debas llevar a cabo todo ese trabajo.Y,silos trabajos pendientes
clasificados juntosdon'tcrear una
valor comercial, donde todo el producto es más valioso que cada
proyecto,usted no tiene un programa.
¿Puedes tener equipos de cascada con tus equipos ágiles y magros

y todavía tienen un programa exitoso?Sedependeensi elcascadaequipos
tienen interdependenciasconlo ágil ymagraequipos. Asegúrese de leer
Integración de equipos ágiles y no ágiles
en Su Programa.
Cada programa necesita una visión coherente detrás del programa para
que pueda crear una carta del programa. La carta ayuda a los equipos
de características a asumir laresponsabilidad de sus compensaciones.
Hablaremos más sobre esto
en Iniciar su programa a la derecha. With una carta de programa en su
lugar, los equipos de característicasno tendránque trabajar hacia arriba
y luego por una jerarquía.
Algunas personas llaman a la gestión de programas"escalado ágil." Se
podría llamarqueeso.Elnombre realesgestión de
programas.Enprograma
gestión, usted escala ágil yl eancollaborationpracticestodo el programa,
para que pueda lanzar un gran producto.
1.5 La gestión de programas facilita

el Programa de Lanzamiento
La gestión del programa es la coordinación y facilitación de todo el

trabajo en toda la organización para release elproducto.
El trabajo del directordel programa es coordinar los equipos para que
entender lo suficiente acerca de losriesgos de los demás para que
puedan cumplir.Elprogramagerentehaceno y no puedehaceresto solo. El
programa
se trata de la colaboración.
Los proyectos sontaccticas; hacen el trabajo. El

programa es estratégico.Selazoslos proyectos
juntos paratraerellos a la entrega.
1.6 La Gestión de Programas Coordina el Valor Empresarial
He visto—y apuesto a que también lo hashecho—programas donde el

software
wasalldoneexceptforone smallpiece. El producto se basóporque esa
pieza era vital para la liberación.Oelsoftwarefue
hecho, pero el marketing no lo era. Oel hardwarefuehecho, el marketing

fuehecho,yel softwarefueatascado.
Si emplea enfoques ágilespara los programas, puede ver un progreso
visible(o la falta de ellos) al final de cada iteración o el final de cada
característica en el flujo o a medida que los equipos crean el producto.
No tiene queesperar hasta el final predicho o deseado del programa
para
ver el riesgo.
Esaes una de las formas ágiles que reducen el riesgo técnico y de

programación. Las iteracionesoflujoayudar ase obtieneatodo el
programa.Cada unoiteraciónayuda aquevercómocosasajustejuntos. La
demostración en la d de una iteración (o en un hito) le muestra dónde
riesgo técnico, lo que reduce el riesgo de programación. En
enfoques generales e incrementales reducen el riesgo de programación
y los enfoques iterativos
enfoques reducen el riesgo técnico. Debido a que agile combina ambos,
se reducen los tipos de riesgo del
both.Paramásdetalleenvidaciclos,verAdministrar¡!Su
guíaaModerno,Gestión de Proyectos Pragmáticos,(ROT07).
Si utiliza enfoques lean para su programa, puede reducir la
trabajo en curso, lo que le permitirámaximizar el rendimiento.Alean
enfoque sehabilitarque vercuellos de botella,reducirresiduos,yverlo
queesnoconseguirhecho.Necesitastantoágilymagrapara
un programa.
Notiene que liberar cada iteración o característica a sus cus tomers.

Usted puede decidir cuándoliberarexternamente,esoesun negocio
Decisión. Cuandoquevercompletadotrabajocada
unocaracterísticaocada unoiteraciónescómoquesaberqueproporcionar
valor comercial.
1.7Escalas ágiles de gestión de programas

Colaboración
En la gestión de programas no ágiles, los gerentes de

proyectosogerentes funcionales hablan por sus equipos de proyecto o
área. Comprometen a las personas, gestionan los riesgos y
comprometen otros recursos, tales como
como dinero.Avisoquenoessin programa

específicoverdeelproductoocoordinación transparenteión a través de
los equipos funcionales.
Es posible que esos programas no tengan un trabajo pendiente de
producto clasificado.
En la gestión de programas, no hay jerarquía.Todo el mundocol
laborates y coordenadas en los equipos multifuncionales. Esta
colaboración evita el Caos de Coordinación como en TIK14.
El programateamssolveproblemscross-funcionalmente. Esagran
diferencia.
En lugar de que los gerentes funcionales se comprometan en nombre de

los equipos funcionales, los equipos de características se comprometen
con el programa. El equipo del programa tiene la responsabilidad de
eliminar losobstáculospara que el programa entregue el valor
programa.
El pensamiento magro añade la visión holística al programa. Cuando
añadimos lean, potenciamos a los equipos y eliminamos los residuos.
Amplificamos elaprendizaje de todos para construir la integridad en el
producto al ver el trabajo en curso, compartir decisiones, y tener una
definición detallada de hecho. Esto es crítico, porque cuanta más gente
tengamos,
más posibilidades tenemos de aprender y cometer errores. Si tomamos
un enfoque aleanal al principio, comenzamos con principios que hacen
sentido para la construcción de grandes productos.
De la misma manera que una buena gestión de proyectosnunca se
trataba de comando y control, una buena gestión del programa no
escom
mand-y-control. Buenogestión del programaessirviente de la comadería
principal. La gestión de programas permite la coordinación: ayudar a los
equipos y proyectos a colaborar para entregar algunos negocios
específicos objetivos.
Una vez que su programa tiene más de dos equipos, o necesita

coordinar con varias personas en toda la organización, liberar su
producto se vuelvemás difícil.Programagestión
le ayuda a coordinarse en toda la organización, para que todos se
centren en el objetivo: lanzar un gran producto que funcione.
1.8 Cambio de efecto ágil y magro en el

Nivel de programa
Agile se trata de la capacidad de cambiar mediante la entrega de

características que son valiosas para el negocio y aprender de ese
trabajo. Lean se trata de ver el todo, el flujo de su trabajo, la
construcción de la integridad en su trabajo, y la eliminación de
waste.Siqueañadirelprácticas técnicas(que debeen un programa
grande), elprogramahacevisibleelvaloresdesimplicidad, respeto y
coraje.Todo el mundocompromete a sutrabajo.Túcrearempoderado
Equipos.
Obtendrá mayor velocidad como subproducto si tiene la capacidad de
cambiar. Obtendrá saldría saldría sin velocidad si reduce su trabajo en
curso (WIP) y el desperdicio.
Ninguna administración puede exigir una agilidad y una inclinación a
nivel de programa.
Los equipos de características que pueden adaptarse y trabajar junto
con un enfoque de producto crean el programa ágil y magro.
Como resultado de la transición a ágil y ágil en los equipos, y el uso de
la gestión de programas adaptable, obtendrá mejor entrega-a
velocidad del mercado como resultado.
1.9 Lo quehacen los directores de programas
El administrador del programa es la voz o la cara del

programa.ElprogramagerenterepresentaelprogramaaelPMO(Proyecto
programa reportadopara senior
ManagementOffice)manager,I a
managersintheOperationsCommittee,organizationteam. Asa
de altos directivos.
El director delprograma facilita la colaboraciónen todala orga
nización. El director del programaes un líder de sirvientes. El
envejecimiento del hombre del programa no lleva nada a su
fin;directores de programas
permitir que los participantes del programa terminen su trabajo.
1.10 Take a Product Perspective
Puede que hayas pasado por que he estado hablando de tuproducto."

Es posible que tenga aplicaciones quequereferirseacomo"sistemas."
Usted podría
integrar varios sistemas de otros proveedores. Algunos de ustedes
podrían tener algo más.
Tomo una visión centrada en el producto de las cosas. Te sugiero que
lo hagas también.Sique
pensar todo el tiempo, "¿Quién es el cliente para esto?"quepodría tener
algunas ideas sobrecómoausarágilymagraaentregar.
"Pienso 'Producto'Ahora"
Solía pensar en sistemas o aplicaciones.Yo'vesidoun

administrador de programashaciendoaplicaciones
financieras internas para
Años.
Cuando empecé a pensar en "productos"en lugar de
"aplicaciones"sucedió una cosa divertida. Otras personas
también empezaron a hablar de producto. Los propietarios
de los productosen
comenzó a hablar de unapelea a sus clientesde manera

diferente. Empezaron a nombrar a sus usuarios, con
personas específicas.Yohizonoesperar
que suceda.
Nuestras historias se han enpequeño.Nuestroequipos de

características produjo más valor,
porqueconsiguióhacerenhistorias más pequeñas más
rápido. Todo porque empecé a hablar de "producto",no
"aplicación."
—Un gestor de programas experimentado
Bien. Ahoraquesaber lo queunágilomagraprogramaes.Deje que'shablar
decómousted podría organizarsuprograma.
1.11 Principles de Agile and Lean
Gestión de Programas
1. Tome una perspectiva de producto. Elprincipioes:"Los

negociosla genteydesarrolladoresdebetrabajojuntos."
2. Los enfoques ágiles y ajustados fomentan un enfoque holístico
del producto en el que puede cambiar más fácilmente para
cumplir
necesidades actuales. El principio es: "El cambio de bienvenida
requiere ments. Esta es una ventaja competitiva."
3. Los directores de programa son líderes de sirvientes. Los
principios son: "Construir proyectos en torno a individuos
motivados","Confía en ellos para hacerel trabajo"y "Empoderar
el equipo."
2. Considere su programa
Contexto
Usted y todos los miembros de su programa tomarán múltiples

decisiones a diario. El Marco Cynefines una forma de
pensando en su contexto con la intención de guiar sus acciones. Utilizo
Cynefin para pensarcómo puedoresolver problemas: ¿Podemos usar
buenas prácticas que todos los demás
usan?Hacerquenecesidadaexperimentoasabercómoaproceder?Hacerq
uetienen tantas incógnitas queque
no sé por dónde empezar?
2.1 Cynefin ayuda con las decisiones
Cynefinto para guiar

Thecan use solveFrameworkproblems(SNB07). Use isasense-
yourmakingapproachframeworkyouto su
Programa.
12
Considere el contexto de su programa 13
Marco Cynefin
Basado en el hecho de que usted está trabajando en un programa, usted

no está en elcontextoobvio. Un programa, por su propia naturaleza,
está al menos en el contexto complicado, debido al númerode
decomunicación
Caminos.
Si todos están en una única ubicación física, es posible que esté en el

contexto Complicado.Enel complicadocontexto,que can ver las
relaciones directas de causa y efecto entreeldiferenteestrésensu
programa.Sitodossus equipos
sonexperimentadoágilomagraequipos,quesabercómoaentregarpequeñ
as historias cada unodíaoasí que,quepodríaserenel
complicadocontexto.Entiendeslo quesudesconocidosson.Túpuedeuso
conocido y razonableprácticasparaorganización y organización
ytrabajandoensu programa ágil.
Tan pronto como usted y las personas de su programa no estén en la
misma ubicación, ya noelComplicadocontexto.Te has mudadoen
cualquiera de losComplejooContexto caótico. Esoes porque
Interferencias. Problemawill o o ser y suotracomunicación
tienecausasdeliveryeffectscommunicationmayunclearlagsand
incluso desconocido, aunque sólo sea debido a retrasos de

comunicación.
Considere su programa Context 14
Si la gente en su programare multitarea, o si usted tiene personas o

equipos que no puedencomprometerse con el programa, o si muchos
de sus equipos de características son nuevos en ágil, están al menosen
el contexto complejo.Túpuedeestar enelCaóticocontexto. En cualquiera
deloscontextos, el
desconocidos crean muchos riesgos y problemas potenciales.
En mi experiencia, si se puede decir, "Hemos hecho un trabajo así,pero
nunca en esta complejidad o con tantos equipos, o nunca tan distribuido
como estamos ahora",usted está en el complejo de texto deestafa.
Tienes muchas incógnitas desconocidas. Usted tendrá que manejar el
riesgo
de esas incógnitas.
Almirar el Marco Cynefin, pregúntese: ¿qué contexto

refleja surealidad? ¿Cómo te ayudará ese contexto a decidir si
debessentir, sondear o actuar como un alimentoelectrónico primero?
Si usted está en la parte complicada del marco de trabajo, necesita
expertos para resolver los problemas de su programa.Yo'mno hablar
deexpertosque crean cuellos de botellaportrabajandosolo.En su
lugar,desarrollaracommunityofexperts—tal vez la mayoría de
lospeopleen su
programa, trabajando en sus Comunidades de Práctica—para ayudar a
resolver los problemas.
Si se encuentra en la parte complejadel marco de trabajo, tenga en

cuenta estas acciones: ¿Qué experimentos utilizará
parasonda,adescubrir su
¿Incógnitas? Y, lo queproblemscanyousolvetomove elprograma de
nuevo a la parte complicada del marco, donde se puede
conocer sus desafíos?
Cynefinisnotatwo-by-twomatrixwhereyoulocateyourprogram, úselo
para tomar decisiones y nunca vuelva al marco.En su
lugar,especialmenteconprogramsde nueve equipos o más, diferentes
partesdeel programavoluntadtienen diferentes desafíos.Elmás
inconocibles los desafíos, más
quepartedeelprogramaesenelComplejopartedeel marco. A medida que
los equipos ofrecen características,
aprenden más. ThatpartoftheprogrammovestotheComplicated parte
del framework.
A veces, los equipos de la parte complicada del marco de trabajo

terminan las características.Comoqueaprender,quedescubrir un
enorme"gotcha." Eso podría causarellosaserenelComplejo partedeel
marco hasta quequeejecutaralgunosexperimentos para verlo
quequepuedehacer.
Howcanyou
AsaprogramComplexmanager,again?howencounter
canidentifyissuesearlyhelptheprogr
amwhenyoumove
de Complejo a Complicado?
No hay respuestas fáciles.No hayesnoreceta.Esteestrabajo.Se'es la
razónpor quéquenecesidadprogramagestión,areconocer y resolver
problemas en toda la organización.
El marco de Cynefin revela por qué la gestión ágil de programas puede

ser difícil. A medida que los equipos completan sus características,
lospropietariosdel producto deben actualizar la hoja de ruta y los
trabajos pendientes. Esposible que el programa termine antes de lo
esperado. Completar—o no—otros
projectorprogramsmayaffecttheteam'sfeaturecompletionorganization'
sprojectportfoliomightaffectability. Ciertamente,unodelos
otros teams para entregar.
Independientemente de su contexto, un programa está

emergente.Conemergenteproyectos,quepuede't planificar todo
enelcomenzando. Se puede ver un
hoja de ruta, planificar un poco, y seguir aprendiendo y adaptándose a
medida que avanza. Es posible que desee mantener lavisión same del
producto, pero los equipos (con sus propietarios de productos) podrían
seleccionar trabajo diferente.
O,comosuclientes/productopropietariosverelproducto,quepodríaquiero
acambiar el productodirección.
Si los equipos nocompletan las característicasenashort, regularbasis,
noone puede entender cuál es el estado del programa. Siel equipo
principaldoesn't
resolver problemas que permiten al programa crear un producto, usted
tiene un montón de riesgos, muchos de ellos desconocidos.
Gestionar por principios, no por prácticas.

Porsus riesgos, considere principios para su programa, no practica.

receta
Irecognizecouldtrytocreateyourcontext. for
you,butthatwon"Twork. Thinkand
2.2 Comprender suproducto

Complejidad
Su programa es único. Su programa puede tener complejidad en una

variedadde áreas: arquitectura, presión para liberar, donde las personas
sentarse en relación entre sí, los idiomas que todo el mundo utiliza, yla
agilidad de cada equipo.
En mi experiencia, la arquitectura general de su producto puede

gran parte de la complejidad. Cuanto másgrande sea su programa, más
complejidad tendráque administrar.Aquíson algunas arquitecturas de
programas que he visto.
Programa grande, un producto coherente
En este caso, tiene un producto grande.Se'snointegrando otros

productososistemas. El programa crea todo el
producto.Se'sgrandeconmúltiples equipos de características,queespor
qué tienes complejidadensuprograma.
Por ejemplo, un sistema operativo podría parecerun sistema
coherente
Producto. Tal vezuna gran tienda basada en la web

podríamirarcomounocoherentproducto.
Los productos interrelacionados son
diferentes.Siquenuncadecir,"Plataformayproductos en capas,"quetener
un ejemplodeunproductos interrelacionados.
Programade Productos Interrelacionados
En este caso, usted tiene una plataforma de servicios comunes conlo que
se siente al cliente como productos separados. Las GUI pueden tener su
propio aspecto, pero la GUI no es común en todo el programa
Producto.
Por ejemplo, un smartphone es un producto de sistema integrado. Cada

aplicación en el teléfono tiene su propia interfaz gráfica de usuario
donde se establecen las preferencias y se utiliza la aplicación.Cada
unoaplicaciónutilizaserviciosdeel teléfono'está operando
Sistema.
A veces, los productos interrelacionados integran otros productos en un
solo producto.
Es más probable que si integra sesión de otros proveedores' productos
en su propio, que usted tiene un sistema integrado programa.
Programa de Productos del Sistema Integrado
En este caso, los clientes comprantodo su conducto profesional. El

producto sigue siendo
tiene la plataforma de servicios comunes. Sin embargo, usted tiene
unaINTERFAgráfica coherente con la que los productos tienen que
integrarse. Usted podría
integrar sistemas o hardware de proveedores.
Estos programas tienden a necesitar programas de
programas.Diferententproductosvoluntadejecutarensupropiohorario. A
menos que sus proveedores también sean ágiles y magros, es posible
que tenga que administrar los riesgos de integración.
2.3 Saber qué equiposde programa
Necesita
Cada programa necesita la capacidad de trabajaren toda la

organización.
Es posible que necesite acoreteam, el equipo de negocios multifuncional
que tiene miembros de toda la organización. El equipo principal ayuda
a coordinar los esfuerzos que hacen que todoel producto sea un
Entrega.
Considere el contexto de su 1
programa 9
Si tiene más de dos softwson

equipos de características, es posible
el equipo delprograma. El que también necesite un equipo de
programa de software que ayude a
entregar
el software de trabajo. Eladministrador de programas de softwareesun
delegadoael equipo principal del programa. Eso significa que el
administrador del programa de software debe tener un equipo de
programpropio.Esteesverdaderopara
un gran programa.
Usted, comoadministrador de programas,necesita entender

quéequipos de programas necesita. ¿Su programa requiere un equipo
central y un
softwareprogramteam? Doyouneedacoreteamprogrammanager y un
administrador de equipo de software program?
Solopuede administrar un equipo de programa. Uno de los problemas
que veo en demasiados programas ágiles es que no tienen ni un equipo
centralni un equipo de programas de software. Tienen muchas
características o
equipos de componentes. EllospodríatienenScrum-of-Scrum
meetings,peronorealforopararesolviendo elprofundoproblemasolos
riesgos que pueden ocurrir a través deelorganización.
Cada equipo del programa tiene la responsabilidad de resolver los
problemas que el
los equipos que representa no puedenresolver por sí mismos.Elequipo
del programa,siesanúcleoequipooaprograma de
softwareequipo,obrasa través dela
organización,resolverproblemasyeliminación deobstáculosparael
Programa.
Cómo podría ser su equipo principal
Siestá coordinando y collaborating a través de toda la organi zation,

usted está manejando o es parte del equipo principal.Siquetomaramirar
a la¿QuéSuNúcleoEquipoMightLookComo,se puede ver
que hay un montón de participantes potenciales en este equipo del
programa.
Aparte del administrador delprograma, está elprograma de software
gerente de programas de hardware potencial, el propietario del

producto del programa, así como las ventas, implementación, legal,
marketing,
gerentes de proyectos de finanzas, recursos humanos y relaciones con
los inversores. Y esas son sólo las personas que podría imaginar. Puede
haber otras personas o diferentes en su organización.
¿Tiene un programa de procesos?

A veces, las organizaciones ejecutanproyectos de mejora de
procesos,
como la transición a ágil, como si fueran programas. Esoestá
bien.Enesto,sunúcleoequipo semirardiferente. Es posible
que no tenga equipos de características en su programa.
Sepa qué tipo de programa tiene.Notodos los programas son

ello mismo.Usoanúcleoequipo que tiene
sentidoparasuprograma.
Cómo podría ser su equipo de programa de software
Eche un vistazo a cómo podría parecerse su equipo de programa de

software para ver un prototipo de composición.
Tenga en cuenta que el propietario del producto del programay el

arquitecto del programa podrían funcionar como una tríada enel
administrador del programa de software para
decisiones de riesgo. ¿Significa esto que el programaproductowner no
funciona con el administrador principal del programa?
Depende.Depende de quién
necesiteelprogramaproductopropietario.Tal vezquenecesidadun
productopropietarioequipo, y el program propietario del producto
trabaja con el
núcleoequipoyeltécnicosproductopropietarioobrasconelsoftwarepropie
tario del programa.Sedependeenlo que su programanecesidades.
Mira al arquitecto del programa. Sus equipos de características

necesitan su
propios architects en sus equipos. Elproyecto deSally,que es su propio

programa,necesita su propio arquitecto. Mejor que el arquitecto hable
con el arquitecto del programa. Y si hayun arquitecto dehardware,
mejorque hable con el arquitecto del programa.Así quequepodría
necesitar una crcomunidad oss-funcionaldepráctica equipo de
arquitectura, como se ilustraenel"comunidadesdepráctica" equipo de
arquitectura.
Si usted es un director de programa, primero, ¿está en el
equipoprincipal?Siasí que,hacerquetener todos los que
necesita?Haceque el equipo tiene responsibilityparadespliegue?(No me
importaquién tenga la responsabilidad
para la implementación, siempre y cuando alguien lo haga.)
Si ustedno está en el equipo principal, ¿está en elequipo técnico que
trabaja a través de la tecnología? ¿Este equipo tiene la responsabilidad
de la implementación?Yo'msera little touchy acerca de la
implementación porque he consultado aprogramas en los que nounofue
responsableparadespliegue y sólo
descubrieronquecuandoPregunté,"¿QuiénEs
responsableparadespliegue?" Pensé quefueserestúpido porque lo hice't
verque.No,nouna had pensado enque.Vaya.
¿Por qué necesitas todos estos equipos de programa? El equipoprincipal
puede requerir un ritmo diferente al del equipo del programa de
software. Dado que el equipo principal a menudo tienegerentes sénior
o personas de alto nivel en él, recomiendoal equipo principal utilizar
kanban para reducir el trabajo en curso (trabajo en curso).Elprograma
de softwareequipospuedeusariteraciones sique
trabaja para ellos.Tal
veztambiénusarkanban;no'tmateria.Eldosprogramaequiposdireccióndi
ferentes riesgosendiferentes niveles.
El equipo principal del programa es mucho más estratégico. A menudo,

los directores de programas de este nivel gestionan los presupuestos y
los problemas de la cartera de proyectos. Ellos son los que dicen,
"Espera un minuto. El programade software no puedetener éxito.
Necesitamos fusionar estos dos productos." Que's una cartera de
proyectosproblema.
El equipo del programa software es más estratégico que un proyecto

determinado, pero noes tan probable queaproyectoproblema de
cartera.
Gestión de programas, especialmente para muchos equipos (piense
más que
20 equipos) se trata de asegurarse de que tiene un producto que ofrece

el valor de negocio que desea de todo ese esfuerzo.Así queel programa
de software tendrá supropioriesgos y el ritmo, que
esseparadodeelnúcleoequipoRiesgos y ritmo.
Si usted es un administrador de programas, asegúrese de saber qué
equipo está tratando de gestionar (coordinar y colaborar), para que
pueda ser más efectivos. Recuerde que solo puede administrar un
equipo del programa. (VéaseDon'tAdministrarMásQueUnoEquipo del
programa usted mismoparamás detalles.)
2.4 El equipo principal proporciona

Liderazgo y Valor
El equipo principal establece la agenda y la visión del programa. El

equipo principal ayuda a los equipos de características cuandolo
necesitan, y se mantiene fuera de su camino cuandono lonecesitan.
Elcaracterísticaequiposproporcionar el estatusaelnúcleoequipo,así
queque elnúcleoequipopuedecompartir el estado en toda la
organización.Elnúcleoequipo puede adaptarsesuriesgogestión, incluida
laprogramahoja de ruta,sinecesario.
Los delegados principales del equipo son esencialespara el éxito de su
programa. Pregúntate a ti mismo—y tal vez a las personas que podrían
estar en el núcleo
equipo—estas preguntas:
• ¿Tiene autoridad para comprometerse con las decisiones

presupuestarias para este programa?Canqueaprobar el gasto?
• ¿Tiene tiempo para comprometerse con este programa?
• ¿Hay personas o equipos de proyecto que puedas
comprometerte con este programa?
• ¿Puedes dedicar apersonas o recursos a este programa?
• ¿Puedes comprometerte con el éxito de este programa?
Cuando los miembros principales del equipo están comprometidos con

el éxito del programa,pueden resolver los problemas más fácilmente.
Estas son las responsabilidadesdel equipo principalantes de que

comience el programa:
• Escriba la carta del programa.

• Cree la hoja de ruta ágil.
• Cree el trabajo pendiente del programa, el trabajo pendiente de
las entidades.
Esto es lo que hace elequipo principal durante el programa:

• Iterar en la hoja de rutaágil.
• Iterar en el trabajo pendiente program, la acumulación de
características.
• Resuelva problemas empresariales multifuncionales.
• Resolver problemas que se intensifican desde el equipo del
programa de software.
• Supervise el estado y los riesgos delproducto.
• Borrar los obstáculos del programa para los equipos.
• Decida cuándo está listo el producto para su lanzamiento.
El equipo principalhace todo esto porque son responsables de la

valor comercial del programa. Debido a que el equipo principal es
multifuncional, las personas delequipo principal pueden ayudar a
diferentes departamentos y los proyectos entienden cómo son
interdependent.
El equipo principal encarna el principio de que los empresarios y los
desarrolladores trabajen juntos.
2.5 ¿Necesita un equipo principal?
Es posible que no necesite un equipo principal si tiene un programa

pequeño. Es posible que necesite un equipo de programa de software
conalgunaspersonas nal de funcióncruzada, como la persona que
pastorea productoaliberación, tal vez llamada implementaciónoSuelte.
Imagine que tiene un producto basado en la web.Tal vezquesólo tienen

cuatro o cinco equipos de características. Esos equipos de
características quieren saber lo que marketing e implementación
también están haciendo,y quieren saber loque todos los equipos de
software están haciendo, también.Enese caso, tal vezquepuede
mantener sólounoprogramaequipoytienentodoslo necesariola genteen
ese equipo.
Trate de mantener el número de personas en el equipo del programa a

diez o menos. De lo contrario,es difícil tomar decisiones.
Si usted tiene el equipo principal y el equipo del programa de software
como un equipo de programa mixto, tengaen cuenta que usted puede
tener problemas para resolverproblemasygestión de riesgos. Las
personas en el equipo del programa mixed querrán resolver problemas
en diferentes niveles, y ustedtendrá demasiadospersonas en su equipo
principal.
2.6 Principios de considerar su programa

Contexto
1. Considere su complejidad. Sisu organización quiere iniciar una

nuevaágilprogramaena
holaghlycomplejoarquitecturaconequipos distribuidos
geográficamentecuandoquetienennotuvo éxitoconágil en
elequiponivel,sus riesgosvoluntadserdiferente
desieltodoorganización
haágilexperiencia.Elprincipiosson:"Amplificar el
aprendizaje"y"Verelentero."
2. Defina qué equipos de programa necesita su programa. El prin
cipleis:"Empresarios ydesarrolladoresdeben trabajar juntos."
3. Considere cómo ayudará a su equipo del programa a entregar lo
que la organización requiere.Elprincipioes:"Eliminar los
residuos."
3. Organice su programa
Equipos
Cada programa es único. Una vez que entienda el texto de su programa,

puede decidir cómo guiar su programa hacia el éxito.
3.1 Crear su equipo principal
Su equipo principal son sus aliados en toda la organización. Son las

personas que le ayudarán a mover el producto de una idea a una
producto completado y enelseble.
Necesita una persona de cada función necesaria en toda la

organización, y no más de una persona.
De vuelta en cómo podría ser tu equipo principal,viste una foto
de un posible equipo central. Es posible que no tenga un administrador
de programas de hardware, por ejemplo. Tal vez ustedno necesita a
nadie de las relaciones con los inversores para liberar su producto.
Nomatterwhat, asegúrate de tener algún modelo de despliegue, ya sea

en tu equipo principalo en el equipo de
softwareprogram.Sedoesn'tmateriaqueequipo que la persona se
sientaen,comolargocomoquetienen un
persona de despliegue en algún lugar de un equipo del programa.
Tampoco importa a qué se llama la persona de implementación:
Libere ingeniería, DevOps, TI o algo más. Asegúrese de tener a alguien
cuya responsabilidad es asegurarse de que su producto
se implementa correctamente.
Su equipo principalnecesita personas que puedan dedicar su tiempo, y

el tiempode su departamentopara resolver problemas, asícomo
Presupuesto. Si puedes identificar a la persona específica que necesitas,
esoes lo mejor. Si sólo
26
Organice sus equiposde programa 27
conocer el papel, queestá bien. Pero también necesitasaber el nivel de

ese rol en la organización.
Asegúrese de hacer las preguntas en The Core Team Provides
Liderazgo empresarial. De esa manera, ya sabes que tieneselderechola
genteenel nivel adecuadoenelnúcleoequipo.
En el pasado, he tenido problemas para reunir a todos en mis equipos
principales.Elvendedor tipo hizo't quieren comprometerseauna reunión
quincenal.Elfue"demasiadoocupado." La mujer
MarCommfuetambiénfrantichaciendootras cosas.Elabogado
corporativonuncarespondiósucorreo electrónico.
Necesitaba a esas personas para un lanzamiento exitoso del producto.
Sin ellos, no podríamossaber si teníamos las fechas correctas, si todos
entendiéramos los riesgos. Estaríamos en el proverbialarroyo.
¿Cómo podría hacer que valga la pena venir a las reuniones del equipo
principal?
He hecho estas cosas:
1. Apellido de persona específica. "María, ¿por favor?trabajoen mi

nuevoprogramaconmigo?Yodisfrutado trabajando con usted
en ese último programa.Yo'dcomoahacerqueagain."
Cuandoquepedir a unpersonapornombreparaayuda,
quepersonaesmás probable que diga que sí.Siqueponer
unsolicitudencorreo electrónico, todo el mundose
sientegratisignorarque.
2. Le pidió a un gerente sénior que asignara"la mejor persona"en
su departamento.Yo'vetuvo esta conversaciónconasegerente de
niormásmás de una vez:"John, ya sabes queYo'mel director del
programaparaelXYZprograma,queesla empresa's#1prioridad.
Necesito a alguien de Training en el equipo principal.
Yonecesidadsumejorpersona, nosólopara representar la
Formación. Ese person desarrollará nuevos materiales de
capacitacióncomo
Softwaredevelopstheproduct,andasDeploymentgetsready para
su lanzamiento. Nosotrosserálistocomounorganizaciónpara
liberar, todosenel mismo día. Poreso necesito a tu mejor
persona."
Veola Voz de la Razón, junto con el resplandor Steely Eyed y una

gran sonrisa.Casi siempreobtenerlo queYopreguntarpara.
3. Yo uso la influencia, donde pienso, "¿Qué va a hacer que valga la
pena para este gerente senior para darme lo que quiero?"Estees
por eso que
usted necesita saberpor qué la organización quiere iniciar el
programa. He discutido los resultadosdel programacon la vista
puesta en el beneficio empresarial para el gerente senior.
Siempre les digo a los miembros del equipo principal que somos las
mejores personas de la organización para trabajar en este producto—
que podemos
collaborateandshepherdthisproducttoitsfinalrelease. Poreso la
organización nos eligió.
Yo creo esto.Por quéotra cosaseríala organización gastadineroenel

programa?
3.2 Tenga cuidado con el olvido del equipo principal

Miembros
Cuandoentreno a los de managers del programa, a veces descubren que

han pasado por alto a personas o jugadores clave para el equipo
principal. A veces se olvidan porque el programa es pequeño y el equipo
principalse enrolla en el equipo del programa de software. A veces es
porque el director del programa invita a las personas correctas yno
responden en un cantidad razonable de tiempo.A
veces,no'sapoderjugaren
trabajo a un nivel superior en la organización. A veces,es otra razón.
¿Tiene algunos roles comúnmente "omitidos"en sus

programas?Revisiónsucoremiembros del equipo. ¿Tienes a todos los
que necesitas,
para lanzar un producto?
Si no es así, pida a la gente que participe o alista al gerente senior enesa
área para ayudarle a encontrar el persona para su equipo principal.
3.3 Elpapel propio del producto es clave para eléxito del

programa
No importa si hablamos delpropietario del producto del programa o de

un propietario de producto en un equipo. Cada propietario de producto
tieneun papel clave para jugar en un programa.
El propietario del producto del programa, a veces conocido como el PPO,
o el delegado delequipo del programa, pastorea el valor comercial de la
hoja de ruta y de las liberaciones. El PPO representa a los propietarios
del producto al resto del equipo del programa. El PPO
esasirvienteliderazgoposición. Su organización podría llamar al
aproductoPPO
director.
El propietario del producto, a veces conocido como el PO, es la

persona en
el equipo de características que entiende lo que los clientes quieren y
traduce esa comprensión. Ustedtambiénpuedeneedasujeto
matterexpertsuchasanarchitectorseniorseniortechnicaltowork with the

PO.ThePO,o el equipo de po, o el POyelprogramaarquitecto
evaluarquecaracterísticasahacerprimero,los desafíos técnicos con esas
características, yelCostodeRetrasoparacada característica.
Si tiene un producto muy complejo con muchos equipos de
características, considere la posibilidadde un equipo de valor de
propietario deconductos profesional.
Diferentes equipos
En este escenario, el equipo de características (equipo de desarrollo de

productos) im plements una característica. El equipo de valor del
productodecide la hoja de ruta del producto y clasifica
lascaracterísticas:qué hacer cuando, para el programa.Elel equipo de
cartera de proyectos decide cuándo comprometeraaproyectoo
un programa.
Estos equipos trabajan desde su perspectiva—equipo de características,

producto u organización—cuando tomandecisiones.
Los propietarios de productos en todo el programa funcionan como un

equipo de valor de producto o un equipo propietario del producto.
Cuando trabajana través deel o
ganización, pueden limitar el número de interdependencias y continuar
actualizando la hoja de ruta en función de lo que los equipos completan.
Cualquier persona con el propietario del productoen su título debe
valor de la característica en discusión y la base de clientes para este
producto.Siun productopropietariodoesn'tentender la base de
clientesparaesteproducto,elPOvoluntadno tomar buenas decisiones
basadasenvalor. El PO no podrá responder a ninguna de las preguntas
sobre el riesgo, tales como, "¿Qué hacen nuestros clientes ¿necesita o
quiere?"paraeste
Producto.
El propietario del producto también debe entender la tecnología del

producto. SielPOentiende la tecnología, el equipo puede
explicar,"Podemoshacerlas cosas de esta maneraode esa manera."
O,"Siqueimplementarestecaracterística en primer lugar,quepuede
ahorrar tiempoenque la característica en segundo lugar."
O,"Nosotrospuedeimplementar elflujoestemanerayahorrartiempo
paraelusuario."Vereldiscusión en Product ManagerVs.ProductoEl
dueño.
Cuando el PO entiende a los clientes y latecnología, usted tiene un gran
PO. Sin las dos cosas, pierdes el barco.
Los propietarios de productos en los equipos saben dónde está el
producto. Ellospuedever el producto evolucionar
cadadía.Ellostienenelresponsabilidad
para tomar pequeñas decisiones todos los días que ayudan a la
producciónt crecer.Usola inteligenciadeel
productopropietarioscomoequipoacrearyactualizaciónelhoja de ruta
ágil. Cuanto más pequeñas seanlascaracterísticas, más fácil será.
el intento de PPO de dictar la direccióndel producto

sin retroalimentación,esto se vuelve bastante difícil. Su programa
perder impulso. Siel todoelproductopropietariosunirseencolaboración
conelPPOpara crear la hoja de ruta ágil yelliberacióndefinición,basado
enenlo queque'vedecididolos equipos deben entregar,
suprogramavoluntadmantener su impulso.
3.4 Organizar elPrograma de Software
Equipo
Ahora que tiene un equipo principal, vamosa ver cómo podría sersu
equipo de programa de software. Es posible que debarevisar la imagen
Cómo podría ser su programa de software.
El equipo del programa de software tiene equipos de características
solos, si pueden estar solos.Joe,Tim,yHenrytodos tienen equipos de
características independientes.
Si más de un equipo trabaja en un conjunto de características, es posible
que necesite un programa para ese conjunto de características.
Recogeresos equiposenun programa.
Sally tiene un pequeño programa de equipos de características
recopilados.
Para un programa de software, escale horizontalmente, no hacia arriba.
No hay jerarquía de gerentes de proyecto, a menos que los equipos lo
deseen. No hay jerarquía de Maestros Scrum. Los equipos son iguales y
trabajan juntos.
El té del programade softwaretiene estas responsabilidades durante el
programa:
• Resuelva problemas técnicos multifuncionales.

• Revise, supervise y administre los riesgos en los equipos de
entidades.
• Resuelva problemas que se escalan desde los equipos de
entidades.
• Supervise el estado delproducto.
• Borrar los obstáculos del programa paralos equipos.
• Proporcionar consultoría al equipo principal sobre riesgos,
decisiones de productos y más.
El equipo del programa de software no tiene que hacerse

grande.CuandoYoejecutarprogramas, envio por correo electrónico a
laprogramaequipoagenda de reuniones(una reunión de
problemasolución) paratodo el mundoenel programa, y
decir,"Aquísonella genteYonecesidadaasistir.Todos los demás:
permítanmesabersiqueson
Asistir. "
Evitar el caos de coordinación
Si todo el mundo tiene que participar en cada reunión, su

programa nunca entregará un product.
Si tiene20, 30 o 40 equipos, pida a los equipos de

características que se organicen como equipos de "conjunto
de características". Eso ayudará a varios equipos a
convertirse en pequeños programas dentro del programa
más grande.
Solicite que una persona,el administrador del programa
para ese conjunto de fea ture—participe en las reuniones del
equipo del programa de software. Ese equipo del conjunto
de características puede decidir cómo quieren hacer
la información transparente hacia y desde todos los equipos de
características.
Biga
Youprogramcangetforthesoftwareprogramorthehardwareprogramma
ydiscoveryourorganizationhasanaturallimittohow.
A algunos gerentes les gustaría lanzar a la gente al programa, con la

esperanza de que puedan trabajar más rápido porque hay más
personas.Tú
puede descubrir quees tan difícil coordinar las comunicaciones y las
interdependencias, queno vale la pena la grandeza.Se'svale la pena
tener
el programatomar más
tiempoutilizandoagileroadmaps,sothelosequipos del programa y el
director del programa pueden gestionar la coordinación.
Cada organización tiene un punto ideal para el tamaño

del programa.
Si está empezando con la administración del programa,
intente
en tamaño antes de que
para mantener su programa-administrara nueveque
vapor menos.
Learnhowstartwith
un programa más grande. Puede que no necesites

más equipos que eso.
¿Necesita un equipo de programa de hardware?
Te darás cuenta deque mencioné un equipo de programas de

hardware.
tienen un producto que requiere un equipo de programa de
hardware, o
un equipo de programas mecánicos, organizar esos equipos
de programas. Recuerda,una vez que tenga másqueaun par
de equipos de proyecto,considerarla organización de
unpequeñoprogramaparaellos.Miregladepulgarisqueuna
vezTengo cuatroproyectoequipos, tengo un pequeño
programa. Esaes mi regla general. El tuyo puede ser
diferente.
Considero que el firmware es un caso especial de software.
También pido que
el firmware es actualizable como si fuera software. De esta
manera, tenemos la máxima flexibilidad para las decisiones
de liberación.
3.5No administre más de un equipo de programa usted

mismo
Algunos directores de programas cuyas organizaciones están en

transición a ágiles no siempretienen claro qué equipo de programa
están gestionando. A veces, esoes porquela organización no siempre se
da cuenta de que necesitan más de un programaequipo.
Usted podría pensar que puede administrar el equipo principal y el
software
programteam, especialmentesi sólo tienes trestofiveprojectteams para
la parte de software del programa.SeTentacióning.
Nolo hagas.
Puede administrar un equipo de programay tener un tablero kanban.

Asegúrate de que todos ven todo el estado, los riesgos, los obstáculos,
todo. O bien, puede tener dos equipos de programas, y tendráque elegir
qué equipo de programa administra.
Organizatus equipos de programa 34
Una vez que tienes tres o más equipos, tienden a necesitar un

programa
gerentepropio.QueEs una directriz,nouna
regla.Ensuprograma,elsoftwareequipospodría
necesitaraprogramagerentepara
dos equipos, especialmente si están distribuidos
geográficamente.Ellostienen más obstáculos e interdependencias.
Si intenta administrar más de un equipo del programa,

facilitarla colaboración necesaria en toda la organización. No serás un
líder siervo útil y defraudarás a la gente. Don'thacerlo.
3.6 Principios de organización de su

Equipos de programa
1. Sepa qué equipos de programas necesita.Elprincipiosson:"Ver

todo el" y"Simplicidad."
2. Su equipo principal, si lo necesita, es tan grande como lo
necesita para
ser,ytanpequeño comousted puede hacerlo. El principio
es:"Amplificar el aprendizaje."
3. Asegúrese de que el equipo principal está formado por todos los
que necesita para lanzar el producto.El principioes:"Los
negociospersonas y desarrolladores debentrabajojuntos."
4. Inicie su programa a la derecha
Si desea que su programa tenga éxito, comience de una manera que

promueva el éxito. Utilice una carta del programapara definir la visión
y lo que hecho significa paratodo el programa.Enademás, cree
elprimeroágilhoja de rutaaespectáculotodo el mundo el
grandeimagen,eldirección del producto.
4.1 Una arteria Chdel programa Establece laestrategia
Iniciar un programa esmuy parecido a iniciar un proyecto. Necesitas

saber adóndevas. Necesitas saber lo que significa hacer. Eso significa
que necesita una carta del programa. Charteringaprograma crea un
programa compartidovisiónparael
programaequipoandporextensión,eltodo
Programa.
Elalcance de una carta del programa es todo el producto. Imagine que

su producto es unsitio web que permite a las personas comprar
antiguedades.Hayasearchproject que permite a las personasabúsqueda
ylugarartículosonwish
listas; correo electrónico para anotarel posiblecomprador de productos
nuevos o existentes;yatransacciónproyecto de procesamientoqueayuda
a la gentepagarparalo que
quieren.
La carta del programa podría ser algo como esto: "Proporcionar a los
amantes de la tique una manera de comprar artículos inusuales,
personalizados para su
Gustos. " Quevisióninferela búsqueda, la comunicación y el
pagoproyectos,perodoesn't decir nada acerca
deelespecíficosproyectosenel programa.Elprogramavisiónayuda ala
gentever todo el producto
Posibilidades.
Cuando el equipo del programa crea una carta, they tienen

laoportunidad de fusionarse, para trabajar como un equipo del
programa. Esoes porque aprenden a definir y acordarelpropósito del
proyecto, lavisión y los criterios de liberación.Para
cuandoelprogramaequipoterminaelcarta,que
35
Comience su programa a la derecha 36
haciadónde se dirige el programa y qué significa hacer para el

programa.
Para los proyectos, la fletamento tiene el mismo

efecto.Aproyectolímites de cartasualcanceaun conjunto de
características,inclusosiel conjunto de
característicasesgrandes.Siquetienen correo electrónicocomopartedesu
producto,elprojectequipo que implementa el correo electrónico
limitarásuvisiónacorreo electrónico.Y,un equipo de proyecto (o varios
equipos pequeños)puedetrabajojuntosaescribiruna carta de proyecto.
Una vez que su programa tiene más de tres equipos, es posible que no
desee que todos en el programa (core team, equipo del programa de
software,
y los equipos destacados) que participan en el esfuerzode fletamento
del programa, que'es demasiada gente.
No importa cómo decida involucrara la gente, fletar el programa. La

carta del programa establece el escenario paratodo el
programa.Sinecessary, cada unoproyectopuedeescribirsupropio basado
en la cartaenel
Programa.
La carta ayuda a todos a entender lo que el programa necesita de ellos

y cómo pueden contribuir. Pueden tomar las pequeñas decisiones y
compensaciones todos los días que suman.
Normalmente, usted bring suequipo del programa juntos en una
habitación para crear la carta. Pero, ¿qué sucede cuando tu programa
es grande?O,'s geográficamente distribuido? ¿O ni siquiera sabes quién
se supone que está en qué equipo del programa? Esto es cuando la
administración del programa demonstrates su valor— cuando
lascircunstancias noson
Fácil.
4.2 Desarrollar la Carta del Programa con

el Equipo Principal
El equipo principal es responsable del valor comercial del programa. La
carta define por qué la organización está trabajando en el
gramo, y explica las razones de los planes subordinados: la
comercialización
plan, el plan de ventas, el plan de capacitación, el plan de

implementación y en y en.
La carta del programa.Sisu

programa está limitado a decir, 25 personas o menos, es posible que
desee reunira unall de la gentepara fletar elprograma,siempre y
cuando un facilitador experimentado ejecute esa reunión.
Si su organización le ha dicho a 150 personas que inicien este programa
el lunes, no intente crear un programa carta con todo el mundo.Se's
bastante,siimposible,afacilitar 150personaspara abrazar una visión y
criterios de liberación.
Usted necesita suficiente gente para colaborar en la carta del programa

para que reciba comentarios de las personas que trabajanenel
programa. Necesitas mantener ese número lo suficientemente pequeño
para que puedas facilitar alas personas en la habitación.
Para un programa, especialmente si tienes equipos distribuidos, te

recomensaque consigas a todos en el equipo principal en unaubicación
físicaacrearla carta.Sialguiendice,"Nosotrosdon'ttienenelpresupuesto,"
ver las ideasen WeCan't Afford the Travel.
4.3 No podemospermitirnos el viaje
Es horade fletar el programa, y todosestánseparados por el tiempo

Zona. Su gerente dice que no, la organización puede'taffordthetravel.
Debido a que el programa es un gran esfuerzo, todo el mundo necesita

ser hiper
conscientedesexpensesand,asaresult,budgetwisely. Eso'por qué hacer
que todos se unan en un lugar físico para fletar el programa, desarrollar
la hoja de ruta inicial del producto, y determinar lo que necesita
en una primera versión es tan rentable.
Iniciar la planificación contodo el equipo del programa puede ayudar.

Asíes como vendes la idea a tu dirección.¿Cómomucho¿lo haríacostopor
cadapersonapara llegar a unaubicaciónparaasemana?
Promediar los costos para cada persona en su equipo de programa.

LetSupongamos que tienediezla genteensu programaequipoyelcosto
promedio es de $3000 paraasemana de viaje.Que's$30,000.
Ahora, ¿cuáles son los costos por cada semana de retraso del
programa? Si usted asume que las personas cuestan $75/hora de
trabajo cargada, entonces un retraso de unasemana en suproyector
sería $75 multiplicado por el número de personas multiplicado por 40
(horas en una semana).Usted podríafácilmentetienen ununoretraso de
la semana si la gente en elcaracterísticaequiposdon't saber lo que
se supone que deben hacer cuando.
¿Cuántas personas tienes en tu programa? Si son25 personas, el costo
de un retraso de una semana es de $75,000.Sique's80personas,
quenúmeroes de $240,000. Sison 150 personas, ese número es de
$450,000, por sólo una semana de retraso.
Compare ese costo con el inicio correcto del programa, haciendo

algunas
backlogpreparation, reunir al equipo del programa para prepararse
para influir el uno en el otro, toda esa relación-construcción?No tiene
precio.Ciertamentebaratoen comparacióna los costos de viaje.
Recuerde, puede pagar porviajes baratos ahora o defectos y confusión
que causa un gran costo de Retraso más tarde. Tú eliges.
4.4 Liderar el esfuerzo de fletamento del programa
El equipo principal es responsable de la carta.Como

elprogramagerente,quepuedeplomoelprograma de
fletamentoesfuerzo.No se puedeyno
quierenaescribirelprogramacartaaluno. Si escribes la carta solo, pierdes
la oportunidad de ayudar al equipoprincipal
fusión como un equipo.
"Acuerdos de trabajo nos ayudaron a la Carta"

Estábamos acostumbrados a trabajar en proyectos ágiles

más pequeños,uno, tal vez dos equipos. Entuvimos que
empezar este gran pro gramo. Tratamos de escribir una
carta, y nos quedamos atascados.
Todos sabíamos cómo trabajar equipos inágiles, diferentes
equipos ágiles.
Wedidnotknowhowtoworktogether.Wedecidedto
desarrollar nuestros acuerdos de trabajo como un
equipocentral.
Una vez que tuvimos acuerdos de trabajo,pudimos
fundar.Nuestroacuerdos de trabajo ayudaron a
nosotrosvercómo trabajar juntos
en toda la organización.
—Experimentado gestor de proyectos ágil, pasando a un
director de programa de equipo principal
Comience el programa con el equipo principal unos días antesde invitar

al resto de los equipos de características.Siqueyatienenelequipos de
característicasenjunta,Pregunto a los equipos de
característicasaaprendercómotrabajojuntosparaunoiteración,
comoen¿CómoaIniciar un programaConMásPersonasThan
YouNecesidad.Eso da lanúcleoequipoaoportunidadaaprender
cómoatrabajo
juntos y crear la carta del programa.
Para un programa, asegúrese de que la carta sea
visible.Yocomoaescribirla carta,postque,y hacerquedisponibleasí
quetodo el mundoenel programapuedeversiempre que lo necesiten. En
cierto sentido, la carta es una de sus grandes cartasvisibles, a pesar de
que no es algo que
Medida. Después de todo, la razón para fletar el programa es

asegurarse de que todos entiendan por qué este espín. están pasando
su tiempo trabajando en
4.5 Crear su propia cartade programa
Plantilla
Como mínimo, la carta del programa contiene la visión del producto y

los criterios de liberación, para que las personas sepan por qué están
trabajando en el
programa, y cómo sabrán cuándo pueden lanzar la versión finalde

laproduc.
Plantilla de cartade programa ágil
Youmaytoaddmilestonessuchastradeshowsshowsortarget fechas;lo
que está impulsando esteprograma,ROT07 y punterosaotros
planesoelriesgolista.
Esta carta es a la vez un documento chárter y un plan de programa.
Sique
needtobreakthedocumentintotwo,considerarhavingjustthevisión y
criterios de liberación como el documento de carta del programa. A
continuación, puede tener el resto del documento como plan de
programa.
Si usted tiene un documento como carta del programa, puede talleres
de la carta programconteo con todo el equipo principal en un día o
menos al comienzo del programa. Recomiendo esto porque es fácil y
ayuda al equipo principala fusionarse como un equipo.
4.5.1 Desarrollar la Visión del Programa
La visión del producto ayuda al equipo principalacrear lahoja de ruta

delpro gramo y el trabajo pendiente del programa.Setambién ayuda a
los equipos de entidades a tomar decisiones diariamente. La visión del
programa puede incluso ayudar a los proyectos a crear sus visiones, si
es necesario.
Estos son tres pasos para crear una visión del programa:
1. Defina los erspersonalizados principalespara este producto.

Podrían
ser el mercado masivo, clientes existentes,nuevos clientes o un

segmento de mercado específico.
2. Defina el beneficio del programa.Por quésonusted está haciendo
este programa? Responda a la pregunta de "porqué".
3. Defina los problemas que resuelve este producto.
Escribe todo lo que necesites y luego edita hasta quebajes de dos a

cuatro oraciones.Sisuvisiónesmás de cuatro frases,refugio'tdescribió
elprogramaenfoque todavía.
Asthecoreteam funciona a través de estos problemas,quewilbecome

más de un equipo.Túvoluntaddescubrirriesgosenel comienzo de
laprograma.
Consulte Identificar riesgos del programa para obtener más
información sobre los riesgos.
Si ustedtieneunsmallprograma, yeveryoneisinla habitación, podría pedir
a la gente que se divida en pequeños grupos de tres o cuatros, y trabajar
en esto en paralelo.
Timebox esta a 30 minutos. Es posible que no crees la visión perfecta.
Puedeitrenestedespués dequehacerelsiguientepieza,el lanzamiento
4.5.2 Desarrollar criterios de liberación
criterios le dicen lo que significa "hecho"para el programa.Tú

enumerar todas lascaracterísticas,que sería imposible. Es
posible que pocos escenarios de lo que el producto debe ser
capazde hacer.usted tiene una fecha objetivoenmente.Tal
vezquetienen algunos
criterios de rendimiento en mente.
Los criterios de liberación son los pocos criterios vitales que le indican
cuándo se hace el producto, ROT07.No son todo lo quepodríahacer en el
producto.Comolargocomoquerecuerden que,que'llserestá bien.
¿Necesita zonas de aterrizaje?
A veces, usted tiene que hacer compensaciones técnicas

cuando se trata deunprograma. Casi sabes lo que significa
hacer,pero no del
todo.Esoscompensacionesproporcionarqueun
aterrizajezona.
Imagina un smartphone. Usted sabe que los desarrolladores de
productos
necesidad de intercambiar el tamaño de la batería con el
consumo de rendimiento, disipación de calor, dondeestá
latenna, y probablemente otras cosas que yo'tsaberacerca
de. Esoes lo que quiero decir con aterrizar
Zona.
Anote sus zonas de aterrizaje en su carta.Observe cómo
resolverá las zonas durante el programa. Asegúrese de que
el
resolución está en la hoja de ruta en alguna parte.
Si agregas zonas deaterrizaje, describetheminawayque hace sentido

para los equipos de características. Usted puede decir, "Necesitamos
zonas de aterrizaje que el comercio
offpowerconsumption ybatterylife"forahardwareproduct. Para un
producto solo de software, podría decir: "Necesitamos zonas de
aterrizaje que negocien el rendimiento y la huella de database."
4.5.3 Fechas principales
Si tienes hitos importantes, este es el lugar para ponerlos.Tal

vezquetienenacomercioespectáculo.Tal vez usted
tienemensualmentegotas deaproveedor o paraaproveedor/cliente.Tal
veztienenpara cumplira
Regulación. Sea lo que sea, asegúrate de tener fechas transparentes.
Especificar fechasneutrales
Un gerente de programa de equipo principalbasadoen
Estados Unidos escribió las fechas de ma jor para su
programa como 6/1/2014,8/2/2014, y 10/15/2014.
Esas fechas significaban el 1 de junio de

2014;Auráfaga2,2014,y 15 de octubre de 2014.
Cuando la directora del equipo del programa de software

con sede en el Reino Unido vio las fechas, estaba
preocupada."¿Por quéhacerquetienen fechas quesonasí
quecercajuntos? Tienes 6 de enero, 8 de febrero, ¿y cuál es
el mes15 de todos modos? No tengo idea de lo que eres."
El director del programabasadoen el Reino Unidosospechó
que las fechas estaban en orden mes/día/año. Necesitaba
comprobarlo.Segurosuficiente, lo eran.Basado enensu
sorpresa, el programa del equipo
principalgerentedecididoadeletrear todofechas.Lo hizo't
ponereldíaprimero, sino
porqueespecificóelmesenortografía,no
números, todos los demás entendían lo que quería decir.
Considere las fechas neutrales cuanto más grande y
geográficamente se distribuya suprograma.
4.5.4 Señale la hoja de ruta del producto
Los propietarios de sus productos o el propietario del programa product

crearány entregarán una hoja de ruta del producto al programa. Sin
embargo, usted y el equipo principal y/o el equipo del programa podrían
tener que colaborar para crear la primera hoja de ruta para mostrar a
todos ladirección del producto. (Consulte Crear la hoja de ruta ágil para
details sobre cómo crear una
hoja de ruta.)
4.5.5 Desarrollar los otros planes
Después de crear la visión del programa y los criterios de liberación, los

demás miembros del equipo del programa pueden producir sus planes
para sus áreas.Esosplanesson entregables aelnúcleoequipo.
projectfirstjob para createa Todo el que está a laTu planespodría

serel equipo principalkanbandonde.
el equipo principal le debe al equipoprincipal un plan para su trabajo.

De lo contrario,
¿por qué necesitan serelcore equipo? Me pareceque estoes sacaron a la
gente del equipo del programa que "sólo"quierevisitar.Se'sestá
biensiquierenavisita. Pueden mirar, y no hablar. No pueden resolver
problemas ni participar. La entrada en cualquier equipo del programa
es un plan.
Pregunte a los miembros del equipo del programa para mantener sus
planes de proyectocortos.Los planes se basan en elementos de acción:lo
queestefunctionneedsaentregarparael programaasí quequeelproducto
puede liberarse. Esoes todo.
4.5.6 Identificar los riesgos del programa
Es posible que conozca saquede riesgos significativos para su programa

al principio.Siquehacer,desarrollar su riesgolista y planes de mitigación
ahora—tantocomopuedes.
Plantilla de riesgo del programa
Te recomiendo que uses alto, medio y bajo para describir tus riesgos.
Muchos programas comienzan con piezas significativas de riesgos
indefinidos.Siquetry yadescribircon porcentajes,quepodría encontrarse
estos problemas:
• Otras personas,como los altos directivos, quieren reducir la

importancia de los riesgos reduciendo el porcentaje de número.
Eso proporciona a las personas alivio emotional, pero no

arriesgan el envejecimientodel hombre.
• El uso de números al inicio del programa lleva a la gente a creer
que tiene más datos que ustedhacer.Un adulto mayor
desarrollador una vez me dijo: "Pensé que era sólo un problema
del 60%."SefueNo.
Considere la posibilidad de hacer una lluvia de ideas sobre la lista de

riesgos que desea administrar y mitigar con el equipo del programa. De
esta manera, puede ver los riesgos a nivel de negocio con el equipo
principal, y los riesgos a nivel técnico con elequipo de programas de
software.
4.6 Iterar sobre la Carta del Programa y

Planes
Esmejor para su programa tener una carta parcial de la visión del

producto y los criterios de liberación que esperar y tienen una carta
"completa". Al iterar, muestra alas personas del programa cómo crear
de forma incremental e iterar.Elprograma team proporciona el
ejemplodetrabajandoenunmanera ágil y magra.
No tengas miedo de iterar en la carta porque nadie lo sabe todo al
principio del programa. Su equipo de programa necesita tiempo para
aprender, tanto como los equipos de características.
No utilice un cero de iteración para crear la documentación
necesaria.Siquepermitir dos
semanas,quevoluntadtomardossemanas.Sin
embargo,siqueorganizarelequipo del programa y crear un
talleraconstruir elvisión y los criterios de liberación, el
programaequipomiembrosvoluntadsaber lo
suficienteagentasaelprimeroborradordesuplanes. Usted puede ayudar
al programa a ser más ágil pidiendo a las personas que iteran en sus
planes.
4.7 Crear la hoja de rutaágil
La visión delproducto es necesaria, pero no es suficiente para iniciar el

programa.Enadiciónala carta, utilice esta vezacrear
la primera hoja de ruta ágil.
La hoja de ruta ágil proporciona dirección del productoa todos: los
equipos de desarrollo de productos, los equipos del programa y los
patrocinadores. La hoja de ruta ágil explica la directidelproducto.
Elproducto
la dirección proporciona contexto a todos.
Una hoja de ruta es una lista de deseos, lo que desea que ocurra. Los
atrasos son lo que hacen los equipos. A medida que los equipos terminan
sus atrasos, el producto
los propietarios actualizan la hoja de ruta.
La hoja de ruta tiene las versiones internas y externas, los conjuntos de
características (también llamados temas) y cuando los propietarios de
productos esperan ver
características del producto. Se'suna hoja de ruta;'slo que esperasellos
equipos pueden implementar.
La hoja de ruta es una lista de deseos.Seesnouna

promesa de cumplir. La hoja de ruta es una
dirección product.
Al igual que un mapa regular, los equipos pueden encontrar desvíos en

el camino. Esporeso que los propietarios de productos crean trabajos
pendientes clasificados para los equipos que son mucho más pequeños
en el alcance. Los propietarios de productos actualizan la hoja de ruta
basada en la realidad, al igual que usted would si usted estaba
conduciendo
en algún lugar y se encontró con un desvío.
Asegúrese de que su hoja de ruta sea suficiente para que su programa

lo busque.Siquedon'tnecesidadun seis cuartosperspectiva,considerar un
seis mesesperspectiva.Una organización que conozco tiene programas
de tres meses. Ely utilizar una perspectiva de 12-semana. Tienen varios
equipos,así queque
necesidad de mostrar a todos aproximadamente cuando los equipos
necesitan entregar qué.Perosuperspectivaestodo el programa.
Un potencial ágil Roadmap
A medida que los equipos completan las características, los propietarios

de los productos actualizan la hoja de ruta para este
trimestre.Sielequiposentregaral menos mensualmente, elproductolos
propietarios pueden actualizar la hoja de ruta trimestre a trimestre cada
mes.Elpropietarios de productosactualizacióntantohojas de
rutacuandoque need
tomar decisiones o cambiar las decisiones del producto.
Los atrasos cambiaránincluso si la hoja de ruta no lo hace.Desarrollarlos
atrasos detalladosparaenmenosunoynomás de tres iteraciones.
Ifyourteamsusekanban,developseveralseveralmore featuresthanateam
see en su tablero kanban.
Cuanto más trabajo de preparación hagas para los atrasos, más
descubrirás que perderás
tiempo.Elequiposnecesidadasaberquecaracterísticas
quevoluntadtrabajoena continuación. La hoja de ruta ayuda a los
equipos a ver la dirección general del producto.
Nopasesmucho tiempo preparando historias antes

de tiempo.Usoágilymagraahacerproducto justo a
tiempo
Planificación.
Definir y actualizar la hoja de ruta lleva tiempo.Definiciónpequeñas
características, clasificaciónellos,y reclasificarellostambién
tomatiempo.Su
Inicie su programa Right 48
los propietarios de productos descubrirán quees una línea fina entre

proporcionar a los equipos una perspectiva a largoplazo(la hoja de ruta)
y la creación de residuos
porque lo que los equipos implementan a partir de los atrasos cambiará
la perspectiva a largo plazo y el siguiente trabajo pendiente.
Esta fina línea es la razón por la que el rol de propietario de productode

cada equipoes un trabajo de tiempo completo. Noes posible que el
propietario de un producto entrey salga en un programa ágil y espere
satisfacerelpapel.EllospuedeNo. Los equipos necesitan a sus
propietarios de productos a tiempo completo para preparar historias
para el próximo
trabajo saque o clasificación. Elpropietario del
productovoluntadnecesidadaresponder preguntas y proporcionar
comentariossobrelas historias que sontrabajandoenahora.
La propiedad del producto en un programa es un trabajo de tiempo
completo. Consulte El rol De propietario del producto es clave para el
éxito del programa.
4.8 Crear la hoja de ruta de panorama general
Puede poner características, conjuntos de características, temas o

épicas en su
Plan. También te gustaría añadir hitos externos a la hoja de ruta
general, para que la gente entienda lo que necesitas y cuándo.
Dependerá de cuánto ya entienda sobre el problema que necesita
resolver y laduracióndesu programa.
Un conjunto de características es una colección de características
relacionadas en un área del producto. Un conjunto de características
puede ser:
• Variashistoriassobre el inicio de
sesióndesylaseguridad,todaslashistorias especificadas para que
pueda ver su valor.
• Incluirían lo que puede salir mal con el inicio de sesión,como los
usuarios malintencionados.
• Incluirían cómo crear un nuevo usuario, cómo enviar una
contraseña a alguien que haya olvidado una contraseña, etc.
• Se clasificarían, por lo que el PO puede decidircuáles de esas
características hacer ahora y cuáles hacer más adelante.
Un tema o una épica es una declaración de alto nivel de lo que

deseapara una característica.Seesuna promesaacrear historias. Un
tema podría ser:
• Hacernaturaleza sig electrónica.
• Realice la seguridad para iniciar sesión.
• Restablecimiento de contraseña.
Las historias tienen un valor como parte de su definición. Un tema habla

sólo sobre las características y no mucho sobre los
beneficios.Hacerquever la diferenciaenespecificidad?
El propietario del producto puede comenzar con temas y
evolucionarlosa conjuntos de características. Tómese el tiempo para un
taller de requisitos o un usuario storymappingtofullyspecifythe
featuresets. ThenthePOcanrank
los conjuntos de características para decidir qué historias en el conjunto
de características el equipo implementará ahora y qué historias
implementaráel team
Más tarde.
Este es un ejemplo de cómo podría ser su hoja de ruta de una cuarta

parte.
Comience su programa a la derecha
5
0
Ejemplo de una hoja de ruta ágil para un trimestre
Para la primera versión interna, el equipo de inicio de sesión haría

secure login, parte 1.EladminequiposeríahacerAdmin, Parte 1 y
Diagnóstico, Parte1. El equipo de la plataforma haría la transferencia
de archivos, Parte 1.
Debido a que los equipos completan sus historias, el propietario del
producto puede
decidir quéfeatureset,orpartofafeaturesetyouwantcuando. Los
propietarios de los productospueden guiar a los equipos a crear un
esqueleto
en orden de valor.
4.9 Principios de inicio de su programa

Correcto
1. Pasa suficiente tiempo fletamento, para que sepas a dónde

tiene que ir el pro gramo. Don'tgastar
tantotiempoquequedon'tcomenzar a entregaring. El principio
es: "Entregar temprano y a menudo para satisfacer al cliente."
2. Askthetechnicalteamsforfeedbackonthevisionandrelease
Criterios. Hacerentienden esas piezasdela carta? ¿Son lo
suficientemente claras para que los equipos técnicos hagan
compensaciones? Los principios son: "Empoderar al equipo"y
"Ver el todo."
3. Comience con un altonivel,imagen generalde su hoja de ruta.
Sigue evolucionando esa imagen, para que la gente pueda ver a
dónde quieres que vaya el producto. El principio es: "Las
personas y los desarrolladores de Businesdeben trabajar juntos."
5. Utilice la planificación continua
Ustedha visto cómo crear su primera hoja de ruta y tal vez incluso el
primer par de atrasos de productos para cualquier equipo dado. Ahora,
considere cómo actualizará la hoja de ruta y los trabajos pendientes.
As que replante, considere lo pequeñas que puede hacer las
características y los productos mínimos viables. Su programa
aumentarásu
rendimiento como el tamaño del lote sigue siendo pequeño.
5.1 Diferenciar entre interno y

Versiones externas
Si tiene entrega continua, puede entregar algo inter

nally, a su organización, todos los días o varias veces al día. Si no tiene
sin entrega continua, es posible que no pueda liberar todos los días.
Libere algo internamente a su organización al menos una vez al mes.

Releasing que a menudo proporciona a todo el programa con
retroalimentación.Setambién proporciona una cadencia
queotrosvoluntadencontrarde
pendable. Cuandoqueliberación interna,quegenerar confianza en toda
la organización.Setiene sentido para liberar comoa
menudocomoposible.
Las versiones internas ayudan a los equipos de características a
obtener comentarios sobre
el producto. Elcomunicados internosvoluntadtambién mostrar a su
dirección y patrocinadoreselvalordesu trabajo. Las versiones internas
muestran a las personas dentro de la organización lo que ha
completado.
Las versiones externas muestran a sus clientes lo que hahecho.Exterlas
liberaciones nal son una decisión empresarial.Tal vezsu cliente puede
tomar elactualizadoproducto ahora, tal vezno.Sin embargo, los equipos
todavía necesitan retroalimentaciónsutrabajar más a
menudothanonceatrimestreo cuando
52
UsarPlanificación Continua 53
su cliente puede tomar una versión. Esta es la razón por la que necesita
versiones internas al menos tan a menudo como una vez al mes.
Puede liberar internamente más de una vez al mes. Haga que el tiempo
mínimo entre las versiones internas sea una vez al mes.
5.2 ¿Qué quieres liberar

¿Mes?
Los equipos necesitan características pequeñas para que puedan

integrarse y liberarse con frecuencia.Inclusoaunquequequieroaliberar
algocadames,quevoluntadserpequeño. ¿Qué quiereslanzar este mes?
Supongamosque tiene iteraciones de dos semanas. Dos dos-semana
iteras encajan en un mes.Si trabajas en tres semanasiteraciones,que
podríareleaseattheendofeachiteration. Si youworkinflow,tal vez
quierasliberar cada vez que completes una función, en lugar de dos
semanas. Tal vez usted quiere relfacilidad cuando usted tiene un
producto mínimo viable (MVP).
Supongo que liberas internamente al menos tan a menudocomo una

vez al mes.Mása menudoesgenial. Cuanto más a menudo se libera
internamente, el
más todos—los participantes del programa, tus patrocinadores,
cualquier persona interesada en tuprograma—pueden ver tu progreso.
Todo el mundo ve
Comentarios.
Cuanto menos a menudo se libera, más tienen que estimar los equipos
deentidades. Con más versiones internas, los propietarios de productos
pueden cambiar los trabajos pendientes.Se'saganar-ganar.
Cree versiones internas para que todos puedan ver

el progreso del programa. Cuanto más grande sea
el programa, más necesita
versiones internas frecuentes.
Si utiliza la entrega continua, es posible que no necesite la cuarta

parte
hoja de ruta ágil asonEjemplo deunahojada paraOneQuarter.
Usar Plannincontinuo g 54
El programa lanzaría características más rápido de lo que el

propietario de un producto podría mantener la hoja de ruta.
Considere la falta de entrega frecuente-suficiente un impedimento. Vea
si los equipos de entidades pueden resolver este problema, o si es un
programa
Problema.
5.3 Crearmínimos releasables
A partir de la gran hoja de ruta, puede generar algo que le permita

para ver lo quesus productosmínimoviables,yourMVPs,son foreach
liberación interna.
Tal vez los propietarios de productos para un conjunto de características

determinado dicen algo como esto, "No tenemos algomínimo a menos
queal menos 80% de las características
existen."Ellossoncorrectocuandoconsideran una liberación externa. Sin
embargo, el programa necesita versiones internas mínimas.
Tal vez en lugar de un producto mínimo viable, los propietarios de
productos pueden considerar un conjunto de características mínimas
indispensables, MIFS (BRO14).
Los MVP o MIFS variarán en tamaño. Cada conjunto de características
puede necesitar algo diferente para un MVP.
"NuestroProductoGrewDifferentlyAtiempo"
Teníamos unsistema de correo electrónico como parte de

nuestro producto. Tuvimos un MVP de obtener-y-send
correos electrónicos en nuestro primer MVP.Pero,que
no hizo el reenvío o los archivos adjuntos hasta nuestra
segunda versión interna. No hicimos correos electrónicos de
grupohasta nuestra tercera versión interna. Tomamos otras
características de otros conjuntos de características, a pesar
de que éramos el equipo de "correoelectrónico".
Me sorprendió que el equipo no lopasara tan mal con eso.
Tuve más tiempo porque era el dueño del producto.
Usar planificación continua 55
¡Ya quería terminar el sistema de correo electrónico! Pero, el

equipo vio hacia dónde iba la hoja de ruta del producto, y
tenía sentido para ellos. Estaban bien con hacer diferentes
características, y
se divirtió con él.
Se llamaban a sí mismos el "Correo electrónico y...Equipo,"

porquehizocorreo electrónicoylotesdeotras características.
Dijeron que saber
sus MVP hicieron una diferencia para ellos.
—Un propietariodelproductodel equipo
No intente planificar los detalles de los conjuntos de

características/temas durante más de un trimestre a la vez.Inclusoun
cuartoesatoneladasdeplanificación. Tenga en cuenta que debe tener
en cuenta los MVP para su lanzamiento.
Si restringe su planificación a los MVP paraser lasliberaciones internas
de un trimestre: lo que tiene que estar en sus MVP para cada
lanzamiento interno cada trimestre y luego trabajar hacia eso, usted
hará suficiente planificación para la mayoría de los proyectos.
Si lanzas algo cada mes, nuncatienes que hacer una gran
versión.Siactualizar elágilhoja de rutacadaiteración,
o después de cada pocas características cuando los equipos trabajan en
flujo, ustedpuededirigir el desarrollo del productossssssin planificación
bigrelease.Se'stodo sobre MVPs,mínimoviableproducto.Siempre y
cuando seleccionesuMVPparaelcaracterísticaconjunto,oparatodo el
producto, ycrearpequeñas historias,
los equipos trabajarán para lograrlo.
Entrega Continua y Planificación Trimestral
Si utiliza la entrega continua, ¿todavía necesita una

planificación trimestral? Podrías.
Si necesita comprometerse a través dela organización o con los
clientes,
utilizar una hoja de ruta. La hoja de ruta mostrará a las

personas los pequeños
forproductdirectionnow, y los más grandeselementos más
tarde. Todo el mundo puede ver la dirección del producto.
El hecho de que usted entrega continuay hace quesea
mucho más fácil de entregar según sea necesario y para
comprometerse conlos predichos
Entregas.
La hoja de ruta es una lista de deseos. Los entregables son la realidad.
5.4 Plan de lanzamientos externos
Si los propietarios de productos siempre definen MVP, y los equipos

siempre dehígado MVP, y los MVP mueven el producto hacia los criterios
de lanzamiento, nadie tiene que preocuparse por lo que entra en las
versiones externas.
Si tiene entrega continua, no tiene que preocuparse por las versiones

externas. Te liberas todo el tiempo.
Usted tiene que worry acerca de las versiones externas cuando:
• El programano se libera todo el tiempo.

• Los equipos de característicasno realizan la integración
continua y vuelven a arrendar lo que tienen en la línea
principal.
• Los equipos trabajan en la arquitectura en lugar de las
características (cuando los equipos de entidadesno crean
características).
Si te atrapan en estas trampas, el programa tiene

problemas.Cualquiera de los dos
los propietarios pueden problemas
completoslos equipos tienen. Theproductproblemsatthe
teamlevel,orthestartaddressing theseprogramhas
creando MVP y asegurándose de que los equipos devivanalvalor, no a
las historias arquitectónicas.
5.5 Beentregable y Rolling Wave

Ayudas a la planificación
Las versiones internas son una planificación basada en entregas. Los

propios ers del producto especifican los fragmentos de entrega que
desean ver.Comolos equiposacabadotque pedazos,quepuedetomar
más.
La programación de ondas continuas es la siguiente:
• Programe su próxima entrega. Asegúrese de que la entrega no

esté más de dos o cuatro semanas de distancia.
• Al final de su primera semana, programe la próxima entrega.
• Repito, después de cada semana.
Ahora siempre tienes un horario de dos a cuatro semanas con

entregas.
Los equipos pueden usar iteraciones o flujo. Noimporta. Cada equipo

tiene esta responsabilidad: proporcionar un flujo constante de valor sin
incurrir en deuda técnica. Ver Integración Continuay Testing
SupportsCollaborationpara obtener más información
sobrewaystoremove deuda técnica.
Usted o el propietario del producto del programa podríandecidir que el

programa puede tomar alguna deuda técnica para cumplir con una
entrega específica.(No lo recomiendo.)Comopartedesu dplanificación
basada en eliverables,añadirla resolucióndequedeudaaelhoja de ruta
del productooun futuro atraso.
El uso de presupuesto de onda rodante y presupuesto incremental

esmuy útil si usted tiene personas que quieren saber cuánto el proyecto
costará. Usted can actualizar el gasto y los números del
planconcadaliberación.
5.6 Pequeño es hermoso para los programas
Algunas personas piensan que a medida que creas un programa ágil y

ágil, es
tratando de tener iteraciones cortas. Ellosdecirme que porque
máspersonas y equipos sonenelprograma, ustednecesidadahacer las
iteracionesmás tiempo.
El problema es este:cuanto más quieres los beneficios de ágil o magro,
cuanto más necesite retroalimentación. Cuanto mayor sea el programa,
más frecuentemente necesitará retroalimentación.¿Por
qué?Túhacernoquieroaunidadla empresa bajo mientras
quequeesesperandoparaqueacompletael programa. Cuanto más
tiempo se tarde en obtener comentarios sobre cualquier característica
o conjunto de
características, más difícil es para la empresa saber si el programa está
teniendo éxito.
Cuanto mayor sea el programa, más gastará la organización en su
trabajo.Túnecesidadaentregar—encadanivel—a menudo. El valor de
progresar cada día es que todos reciban comentarios. La gente aprende
temprano si alguien vapor el camino equivocado. No tienes
la oportunidadde quebrar a su organización porque usted no está
entregando.
Si revisa los Doce Principios del Desarrollode Software Agile y Revisa los
Siete Principios Lean,puede ver que el
principios son acerca dela entregadesoftware de trabajo, asfastas
possible.
Las iteraciones más cortas le permiten hacer eso.
¿Qué pasa si la gente de sus equipospiensa que las aliteraciones cortas
encom
passoverheadforplanningandestimacióny,inclusoretrospectivas?
Hay varias razones para ello.
• Cuando escuchas la palabra "overhead", eres heaanilloalgunos

uno que aúnno ha pasado completamente a ágil.Gastos
generalesescódigopara"quetienen impedimentos, yquedon'tsin
embargo,darse cuenta
lo que son, así que los llamamos por encima." Estos
impedimentos
para dividirlo en o
podría serlargespikelargestories,ythestorycan
lackofunderstandingthattheysmallerchunks;
podría ser un malentendido de lo que podría ser un producto

mínimo viable.
• Es posible que esas personas no se den cuenta de la poca
planificación que tienen que hacer, para completar pequeños
entregables y lograr una liberación interna cada mes.
• Si su organización aún no ha comenzado a administrar la cartera
de proyectos,las personas están realizando varias tareas entre
varios proyectos o características. En esas condiciones, tendrá
problemas para construir y mantener un programa de pequeñas
feas.
• Usted tiene un producto complejo, por lo que los equipos
extienden su
esto en el
iteraciones. weekstoachieveShepherd
I'lltalkmoretwoaboutMVP someArchitecture.formofan
¿Qué sucede si crees que las iteraciones deben ser más

largas?Siquepensarplanificaciónessobrecarga,Yoapuestaquedon't
tienen pequeñoshistorias,oquequesontratando deaestimación de
usoagestionarelhoja de ruta del productooelproyectocartera.
Empieza a pensar en el valor. Comience a pensar en la característica
más pequeña que mostrará a todos el progreso de una característica o
conjunto de características.
5.7 ¿Con qué frecuencia puede replanificar?
La planificación continua funciona de la misma manera que la

integración continua. Cuando los equipos de entidades se integran todo
el tiempo, el código
integración es más fácil.Cuandoquereplanificar todoeltiempo,la
planificación lleva menos tiempoy es más fácil.
Cuando usas la planificación continua, notienes quetener grandes

planes. Puede planificar la siguiente iteración (o dos).Puede
planificarparaelsiguiente entregable (o dos).
Túnuncatienenatienentodos en el mismohabitaciónparaplanificación de
liberaciones.
A medida que los propietarios de productos ven y aceptan las
características que los equipos completan en sus trabajos pendientes,
pueden actualizar la hoja de ruta como
equipo de valor del producto. La planificación continua evita la

necesidad de
grande"dejar'sgeteveryoneen la misma
habitación"toplanaquarter'sworth
de trabajo.
Muy pocos equipos pueden planificar un cuarto a la vez y cumplir con

ese plan. Su programa podría tener interrupciones de las
operaciones/apoyo,
el rango de algunas características puede cambiar, y los equipos
encuentran problemas todos los días.Siqueplanparaun cuarto, usted
esnoprobable
para lograr todo lo que planeas.
Con la planificación continua, actualice los trabajos pendientes a tiempo
y mantenga su programa abierto a cambios. Cuanto más pequeña sea
su planificación, más probable es que los equipos sean capaces de
lograr la visión andrelease
Criterios.
Sigue planeando pequeño.

Conpequeñohistorias,pequeñoplanning, y
pequeñoequipos,suprogramaesmásprobable
quetienenrendimiento más rápido y más
rápidoretroalimentación.Pequeño
y la planificación frecuente ayuda a su programa a
ser más resistente.
Cuanto más pueda mover laplanificación continua, más ágil y ajustado

su programaserá.Elpunto deelhojas de rutaesaespectáculoel
el equipo general del producto, y cómo esa visión cambia con el
tiempo.Elatrasossonlos detallesparacada equipo.
Cuanto más riesgo tenga en su programa, más
comentariosnecesitará.Cuanto másquieroamantener a los
patrocinadores comprometidos, más
a menudo podría tener que cambiar la hoja de ruta—y por extensión—
losatrasos.
Si desea más comentarios, publique con más frecuencia.Canqueliberar

todos los días? Si no hayt todos los días, ¿qué impedimentostiene para
crear una versión interna al menos una vez al mes? Como programa
gerente, elimine esos impedimentos. A
continuación,youcanaskthepropietario del producto del programa para
actualizar la hoja de ruta al menos tan a menudo como una vez un
Mes.
Usar Plcontinuo 61
"Noes el Plan;Se'sAcerca de Plan ning"
Iusedtouseamorewaterfallapproachtomyprograms.Traté de
planificar una vez y que sea "el plan de registro"para todoel
Programa.
No funcionótan bien. Siempre estaba replanificando. Entonces
yo
descubrió la planificación deondas, y me enteré del valor de
la planificación, donde discutimos lo que podíamos hacer
cuando, y dónde estaban los riesgos, frente a la plan real,
que siempre estaba desfasado al díasiguiente.
Ahora, utilizo nuestra planificación como una manera de
entender los problemas ylos riesgos.Yousarla
planificaciónaayudar a tomar decisionesmás deellas
próximas semanas. Nunca espero que el plan dure un par de
semanas.Pero yo'm inmejorformaporquedeeldiscusiones de
riesgo
Tuvimos.
—Un director de programa sénior
Una buena planificación, en el sentido dequeproporciona una hoja de

ruta para los equipos y refleja la realidad actual dependeenmás
retroalimentación,nomenos.Cuandoplanmenosa menudo,quedon't
versurealidad actual.
Los planes se convierten en objetivos, en lugar de planes que los equipos
pueden usar para guiar su trabajo.
5.8 Separar la hoja de ruta del producto de

la cartera de proyectos
Cuanto más grande sea su programa, más podría tener proyectos en el

forma de conjuntos de características a secuencia. Me gusta pensar en
este ranking como una forma de gestión de carterade características. La
secuenciación se produce wgallina decir algo como esto, "Tenemos que
trabajar en suficiente
características para el motor antes de llegar al módulo de diagnóstico

o al módulo de finanzas."
Esa podría ser exactamente la manera correcta de abordar lo que es

más valioso para elprogramay sus patrocinadores. Se trata de una
forma de gestión de carteras de proyectos. Sin embargo, está
decidiendo lo que es correcto
para este producto, no para la organización en general. Debido a que es
para este producto, noes la gestión de cartera de proyectos.(Consulte
Administrar su cartera de proyectos: Aumente su capacidad y termine
más proyectos, ROT09 para obtener más información sobre un enfoque
de toda la organización para proyectos y programas de secuenciación.)
El equipo de valor del propietario del producto clasifica las
características y posiblemente los proyectos (como colecciones de
conjuntos decomida) para su programa.Hacerque,ydejarelcartera
global de proyectosgestiónalas personas que
decidenenelestrategiaparasuorganización.
5.9 Maneras de clasificar los elementos en la hoja de ruta

o Backlogs
¿Alguna vezpreguntacómoelproductoownerotheprogramaproducto
propietario de conducto según decide qué hacer primero, segundo o
tercero? Como administrador de programas, es posible que pueda
ayudar al equipo propietario del producto a decidir
qué hacer cuando.
5.9.1 Hacer el trabajo más corto primero
A muchos propietarios de productos les gusta usar la estimación de

programación como una forma de definir un valor para las entidades o
conjuntos de características.Siquedecidirhacerlas características más
cortas primero(que podría ser una gran manera de
mostrarprogreso),queSe llama el"más corto
ponderadotrabajoprimero."
Consulte The Principles of Product Development Flow: Second
Generation Lean Product Development, REI09.
El trabajo más corto funciona bien primero cuando tienes relaciones de

posición de esti confiables y sin costo de retraso.Aquísontres desafíos
que tengovistoautilizandomás cortotrabajoprimero:
equiposproporcionarinexactoo
estimaciones largas; los equipos tienen interdependencias;oelequipos
son
missingnecessarypeopleforthemtofinishfeatures. En cada uno de estos
casos, su programa incurrirá en un Costo de Retraso tratando de hacer
el
trabajo más corto primero. Los equipos no puedensaber qué work es el
máscorto. Utilice estas otras ideas para evaluar elementos de su hoja de
ruta o características en
el atraso.
5.9.2 "¿Sigue siendo valioso?"
Lo que parece una buena idea al principio del programa podría no ser
útil en absolutopartalo a través del programa. Recommend que para
todas las características no iniciadas,e incluso las características
incompletas,el propietario delproducto pregunta: "¿Es esto todavía
valioso?"
Esta pregunta es similar a la pregunta cero en la gestión de carteras de
proyectos: "¿Deberíamos hacer este proyecto en
absoluto?"VerGestiona tu ProjectCartera:Aumente su
capacidadyTerminar más proyectos,ROT09.Cuandoquehacer esta
preguntasobreelproyectocartera,queoptimizarvalorparaeltodoorganiz
ación.Cuandoquehacer la pregunta de valorsobreel
programacaracterística-sets,queoptimizarelvalorpara
este programa. Tú decides qué trabajo no hacer, lo que evita los
desperdicios.
5.9.3 Utilizar puntos de valor comercial

Cuando trabajo con clientes, a menudo descubroquesaben
características valen más para ellos y qué características valen menos.
El problema es que nosaben cuánto más o cuánto menos.
Los puntos de valor empresarial pueden ayudar.
Con estos puntos, se asigna un número único a cada entidad que

considerar la clasificación de un número total de puntos. Imagina que
tienes
10.000 puntos y siete características. Esto podría ser su clasificación:
Clasificación con puntos de valor empresarial
El valor relativo de cada entidad es lo que importa. Si un equipo

normalmente implementa todas lascaracterísticas 1, 2 y 3, puede
considerarssalgunosequiposparatrabajarcon esas
cosasnormalmentelascaracterísticas,inclusosielque'sarenoelimplement
o.
porque esas características son mucho más importantes que todas las
otras características en este momento.
Cada vez que evalúe el trabajo pendiente del producto, vuelva a asignar
el valor empresarial points. Una iteración, puede decidir que solo
necesita 10.000 puntos. Algunas iteraciones más tarde, es posible que
tenga cinco equipos másy necesite usar 50.000 puntos para decidir qué
partes de las cuales cuenta
son más importantes ahora. Siempre y cuando utilices un número único
de points, noimporta cuántos puntos uses.Seasuntos que cada
característica tiene un número únicodepuntos.
5.9.4 Evaluar el costo del retraso
El costo del retraso es el costo en el que incurre la organización cuando

tieneretrasos en el lanzamiento del producto. La organización espera
obtener un beneficio de la versión.Si ustedretrasoel producto
porames,elcostodeque el retrasoesun
mesdemáximoperdidoingresos.ElCostodeEl retardo esrealy ralentizará
suprograma'simpulso.
En un programa, los equipos pueden encontrar muchas causas posibles

para un costo de retraso:
• Esperando a que otro equipo implemente una característica

necesaria.
• Insuficientes personas en unequipo específico, por ejemplo, no
hay suficientes DBA o probadores, o alguna otra persona
escasa.
• Expertos, que conducen a colas de trabajo para esa persona.
• Deuda técnica.
Como parte de un equipo de programas, es posible que veas retrasos

cuando las personas no terminan sus acciones a tiempo:
• Marketing Communications tuvo un retraso en el acabado de las

hojas de una, yno tiene sentido liberar el product con ellos fuera.
• Un proveedor noentrega un subsistema a tiempo.
• El hardware no está listo para la instalación.
Hay muchas otras causas posibles de costo de retraso. Consulte Buceo

para tesoros ocultos: encontrar el valor en su cartera de proyectos RE14.
El costo de Delay es real.Decidircuandoquenecesidadatomarelretrasos
en cuenta comoquecaracterísticas de rangootrabajoparaelprograma.
5.9.5 ¿Quién tiene residuos?
Si está gestionando un programa que automatiza alguna pieza de

trabajo, las personas que hacen el trabajose desperdician hastaque
trozos necesarios. Una vez trabajé con un programa que implementaba
la solicitud de back officepara un banco. Porque el "back-end"noera
hecho, la gente de la oficina de fondohadtomanuallytakela entrada dela
"abrir una cuentade cheques" feature e introducir los datos en el back-
end procesamiento.No hayfueno tiene sentido implementar más"frente
oficina" características hasta que el back-end se completó.
Youmayhaveaprograminwhichpeoplehavetraditionaltraditionalthough
t en términos de la "front-end"y el "back-end. "Yosi lo haces, bien puedes
verresiduosentodostipos delugaresen suproducto.Ayudar a las personas
características como de extremo a extremo, no de extremos frontales o
traseros. Pensar de esta manera podría ser un cambio importante para
ellos.Personasnecesidadtiempoa
pensar de una manera nueva.
A veces, el desperdicio es parte de la deuda técnica. Silos equipos don't
tener suficientes pruebas automatizadas, que"residuos"
tiempohaciendopruebas manuales.
No estoy diciendo que las pruebas exploratorias sean un desperdicio.
Estoy diciendo que las pruebas que se ejecutan más de una vez para
asegurarse de que nada
broke debe ser automatizado. Esa falta de automatización es un
desperdicio.
Teamsnewtoagilemaywellhavetest-automation-and-buildwaste.
Elantes descubresesto,elmejor,si usted esaproductopropietariooun
administrador de programas. Clasificar ese trabajo es tan importante
como
funcionesdel rey corrió.
5.9.6 ¿Qué aprenderemos?

A veces, el programaneedstolearnaboutafeature setorseveral
características conjuntos.A veces, un equiponecesidadesevaluar
variosopcionesparaun usuariointerfaz.A veces, los arquitectos
necesitanaexperimento
con arquitectura o diseño para evaluar opciones.Enestos
casos,quecomerciar con el aprendizaje temprano contra terminar otras
características.
No confunda este aprendizaje con "Iteration Zero."

IteraciónCeroescuandoqueobtenerlisto(y prepárate y
prepárate)ainiciartrabajo.En su
lugar,cuandoquehorarioaprenderparaun equipo, timebox el
aprendizajeyserlistoaespectáculoelresto del programa elresultados.Es
posible que el equipo nosercapaz deaintegrar
algunoscódigo.Peroquedebe
ser capaz de responderpreguntas.
5.9.7 ¿Qué riesgos gestiona esta función?
Su programa puede tener riesgos basados en el cliente, riesgos

arquitectónicos, riesgos de desarrollo y más.Siusted está seguro de que
sus clientesvoluntad
ser perturbado a menos que agregue esta característica y pronto,
clasificar esa característica más alto que otros.
A menudo meda que estos riesgos se afectan entre sí. El cliente quiere
algo de inmediato. Hacer esa característica pone al resto del programa
en riesgo de retraso. Parece que no hay una respuesta correcta.Siquever
estoensu programa,tratar deCostodeRetrasoparasu característica
ranking. Usted puede tener clientes que quierendifferentfeaturesnow, o
que necesita paraintercambiar alguna exploración arquitectónica antes
de que pueda decidir . El costo del retraso puede ayudar a su decisión.
5.10 Decida cómo evaluará el valor
Utilice una combinación de estos dispositivos de evaluaciónmientras

trabaja en el programa. Podría decidir implementar algunos pequeños
características en primer lugar, para ver algunas victorias rápidas
(trabajo más corto ponderado primero). Usted podría decidir aprender
con picos o pequeños prototipos para informar
la arquitectura o el diseño de algunas características (aprendizaje). A
veces, miras Costo de retraso para ver si los equipos están esperando
esta característica o esa historia. No hay una respuesta correcta para
evaluar los artículos
en su hoja de ruta o trabajos pendientes.
No utilice solo la estimación de una característica o conjunto de feature
determinado. Cuando haces eso, los equipos se sienten bajo una
enorme presión para
que característica o conjunto de características dentro de su

estimación.Sielartículoesgrandes, su estimaciónesprobableasermal.El
programavoluntadincurrir en residuos, delsí, y posiblemente
técnicodeuda.
En su lugar, considere cómo puede compartir la decisión de "qué valor
es paranosotros ahora"conlos equipos.Ellosayudará atú.
5.11 Actualizar las hojas de ruta con frecuencia
El propietario del producto del programatendrá que actualizar el

panorama general
hoja de ruta al menos una vez al trimestre. lanzamiento de los
equipos de características
internamente al menos una vez al mes, el propietario del producto del
programa puede
actualizar la hoja de ruta y cambiar los trabajos pendientes una vez al
mes. Sisuprogramánutilizar la entrega continua,usted
puedeactualizaciónelhojas de ruta
al menos que often.
Esto significa que los propietarios de productos del equipotendrán que

actualizar los MVP para los trabajos pendientes del equipo de
características al menos una vez al mes.
Utilice la planificación de ondas rodantes y los entregables
provisionales, y nunca tendrá que hacer una gran planificación.
Haga que sus historias sean pequeñas—el producto owners necesitan
aprender a hacer esto con sus equipos de características—y nadie tiene
que pasar mucho tiempo planeando. En su lugar, todo el mundo pasa
tiempo discutiendo lo que quieren para los MVP y cómo se ve el
producto ahora y debe
se ven como en el futuro.
5.12 Principles de Planificación Continua
1. Genere la pequeña imagen con su MVP, productos mínimos

viables. Elprincipioes:"Los negociospersonas y desarrolladores
debentrabajojuntos."
2. Comience siempre desde las hojas de ruta y pase a los trabajos
pendientes. El principio es: "Amplificar learning."
3. Planifica un plan pequeño para que puedas evolucionar el plan a

medida que cambie tu realidad. El principio es: "Requisitos
cambiantes bienvenidos."
4. Actualice el plan a medida que los equipos completen eltrabajo
y la realidad cambie.Elprincipio
es:"Entregartrabajandosoftwarefrequently."
5. Utilice lo que los equipos completan para informar al siguiente
lote de
hoja de ruta y atrasos. El principio es: "Decidir tan tarde como
sea posible."
6. Crear un entorno de
Entrega
Cree un entorno de programa donde la cultura diga, "Entregar" cada

day, un poco ala vez.Sielprogramalos equipos entregan diariamente, los
equipos de características son más propensos ahacerasí que.
Pienseen esto como su propiacultura DevOps. DevOps esamanera
decrearequipos que conocencómoaconstruir e
implementar.Elideaesque el equipo siempre puede build. La
implementación se automatiza y prueba.Túpuedehacer un
clicimplementaciones.
y a TodoRecuerde, dentro
detiveztengasadiferencianuestro edificio """desplegando los
"deploysowecustomers."puede ver
equipo necesita ser capaz de desplegar cualquier cosa internamente en

unmomento deny. a es
Las personas de losequipos del programa tienen mucho trabajo en sus
trabajos de "día".A veces ven el programaequipotrabajocomooneroso,
trabajo adicional. Sedoesn't importa que el
productosuprogramaesproduciendopodríaserelproductoaguardar la
company. Esoes
Irrelevante. Tienen trabajo en su función que su jefe considera muy
importante.A menudo,elequipo del
programatrabajovoluntadsentircomo
multitarea para ellos.
¿Cómo puede ayudarlos a trabajar en su equipo de programa?
6.1 Visualizar el trabajo en equipodel programa
Usted can ayudarles visualizando el trabajo del equipo del programa.Me

gusta el kanbantablerosparaesto,porque todo el mundo puedeverel
flujodetrabajo
a través de la organización.
70
Crear un entorno de entrega 71
Posible Kanban para un equipo principal
La figura Kanban posible para un equipo principal muestra lo que puede

usar para un kanban para un equipo principal. Todavía tienes el trabajo
pendiente de clasificación
trabajo en el "En
uniquecolumn.workflowSincethisisacore.Atminimum,team,everyprogra
mwillhavetrackthe theirownProgress"
y "Waiting"afirma. Cuando se realiza un elemento, la tarea pasa a la

columna Listo.
Este es un posible tablero kanban.Es posible que desee

cambiarque.Siquetienen investigaciónoestados de
análisis,queseríaañadir queasutablero.Siusted tiene"EnCompras" como
estado,queseríaaddeso. Su tablero kanban refleja su flujo.
En la parte inferior están los carriles de natación, donde todo el mundo
puede ver qué elementos están en curso por la persona que trabaja el
artículo.Si alguien necesita ayuda,eltodoequipopuedeverlo.
Si ves el trabajo en curso,es másfácil ayudar a las personas a entender
qué, cuándo y por qué necesitan entregar.
No entierre la obra en hitos sin sentido, como "Beta"o

algún otro hito. Claro, Beta significa algo para todos en el program.
Pero ¿cuáles son las tareas que todo el mundo necesita para cumplir
llegar a ese hito? La planificación basada en la entrega de productos
Hito. Mantenga las tareas pequeñas, algo que las personas pueden
lograr dentro de uno o dos días, para que puedan entregar su trabajo y
no sentir unasielprogramase ha apoderado desuvidas.
Me gustan las placas físicas siempre que sea posible, en lugar de las
placas electrónicas.Incluso si su equipo
principalysoftwareprogramaequipossonexperimentadoenágilymagra,q
uepodríaser nuevoenseranúcleoequipooun
softwareprogramaequipoparaeste producto.Midirectrizpara
nuevos equipos ágiles y magros es comenzar con aphysicalboard hasta
que su trabajo juntos se vuelve natural.
Por ejemplo, es posible que deseen agregar avatares altablero, como
en Kanban en acción, (HAM14).Que personalizes eljunta,y ayuda ala
gentesaberqueestá trabajando enqué.
6.2 Mantenga el trabajo del equipo del programa pequeño
Hemos detectado un problema desconocido. Eso los hace sentir bien

consigo mismos, y los prepara para hacer más work.Secambia su
mentalidad.
Porotro lado, si se slog a través de una gran tarea, y se sienten como
sies interminable,no se sienten bien. Están en peligro de nunca
completar el trabajo, incluso si están a minutos de
finalización (AMA11). El problem con tareas grandes es que es posible
que no pueda decirle que está a minutos de la finalización.
Cuando las personas ponen pequeñas tareas en sus tableros kanban, es

más probable que las tomen y las terminen. Siponen grandes tareas,
tales como,"RedoLicencias," quesonmenosprobableatomarellos.Sisu
programa
componente sea:
los miembros del equipo creantareas.
largeThosetasks,askthemtobreakmight aquellos abajo en
• Llame a la reunión con ventas, soporte y legal el viernes.

• Preparar el handout para la reunión con los cambios propuestos
resaltados.HacerporJuevesaenviarhacia fueraenavance.
• Ejecutar la decisión de CFO después de que todos estemos de
acuerdo.
Ahora, todo el mundo puede ver que "RedoLicensing" no es

trivial.Ellosotras sugerencias, tales
como,"DeberíaquehaveFinanzasenelinicialreunión?"
Si mantienes visible a tu equipo de programa, todo el mundo puede ver
lo que estás haciendo.Quiénsabe?Otrosla gentepodría tener
sugerencias,también.Cuando los miembros del equipo del
programaentregartodos los
tiempo, los equipos de características son más amablesde hacerlo,
también.
6.3 Cómo fluyen las características a través de los equipos
He hablado mucho de los equipos del programa hasta ahora.Túpodría

estar preguntándose cómoelcaracterísticas fluyen a través
deelequipos.Sicada unoequipoeságil, y un equipo de características
totalmente funcional,que'sfácil.
Los equipos de característicastienen todos los roles que necesitan.Cada
unoequipoescapaz deaentregar una historia /
característicacadadíaodos días, después de estos
Principios:
• Visualice el flujo de trabajo para que el equipo pueda ver la

secuencia de valores, los cuellos de botella y cualquier trabajo en
curso. Los equipos hacen esto, en caso de que se vuelvan
interdependientes de otro equipo.
• Mantenga el tamañodel lote (tamaño de la historia) pequeño,
ya que en no más de dos días.¿Por qué?Esto permite que
todosaintegrarcadacosa todoeltiempo.Setambién
permiteeltodoprogramapara hacer entrega
continua,inclusosiqueentregaessólo interna.Setambién
permitepararetroalimentación rápidaycambio. Las pequeñas
historias hacen que las interdependencias sean más obvias. Te
permite separar el
decisión comercial para la liberación del producto de la decisión
real de la liberación.
• Utilice buenas prácticas de ingeniería, como opment de

desarrollo basado en pruebas, desarrollo basado en pruebas de
aceptación, pruebas unitarias, emparejamiento, lo que necesite
para que usted tiene una red de seguridad para su desarrollo.
Las prácticas técnicas que asociamoscon ágilesproporcionan
unared de seguridad para el desarrollo y permiten a todos
proceder a un ritmo sostenible.Siquedon't utilizar
elingenieríaprácticas,quevoluntadconstruir deuda
técnicaymaravillapor quéusted está sin aliento,
poniendoenhoras extras,nuncacapaz dehacerlo
quequequierohacer.
Cuando los equipos cuentan entregan todo el tiempo, crean impulso.

Esfácil para todo elprograma ver cómo proceder.
6.4 ¿Con qué frecuencia puede liberar su

¿Producto?
no es a menudo liberadoapara
Puedes empezar evaluandotuversióntusuproducto podría tu
langostaomersproduct.nowThis.
Este es su potencial para las versiones. Es posible que sus clientes no

quieran tomar un nuevo producto tan a menudo como usted podría
lanzar. Sin embargo, si pudiera liberar eso a menudo, eso podría
cambiar la forma en que piensa
su programa.
Posible frecuencia de liberación

¿Qué tan caro es lanzar su producto?Elgastosdeliberación
cambiarásunegociodecisiónsobrecuandoaliberar su
Producto.
Separe la decisión empresarial de liberar su product de hacer que su

software sea liberable.
Es decir, cuanto más a la izquierda del continuo estás, más puedes
combinar tus liberaciones con tus iteraciones o tus características, si
prefieres.Sudecisiones de cartera de proyectossonmás
fácilahacer,ypuedeoccsutan a menudocomoquequiero,siempre y
cuandoobtenerhacer, cada
o iteración.
Cuanto más a la derecha del continuo esté, más necesita separar la

decisión empresarial de liberar de características de acabado o
iteraciones.Elmásala derechadeel continuo,
elmásimportantequeesasercapaz deaobtenerahechoenuna base
regular,así quequepuedetomar buenas decisiones de cartera de
proyectos. ¿Por qué?Porquequea menudotienendinero
atadohastaenelemento de plomo largogastos.Usted
tieneahacerdecisionestempranoparacomprometiendoahardwareogast
os de ingeniería no recurrente (NRE).
¿Por qué esto es importante para su programa?
El propietario del producto del programa y el equipo principal, los
responsablesdel valor comercial del programa, tendrán que tomar
muchas decisiones semanalmentea partir delos riesgos del programa.
Cuanto máspuedan mostrar los equipos técnicos en la liberación, más
datos tiene el equipo principal,mejores decisionesnúcleoequipo puede
hacer.Seesasí de simple.
Si tiene un producto de Software como servicio (SaaS) y no puede liberar
tan amenudo como una vez al día, Impedimentos. ¿Sabes cuáles son
esos impedimentos?Canqueeliminarlos?
6.5 Liberar internamente, incluso con
Hardware
Como gestor de programas ágil, cree una cultura de entrega incluso si

tiene hardware en su programa. Es posible que no pueda
lanzar nuevo hardware cada mes debido al gasto.Tienes otra

alternativa.
Cuando los desarrolladores de hardware crean su producto, simulan.

Pueden demostrarlas simulaciones. Esposible que sólo la gente del
software entienda esas demostraciones, pero que's
Bien. Alguien tiene que entender esas demostraciones. Pida a los
hardwarepersonas que demuestren su trabajoproductoaelsoftware
personas.
Entonces, la gentede software llega a "demostrable"enlugar de ser

liberable hasta que la gentede hardware hace prototipos hardware
disponible
capaz del programa.Una veztodo el mundo tiene hardware
prototipo,everyonepuedeobtenerareleable.
Pida a todos que puedan lanzar su parte del producto almenos una vez
al mes, o en el caso del software, incluso más a menudo. Esoes
la versión interna de la hoja de ruta.Cuandola gente de hardwarehacerla
finaldepuraciónenel hardware,quenecesidadelmás
actualizadosoftware.Tenerpara esperar inclusodossemanas esados
semanasretrasopara su programa. Tiene una ruta crítica lineal hasta
que el software
Listo.
Ifeveryteam,programteamorfeatureteam,worksonsmallchunks de
trabajo, pueden hacerlo rápidamente. Comprueba si tus equipos pueden
usar la integración continua.Siasí
que,comoqueintegraryconstruir,quepuede
liberarsutrabajopararetroalimentación. Cuanto antes los evaluadores
proporcionen retroalimentación a los desarrolladores, menos defectos
tendrá en generalenel programa. Cuanto antes todos integren su
trabajo,
más rápido los equipos pueden ver si tienen problemas.
Cuanto más rápida sea la retroalimentación en todo el programa,
menos deuda técnica inadvertida se acumulará en su programa.
Ifeveryonelibera algo cotidiano,youcancreateinter-nal libera cada mes
sin demasiado alboroto.Setoma Autonomía,Cotrabajo,y Exploración
enelparte de cada uno de losequipo.
6.6 ¿Está integrando fragmentos o productos de otros?
Si depende de proveedores para suministrar fragmentos de su

producto, cree hitos que muestren lasinterdependencias. Puede
compartir
interdependencias y actualizar las fechas de los hitos amedida que
avanza el programa.
Considere si desea un tablero kanban o un diagrama de Gantt o ambos

para ver las interdependencias. Un tablero kanban ayuda a todos a ver
todos losiverables y el estado de esos
entregables.Siquesontrabajandocon
proveedoresnuevoaágil,quepuedenecesidadun gráfico de Gantt. Tu
diagrama de Ganttno será preciso. Sin embargo, ayudará a todos aver
las interdependencias y le permitirá compartir fechas.
Si puede elp esos proveedores le proporcionan suproducto de trabajo al
menos tan a menudo como una vez al mes, usted
tienesumensualmenteinterno
Lanzamiento.
Utilice la planificación de ondas rodantes y los hitos basados en

entregas. (Consulte Entrega yRollingPlanificación de
oleadasAyudas.)Asegúrese deestos
proveedoresprovideyouworkingproducto,noespecificaciones. También
podría necesitar especificaciones para asegurarse de que todos
entregan su parte del producto que funciona.Y, debido a que
estoesunprograma ágil,quepuede esperar que algunos
deeldetallesenelespecificaciones paracambio,como su
proveedorsproporcionarqueconproducto provisional.
Don'tletyourvendorsrunopen-loop; theyneedtoprovide producto de
trabajo. Comparte todas las fechas con todos tus
proveedores.Necesitanaver
las interdependencias también.
Si usas un diagrama de Gantt no creas la fecha, no en el beginning. La

fecha de finalización del gráficode Gantt es la primera fecha queno
puedesprobar que no puedesconocer. Es posible que desee 3-
estimación depuntos(un gráfico PERT),o una confianza porcentual.
(Véase el debate de estimación en Suministro de una estimación de tres
fechas.) Pero, la forma del Gantt ayudará a todos a ver lo queestá
pasando.
"Gantts ayudó a todo el mundo a ver de los libreables"
Usé este enfoque el añopasado para ofrecer un nuevo

negocio mucho antes de lo que nadie esperaba. Mi
conductor clave y mi clave selling punto fue este: no
hemostenido un buen historial con este proveedor; esperar
que nos envíen softwarebuggy;Yo'dmás bien encontrar el
primer lotedeerrores6 semanasen,en lugar de 6 meses
en;Sino don't entregarnosotrosbuggysoftware entonces...
brillante...quepuedegracias,puedepatellosenelatrás,tenemo
s tranquilidad;siquehacerbarconosotrosbuggysoftware 6
semanasenentonces nosotros'll necesitaasentarsehacia
abajo y tener unlargo,duro
conversación, que es incluso mejor que brillante. Al
vendedorno le gustó esta sugerencia, pero a popael
proyecto, una vez que habían terminado antes de loque
esperaban y se ahorró mucho de reelaboración (no
facturable), dijeron queles encantaría seguir trabajando de
esa manera.
La opinión de Gantt era importante porque gran parte de la

labor de desarrollo de ese programadebíagirar en torno a la
horario ya que era nuestra plataforma principal.
—Clarke Ching, Director del Programa (comunicación
privada)
6.7 Gestionar los riesgos de integración de otros proveedores
Su proveedor externo (o equipo interno no ágil) podría tener excelentes

planes para entregar su programa sus entregables mensuales.
Podrían"Sí, sí"queytienennoplanesaentregar.Ellospodríaseralgoen el
medio.
Si integra sistemas de otros proveedores, gestione los riesgos

tiempo de integración en su trabajo pendiente y programación. ¿Cuánto

tiempo de integración? Mi directriz es que si un proveedor no
ágil, pedir entregas mensuales y esperar pasar un mes integrando la
primera vez.Quevoluntadproporcionardatos.
¿Quéhaces en ese mes? Los equipos de entidades comienzan a integrar
el productodelproveedor.OnDíaUno,encuentran un problema de show-
stopper. No puedenintegrar nada hasta que el proveedor corrija ese
problema.Deje que'sasumirquetienen un gran proveedor
yproporcionara
fix al día siguiente. Sus equipos continúan integrándose y tres días
después encuentran otro problema.Esto continúaparavariossemanas.
Estas son algunas maneras de administrar los riesgos de integración:
• Cree unequipo de integración para administrar la nave de

relación con el proveedor, encontrarblems pro,pedir arreglos y
empujar al proveedor enenviandomásactualizaciones frecuentes
que funcionan.
• Conceda tanto tiempo para la integración como el proveedor ha
sido versiones de además. Silas liberaciones del proveedoruna
vezun mes, permitaparaunointegración mes. Ahora, realice un
seguimiento del tiempo transcurrido.Usoque los datos para
planificarparaelsiguienteintegración.
• Pídale al proveedor que desarrolle y libere de una manera
ágil.Sisu proveedorpodríaliberacióntodos los días o varias
vecesadía,¿podrías tomarelproducto?Sino,lo que
tendríasahacer?
Nunca assume obtendrá unacompilación libre de defectos de un

proveedor en cualquier momento.Nuncaasumirsuproveedor-
suministradoconstruir llegará a tiempo.
Muchosvendedores que sonwaterfallhaveadifficulttime conversiones
frecuentes y libres de defectos.Fomentarsu proveedory,siencajapara ti,
offer para ayudarellos.
6.8 Crear una cultura de entrega
A lo largo del Programa
En los programas, los equipos de entidades tendránpuntos de

interconexión con el resto de los equipos de entidades. Asegúrese de
que nada impida
equipos de integrating a menudo y a
cualquiera que vea. Esto permite a todos crear una cultura de entrega,
para que pueda obtener comentarios y asegurarse de que está en el
camino correcto.
6.9 Principios de crear un entorno

de Entrega
1. Un entorno de entrega ayuda a las personas a ver las pequeñas

victorias mientras trabajan en el
programa.Elprincipiosson:"Entregar
temprano y a menudosatisfacerthecliente" y"Entregar software
de trabajo con frecuencia."
2. Busque lugares donde el trabajo pueda ocultar y exponer ese
trabajo.Elprincipiosson:"Eliminar los residuos" und"Amplificar el
aprendizaje."
3. Haga que las iteraciones y las historias sean breves para que
todos puedanentregarlas todos los días. Comience con un
tamaño de historia que nosea mayor que un día de equipo o dos
días de equipo. Esto permite que cada equipo se integre en el
código base todo el tiempo.Todo el mundopuede
verelproduccreciendo todo el tiempo. Todo el programa
cumple.Cada unopequeñoganarcrea más confianza en toda la
organización. Los principios son: "Entregar temprano y a menudo
para satisfacer al cliente","Requisitos cambiantes de
bienvenida","Software de trabajoesla medida
primariaofprogreso," y"Simplicidad."
7. Fomentar la autonomía,
Colaboración, y
Exploración
De vuelta en un programa es una colección estratégica de varios

proyectos, expliqué que la gestión del programa no era ágil, que era
escalar las prácticas de colaboración en todo el programa.
En primer lugar, hablemosde qué es el software y cómo eso cambia la
forma en que pensamos acerca de nuestras prácticas.
7.1 El software es Aprendizaje, No
Construcción
El desarrollo de productos, especialmente el desarrollo desoftware,se

trata de aprender.Descubrimos requirements
comoqueproceder.Siqueesperaralos requisitos de descubrir, usted
aprenderácomoqueproceder.Agiley
le permiten implementar y replanificar amedida que aprende.
Podemosconstruir software de la misma
maneraweconstructormanufactura.
Esoes porque todo el nuevo software es innovation.
Los proyectos de software ayudan a los equipos a aprender e innovar a

medida que avanzan.Nosotrospuede cronometrar nuestro
aprendizaje.Nosotrospuedeelegiradejar de haceralgunos
Cosa. Podemos poner criterios de aceptación o liberación alrededor de
él y decir: "Hemos hecho suficiente por ahora."
Cuando enseñé ágilmente a un grupo de diseñadores de chips
analógicos, me dijeron: "Esto es exactamente lo que hacemos.Iteramos
hasta quequeobtenerelcompensaciones
Correcto. "
81
Fomentar la autonomía, la colaboración y la exploración 82
Iterar hasta que se hacen las compensaciones correctas es lo que

haces cuando aprendes.
Cuando itera según el diseño y se construye de forma incremental, se
aprende a lo largo del desarrollo de su Producto. Puedes cambiar a
medida que aprendas.
Los enfoques ágiles y ajustados ayudan a la gestión del programaal
encour el cambio de envejecimiento.¿Cómo?Agileymagrafomentar el
cambioporayudando aelequiposdarse cuentanecesitan:
• Implemente pequeños fragmentos de trabajo en forma de

características.
• Termina ese trabajo, así queestá hecho.
• Integre ese trabajo en todo el programa, para que todo el
mundo vea ese trabajo.Retrospectenintervalos razonables.
• Repetir.
Noimporta cuál sea su producto. Sepodríaserunaplicación de correo

electrónico, un sistema operativo, unincrustadosistema,oalgún otro
producto.Siqueseguirelmodelo
anterior,quevoluntadaprendercomoqueproceder.Esteaprenderconduce
al cambio. Ahíes donde losenfoques ágiles son tan útiles.
La tasa de aprendizaje en un programa es significativa, porque hay
muchas más personas de las que hay en un proyecto único. Si intenta
tratar un programa como si fuera un proyecto de construcción,
decepcionado. No creo que se puede "roll down" desde el programa a
los proyectos y ser ágil. Eso es jerárquico, pensar en cascada.
En programas ágiles y ajustados, escalamoshorizontalmente desde los
equipos multifuncionales.
7.2 Escalado ágil significa escalado

Prácticas de colaboración
Si desea un programa grande porque deseauna fecha de lanzamiento

anterior, sus equipos deben ser autónomos, para que puedan hacer su
decisiones propias.Ellosnecesidadasercolaboración,
porquequevoluntadaprendercomoproceden.Algunosdethoseaprendizaj
esvoluntadcrearinterdependencias. Y, los equipos necesitan ser
capaces de explorar,no abrir
intentloop, de
wanderofflearningexplorationinto. en ninguna parte,
peroexploraciónconel
La forma en que su programa tendrá éxito es si los equipos se

comunican
a través de sus tests y laintegración continua.Setodo se remonta
aelágily principios magros(Véase los principios ágilesy los
principiosmagros)de la entrega de software de trabajo a menudo
comoaholístico
Enfoque.
Para fomentar la velocidad en su programa ágil, el propietario del

producto del programanecesita tener conjuntos de características en la
hoja de ruta ágil, no compo
nents.
Cuantos másconjuntos de características específicos tenga, más podrán

crear pruebas e integrarse de forma independiente.Ellospuedetodavía
tienenpuntosde interdependencia.Sin embargo,cuanto más
definasespecíficoscaracterísticasdentroconjuntos de características,
más pueden operar los equiposcomoequipos de características,
o como equipos de conjuntos de características (varios equipos juntos
trabajando en un conjunto de características).
Sin embargo, si desea fomentarsu ágil

programa, el propietario del producto del programa puede tener
temas o
la hoja de ruta ágil. Sisuproductoesmarcanuevo, a veces
llamado"Greenfield,"quepuedequieroatienenvariosequipos de
característicasexplorarjuntos. Los equipos de características tienen que
trabajar de manera interdependiente en cada
Característica.
Es posible que necesite según los arquitectos que hagan algo, aunque
prefiero que los equipos lo hagan de forma colaborativa. Cuando los
equipos colaboran en el descubrimiento de la arquitectura, no solo
producen características ahora, sino que también formulan
características futuras para la hoja de ruta.
Cuanto mayor sea la característica—cuanto más cerca esté de un
tema o de una épica—,
más lentos son los equipos de características. Deben discutir entre sí lo
que significa la épica, y lo que los conjuntos de características son para
esa épica.
Los equipos podrían tener que mapear sus historias juntos, junto con sus
propietarios de productos para entender cuál es la épica.
Si desea velocidad, las prácticas de colaboración son pruebas e
integración.
Si desea explorar, las prácticas colaborativas son ping de mapas de

historias y wayfinding, antes de que pueda considerar las pruebas e
integrar
tion.
Depende de cuánto saben los propietarios de productos y los equipos

sobre el dominio de la solución de producto.
7.3 Crear equipos de entidades autónomos
Asumo que su programa tiene equipos de características, o está

trabajando hacia
composición característica téms. ¿Por qué? Porque tus clientes
compran fea tures. Nocomprancomponentes, a menos que vendas
bibliotecas.Ellosdon'tcomprarservicios.Ellosdon'tcomprararquitecturao
marcos.
Compran funciones. Considere la posibilidad de organizar los equipos y
lo que los equipos producen por lo quecompran sus clientes. De esa
manera, usted puede
maketheConway'sLawproductarchitectureworkforyou,notagainstyouth
ecommunication.( Conway'sLawstructuressaysrefleja
de esas organizaciones.VerelEntrada de Wikipediaparamás detalles.)
Con un programa, si no se organize por los equipos de características,

cada equipo'sCostofDelayaddsup. Los equipos solteros piensan que han
terminado con su trabajo, sólo para descubrir más tarde que los
componentes no crean Funciones. Vea los equipos tienen dependencias
en otros equipos.
Si su programisnotyetorganizedintofeatureteams,eche otro vistazo a

Cómo las características fluyen a través de los equipos y las sugerencias
sobre el movimiento de otros tipos deequiposaequipos de
características.Verlas ideasenSolución de problemas de equipo ágil.
Cuando los equipos de entidades son autónomos, crean su propio tipo
de enfoque agile.Sedoesn't importasiutilizan iteraciones, kanban,
ambos, o ninguno.Sesólo importa quequetienenuna

constanteflujodecaracterísticas a través de su equipo. Siun equipo de
características se queda atascado—y estodoesocurrir—pueden
preguntarparaayuda.Peroelequiponecesidadesasercapaz dea
crear confianzacon expertos de otrosuscaracterísticaspor equipo. O, sin
ellos mismos, interdependenciass sin otros equipos.
significa Autónoma.
Esoes lo que
por
esperaría equipo es
Cada team cantodavía eso. Pero preguntas cada uno deotroreo-
teamorfunctioningteamagileteam,. Yo
un equipo que ha estado practicando, aprendiendo y mejorando su

enfoque ágil.
7.4 Crear redes de pequeños mundos para

Optimizar el aprendizaje
¿Cuál es la "mejor"manera de obtener información a través de su

organi zation? El molino de rumores.
Una persona le dice algo a alguien. Quepersona le dice a alguien
Más. Es viral. Escomo si la información tiene una mente propia. ¿Puede
salusar esa red, esa viral para el beneficio de su
¿Programa? Puedes, si organizas el programa para hacerlo.
Esa red tiene un nombre. Sellama una red de pequeño mundo. Si alguna
vez hasusado Wikipedia, has usado un producto creado por una
pequeñaredmundial.Cualquierapuedeeditar Wikipedia. Hay algunas
reglas, muyaplicadaspor la comunidad, acerca de cómo la gente edita.
no código, el Son
lenguaje,Wikipediatienela noción depero . Esnatural
ideascolectiva"lamisma propiedad.
La mayoría de los usuarios no cambian Wikipedia—no vemos necesidad

de hacerlo.Ensu programa, usted
wouldesperareldesarrolladoresacambiar elcódigo.Usted lo
haríaesperarelprobadoresacambiar las pruebasy
los analistas de negocios para cambiar las historias, y así
sucesivamente. Es posible que tenga algunas reglas sobre quién puede
cambiar qué hacer que el entorno del programa se ejecute sin
problemas. Ejemplodefo r,usted podría estar de acuerdo en el
norma que nadie que no sea un analista de negocios o un propietario

de producto
puede cambiarhistoriassssss que tres semanas.

Pero,cualquierapuedeactualizar para mayor claridad cualquier historia
en cualquier momento.
Las redes Small-world son flexibles y dependen del equipo mem bers
para que funcionen (Here Comes Everybody: The Power of
Organización con Organizaciones, SHI08). Casi no tienenlímitepara su
escala. No requieren jerarquía. Se escalan, no
hacia arriba. The y tienen un costo de transacción muy bajo.
Norequieren administración. Sin embargo, requieren que le digas a la
gente que quieres que trabajen juntos.
Esta es una imagen de cómo podría ser una red de pequeño mundo para
nueve equipos. Supequeño-mundonetwork será diferente.
Posible imagen de nueve equipos de la red de pequeñomundos
Tenga en cuenta que cada equipo está conectado con todos los demás
equipos, pero no de la misma manera.Algunosla gente está altamente
conectada; algunosla genteestán mucho menos conectados. Eso no
importa.Elprogramapuede
aprovechar cómo las personas están conectadas, incluso si las

personasno están directamente conectadas entre sí.
7.5 Comunidades de Práctica crear

Conexión y colaboración
Cuando tienes equipos de entidades, la gente quiere conectarse a

otros
personas como ellos mismos a través del programa. Ellosquieropara
conectaraotra plataforma, middleware,Interfaz de
usuariodesarrolladores.Ellosquieroaconectaraotrosprobadores,analista
s, escritores, DBAs.Sicreas communitiesdeprácticaenel programa,
quevoluntadtienen unmaneraaconectar.
Los equipos de características se responsabilistice de sus
características. Y, las comunidades de práctica proporcionana las
personas una manera de conectar
todos los equipos de características y discutir los problemas que
lespermitenexplorar los problemas y resolverlos a través del
programa.Elcomunidadesdeprácticaayudar ala gente colabora y
aprende a través deelprograma.
Este es un ejemplo de cómo podrían verse los tres equipos de
características sidecidieran crear comunidades de práctica de
lacaracterística de heredero t
Equipos.
Comunidad de Prácticas
Observe que cada comunidad de práctica tiene miembros únicos,

excepto por
velopers,thearchitectsanddevelopersmightoverlapDevelopercommunit
y. Because architectsare. Su programatambién de-
tendrán que decidir qué hacer: ¿todos los desarrolladores también son
arquitectos?O,sonarquitectos,quesonincrustadoenlos equipos, un
subconjuntodeeldesarrolladores?Deje que los equiposdecidir.Recuerde,
los arquitectos guían el valor empresarialdela arquitectura. No son los
únicos que se les permite diseñar.VerPastor de la arquitectura
ágilparamásideassobrearquitectos ycómoayudan a pastorearelvalor
empresarialdeelproducto.
Las comunidades de práctica ayudan a los equipos a conectarse y decidir
cuándo y si profundizar sus redes de pequeño mundo.
Esto es más fácil si todos están ubicados.Cuandola gentesongeografía
distribuidas de forma cídica, sus oportunidades deaprenderdecada
unootrosson virtuales y no
casicomosatisfactorio.Personasvoluntadtodavía aprenderfromcada uno
otros cuando se distribuyen.Peropueden descubrirquetoma más tiempo.
7.6 Evitar títulos jerárquicos
Cuando empiezas a pensar en tu programa ágilcomo portavoces de los

trabajos netos,te das cuenta de que los equipos se mueven no sólo hacia
resolver
problemas alos elfos, pero también a la coordinación entre sí.
Piense en sus equipos ágiles como radios en una

rueda.Cuandoquetodostrabajan juntos, la rueda
gira y el
programa funciona. Cuandono don't trabajar
juntos, la ruedadoesn'tgirar y se
atasca.Noimpulso.
I avoid títulos tales como Arquitecto Jefe, Jefe de producto, Maestro
arquitecto, Ober cualquier cosa, Dominar cualquier cosa. El núcleo o los
miembros del equipo del programa noforman parte de una jerarquía.
Utilizotítulos como program manager, propietario del producto del

programa, y cuando sea necesario, arquitecto del programa. La idea
detrás de los títulos pro gram es que estas personas tienen la
responsabilidad de proporcionar
valor comercial del programa. No son líderes jerárquicos. Podrían liderar
unaunidad de práctica de comunicacióncomo líder siervo,
facilitando la comunicación, eliminando obstáculos, conectando a la
gente. (Consulte Desarrollar su liderazgo de siervos para obtener más
detalles.)
Sin embargo, no es el programaarchitect'sjob todo Big Architecture Up
Front y diseñar la arcitudela realidad para el producto.Onel
por el contrario, es eltrabajo del arquitectodel programa para nutrir la
evolución
de la arquitectura y el valor empresarial de la arquitectura a medida que
avanzaelprograma. Essuosutrabajoapreocuparse porel
momento más responsable paraliderar la discusión en la comunidad de
arquitectura de la práctica, "Creo que sabemos lo suficiente para decir
que esto es nuestro
arquitectura por ahora. "
Es el trabajo del propietariodel producto del programa definir la hoja

de ruta ágil y actualizarla a medida que el propietario del producto del
programa ve los demoniostra
De
tionsandhearsfromthepractice.community otherproductownersinthe
productowner
Es el trabajo del directordel programacrear el plan del programa con el

equipo principaly actualizarlo y el riesgo lista y cualquier otro
documento si
necesarioy colaborar en toda la organización. Estas personas del
programa tienen responsabilidadesadicionales.Ellosno son
maestrosojefesonadie.Ellostienen responsabilidadparavalor
empresarial.
Y, si necesitas que una persona sea el arquitecto jefe, una persona para
tomar todas las decisionesfinales, dilo. Estábien. Es posible que incluso
necesite que una personasea el propietario del producto del programa
(no un jefe), para ser la persona que tomar la decisión final sobre la hoja
de ruta y la
Atraso. Dilo. Pero que sea una decisión transparente.
Sieres transparentealrespecto, todos respetarán tu decisión.
Tu gente te apreciarápor tu honestidad.
7.7 Integración y pruebas continuas

Apoya la colaboración
Me gusta la integración continua (CI), donde cada equipo termina su

pequeños trozos e integra su trabajo al menos una vez al día. (Cuando
usoCI,cada equipo integra múltiplesvecescada día.) Esincluso
mejor cuando ese pequeño trozo es una historia. Nonecesitas
endurecerte
Sprints. No tienes deuda técnica deprograma-level. Todo el mundo
puede ver crecer el producto cada día.
Si puede utilizar el producto internamente, puede ver el producto y
obtener comentarios de los usuarios internos.Se'saganarparatodos.
Los miembros del equipo pueden usar la integración continua cuando

ellos unutomate sus pruebas unitarias y gran parte de sus pruebas del
sistema. Los evaluadores todavía tendránquerealizar las pruebas
exploratorias desagradables, que encontrarán defectos en lugares
inesperados. Los evaluadores pueden automatizar la mayoría de los
escenarios de prueba normales que el equipo necesita para ejecutar
often.
Cuando los equipos automatizan sus pruebas e integran continuamente

su código, sucede algo mágico.Ellospuede colaborar a nivel de
equipoporquesucódigofunciona.Ellospuederesolverproblemasen sus
comunidadesdeprácticayensus pequeñosworldredes.Que
tienedosefectos secundarios significativos:elprograma se mueve más
rápido, manteniendo el impulso.Y,los problemas que intensificanael
softwareprogramaequipotiendenasermás difícilaresolver.
Si el equipo del programa resuelve sólo los problemas difíciles, no "cómo
pasamos aproblemas ágiles", el equipodel programa puede
proporcionar un valor óptimo al programa. Resuelven problemas que
impiden que todo el producto se libere, no los obstáculos que
equipos de llegar inclusoa un producto.
Si su téms no tiene pruebas automatizadas o no es capaz de integrarse
continuamente, resuelva esos problemas ahora. No espere hasta que
esté a mitad del programa y su producto
desarrollo se ha detenido porque nadie puede integrarse.
Fomentar la autonomía, colaboraren la exploración y la
exploración 91
Del mismo modo, si los equipos no mantienen su desarrollo

automatizado de pruebas—tanto de pruebas unitarias como de
desarrollode pruebas delsistema—será incapaz de descubrir cómo
arreglar su código si dos características se acotan entre sí. Hacer
características delcentro comercial y el uso de redes de pequeño mundo
ayuda con la colaboración.Peromantener un buen apoyoparacódigo
conpruebaautomatización e integración continuaayuda atambién.
¿Qué puede hacer un administrador de programas?
1. Pregunte por el resultado que desea.Siquequierointegración

continua,explicar queEs lo que quieres. Yo digo algo como esto,
"Quiero que el sistema esté en un estado releable todos los
días.Enun mínimo, meseríaasícadasemana.Sé que'sno
donde estamos ahora, y esees el resultado queme gustaría.
¿Qué haría lo que se necesitaría para llegar allí?"
2. Supongamos que los equipos técnicos entienden los lems de prob
técnico mejor que usted, el director del programa.
Siquepreguntarparaelproblemay los impedimentos,don'tcaca-
cacalos problemas. Trate los problemas y los impedimentos
seriamente. Supongamos que laspersonas técnicas tienen razón
sobre los problemas.
3. Utilice la regla de tres para cada solución potencial. Es decir, para
cada problema, desarrollar tres posibles soluciones razonables a
ese problema. De esa manera, todo el mundo entiende el
problema lo suficientemente bien.Sisólotienenunoposible
solución, las posibilidades son bastante buenasnounoentiende
laproblemabiensuficiente para resolverlo.
4. Involucrar a las comunidades de práctica en la generación de las
siguientes condiciones a estos problemas.Que's lo que
sonnopara.Usoellos.
5. Pida el proyecto o presentarvoluntarios delequipo para probar
una solución antes de comprometer el programa. Nunca imponer
la solución entodo el
programa.Sinounoesdispuestoavoluntarioatratar deuna
solución,que'sno es razonable.Irde nuevoael dibujotablero.
Como el programmanager, escucha a tus equipos. Si dicen, "No
podemos
hacer esto ", pregunte qué lespermitiría ser capaz de hacer lo que usted
desea.Considerepreguntandoexperimentar para convertirse enmáságil
y magra.
Sin integración continua, su programa no puede lograr unaentrega

intinuosa.Siquetienen la posibilidad de utilizar entrega,lo quele impide
hacerlo?Que'sunimpedimento,quecomoprogramagerente,puedefacilit
ar la eliminación.
7.8 Tenga cuidado con la deuda técnica
Cuanto más grande y más largo sea su programa, másnecesitan los

equipos para mantener el código y las pruebas limpias.Simantienen
elcódigoy pruebaslimpio,pueden utilizar la integración continua.
Pueden cumplir con todos los
sus entregables el uno al otro. El puede colaborar en toda la
organización,porque todo el código y las pruebas están listos y
disponibles para que trabajen encualquiertiempo.Siel programa se
encuentra con ungrandeproblema, talescomolos equiposdarse
cuentaelactualarquitecturaganó'ttrabajo,elcódigoesengranformaarefa
ctorizarorediseño.
Comogerente de program,escuche a sus equipos si comienzan a decir:
"Nos sentimos presionados para fecha."Mi experiencia(y apuesto a que
el tuyo también)esque cuando los equipostratar depara cumplir con las
fechas, que la calidad de la delicadeza.
Inágil, equipos terminan su trabajo. Limitthefeature scope,notquality.
Enla forma de construir un gran producto en un programa.
Elimine la deuda técnica en cada función. Eliminar la deuda técnica

para cada iteración o conjunto de características. Elimine la deuda
técnica para cada liberación. Sicualquierequiponecesidadesun sprint de
endurecimiento,quetienen técnicos
Deuda. Encuéntralo y elimínalo.
7.9 Invitar a las personas a experimentar
Una manera de ayudar a la autonomía, la colaboración y la exploración

a través del programa es invitar a las personas a experimentar.
Un experimento es when usted ha desarrollado una hipótesis de lo que
está causando un problema o impedimento. Usted decideprobar algo
para
cierta cantidad de tiempo y medir los resultados. Necesitas medir,
onoestás experimentando.Enel finaldequetiempo,usted evalúa el
resultados y decide qué hacer a continuación.
Si invitas a la gente a experimentar, o si otros te invitan a
experimento, nadie exige nada para nadie más. Nadie sostiene la
"salsasecreta"para resolver problemas en el programa. Esoes bueno,
porque no hay salsa secreta.
Cuanto más invites a la gente a experimentar, para crear una hipótesis,
para
probar algoforashorttimebox, paramedir los resultadosy decidir qué
hacer, cuanto más toman la responsabilidad de sus acciones.
Cuando son responsables, es más probable que demanden.
A algunas personas tal vez no les guste la palabra "experimento."
Considere estos
palabras como alternativas: "pruebas"o "manicomiese con la forma en
que trabajamos. " Independientementedelo
quequellamarque,trabajoencajas de tiempo cortascomoequipos y
medir los resultadosasí quequepuededecidirlo queahacera
continuación.
Trata a las personas como si fueran adultos y tus iguales. (Son iguales—
quetienensupartesahacer,como¿Usted.) Responderán
actuando como si fueran adultos.Siquetrabajoa través
deelorganización, colaborandoensu pequeño mundoredescomodults,
ustedobtenerlos resultadosquequiero—atrabajandoproducto.
7.10 Principios de Fomento a la Autonomía, la Colaboración y la

Exploración
1. La autonomía, la colaboración y la exploración son la base
for característica de éxito del equipo. Dígale eso a los equipos de

características. Los principios son: "Atención continua a la
excelencia técnica
y un buen diseño mejora la agilidad"y "Las mejores tures,
requisitos y diseños de los equipos auto-organizador."
2. Fomentar las redes small-world con listas de correo electrónico
y reuniones presenciales siempre que sea posible.El
principioes:"Amplificar el aprendizaje"y"Conversación cara a
caraesel máseficienteyeficazmétododeinformación."
3. Crear comunidades de práctica. Los principiosson: "Con
la atención tinuosa a la excelencia técnica y el buen diseño
mejoran laagilidad"y "las mejores arquitecturas, requisitos y
diseños surgen de la autoorganización equipos" y "Am plify
aprendizaje."
8. Llevar a cabo reunionesútiles
para su programa
En el programa, la gente necesita reuniones a nivel de programa por

varias razones:
• Los propietarios de los productos deben colaborar para

actualizar la hoja de ruta ágil.VerUsoPlanificación continua.
• Los propietarios de productos necesitan crear atrasos de MVP.
Los propietarios de productos pueden crear el trabajo pendiente
primero y pedir al equipo que revise el trabajo
pendiente.Ellospodría construireltrabajo pendiente
soloypresentequeael equipo.Sedependeencómo integrado el
propietario del productoesconelequipoen circunstancias
normales.
• El equipo del programa de software necesita resolver problemas
que losequipos que cuentanno puedenresolver, y necesita
presentar el estado informes al resto de la organización.
• El equipo principal necesita resolver problemas que el equipo del
programa de software no puederesolver, y necesita asegurarse
de que todos loselnúcleoequipoeslistoparaproductoliberación.
• El núcleo o el equipo del programa de software pueden tener
una especificación retro.
• Es posible que cualquier equipo del programa deba proporcionar
un informe de estado al resto de la organización.Cada unoequipo
del programa podría quereratienenaBig VisibleGráficoexplicando
el programaestadoen
en cualquier momento. Elequipo del
programavoluntadnecesidadacumpliracrear ese gráfico de
estadooinforme.
Usted tiene opciones sobre cómo las personas llevan a cabo estas
reuniones.
95
Lleve a cabo reuniones útiles para su programa 96
8.1 Explicar el estado: No usar soportes en el nivel Program
Notarásque ninguna de estas reuniones son reuniones de stand up. Un

stand up es insuficiente para estas reuniones.
No utilice standups para los equipos de programa.

Standupsevolucionaren reuniones de estado serie.
Preguntando "qué completaste", o incluso "lohiciste desde nuestro

último standup"eselmalpregunta.Elpreguntaesirrelevante porque
elprogramamiembros del equipohacernotienen micro diario
compromisos entre sí como lo hacen los miembros del equipo en un
equipo de características.
Esoes porque los miembros principales del equipo no son un equipo

real en el
sensación de queno tienen entregables interdependientes. Recuerde,
elequipo principal es un grupo de personas cuyo trabajo es pastorear el
producto para liberar, resolviendo problemas de negocio que liberación.
Un stand up también es irrelevante para un equipode programas de
software —
demasiado ocurrió en el programa de software si los equipos están
integrando características todos los días o más a menudo.
Si hace la pregunta "desde el último standup", creará una reunión de
estado en serie. Nolohagas. Nadiele gusta el estado de serie
mehormigueos.
Existen equipos de programa para resolver problemas y eliminar
obstáculos en toda la organización. Usted, como administrador de
programas, puede que tenga que informar del estado hacia arriba, hacia
abajo y de lado.Hacernohacer que
suprogramaequipomiembrossentarsea través de una reunión de estado
de serie.
La siguiente quesción, "¿En qué estás trabajando ahora" es también
irrele
vant. Es posible que necesite
preguntaraboutactionitem/kanbanitemprogress en una parte de la
reunión, perono desea liderar con eso
Pregunta.
Sin embargo, usted necesita sabercuáles son los obstáculos. También
necesita skahora cuáles son las interdependencias. Usted necesita
sabersi
entregas van a llegar tarde. Y los equipos tienen que decírtelo.

Eso es gestiónde programas.
No aprendes esos problemas en un stand up. Aprendes lam de otras
maneras.
8.2 Definir un ritmo para su programa

Equipo
Todos en el equipo principal o el equipodel programa de software están

ocupados con su otro trabajo.Definirun ritmo para que estas personas
ocupadas saben qué esperar parasuprogramacompromisoy cuándo
esperarque.Una cadencia de programa muestra
respetoparasutiempoyelotras demandasdesutrabajo.
Usted mantiene la misma cadencia a lo largo de la
Programa. Usted puede comenzar con un quincenal (una vez cada dos
semanas)
reunión y transición a una reunión semanal amedida que la fecha de
facilidad del productose acerca.
Algunos equipos de programas intentan trabajar en iteraciones.
Algunos intentan trabajar en kanban.
Recomiendo usar kanban para cada equipo del programa, para que
cada equipo pueda visualizar su trabajo en curso.
También recomiendo que tenga reuniones semanales o quincenales,
depend ing en la duración de su programa. Las reuniones le
proporcionan una cadencia, un ritmo para su trabajo, sin tener que
comprometerse
a iteraciones reales.
El problema es que cada equipo del programa resuelve diferentes
problemas, especialmente si su programa es grande enough.
El softwareprogramteamssolucionaproblemas técnicos. Responden a

estas preguntas:
• ¿Cómo podemos ayudar a la organización a comprender el

progreso que están haciendo todos los equipos de software en
su conjunto?
• ¿Qué problemas estamos encontrarrestar como un programa?
• ¿Cómo podemos nosotros, como equipo del programa, ayudar a
los equipos a resolver esos problemas o eliminar esos
obstáculos?
Las dos últimas preguntas son enfoques más tácticos a la pregunta del
equipocentral,"¿Cómo podemos ayudar al programa a
organización?"El programa de
softwareteamwilllimittheirtheirproblem-
resolviendo al programa de software. Siqueverproblemas en toda la
organización que pueden'tarreglar,queintensificar queproblemaael
equipo principal.
El equipo principalresuelve los problemas de valor empresarial.
Responden a estas preguntas:
• ¿Cómo podemos ayudar a las funciones de toda la organización

a resolver sus problemas y obtener la información que
necesitan?
• ¿Qué problemasnos encontramos como programa?
• ¿Cómo puedeel equipo de weveasaprogramhelpthecross-
functionalcore equipo resolver esos problemaso eliminar esos
obstáculos?
La primera pregunta aborda la estrategia para el programa. Las dos

últimas preguntas son enfoques más tácticos a la pregunta del
equipocentral,"¿Cómo podemos ayudar al negocio valor de este
programa?"Elequipo del programa principal añadirássproblemasa
través deelorganization.Sielnúcleoequipove problemas que puede't
arreglar,tú,comoelnúcleoequipodirector del programavoluntadtienen
que escalar elproblemaasupatrocinadoresogestión.
Con qué frecuencia debe su programa

¿Equipo de reunión?
Dependiendo de la duración delproyecto del programa, he
programas con una reunión quincenal del equipo del

programa. Eso ayuda a todos a iniciar el programa y
aprender a trabajar
Juntos. Comoel programa se acerca a la fecha de
lanzamiento, quemoverareuniones semanales del equipo del
programa. Esoes porque tenemos entregas más frecuentes.
Reúnase cuando necesite reunirse.Nocualquier
más a menudo.
El equipo del programaes un equipo en el sentido de que todos tienen el

mismo objetivo: lanzar el producto. Pero, casi nadie sejuntará en su
trabajo.Cada unopersonaesun delegadodeen toda la organización. La
probabilidad de que el equipo del programapueda enjambre en sus
problemas fuera de las reuniones del equipo del programaes
pequeña.Enese sentido, elprogramaequipoesun grupo.
Talvez puedas gastarcon tus reuniones de equipo
principales.Setodosdepende decómosu programa
esprocedimiento.Yorecomendar utilizas una agenda de reuniones para
resolver problemas. Tengo sugerencias para esa agenda en Organizar
sus reuniones de equipo de programa.
Puede utilizar una lista de elementos de acción, que he utilizado durante
muchos años. Ahora prefiero un tablero kanban, porque muestra el
número de elementos en curso. Aquí hay un tablero kanbanpotencial
para un equipo principal:
Posible tablero kanban para un equipo principal
Podrías preferir anactionitemlist. Asegúrese de tener algún gráfico que

exponga el trabajo y especialmente el trabajo en curso, el trabajo en
curso.
El equipo del programa es un lugar donde WIP puede

ocultarse.Hacernodejar queelWIPesconderse
enelprogramaequipo.Túpodría estar cerca deelfin deelprograma y
realizarquenosonlegalacuerdosasigno,preciosadeterminar, la
formaciónaplan, todos lostiposdecosas queelnúcleoequipo del
programa necesitaaentregar.Elkanbanjunta paraelequipo principal
ayudará a queequipover suWIPy gestionar susriesgos.
Cómo administrar elementos de clientes potenciales largos
De vez en cuando, tienes elementos de plomo largos. Tal
veztienenaordenequipo.Tal veztienencomprometerse
aunhacia fueraladoproveedor. Tal vez usted tiene que
integrarse con algún otro software. Tienes que
comprometerte con algo más de tres
meses de antelación, muy fuera de una iteración. Usted tiene un
largo elemento de plomo.¿Qué¿Lo haces?

Este es un riesgo para su programa. Gestionarlo como un
riesgo.
Pregúntate, ¿cuál es la acción más pequeña que puedo
hacer para ver resultados o acción en este elemento de larga
duración? ¿Cómo sabré que
me estoy acercando o más lejos de esta
entrega?¿Cómopuedequevisualizarsiqueestán más
cerca,nomás lejos
de esta entrega? Añade algo cada semana, un guijarro de
pulgada (ROT07), a tu kanban, para asegurarte de
progresar en tus artículos de larga duración.
8.3 Organizar las reuniones del equipo del programa
¿Las reuniones del equipo del programa son demasiado grandes?
"Tamañocorrecto" Las reuniones del equipodel programa
Una vez entrené a un director de programa que intentaba

rescatar un gran programa de 16 equipos de
características. Su programa
reuniones de equipo fueron un desastre.
Cada equipo de características tenía un Maestro Scrum. Cada

Maestro Scrum
asistieron a las reuniones semanales del equipo del
programa de software. Ese equipo del programa no fue
capaz de tomar decisiones o volver a
Obstáculos. El programa se retrasó cada vez más, no porque
usaran Scrum, sino porque no podían estar de acuerdo como
un grupo de 17 personas.
El director del programa decidió organizar el equipo del
programa
reuniones en primer lugar. Ella dijo,"Ustedes Scrum
Masters son todosen
diferentesniveles.AlgunosdequesonScrumdeScrumMaestros
para varios
equipos que trabajan en conjuntos de características

relacionadas.Algunosdequetienen
sólo un equipo de características trabajando en un conjunto
de características. Tenemos un gran riesgo para el carnero
prog. No estamos terminando nuestro trabajo en equipo del
programa porquenopodemosestar de acuerdo en nada.
Tengo una gran pregunta: ¿Necesitan estar todos en esta
reunión?
"Ustedes deciden. ¿Deberías ganarle a esta reunión? Si no,
decida cómo obtendrá la información. Te lodejo a
ti.Trabajoparatú." Ellase sentóde nuevoabajo y dejarques
trabajarpara30
Minutos.
Alfinal de 20 minutos, se habían autoorganizado en una

reunión de cuatro directores de programas de
pequeñoprograma. Cada uno de esos directores de
programas tenía tres equipos de características trabajando
en
conjuntos de características relacionados. Enademás,
hubocincoequipo de características
independientesScrumMaestros. Eso hizo nueve personas
más el director del programa y el propietario del productodel
programa.
Scrum decidió ser después de la reunión del equipo del
programa FirstMasters,theydidn'the
independentfeatureneedallthere.
Uno de ellos vino a cada reunión, y informó a los otros

cuatro más tarde.
El director del programa continuó enviando por correo

electrónico la agenda a todos los Maestros Scrumantesde
cada reunión, en caso de que
quería participar. Ella envió el minutoa todo el mundo,
también, así que todos se sentían como sipudieran ver la
información.
Los equipos del programa tenían un

ellos, el equipo del programa de software y los equipos de
programas de características. Cada uno podía tomar sus
propias decisiones y tenía una manera de ayudar a la
informacióna moverse por la organización.
Si usted tiene un programa grande, busque programas dentro de su pro

gram. Encuentre una manera de administrar el número de personas en
las reuniones del equipo de su programa. Consulte Conocer qué equipos
de programa necesita.
Si todavía necesita un delegado de cadaequipo de características, cree
normas de equipo de compro gram o sobre cómo tomará decisiones.
He visto
estas normas funcionan:
• La gente discute temas e inquietudes de antemano en un wiki o

en algún otro foro de proyecto interno.
• Si la genteno ha leído la agenda y los puntos de discusión de
antemano, no pueden participar en una decisión.
• Si las personas que se supone que están en el equipo del
programa también están haciendotrabajo técnico, encuentran
a alguien otros para votar como su apoderado.
• People acepta usar un consenso limitado para que
puedanexperimentar y medir, antes de rechazar una idea.
Es posible que deba crear normas de equipopara su equipo del

programa si nunca ha trabajado juntos antes.Esperarpara pasar tiempo
construyendo
normas del equipo en su primera reunión del equipo del programa.
Bepreparadoaiterarensuequiponormas. Usted tendrá que encontrar las
normas que funcionan para su equipo.
8.4 Resolverreuniones del equipo del programa
Problemas
la resolución de
problemas,
Aprogrammanageraformofservantleadershipfacilitatesanenvironmentf
or.It'sallaboutriskmanagement,ayudando
personas para ser más ágily y delgado.
1. Considere una agenda de resolución de problemas como la

siguiente.
2. Podrías decidir tener reuniones de Lean Coffee.
3. Considere una lectura de temperatura, especialmente para
retrospectives.
8.4.1 Cómo utilizar una reunión de resolución de problemas

Agenda
He usado y evolucionado este tipo de agenda con el tiempo.Inicioaquíy

evolucionarqueparasu uso.
Me gusta enviar la agenda en un correo electrónico a todos al menos
24 horas en
Avanzar. Inthatemail, le pregunto,"¿Tienes algo para el problema de la
semana?" Siquehacerresponder,Yopuedeañadirque. De lo contrario,
podrían estar listos para agregarlo en el momento de la registro de la
reunión.
Incluya la lista de participantes invitadospara que todos sepan quién
está en la reunión o en la llamada.
Incluya la ubicación: sala de reuniones o información de llamada,sise
trata de una llamada de conferencia.
1. Haz el check-in con todo el mundo.

2. Visualice la información kanban o de hitos.Ayudala gentever el
corto plazo ylargo-términohitos.
3. Enumere los problemas de la semana. (Si usted
estenerquincenalmente
reuniones, cambiar este problemadela reunión. O, llame
"eliminaciónde obstáculos" o "eliminación de
impedimentos."Usotérminos queapto parasuorganización.
Recuerde, el equipo del programa existe para resolver problemas
a nivel de equipo del programa, core nivel de equipo, osoftware
programteam,notatthe featureteam.)
• Discuta cada problema. Asegúrese de que este es un
problema que puede resolver con este equipo del
programa. Evalúe si necesita realizar un cuadro de tiempo
en la discusión. Decida sinecesita dividir se divide en
subequipos para discuss el problema y generar
soluciones.Pregunteustedes
mismossiquenecesidadaescalar elproblemasise puede't
resolverque.
• Asaprogramteam, su objetivoderesolver cadaproblema
alfinal de la reunión. Pero algunos problemas no son de 20
minutos a problemas de una hora.Enthat
caso,quenecesidadpara tener un separadoreuniónpara
resolver el problema. Put
el problema en su tablero kanban olista de elementos de

acción con un tiempo para resolverlo. Nodejes que este
trabajo se esconda. EsWIP.
4. Revise los elementos de acción outstanding oelementos kanban
que no haya resuelto.
5. Aplazar la reunión.
Cree un repositorio central al que cualquier persona pueda

acceder.Usoque repositoryaplantear cuestiones
yresolverproblemasfueradeelreunión. Me gustan las notas de la reunión
y los elementos de acción en un wiki o en su propio kanban
Tablero.
Después de la reunión, envíe los minutos conelementos de acción (tal

vez una imagen del tablero kanban o un puntero a la pizarra) dentro de
las 24 horasdespués deelreunión.
8.4.2 Cómo utilizar las reuniones de café magro
Cuando usas café magro, everyone hace una lluvia de ideas sobre la lista
de problemas en stickies. Votas sobre los stickies. Tomas la clasificación
más alta
pegajoso, discutirqueforashorttimebox. Considere la posibilidad
deseleccionarun cuadro de tiempo de ocho minutos y ver si eso funciona
para usted.Túpuedesiempre
disminuir la duración del intervalo de tiempo a cinco minutos, si lo
desea.Hacerno
startwithatimeboxlongerthaneightminutes. La idea de café lean es que
discutas algo siempre y cuando la gente tenga energía a su alrededor.
Más deochominutos yeldiscusiónvoluntadhundirse.
Alfinal de lacaja detiempo, usted vota el pulgar para continuar (thumb-
up), nole importa (thumb-sideways), o cambiar el tema (thumb-down ).
Si
usted cronometra las reuniones de su equipo del programa a una hora,
puedesorprendersepor la cantidad de problemasque puede cubriren
una hora. Podría decidir resumirla lista de elementos de acción o
preparar un kanban de las acciones al final de la reunión.Siasí que,ya
seaañadir otro5-10minutos (timebox este
trabajo),oincluirqueenelreunión.
8.4.3 Cómo utilizar un Temperature Reading
Virginia Satir, terapeuta familiar, desarrolló la lectura de la

temperatura.Es posible que deseetratar dequeparasuequipo del
programa. Alternativamente,
es una gran manera de hacer retrospectivas con un equipo.
1. Aprecios. Unapreciaciónesun agradecimiento

personalizadoquewithla razón por la que.Setoma
elformulariode"PrimeroNombre, te agradezcoquepara(algo)
porque(por alguna razón)."
2. Nueva información. ¿Qué información nueva tiene?
3. Rompecabezas. ¿Qué tedesconcierta?
4. Solicitudes de cambio. ¿Qué cambios serían útiles?
5. Hopes y deseos. ¿Qué esperanzas y deseos tienes?
8.5 Retrospect en el Equipo del Programa
Nivel
Los equipos del programa debenreflexionar y cambiar sus enfoques

los equipos de características lo hacen.Ellospodría
necesitarainspeccionar y adaptar mása menudoomenosa menudocomo
el teams.Aquíson algunas pautasparacuando elprogramanecesidades
del equipoaretrospectiva:
• Cuando el equipo del programa tiene más WIP de lo que

pensaban que era razonable.
• Cuando la genteno termina sus entregas al
programa.Entregaspodríasermódulos de
formacióndeelformacióndepartemiento,oacuerdos
legales,odespliegue automáticoparael programa de software.
Estos son ejemplos, y los equipos del programa los rastrearían.
• Cuando los equipos del programano despejan obstáculos para
nadie en el programa.
Llevar a cabo reuniones útiles para ynuestro
programa 107
Aparte de una lectura de temperatura, considere maneras de descubrir

los datos y, a continuación, pasar a la resolución de problemas.Dense
suficiente tiempo—al menos medio día—para entender los
problemasydesarrollar
elementos de acción de la retrospectiva.
Si los miembros de suequipo de program están distribuidos
geográficamente, es aún más importante a intervalos
regulares.Elespacioproblemas continuos del tiempo pueden
manifestarse enlos equipos de características, también. Entiéndalos y
resuelvalos.
Para más posibilidades para sus retrospectivas, consulte Agile Retrospec
tives: Making Good Teams Great, (DER06) y Getting Value out of
Retrospectivas ágiles: Una caja de herramientas de ejercicios
retrospectivos, GLI15.
8.6 Principios para llevar a cabo reuniones útiles para su

programa
1. Defina el purpose para sus reuniones.Hacerseguroquetienenla

gentequenecesidad.Timebox las reuniones,sinecesario,así que
personas y desarrolladores
"Eliminatedon'tspendwaste"alldayatthe"Businessmeetingspeopl
eand.The principlesare: must
trabajar juntos."
2. Notienesreuniones quenonecesites tener.Elprincipio es:"Eliminar
los residuos."
3. Cree un foro público en línea para que todos puedan ver la dis
cussions que su equipo del programa está
teniendo.Estevoluntadayudar ala transparenciadesu programa,
y ayudar a la gente a verquesontrabajandoeneliminación de
obstacles. Los principios son: "Amplificarel aprendizaje"y "Los
empresarios y desarrolladores deben trabajar juntos."
9. Programa de estimación
Horario o costo
Si alguna vez ha utilizado enfoques de cascada para los programas,

usted y los equipos pasaron una buena cantidad de tiempo estimando
cómo largo tiempo que el programa tomaría o
cuántocostaría.Ahora,incluso si usted
voluntad de "¿Cuánto tiempo
son estousandoprogramaágil,tomar? "sus gerentesO,ellos podrían
querer saber, saber, mucho
esta bestia costó? "
Sus gerentes pidieron estimaciones, porque en losdías decascada, las

estimaciones eran la única manera en que podían manejar el
riesgodelprograma. Encascada,quese suponía que
actualizarelestimación en elfindecada unofase. No tenemos fases en
ágil, por lo que sus gerentes podrían no darse cuenta de que tienen otras
maneras deriesgo del programa en una reunión derevisión de
operaciones o una gestión de cartera de proyectos
Reunión.
Sin embargo, tiene otras palancasen su disposiciónparaadministrar el

riesgo del programa y el estado del informe.VerMedidas útilesenunAgile
y
Programa Lean.
La mejor palanca que tiene para manage riesgo es el hecho de que se
puede ver el producto de trabajo todo el hora. Si utiliza la idea de las
versionesinternas
al menos cada mes, sus gerentes nonecesitan pedir estimaciones.
Los gerentes de hoy pueden pedir estimaciones porque piensan que
pueden agregar más peopple a su programa y reducir la tiempo
necesario.
Están equivocados.
Una vez que tenga un equipo de características porconjunto de

características, es posible que no necesite más equipos en su programa.
Puede preguntar función
equipos, "¿Sería útil trabajar en conjunto con otroequipo para reducir
el tiempo?"Escucharalo que dicen los equipos de características.
108
Estimación del Programa o Costo 109
Agregar más personas o más equipos a tu programa puede ralentizarlo,

especialmente si el programa llega tarde.Adición demás personas o
teamsincreasesthe communicationoverhead. Si el programa, se
encontrará con Brooks' Ley de Elhombre mítico -Mes (BRO95).
Ayude a sus gerentes a ver que tienen palancas que no sean la

estimación de su
programa.Enunágilomagraorganización,comolargocomoel fequipos de
eaturecompletauna característicacadadíaoasí que,los gerentes pueden
decir,"Deténgase"cada vez queel programa tiene
suficientetrabajando.Gastotiempoestimando en su lugardeentrega
tiene poco sentidoparaunágilprograma.
9.1 ¿Quiere su organización

¿Resiliencia oredicción P?
Si su gestión es nueva en ágil, es posible que no se den cuenta de que

ágil y magro proporciona la resiliencia del programa.
Estimaciónespredicción,ysuequiposcanestimacióntrabajoqueescerca y
pequeñoconbuenos resultados. Sin embargo, cuanto más grande o más
lejos esel trabajo,peor es el
es probable que la estimación.
Una vez que los equipos comiencen a entregar, puede explicar el valor
de la resiliencia:la capacidad de cambiar rápidamente.
Pregunte a su dirección lo que quieren: resiliencia o predicción?Sidicen
predicción, tal vezvoluntadcambiar sumentesdespués de
los equipos producen productos de trabajo y continúan produciendo
más productos de trabajo.
Si dicen resiliencia, confían en que el equipo de valordel propietario
del producto
clasificar las características. Ellos gerentes también
confíanelequiposacaracterísticas completas. Workwith sus gerentes
para construirconfianza para queno necesitan tantas estimaciones
como solían hacerlo.
9.2 Haga estas preguntas antes de
Estimar
Si sus gerentes todavía quieren saber cuánto costaráel programa o

cuánto tiempo tomará, recuérdeles que estas preguntas son las
preguntas equivocadas. Usted, como puede preguntar el director del
programa,
• ¿Cuánto te gustaría invertir en tiempo, dinero o aprendizaje

antes de que nos detengamos?
• ¿Estáslisto para ver el programa crecer a medida que lo
construimos para que pueda detenernos cuando
noquieroainvertir más?
• ¿Cuál es el valor de este proyecto o programa para usted?
Es mucho más fácil gestionar la inversión de lo que es predecir una

estimación.Conunhoja de ruta ágil, sus patrocinadores puedenayudar
aseleccionar elinversióndirección, también.
Yo t 's fácil de responder a la pregunta "¿Cuánto le gustaría

invertir",siempre y cuando el programa siempre tiene demostrable o
producto como se puede el laqueable. O tus patrocinadores dirán,
"Hevisto suficiente. Por favor, deténgase."
O,quevoluntaddecir,"Yocomolo queYover.Por favor, manténgaseing."
O, podrían decir,"Me gusta lo que veo, y megustaría que cambiaras esto
y aquello, por favor."
Es fácil trabajar con gente así.Se'smuchomásdifícilpara estimar todo un
programa.
Pero, ¿qué pasa si sus patrocinadores necesitan algún tipo de

estimación de ballpark, algo que les da una idea de cuánto o ¿Cuánto
durará este programa? Es posible que necesite una estimación bruta
porque sus patrocinadores pueden querer limitar su tiempo y su
inversión monetaria. Ellos
puede querer detener antes de alcanzarNRE,No-
RecurringEngineegastos de anillo.
Estas son algunas ideas.

9.3 Targets Beat Estimates
Trabajar hacia un objetivo, ya sea fecha o presupuesto, es mucho más

fácil que tratar de estimar un programa grande.
Si supatrocinador dice, "Aquí está sutargetdate,"o"Noexcedaeste
presupuesto", que'sgreat. Puedeadministrar el
programariskstomeetesa fecha objetivo o presupuesto. Puede trabajar
hacia un objetivo, asegurándose de
usted tiene, como mínimo, entregas mensuales que son productos
liberables.
Tendrás que ayudar al productownersfocusonla hoja de ruta más

valiosa. Usted tendrá que ver la tasa de ejecución para el programa. Tú
tendrán que trabajar con los equipos de características para asegurarse
de que producen demostraciones mensuales o productos de trabajo.
9.4 Generar una estimación con un

Porcentaje Confidence
Si debe estimar, pruebe una estimación bruta con un porcentaje de

confi dence.
Su estimación será incorrecta, pero silo llama una "Estimación Bruta

con un Porcentaje de Confianza, "una "Predicción",o un "Pronóstico", es
más probable que obtenga el resultado quequiero.
Recuerde a sus patrocinadores que las estimaciones son conjeturas, no
promesas.
Suponiendo que tiene equipos y tienen alguna idea de lo que está en sus
conjuntos de características o trabajos pendientes, pruebe este
enfoque:
9.4.1 Opción 1: Los equipos estiman su propio

atrasos clasificados
Para un programa, el equipo de eachhace esto para su propio trabajo

pendiente clasificado:
• Tome todos los elementos del trabajo pendiente y la hoja de ruta,

y utilice el enfoque de tamaño relativo que utilice ahora para
estimar.Si usted
tienen pequeñas características, puede contarlas. Remember,
porque eres ágil,quepuedenohacereltrabajomás lejosenla hoja
de ruta. Tiene incertidumbre, no solo en el tamaño, sino en si va
a implementar esas características.
• Camina a través de todo el trabajo pendiente, estimando a
medida que avanzas. Note preocupes porcómo mearge las
características son.Mantener uncontardeelgrandes
características.Decidircomo equiposiesta característicaesmás
grande quedosotresdías de equipo.Siquees, mantener un
conteodeesas características.Elmás grandes las características,
elmásincertidumbrequetienenensu estimación.
• Como equipo,agregue todas sus estimaciones relativas para sus
características. Agregue el número de entidades grandes. Ahora,
tienes una estimación relativa que, en base a tu velocidad
anterior, significa algo para ti. También tiene una serie de
entidades grandes, lo que disminuirá la confidencia en esa
estimación.
• ¿Tiene 50 características, de las cuales sólo cinco son
grandes?Tal vez
tienes 75% de confianza en tuestimación. Por otro lado,
tal vez todas sus características son grandes. Sólo podría tener
entre un 5y un10% de confianza en la estimación.¿Por
qué?Debido a que el equipo hasn't completado cualquier
trabajoyet usted no tiene idea de cuánto tiempo su
el trabajo tomará.
Estimaciones del equipo del programa por equipo
Estoes lo que esto podría pareceren un programa. Supongamos que

tiene cinco equipos, cada uno con supropio trabajo pendiente
clasificado.Cada unoequipoevalúa su atraso
yvueltasqueenunestimaciónconun porcentajeconfianzanivel.Eneste
ejemplo,quetienenequiposconniveles de confianzaque vandel 10% al
90%.Quediceelatrasoartículos no son
lo suficientemente pequeño como para que los equipos calculen un
tamaño razonable. O, que
hay tanto riesgo quelos equipos pueden'tprovideamore preciso
Estimación.
Tal vez quieras saber, "¿Cuándo se hará este programa?"
peroquepuede't saberquesin los equiposhaciendoun poco de trabajo.
Como un equipo de software program, reúnase y evalúe la estimación
total.Haceelprograma de softwareequiponecesidadaañadirtiempopara
obstáculos actuales? Siasí que,añadirtiempo y aumentar el porcentaje
de incertidumbre.
Una vez que el equipo del programa de software tiene algún tipo de
estimación, el administrador del programa tanftwarepuede llevar esa
estimación al núcleoequipo del programa.
Paralelamentea la estimación del programa de software, el equipo

principalnecesita generar sus estimaciones para sus planes.Una veztodo
el mundotiene
estimadoes, el equipo principal puede evaluar cuánto tiempo tomarán

el equipo de asacore. Y, el administrador de programas de software
puede presentar la estimación del programa de software.
Ahora, el equipo principal puede revisar la estimación completa y
generar un número para las personas que pidieron una estimación.
9.4.2 Opción 2: Pida a los expertos que calculen en nombre

de los equipos
Si tiene una hoja de ruta, pero aún no ha asignado equipos de entidades,

considere preguntar a los expertos de la organización.Ellostendrá
estimacióntionsesgo. Usted no sabe cuánto sesgo de estimación tienen.
Pida a los expertos que calculen en nombre de los equipos, utilizando el
mismo enfoque de confianza porcentual anterior.Cuandoqueinformeel
número a la gerencia, explique que usted no sabe cuánto sesgo de
estimación hay en la estimación. Sus patrocinadoresestaríanlibres de
dejar que los equipos trabajen durante un par de semanas y ver
resultados. A continuación, podrían responder a las preguntas:
• ¿Cuánto te gustaría invertir antes de que nos detengamos?

• ¿Cuál es el valor de este proyecto o programa para usted?"
Una estimación de los expertos puede ni siquiera ser un orden de

magnitud correcta.
9.4.3 Opción 3: Usted estima en nombre de todo el programa
Cuando mis gerentes me han pedido una estimación del programa, les
pregunto si tienen una fecha objetivo en mente.Yorecordarellos
quequesontrabajandoincrementalmente,yquepuede cambiar. Les
recuerdo que soy un administrador de programas, y no tengo
capacidad de ver en el futuro.
Les recuerdo que puedo ayudar a los equipos a producir productos de

trabajoa menudo.Pero, preguntándomeparauna fechaesnovaahacer
que ocurran
Rápido.
Si usted dice algo asícon de manera agradable—y dependede su cultura

en cuanto a cómo lo dice—usted puede ser capaz de entender lo que su
patrocinadores o gerentes quieren.Sisu
organizaciónesnuevoaágil,sugerentesno podríadarse cuentaqueelprlos
propietarios de los oductos están a cargodecuandouna
característicaesprogramadoenelatraso.
Nunca permita que una fecha objetivo comprometa la calidad de su
programa. El mantenimiento de la excelencia técnica permite a los
equipos
mantener su ritmo sostenible y seguir liberando,aliado interno y
externamente.
Ambas opciones 2 y 3 tienen problemas.Sicualquier persona estimaenen

nombredelos equipos, los equipos
puedentienennointerésencomprometiendoaesa estimación.Por
quéseríaellos?
Con demasiada frecuencia, los gerentesutilizan las estimaciones que
otras personas crean como un target o "incentivo"para los equipos de
características. Esa es una maneraterrible
para utilizar estas estimaciones. Los equipos no tienen control sobre su
trabajo. Canlos equipos sostienensuritmopara cumplir con estas
estimaciones?Canel
equipos trabajan como equipos auto-organizadores para entregar?
Cuandoalguien más proporciona a los equipos un objetivo, y luego trata
de forzar un compromiso con ese objetivo, usted sabe que MurphyLa
leyesvaasentarse ensuprogramayhaceres imposible paraelequipospara
entregartrabajandocaracterísticasen eldeseadotiempo. Nolo hagas.
9.5 Presente su estimación como

Predicción
Supongo que has experimentado equipos ágiles.Sino,elequipos
hanprobablementeacolchado sus estimaciones. O eso, o las
características son
grandes epopeyas o temas, y la incertidumbre es alta.
Estimación del Programa de Costo 116
Cuanto más experimentados sean los equipos ágiles, mejor será la

estimación. Elmáselequiposson equipos destacados, mejor será la
estimaciónesporque los equipos saben cómoatrabajoy aprender
juntos.Siquesonnuevoaágil,otienen una mezclaprograma(equipos
ágiles y no ágiles),quesaber que la
estimaciónvoluntadsermaneraapagado.
El administrador del programa de software puede decir: "Tenemos
unorden inicial de predicción de magnitud. Pero no
hemosprobadoesta predicción con ningún trabajo, por lo que no
sabemos lo preciso que nuestroestimadoes son.Derechaahoranuestra
confianza essobre5-10%(o lo que sea) ennuestropredicción.
Hemospasado un día más o menos estimando, porque preferimos
dedicar tiempo a la entrega, en lugar de estimar. Tenemos que hacer
una o dos semanas de trabajo, entregar unesqueleto de trabajo, y
luego podemos decirle más sobre nuestra
predicción.Nosotrospuedemejornuestra
prediccióncomoqueproceder.Recuerda,de nuevoeneldías de
cascada,quegastado un
mes estimando y nos equivocamos.Estemanera, usted'llobteneraver
productocomoquetrabajo."
Utilice la palabra "prediction" tanto como sea posible, porque la gente
entiende la palabra predicción.Ellosescucharpredicciones
meteorológicastodoseltiempo.Ellos sabensobrepredicciones
meteorológicas.Perocuandoqueescucharestimacionesde
trabajo,quepensarquesoncorrecto,inclusosi usas números de confianza,
t heypensarqueson exactos.Usoelpalabra
Predicción.
Considere la posibilidad de establecer las expectativas de su

administracióndiciendo: "Aquí
es una predicción para nuestro primer hito (liberación interna).
Podemos proporcionar una estimación mucho mejorpara el próximo
hito." Incremental estimationobrascomobiencomopresupuestación
incrementallo hace.
9.6 Espiral en una estimación
Espiral en una fecha funciona bastante bien para más pequeño, más
corto pro
Gramos. He utilizado este enfoque para programas de cuatro a ocho
meses. Ofrezco "Cuarto 2, el próximo año",como my primera
estimación. A medida que terminamosfea
turesy tienen lanzamientos internos, actualizo la estimación a "Febrero

marzo."Comoqueacabadotrabajoy yopuedevercómoqueentregar,
puedo decir,"La primeraparejadesemanasenMarzo, a sometime."
A medida que terminamos más trabajo, puedo trabajar con el
propietario del productodel programa para ver si todavía tenemos
valorrestante en la hoja de ruta y si
tenemos que pedir a los equipos que trabajen fuera de sus entregables
normales para hacer esa fecha.
9.7 Suministrar una estimación de tres fechas
Ingenioh una estimación de tres fechas, usted ofrece a sus gerentes

esta información:
• La fecha más temprana posible los equipos podrían completar el

programa.Esteesla fecha optimista.
• Una fechamás probable que los equipos puedan completar. Esta
es la fecha realista.
• Una fecha en la que estánseguros de quelos equipos pueden
completar el programa.Esteesla fecha pesimista.
Nunca suministre una sola fecha con suestimación. Esa fecha invita a su
dirección a jugar juegos de estimación con
usted.Cuandoqueproporcionar una estimación de tres
fechas,queinvitarlos a más subsistoy sus riesgos.
Cuanto más largo sea el programa, más lejos deberían estar sus fechas
realistas y pees simísticas. Cuando he usado esto, he dicho,"Debemos
tener un producto general demostrableporJunio1,peroYodon'tcreo que
podemos liberar que uno a nuestra costumbrers. Deberíamos tener un
reasonabledeliverydateofAugust15.IfMurphycomestositonour
programa, no espere un producto liberable hasta el 30 de octubre.
Y,Deberíasercapaz deaactualizar esta estimaciónsiguientemes,
cuandoquepuedetodos
ver lo que los equipos entregan. "
Estimación del horario o costo de Program 118
He encontrado que si establece mis gerentes' expectativas sobre lo que

pueden esperar ver, que entienden este tipo de estimación.
9.8 ¿Realmente necesita una estimación?
He trabajado en muchos programas en mi vida profesional.My

ygerentes dieronmeobjetivosparamanifestaciones, ferias,y
cuando el programa tuvo que entregar. A veces, mis gerentes me dieron
un presupuesto de "no exceder".Nunca me han hecho la pregunta
"Cuánto". Esoes porque el programa entregó mensualmente
demoníacatraciones o liberaciones. La administración podría ver
nuestro progreso. Cuando se trata de entregar productos, si usted
proporciona valor provisional,
la pregunta "Cuánto"desaparece. Su administración confía en que el
programa continúe aportando valor.
Entregar versiones internas. Show un esqueleto andante y luego

mantener
la construcción de pequeñas características. Mantenga los elementos
de trabajo pendiente de clasificación por valor. Sigue preguntando el
"¿Cuánto quieres invertir?"pregunta.
Notendrás que estimar todo el programa.
9.9 Tenga cuidado con esta estimacióndel programa

Trampas
Lare son un montón de trampas potenciales cuando se estiman los

programas.Aquí
• El trabajo pendiente está lleno de temas. Nisiquiera has llegado

a las epopeyas, no importa las historias. Nadie puede hacer un
predic útil
Necesitará más Chinaon tionanairplane. Esaes
como mi toma ",me temo."¿Puedo irdeBostondata: a qué hora
del año? ¿A mitad de semana, fin de semana? De lo contrario,
sólo puedo proporcionar un estadio, no una estimación real.
Cualquier estimación que alguien proporcione
estará apagado por órdenes de magnitud, y usted nosabe cómo

Muchos. Los equipos tendrán que pasar tiempo rompiendolos
en conjuntos de características, tiempo que podrían pasar
desarrollando trabajando
Producto.
• Peor aún, el trabajo pendiente está lleno de tareas, por lo que
noconoce el valor de una historia."Fijarel botón de radio"
nonoexplicarelvalordeuna historia.Tal
vezquepuedeeliminarelbotónen su lugarde la fijaciónque.Túdon't
saber sitienenavaliosoproducto de trabajoenel
finaldetodoseltareas.
• Las personas que estiman no son las que harán el trabajo,
por lo que la estimación está llena de estimatio nsesgo. El hecho
de que el trabajo parezca fácil o se vea duro no significa que lo
sea.Sisuseniorlos gerentes
creenesteestimación,quevoluntadsentirdecepcionados y
frustrados cuando los equipos se toman más tiempo que los
estimadoresesperado.
• La estimación se convierte en un
objetivo.Thesnuncaobras,perohombre agershacerlo todo el
tiempo."Youestimatedit tomaría un cuarto
para hacer este trabajo.Demostrar¡Lo hace!"Algunos gerentes
no entienden que una estimaciónesuna predicciónouna
suposición.
• Las personas en su programa multitarea, por lo que la estimación
es incorrecta.
SeePredictingtheUnpredictable:PragmaticApproaches
a Estimación de Costo o Horario, (ROT15) para más
información.
• Los gerentes creen que pueden predecir el tamaño del equipo a
partir de la estimación.Esteeselproblema dedivisióntrabajo en
elerrorcreencia
quemás la gente hacemás teasiertodomoretrabajo. Más gente
hace que la carga de comunicaciones sea más pesada.
Estimar un programa es más difícil, porque de alguna manera tienes
que añadir estimaciones dispares con diferentesconfidencias
porcentuales.A
mejor manera de manejar los problemas de un programa es decidir si
el programa vale la pena financiar (por valor) en la cartera de proyectos.
Entonces, trabaja de una manera ágil.Belisto para
cambiarelordendetrabajoenel
atrasos, para los equipos y entre los equipos.
Como director de programa, usted tiene dos roles cuando las personas
piden estimaciones: consulte con sus patrocinadores y solicite la
equipos entregan
frecuentemente. Pregunte a sus patrocinadoreslaslasaSestaspreguntas
antes de estimar.
Explicar a los equipos y propietarios de productos los resultados que la

organización necesita:
• Un esqueleto andante (de características en el producto) y

construir sobre él.
• Pequeñas características, para que podamos ver el producto
evolucionar cada día.
Cuanto más thesponsorsver la forma de la toma de producto,

menosinteresados estarán en una estimación general.Ellospuede
pedirparamásespecíficaestimaciones ic (cuándo puede hacer esta
característica específica),queesmucho
el software genera confianza. La confianza

obvia a muchos
necesidades de estimaciones.Sisugerentesoclientes hannuncatenía
confianzaconaproyectooprogramaequipoantes, empezarán a
preguntarparaestimartes. Su trabajo es entregar software de trabajo
todos los días, por lo que
dejan de preguntar.
9.10 Estimación Hacer's yDon'ts para

Directores de programas
Hay varios hacer's y don'ts para la estimación. Estos son algunos

problemas comunes:
9.10.1 Estimaciónno :ts:
• Nunca provide una sola estimaciónde punto. Siqueproporcionar

una solapuntoestimacióndeya sea una fechaodinero,la
gentevoluntadesperar
esa fecha específica o tanto dinero. Incluso si usted está apenas

10% más, ellos pensarán que ha fallado. Hablo en serio.
• Estimando por cualquier persona en nombre de los
equipos.Sicualquier persona estimaparaelequipos,
quetienennorazónacumplir con esa estimación. ¿Por qué lo
harían?¿Lo harías?
• Tratando de hacer cumplir las horas extras para cumplir con una
estimación.Agilese construye
sobre la idea de mantenerun ritmocapaz. Ignora eso a tu
riesgo.
Crearádeuda técnica, perderá la colaboración y derrotará la
idea de autonomía y exploración.
• Nunca permita que los gerentes intenten agregar estimaciones
relativas de los equipos
quiero
deoneworkteamyth
eir
juntosfrogs de. Eseequipode intentos. Youtoadd orangesteams
to at at
propiovelocityorcycletime. Aslongastheycancreatefeatures de un
atraso, note importa lo que llaman su estimación relativa.
9.10.2 Estimación de:
• Escuchen a los equipos. Una vez quete proporcionen sus

compañeros de esti, agradécelos y usa sus estimaciones.
• Planea iterar.Estees ágil.Elatrasosvoluntadcambio,que
significa que las estimaciones cambiarán.Se'ssutrabajocomoel
director del programaaexplicar queasupatrocinadores.
• Las estimaciones caducan.Sisu esponsos piensan que una
estimaciónesbuenoparatodostiempo,desabusar de ellosdeesa
noción.Cadaestimación haunexpiraciónfecha. Ayude a sus
patrocinadores a ver que en lugar de estimaciones, quieren ver el
producto de trabajo.
Formoredetailsonestimatesand whatworksanddoesn'twork, véase
Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost
or Schedule, ROT15.
9.11 Principios de Estimación de la Lista o

Costo
1. Nunca agregue estimaciones relativas juntas ni compare team

es timates.Evaryequipoobrasen un diferenteritmo.Cada
equipo'svelocidadespersonal. Los principios son: "El software de
trabajo es la principal medida de progreso"y "Simplicidad."
2. Utilice un porcentaje de confianza, por lo que todo el mundo
entiende que, especialmente al principio del programa, notiene
idea de cuánto tiempo el programa tomará. El principio es: "Los
empresarios y los desarrolladores deben trabajar juntos."
3. El producto de trabajo es mejor que la
estimación.Construirtrabajandoproducto rápido.Versiproducto
de trabajovoluntadtomar
ellugardeestimacionesparasugestión.Sinecesario,trabajohacia
un objetivofechaopresupuesto.Elprincipioes:"Software de
trabajoesla medida primariadeprogreso."
10. Mediciones útiles en
un ágil y delgado
Programa
Parte de lo que podría necesitar haceren las reuniones del equipo del
programaes preparar el estado de su programapara el resto de la
organización. Es posible que tenga algún tipo de reunión de revisiónde
operaciones. Porque
la organizaciónesperaalgunos progresosensuprograma, es posible que
tenga que mostrar el progreso a las personas que hacen cartera de
proyectos
Decisiones.
Utilice la información de este capítulo para trabajar con sus

patrocinadores y aprender lo que su gestión requiere y cómo necesidad
de mostrar
su progreso de gestión. El software de trabajo es la mejor medida de
progreso.
Cuando su programa entrega elproducto Kingcon frecuencia, usted

construye confianza con las personas que quieren estimaciones o
medidas. Es posible que debarevisar la frecuencia con la que puede
liberar su producto?.
Es posible que aún tenga que proporcionar una tasa de ejecución,o
algún otro informe financiero a esa gente. Ensu mano, no se
preocuparánpor si su programa vale la pena el dinero que han invertido,
pueden ver los resultados cuando ven el producto de trabajo.
El producto de trabajo genera confianza de una manera que cualquier
medida no lohace.Eso puedeserelmejorestadoinformeyoupuede
proporcionar.
Quieres mediciones que signifiquen algo útil en el pro
nivel de gramo. Considere cómo podría explicarle a cualquiera acerca
de lo que el programa ha completado y lo que aún no se ha hecho.
Como siempre, elproducto bestbestmeasurementisworking. Sin
embargo, queno es la única medida que se puede tomar que significa
algo en
123
Mediciones útiles en un programaágil y ajustado 124
el nivel del programa.
El producto de trabajo debe ser su medida

principal.Seescómoquevoluntadverprogreso.
10.1 Lo que Measurements significará

¿Algo para tu programa?
Las mediciones vienen en dos sabores: indicadores predictivos y

retraso
gingindicators. Por supuesto, quieres indicadores predictivos. Tienes un
gran esfuerzo.
¿Qué tienes para un proyecto ágil de un solo equipo? Tienes velocidad,

gráficos de quemados y flujo acumulativo. Canqueutilizar estas
medidasenelprograma?
No se puede utilizar la velocidad en el nivel de programa. Seesnouna

medida predictiva.Aquí'spor qué.
10.2 Nunca use mediciones basadas en equipos para

un programa
Veo una tonelada de medidaen la disfunción cuando se trata de

grandes
Programas. Measurementisone lugar donde se tratade de decir,"Aquíes
lo que hace cada equipo. ¿Qué significa esto para el
programa?"queobtendráenproblemas.
Nisiquiera piense en tomar medidas de equipo de proyectoy
añadiéndolos juntos. Esoes como tomar elpeso de mi marido y elmío,
sumarlos, dividirlos por dos y determinar nuestro tamaño medio de
jean. Sehacesólotanto sentidoatratar deadeterminar
velocidad "promedio"oflujo acumulativo o promedio de cualquier cosa

cuando se hace eso con los equipos.
Cualquier medición basada en el equipo es para que ese equipo lo use
como su guía.
10.2.1 No usar la velocidad como programa

Medida
La velocidad es una medida basada en el equipo. Los equipos pueden

usar la velocidad comoherramienta de diagnóstico para ver cómo les
va. La velocidad noes una buena
medición a nivel de programa.
Uno de los errores que veo mucho es que los gerentes quieren tomar
varios equipos' velocidad y de alguna manera añadirlos juntos. Creen
que esto es una medida del programade velocity.
Nohagas eso. La velocidad es personal para un equipo. Essólo predictivo
para ese equipo y es predictivo para propósitos de
estimación.Se'snotpredictivoacualquierotro equipo. Puede ver lo que los
equipos están haciendo si
son equipos con características, yyouuse aproductbacklog burnup
chart.
Tampocopuede usar la velocidad para predecir el progreso del

programa.¿Por qué?Porque como productopropietariosmejorar en la
fabricaciónelhistorias
más pequeño—y desea quesean mejores en esto—elnúmero de
historias bien puede aumentar por Iteración. Eso cambiará la
Velocidad.
Pero, ¿qué pasa si usted es un administrador de programas o un

propietario de producto y ve un equipo que solía producir
características en ejecución y probadasenun regularclipde repente
lentoabajo?¿Quéhacerquehacer?
La primera es la siguiente: ¿Es importante? Tal vez este equipo está
ayudando a otro equipo.Tal vezquesontan lejos por
delanteensuconjunto de características que
noimporta.Hacerquesaber?
Segundo, ¿eres la persona adecuada para interferir?¿Hayalguienotra
cosa, unproyectogerente, unproductopropietario, un entrenador,oun
Maestro Scrumquepodría llevar una retrospectiva ypreguntarestas
preguntas?Siqueson loscorrectopersona, estas son algunas preguntas
que usted podría hacer:
• ¿Ha encontrado el equipo algún obstáculo recientemente que

haya afectadoa su ability para producir características probadas
y en ejecución? (Ustedpuedeeliminar los obstáculos.)
• ¿Hay alguien en el equipo multitarea? (Asegúrese de
queequipoesdedicadoasuprograma. Ese es un obstáculo que
puede abordar.)
• ¿Ha revisado el equipo sus gráficos de velocidad o el tiempo de
ciclo to
verlo que está
pasando?Avelocidadgráficoociclotiempográficopuedeayudar a
un equipo a resolver sus problemas.(Es posible que el equipo no
se dé cuentade lo que estápasando. Una vez que saben, el
teamcanaddresseste
preocupación.)
• ¿El equipo necesita ayuda de usted?
Espere que el equipo pueda identificar sus problemas. Si un equipo sabe

que tiene un problema y no puedeidentificarlo, puede pedirte
ayuda.Yo'vevistoágilequiposquetrabajadobiencomoequipos
independientes han
problemas para integrarse en un programa. Hasta ahora, todos los
equipos quehe visto hanidentificado sus problemas y han necesitado
ayuda pararesolverlos.
Puede agregar valor sugiriendo maneras en que pueden encontrar

ayuda o adquiriendo la ayuda que necesitan.
10.3 Medida por características, no por equipos
Por lo tanto, tenemos medicionesde equipo queno cuadran. ¿Qué

podemos usar? Medicionesbasadas en características.
Los programas tienen que ver con las características. Eso significa que
usted mide por fea
Ture. A veces, varios equipos trabajan en el mismo trabajo pendiente
compartido.Hacequemateriasiusted mide lo que un equipo¿Lo
hace?Seasuntosparael equipo.Sehacenomateriaparael progrlo soy.
Sin embargo, el director del programa se preocupa por elprogresodel
programa en las características de todos los equipos.Sieltodoprograma
tiene acechoprogreso,comoenequipos quesonnointegrando algo cada
día,
th en's un problema.Sesignifica que usted

podríatienentodosoalgunosdeestos
problemas: demasiadas características en progreso, sin integración
continua, y / o el trabajo en curso en los equipos es demasiado alto.
Entonces, ¿cómo se mide esto? Puede medir "Número de
característicascompletedpor iteración."Por quénohistoriapuntos?
Porque los clientesno compran puntos de historia. Los clientes compran
funciones.Ellossólocomprarcorriendoprobadocaracterísticas. Esoes
todo.
Aquí es donde el programa choca contra la cartera de proyectos.
Ahora, sucede que cada característica es un número de puntosde la
historia. Y,el camino ahacermáscaracterísticases romperelloshacia
abajo en más pequeñorebanadas.Sí, estoesjugando el
sistema.Todosmedidas pueden
ser juego. Allofthem.However,especiallyinalargeeffortsuchasa
program, quieres pequeñas features. Verá el progreso más rápido con
características mínimas comercializables. Por lotanto,está bien si los
propietarios de sus productos comienzan a hacer características más
pequeñas.
Una forma de hacer características más pequeñas es hacer lo que dice

Pawel Brodzinski en El conjunto de características mínimamente
indispensables,(BRO14):
"La razón es que la mayoría de las veces puedo venir al

instante con el lote de trabajo que es un tercio, un quinta
o una décima parte de lo que fue etiquetado como un
mínimo viable
Producto por un cliente potencial y todavía validaría una
hipótesis de negociodetrás de aproduct.Seprobablemente
significa que con
abitofesfuerzoymejorcomprensióndeelcontextonuestrocli
entes serían capaces de reducirlo mucho más allá de eso.
Sepuede significar que'dserinclusocapaz de validar la idea
básica sinescribircualquiersoftware
En absoluto. "—Pawel Brodzinski
Tenga en cuenta que su conjunto de características mínimas

indispensables es muy pequeño.
Cuando empiece a medir por entidades, puede crear pequeñas
ganancias.Cuandoelprogramapuede liberarmása menudo,suel
programa construye
Confianza.
Mediciones útiles en un Programágil y magro 128
10.4 Medir características completadas
Si tiene una hoja de ruta ágil, puede medir el número de características

realizadas y el número de entidades que quedan por completar, frente
al total número de características. Esto proporciona atodos la
oportunidad de ver cuándo aumentan las características, y el progreso
realizado hoja de ruta. Cuanto más pequeñas son las características de
la hoja de ruta,
mejor este gráfico será.
Permitir el aumento de características porque la creación de software

es
sobre el aprendizaje. Comoellos equipos terminan las
características,queysu productopropietariosvoluntaddarse cuenta de
quenecesidadahacerotra cosa. Estábien.
Permítalo.
Gráfico de características del programa
Este gráfico ProgramFeature muestra que thingschange inaprogram.
La hoja de ruta cambiará. Eso significa que los atrasos para el

equipocambiarán. Hazlo visible para todos. De lo contrario, todo el
mundo quiere saber, "¿Por qué nopuedes predecir el costo de este
programa?" Permitirparacambiar y ayudarotrosla
genteentenderelcambios.
Con este tipo de gráfico, puede discutir los cambios inevitables.
Y, cuando la gente te pregunta, "¿Cuánto costará este
programa",puedes preguntarles,"¿Cuándoquieresque reestimemos el
producto
¿Atraso? "
Si sus programas son algo parecidos a los programas en los quehe

trabajado, caen en un par de categorías: elprimeroeseltipoquetienena
porque son críticos para el éxito de la organización. El gran
es que queremos
hoja de rutaesesesescuandovamosamosthedarnthing,soweandbacklog.
Thesecond willadjusttherelease
tlo más maldito tan rápido como sea posible porque necesitamos el
dinero, maldita sea, por lo que tenemos que jugar con la hoja de ruta
yeltrabajo pendiente deobtenerel mayor valorhacia fueradelo
que'rehaciendo.(¿Tiene un tercero?)
¿Has notado el tema común aquí: tendremos que jugar conla hojade
ruta y el trabajo pendiente para obtener el máximo valorhacia fueradeel
programa? Tenga en cuenta que nodije ROI (retorno de la inversión).
No se puede calcular el ROI hasta después de la liberación, por loque no
tienesentido tratar de medir que en este momento.
SumanagementmightwantyoutomeasureEarnedValue.Earned Value es
el valor que obtiene de las características completadas. Conganado
valor, su gestión podría capitalizar la inversión que el programa ha
realizado. Puede mostrar el valor ganado con un gráfico de quemadode
acumulación de productos.
10.5 Measegurar el atraso del producto

Burnup
El siguiente gráfico es el gráfico de quemados de acumulación de

productos. Aquí es donde se toman todos los conjuntos de
características, trazarlos uno al lado del otro en un
gráfico y mostrar cómo se podrían hacer en relación entre sí.
Medidas útilesen un programaágil y magro 130
Retraso del producto Burnup
Esta tabla de quemados de acumulación de productos es lo que

podríamos haber tenido para un productoen el que trabajé hace mucho
tiempo, un sistema de correo de voz.
Cada parte delsistema tiene un equipo de características diferente
working en él.Tuvimosdiferenteequiposparacada partedeelsistema:
Alarmas, Mensajes, Pagos, Ringback,UsuarioAdmin, yCOAdmin.
Teníamos más equipos, pero esta es una versión simplificada del
gráfico. Después de que los equipos trabajaron en el código para cinco
lanzamientos intermedios, esto es lo que
el gráfico parecía:
Acumulación de productos de correo de voz Burnup, después de varias

versiones provisionales
El número de características aumentó con el tiempo para todos

losconjuntos de características. La administración se sorprendió cuando
vieron los requisitos de crecimiento. El gráfico de quemados de trabajo
pendiente de producto muestra el crecimiento de las entidades con la
altura de cada conjunto de entidades en el gráfico.
En cierto sentido, este es un tipo de gráfico de termómetro para cada

conjunto de entidades. Usted puedeverelfinalizacióndecada conjunto de
característicascrecercomo los equipos
entregar código en la base de código.
10.6 Mida el tiempo a su

Entrega liberable
Dado que lo que le importa es un producto releable a nivel de programa,

mida el tiempo para lograrlo. Mida
eltiempoentreentregables.Haceelproducto irderelegableanoreleable?
Este es un indicador predictivo, lo creas o no. Porque usted es

acostumbrado a liberar en un ritál,su pasado tiempo de lanzamiento es
un predictor de su futuro tiempo de lanzamiento.A menos quequesaber
cómoaacortar quetiempo,que'snovaase acortan sinesfuerzo.Usted
puede't obtener
retroalimentaciónenmenostiempoquesutiempoaliberación.Esteesimpor
taciónhormiga al programa.
Si se libera internamente cada mes, y ese lanzamiento es lo
suficientemente bueno para enviar, entonces su tiempo para liberar es
30días.
Si tienes una entrega continua, podrías medir tu tiempo para liberarlo
en horas o minutos.Siquehacertienen un SaaS producto, yqueno están
liberandoenhorasominutos,quepuede tener
unimpedimentoensuprograma. Usted, como administrador del
programa, puede necesitar ayudara
resolver ese problema.
Si sus programas tardan más de 30 días en publicarse, ¿por qué? Eso

podría ser un impedimento para su programa. Cuanto más tiempo
tarde en lanzarse, el tiempo que se tarda en recibir comentarios sobre
el desarrollo del producto equipos.
Cuanto mayor sea su programa, más comentarios

necesitará.Medidaque.
10.7 Medir la frecuencia de liberación
Si su programa comienza a liberar something internamente cada dos

semanas, y algún tiempo más tarde el programa se libera sólo una vez
cada
tres semanas, algo malo ha sucedido.Elequipos podrían haber incurrido

endeudasin nadie realizingque.
Si el programa comienza a lanzarse cinco veces al día y se acumula hasta
liberar cada 20 minutos, es posible que notienen problemasenel
Programa.
Su frecuencia de liberación es una indicación de lo fácil que es liberar su

producto. Desea una frecuencia de lanzamiento internaalta,
independientemente de su capacidad para liberar externamente.
10.8 Medir el tiempo de construcción
Una indicación de que su programa está saludableesel tiempo que se

tarda en hacer una compilación completa o una compilación parcial.
Cuanto menor sea el tiempo de compilación, más frecuentementese
protegerán y compilarán los developers. Cuanto más frecuentemente la
gente se registre y construya, más probable es que
todo la integración continua. Puedes mantener el momento en tu
programa.
Tenga en cuenta cuando los tiempos de construcciónaumentan. O, si el

rendimiento es una tecla fea ture de su producto,tenga en cuenta si
ciertos escenarios han disminuido
rendimiento o fiabilidad. Si usted,y los equiposde entidades,son
conscientes de los escenarios de tiempo de compilación y rendimiento,
todo el mundo puede saber si
algo se rompe.
Mida el tiempo de construcción como

tendencia.Elequipospodríaquieroameasure
construcciones rotas y tiempo para arreglar una compilación como
tendencias, también.Construirlas mediciones de tiempo son una
indicación de que el códigoessaludableono.
10.9 Otras mediciones potenciales

Es posible que deba tomar y proporcionar otras mediciones para sus
patrocinadores o para el equipo del programa.
10.9.1 Medir la tasa de ejecución si tiene un objetivo

Presupuesto
Si tiene un presupuesto objetivo, mida la tasa de ejecución.

Elejecutartasaesla cantidaddesalario y gastos
generaleselprogramautilizacadasemanaoiteración o cadames.
Una nota de precaución aquí: No pida a la gente que realice un

seguimiento de su tiempo por función.Seesrara vezpreciso.
Si los equipos encuentran valor en ese tiempo total de equipo por
característica, pueden medirlo. Podrían medirlo para ver si pueden
hacer que elir
características más pequeñas para que puedan obtener más
rendimiento. Como director de programa, estoy interesado en el
número total de cuánto gastamos por semana o mes, por lo que sé
dónde estamos en relación con el presupuesto objetivo. Esaes la tasa
de carrera.
Eso también le proporciona la excusa para preguntar a todo el mundo,
"Usted'no está trabajando en ningún otro proyecto o
programa,son¿Tú? Porque meestoy quedando con tu salario en este
programa.Así quesique'retrabajandoen
algo más, hágamelo saber!"
La multitarea es un desastre en un programa. Nosinsidiosay ralentiza un
programa a un rastreo más rápido que cualquier cosa que yo sepa.
10.9.2 Considerar el flujo acumulativo, para ver el trabajo en

Progreso
Dependiendo del número de equipos, es posible que pueda ver el flujo

acumulativo o trabajar en progreso.Cuantos más equiposquetienen,
cuanto mástodo este gráfico puedeobtenertambiéngrandespara ser
eficaz.
Cada equipo puedeconsiderar la conmensuración de suflujo acumulado,

paraasegurarse de queno tienen trabajo en curso o inventario.
10.9.3 Considerar un obstáculo a nivel de programa
Puede realizar un seguimiento de un informe deobstáculos, como

sugiero en Administrar su cartera de proyectos, ROT09.
Informe de obstáculos del programa

Sus equiposde entidades quieren saber que está buscando y
eliminando
Obstáculos. Ellossonimpedimentosasuprograma. Losequipos program
también quieren
saber.Comoaprogramagerente,suprimariatrabajoesafacilitarelequipos
que terminansutrabajo.Cuando los equipos de características
ver el progreso del equipo del programaeliminando obstáculos, pueden
ver y sentir su progreso. Ese progreso los alienta a traerte malas noticias
y confiar en ti para eliminar obstáculos.
Cuando haces público el informe de obstáculos, ningún gerente puede
esconderse de su trabajo de eliminación de obstáculos.Ellos gerentes
tienen que comprometerse a ayudar a laprograma.
10.9.4 Considerar otras medidas como diagnóstico

indicators
quieren que los equipos

Si su programa se siente
atascado, sus Ratios de midan
Retroalimentación de Falla como ¡Gestione! su guía para modernos,
en
Gestión de Proyectos Pragmáticos, (ROT07).
Es posible que desee medir el crecimiento del códigoalo largo del

tiempo.Sisus equipos de características don't hacrecimiento, que
podríaseraproblema.Esteesaequipodatospunto.Puede medir el
códigocrecimientoparaeltodocódigobase.Túquerríaaverdondeel
crecimiento del código esmás grandeque
se espera que lohaga yo la resolución de problemas-

noculpar!Personascrecercódigorápidocuandoestán bajo presión.
Aprenda por qué las personas están—o se sienten como si estuvieran—
bajopresión.Hacernoculpaellosparaser
bajo presión.
Si ves una alta proporción de retroalimentación de fallas, busca malas

noticias.Consideremásopcionesen¿CómoLos líderes de los sirvientes
trabajan.
Usted podría querer trackardefectos / característica,aunque usted
tiene muchos,
Sugiero hacer algo al respecto más pronto que tarde. Su deuda técnica
se descontrolarámuy rápido, y reducirá su
Impulso. Remember que incurrir en deuda técnica tiene un costo.Sia la
izquierdasin control, técnicodeudaevitarálos equipos de la liberación
porqueelcaracterísticassonnoen realidadhecho.
10.10 Medir el rendimiento o

Criterios de liberación de confiabilidad
He trabajado en productos donde existían porque pro

videdaperformance o ventaja de fiabilidad sobre sus
competidores.Unomaneraamonitorear esa ventajaesaconstruir las
medidasenel lanzamientocriterios.A continuación, cree mediciones de
productos que le permitan amonitorla competitividadventaja con
cadaconstruir.
"Aprendimos a medir Perfor mance"
Yo era el administrador de programas para un producto de

base de datos. Lo vendimos en función del rendimiento.
Tuve la brillante idea de medir el rendimiento con una
liberación provisional, a mitad de camino a través del
program.
El rendimiento se había degradado, así que éramos mucho
peores que nuestros competidores. No pregunté por qué—
me imaginé que los desarrolladores
y los arquitectos harían eso. Pero pedí que cada equipo
generar pruebas derendimiento automáticas ated que

podríamos ejecutar en cada compilación.Nosotrossabíalo
que el rendimiento necesitabaaser. Si el rendimiento era
demasiado lento, podríamos arreglarlo entonces, no
acumular deuda técnica.
Eso funcionó. Nos enfrentamos con ocho escenarios.

Teníamos a precargado database, para quepudiéramos
hacer las pruebas rápidamente. Los dimos y descubrimos
problemas a medida que avanzamos.
No estabatanpreocupado por los problemas. Yo estaba
preocupado por nuestro no saber acerca de los problemas
hasta muy tarde en el
Programa.
Tener escenarios de rendimiento y ejecutarg pruebas

automatizadascada compilación que representaba esos
escenarios salvó nuestro collec
tushes tive.
—Un Director de Programas Senior
10.11 Cómo responder al "Cuándo la voluntad

Usted se hace / ¿Cuánto va a su
Costo del programa" Pregunta
Si su dirección le pide constantemente fo estimación, no confían en

usted o en el programa. Una solicitud de estimación es también una
garantía mea.Se'suna medición cualitativadesu influenciaen
los gerentes y los equipos. Es una medida de cuánto confía su
administración en usted. Mejor que usted debe kahora, cuando
puede hacer algo al respecto.
De vuelta en Hacer estas preguntas antes de estimar, le sugerí que
preguntara a sus patrocinadores acerca de la inversión o el valor.
Se puede ver que con los enfoques quehe sugerido, el programa siempre
tiene algo que mostrar a sus sponsors. Siempre tienes un
esqueleto andante. Siempre tuviste una demostración en las últimas dos

semanas, o tienes una en camino. Si usted tiene
una hoja de ruta ágil como sugiero, inclusotienes al menos unaversión
mensual, o una demostración.Tiene un producto de
programapropietarioquecontinúatrabajoenelhoja de ruta.
Armado con la hoja de ruta y los datos históricos sobre lo que los
equipos
han entregado, y la tabla de quemados de acumulación de productos,
puede preguntar a las personas que preguntan: "¿Cuándo se hará su
programa?" esta pregunta,"¿Quéesdemayor valora¿Tú?Una
vezquesaber lo queesde la mayoríavalor,podemos trabajar
enqueprimero.Sielatrasoya es
clasificado en orden de valor, podemos tomarnos el tiempo para
estimarlo, o puedo provide una estimación con un nivel de confianza en
un par de
Días. "
Es el mismo tipo de respuesta con la pregunta de costo. El único

problema es si esta gente pregunta antes de quehayasempezado algo.
Esaes realmente una pregunta de cartera de proyectos.
Si su patrocinadorquiere que su programa continúe estimando el
horario o el presupuesto después de haber comenzado a mostrarles
unaentregar
capaz cada mes, pregunte por qué.
• ¿La demostración de su programaes una demostración basada

en características o una demostración de marcos?
Patrocinadores y clientes no'tcomprar marcos. Los equipos
necesitan ofrecer características.
• ¿Pueden sus patrocinadores ver el progreso basado en
lademostración de suprograma, o son los equipos que se
desarrollan como componentes, en lugar de a través dela
arquitectura? Los patrocinadores y clientes no pueden ver el valor
de los componentes. Esnecesario ver las características.
• ¿Hay una fecha objetivo o un presupuesto objetivo que necesite
conocer?Siasí que,puedegestionaraqueriesgo.
Si sus patrocinadores quieren que su programa pase tiempo estimando
en lugar de entregar, puede hacerlo.Enel pasado,
yotienenexplicaredquetodoseltiempo que pasamosestimandoes el
tiempo que don't gastar
Entrega. Sitienes ágiloequipos magrosentregandocuenta con todos

lostiempo,sus patrocinadoresvoluntadentender.
10.12 Principios
1. Medir a nivel de programa, no a nivel de proyecto.Elprincipio
es:"Construirintegridaden."
2. Mide lo que quieras ver.Desea funciones completadas. Quieres
código relegado. ¿Quéotra cosahacerque¿Quieres? Mide eso. No
mida los sustitutos.Elmásusted midee los sustitutos, cuanto
menosusted va aobtener lo que quieres. El principio es: "El
software de trabajo es la principal medida del progreso."
3. Los equipos de características también son responsables de sus
medidas.Ellosnecesidadpara medir lo
quequehacerasabersiquesonvafuerala raiLs
ysiquetienenriesgosensus proyectos. El principio es: "Construir
proyectos en torno a individuos motivados. Confía en ellos para
hacer el trabajo."
4. Pide manifestaciones. Recuerde en el manifiesto, en la página de
principios,hay una línea que dice: "Trabajar tanftware esla
medida primariadeprogreso."Creerque.Elmás funciona su
producto,elmenosmedidas
quenecesidad.Elprincipioes:"Trabajarsoftwareesla medida
primariadeprogreso."
11. Desarrolle a su sirviente
Liderazgo
Las personas mayores en programas ágilesy magros son líderes de

sirvientes.
El propietario del producto del programa, los directores del programa,
el arquitecto del programa son todos líderes de servidor.
Ellosguíaypastorear elnegociovalorde laprograma.Elloscrear el medio
ambiente enquetodos los equipos y equiposmemberspuede
contribuirael producto.
Si no está seguro de lo que es un líder de siervoo cómo cambia su
forma de trabajar, este es el capítulopara ti.
El liderazgo de los sirvientes es un enfoque para gestionar y liderar

donde el líder crea un entorno en el que las personas pueden hacer su
mejor trabajo.Ellíder no'tcontroleltrabajo;elequipolo hace. El líder
confía en el equipo para proporcionar los resultados deseados.
Los líderes de los sirvientes anteponen las necesidades de los clientes,
empleados y comunas. Esto permitequepara crear un entornoenquela
gente vieneprimero.Eso creanegociovalorcuandoquepreguntarparael
resultados que desee.
11.1 Los directores de programa yano
"Conducir"el programa
Algunos directores de programas han utilizado la posición para

intimidar a la gente para que trabaje "más rápido." O,aexigir que el té
ms completar algunas funcionesportrabajandohoras extras.O,quese
comprometería a una fechaofuncionalidad sinelequipos'sabiendosi
eltrabajopodríaserhecho,nuncamenteenesa vez. Uno de mis directores
de programa una vez le dijo a un cliente: "Claro, pueden hacer that."
Nosotrossería
140
Desarrolle su liderazgo de sirvientes 141
han tenido que doblar las leyes de la física en ese

momento.Nuestrocomputadoras eran demasiado lentos entonces.
Cuandoorganizacionorganizationstransición a ágil, el administrador de

programa podría
quieren trabajar como líder sirviente. Sin embargo, es posible que la
administración desee ser comando y control. O, al menos, el control.
Usted podría
dificultades para trabajar como líder sirviente en esta situación. Eso
hace que sea difícil ser un líder sirviente del programa y gestionar
lasexpectativas de los gerentes.
11.2 Consider Su Liderazgo Sirviente
En realidad, puede trabajaren un continuo desde el liderazgo de los

siervoshasta el liderazgo de mando y control.
Tenía un propietario de producto del programa que estaba
"demasiadoocupado"para pasar tiempo iterando en las hojas de ruta
para nuestro programa. Le hice un ping tipo de tiempo para actualizar
la hoja de ruta. Le expliqué que el programa estaba en riesgo.
Tenía otro trabajo que le parecía más importante.
Me preocupaba queno tuviéramos atrasos para el mes siguiente y
ninguna hoja de ruta actualizada. Hice una cita para uno,unocon él.
Tuvimos una conversación cordial. No hay acción en la hoja de ruta.
Lo vi la semanasiguiente y le dije: "Tienes dos días para actualizar la
hoja de ruta.Si no't, yo'llobteneralguienque lo hará.Tú'llestar fuera
el programa. "
Se rió de
mí."Yo'llhacerquecuandoobteneralrededoraque."
Dije,"Don'ttentaciónyo.Dos días."
Los dos días iban y venían. Hice una cita con su jefe y le expliqué que ya
no estabaen mi programa.¿Lo hizoeljefequiero
paraasignar a alguien nuevo,opodríahavemypickofposiblespropietarios
de productos de programa?
Su jefe quería que le diera una segunda oportunidad. No, de ninguna
manera.
Tengo el dueño del producto del nuevo programa. Teníamos una hoja
de ruta actualizada y un nuevo trabajo pendiente.
Podrías pensar que noestaba sirviendo en este caso. No grité ni juré.
Me amito ant-i rolling. Serví a las mayores necesidades de
el programa.
Ser un líder sirviente no significa que seas un intruso.Significa que usted
crea elmedio ambienteenquela gentepuede prosperar
y los equipos de características pueden trabajar con autonomía,
colaboración yeliminación de exp.Sila gentedon'tsaberlo
queahacer,ciertamente no pueden
Entregar.
11.3 Cómo trabajan los líderes de los siervos
En TheCase for Servant Leadership,KEI08, Kent Keithdefinesiete

prácticas de líderes de sirvientes:
1. Son conscientes de sí mismos.

2. Escuchan.
3. Sirvena los quetrabajan "paraellos".(Keith llama a esto
"Cambiar la Pirámide.")
4. Ayudan a otras personas a crecer.
5. Entrenan a la gente, no las controlan.
6. Liberan la energía y la inteligencia de los demás.
7. Trabajan para desarrollar su previsión, para que puedan actuar,
no reaccionar.
Los líderes de los servidores del programa actúan como

administradores del entorno del programa. Ellospodría proteger
laequiposde interferencia. Ellos facili tate el trabajodelos
equipos.Paramásinformación sobre el liderazgo de los sirvientes,
véase Un viaje a la naturaleza del poder legítimo y la grandeza,25th
Anniversary Edition, GRE02.
Cuando pides a los equipos los resultados que deseas, cuando creas el
entorno en el que los equipos pueden entregar esos resultados, y cuando
te las arreglas por excepción, eres un líder de servant.
Asíes comopuede usar estas prácticas.
Nuestros gerentes nos piden que seamos gerentes de programas,
arquitectos de programas o propietarios de productos de programas
porque hemos demostrado nuestra experiencia
competenciaen el pasado.Cuandoquesonautoconsciente,quedon't
necesitaaserel"más inteligente"oelmejorpersona técnica. En cambio,
somos conscientes de nuestras fortalezas y de cómo podemos manejar
nuestras debilidades.
Cuando escuchamos y decidimos que nuestro trabajo es servira la gente
en el programa, lo que importa es cómo la gente puede terminar su
trabajo.Seasuntosque todo el mundo tiene lacapacidadahacer sus
trabajos—queque
escuchar y eliminar los impedimentos.
Podemos ser el líder técnico de alguna parte del programa. Los
arquitectos del programa a menudo descubren que son líderes técnicos.
Unodelas acciones más valiosasparaasirvientelíderesaayudar a otras
personas a usarnuestroexperiencia paramejorarelproductooel
programa. Cuando entrenamos a las personas en lugar de especificar su
trabajo, les ayudamos a aprender y crecer.
Cuando deliberamos sobre cómo crear un entorno en el que las personas
puedan tener más éxito, tenemos dos oportunidades. La primera es que
liberamos las capacidades de todos losdemás.
Puedenserinclusomáséxito.Elotrosesquequetienen la
oportunidadaverelprogramaen su conjunto yactuarantes
deriesgosconvertirse en problemas.
11.4 Algunas personas noquierensirvientes
Liderazgo
Cuando entreno a gerentes y arquitectos para mejorar su liderazgo de

sirvientes,algunas personas dicen: "Pero, algunas personas quieren que
les diga qué hacer. No quieren un líder sirviente. Quieren un
líder al mando. "
Develop Your Servant Leadership 144
Si escuchas eso, revisa tu programa y tu cultura corporativa. ¿Sus

gerentes le dicen cómo trabajar? Si es así, es posible que sientas que
necesitas decirle a los demás cómo hacer su trabajo.Haga
sugerentesculpaqueparahaciendo nieblaakes?Siasí
que,hacerqueculpaella
genteenelprogramasiariesgovieneverdaderooalguien comete un error?
Agile y lean proporcionan transparencia para todo:eltrabajo, el estatus,
quién está haciendo qué.Sisuorganizaciónestodavía culpando a la
genteparaerrores,quepodría haberproblemasserasirvientelíder.
Mi consejo es comenzarprotegiendo el programa.
"Yo soy el Muro Alrededor del Gramo Pro"
Somos un poco ágiles. Tenemos la idea de iteraciones,

yusamos kanban para ver nuestro trabajo en curso.
Nosomos perfectos
para llegara "hecho"todo eltiempo.Y,nuestrogestión
todavíaculpasnosotrossiquedon'thacer sus plazos
impuestos.
Decidí que la mejor manera de servir al programa de
software era proteger a los equipos de características. Le
rogué al producto del programa
para definir entregas provisionales razonables. Y, me gustaría
proteger a los equipos de características de lo que yo llamo
"gestión
Mayhem. "
Mi jefe se acercó a mí a mitad de camino a través del

programa y me dijo: "No creo que su programa está
haciendo suficiente progreso.¿Quésonqueva
ahacerabout¿?"
Le contesté: "Nada. No puedo hacer nada alrespecto.Los
equipos están trabajandoasumáximocapacidad. Necesito
cambiar de opinión y de lasmentes de los otrosgerentes
sobre lo que podemoslograr en un mes. Sus expectativas no
estánen línea con
Realidad. "
Parecía perplejo. Yoarrastradoélmás
deelproductoatrasográfico de quemados y la función
totalquemaduragráfico y explicó que la
gestiónhabíaañadidomásymáscaracterísticas sin
añadiendo más
tiempo."¿Cómorealistaesesto?Yo'vesidodiciendoqueparase
manas ahora,quepuedeañadirlo quequequiero,peroel
totaltiempotiene que cambiar. No somos magos. Puedes ver
nuestro progreso
es constante. Sus adiciones son exponenciales. Esoes una
locura."
Finalmente lo entendió por mis cartas.Elacordó que la
administraciónhabíaexpectativas irrazonables.
Yo era el único con el que hablaba, lo queme hacía feliz. Me
pagan para tratar con la gerencia, no para dejar que las
tonterías rodar
Cuesta abajo. Pude proteger el programa, que para mí, fue
un acto de ershipde sirviente."
—Un gestor de programas de software donde ágil sigue siendo
nuevo
11.5 Bienvenida Malas Noticias
Parte de escuchar es dar la bienvenida a las malas noticias, no sólo a

todas las noticias.
Como directores de programas, preferimos saber que todo va bien.
Pocos programas aceleran a lo largo de los
golpes.Cuandoquehacerquefácilpara que la gente
traigaquemalonoticias,se puedeescucharyverel estado real del
programa.
No puedes estar en todas partes y escuchar todo. Usted, como director
de programas, tiene la obligación de ver lo queestásucediendo en su
programa, buenoy malo. Tu problema: ¿cómo puedes observar lo que
hacen los equipos? Una vezquepuedeverellos,que podríasercapaz
deagenerar varias opciones paraayudando ala gente te
traemalonoticias.
11.5.1 Visitar a todos los equipos, dondequiera que estén
Te recomiendo que visites a los equipos de

características.Siquesontodosenunociudadoenun campus, considere la
AdministraciónPorCaminando por ahí
y Escucha (MBWAL) como en (BCD05). Si la gente sabe queestás

deambulandotodos los martes y jueves (como ejemplo), saben que
tienen unan oportunidad de discutirtemas con usted.
Incluso podría enviar un correo electrónico, "Tengo la intención de vagar
por ahí a partir de las 4 pm del jueves.Déjamesabersi lo
hicieracomomepara pasar por
su equipo y discutir cualquier cosa. "
Si los equipos de características están en todo el mundo, frente alos

equipos que están a distancia de usted al menos una vez al trimestre.
Dependiendo de la duración del programa, es posible que no sea
suficiente con frecuencia. Sí, viajar es tiempo-consumir y puede ser caro.
Es más caro tener
comunicación y defectos insuficientes.
11.5.2 Observa tus expresiones faciales
Todosreaccionamos a las buenas y malas noticias. La forma de

reaccionar puede cambiar la conversación.
"Piensa en las malas noticias como una unidad de opor"
Tuve un programa en el que dos equipos de características

constantemente se perdieron
sus entregables. MarComm wastoobusywith"otrascosas".
Quería arrancarme el pelo.
Un día, cuando estaba cansada, sonrió y frené el ceño en
una reunión del equipo del programa. El propietario del
producto del programa más tarde
me preguntó:"¿Quieres oírmalas noticias?"Dije,"Por
supuesto!""Si no'twatchsuexpresiones faciales,
ustedganó'thear it,"
dijo.
Uhoh.IreframedhowI pensó enbadnewstoanoportunidad de

mejora. Le expliqué lo que hice en el siguiente programa
reunión del equipo:
"Me gustaría replantear nuestras malas noticias en
oportunidades para mejorar. Doy la bienvenida a sus
'malas noticias'y vamosatrabajar
para aprovechar las oportunidades."

Decidí que podía parecer serio, pero no
molesto.Yocomenzóadecir,"Que's una
oportunidadparaproblemaresolver!"
Era cursi, pero funcionó. Escuché más malas
noticiasquepensé que podía soportar, y resolvimos esos
problemas rápidamente.
—Un gestor de programas experimentado
A veces, un cambio en tu mentalidad puede cambiar tus expresiones. A

veces, tu expresión puede cambiar tu mentalidad. Asegúrese de estar
abierto a oportunidades, aunque a veces esas portunidades
operacionales parecen problemas.
11.5.3 Considere un cuadro de correo electrónico anónimo para

Sugerencias
Normalmente no me gustan loscorreos electrónicos anónimos con

sugerencias. Preferiría tener una conversación.Onla otra mano,sila
genteestán teniendo
troubleyquedon'tescucharsobreque,consideraruncorreo electrónico
anónimosistema.Personaspuedea continuación, correo
electrónicosupreocupaciones.
Sitrabaja en un entorno de baja confianza donde necesita un cuadro de

correo electrónico anónimo, es posible que tenga problemas con el uso
ágil para su programa. Usted puede develop más confianza por ser
transparente acerca de su trabajo y entregar con frecuencia. Cuanto
másentregue su
trabajo (arreglar impedimentos, resolver problemas, adquirir recursos
talesaslabs, cualquiera que seasusprogramas), elmássuprograma
confiará en ti.
Desarrollar Ynuestro LiderazgoSirviente 148
11.6 Utilice la mentalidad de crecimiento
Dweck describe la mentalidad de crecimientoen Mindset: The New

Psychol ogy of Success, (DWE07).
Comparación de la mentalidad fija y de crecimiento
Agile y lean se prestana la mentalidad de crecimiento. Losseres

aprenden temprano experimentando y descubriendo lo que funciona y
lo que
no funciona.
Si decides que necesitas entrenar a las personas en el equipo del
programa o en los equipos de características, considera usar la
mentalidad de crecimiento para ayudar a las personas ver que pueden
tener éxito. Es posible que necesiten aprender cómo, y
puede aprender a hacerlo.
11.7 Pregunte por los resultados que desea
La gente vive hasta arriba o hasta sus expectativas. Si esperas a los

equipos
para pedirquepararesolver cada problema, lo harán.Siustedcrea una
jerarquía donde los equipos tienen que comprobarconun cuasi-manager
(como un Scrum Master o un gerente de proyecto ágil), quevoluntad.
En su lugar, imaginelo pasaría silos sayatothe equipos,"Por favor,
resuelva problemas en toda la organización cuando pueda, utilizando
su
redes de pequeño mundo y Comunidades de Práctica. "
Desarrolle su liderazgode Servant 149
La gente hablaba con otras personas. Pueden enviar un correo

electrónico, mensajería instantánea, usar cualquier programa/proyecto
wiki o espacio electrónico que proporcione
Colaboración. No se puedesaber de antemano lo que van a resolver o
no resolver.
Las personas y los equipos todavía pueden nosotrose su director de

programa, Scrum Master, o el director de proyecto para ayudar a
resolver problemas.Pero,cuandoquepreguntarla
gentearesolverproblemas—ydon'tsegundo-adivinar los—que
será. Recuerde, tiene adultos trabajando en su programa. Ellos saben
cómo vestir a loselfos, alquilar un apartamento o comprar una casa, y
criar niños.Ellosresolverproblemasahora.Esperar
hacerlo en el trabajo.
Cuando le pides a la gente queresuelva problemas, puedes magnificar

momen tum en tu programa.
Estas son algunas pautas que he encontrado útiles:
11.7.1 Expectativas de estar atascado
Pida a las personas que definan cuánto tiempo trabajarán solas antes
de pedir ayuda, en sus equipos o en toda la
organización.Misugerenciaparaesta vezes30minutos. Eso puede
parecer tecorto. He encontrado que si la gente spend un sólido 30
minutos que se atascan, como en que no se puede pensar en
unexperimentototryosu búsquedaparauna respuestaesinfructuosas, se
detienentrabajandoenesteproblemay leer el correo
electrónicoonavegar por la web.Ellosgastarmucho más
que30minutosseratascado.
Sino le piden a alguien que empareje o pida al equipo que enrede un
problema una vez quehaya gastado 30 minutos atascados,las
posibilidades aumentan que pasarán un día completo
atascado.Ellosganó'tdecir
nada hasta el stand up,e incluso entonces, podrían ser reacios a decir
cualquier cosa en público.
En cambio, si las personas tienen una directriz sobre estar atascada,
pueden actuar antes de que el día se haya ido.
Usted, como administrador de programas, puede mostrar a otros

cómopedir ayuda. Incluso si nonecesitasayuda, pídela. Cuando se da el
ejemplo, es más probable quelas personaspidan ayuda.
11.8 Principios del Desarrollo de su Siervo

Liderazgo:
1. Confíe en las personas del equipo del programa y en los equipos

de características para hacer su trabajo.Elprincipio
es:"Construirproyectosalrededorindi motivadoviduals. Confía en
ellos para hacer el trabajo."
2. Buscar y quitar impedimentos que la gente no puede quitarse a
sí mismos. Elprincipioes:"Empoderar al equipo."
3. Descubre maneras de animar a los equipos a hacerlo mejor o más
de lo que puedas imaginar. El principio es: "Los mejores
arcos,requisitos y diseños emergen de la autoorganización
Equipos. "
12. Shepherd the Agile
Arquitectura
Uno de los grandes problemas en la gestión ágil y eficiente de

programas es cómo gestionar la arquitectura del
producto.Siquedon'tpastor la arquitectura, youfinhastacon un
desastre.Siquecrear marcosantes dequetiene características,
ustedvoluntadsermal. Usted podría tener sig
reelaboración de nificante (no refactorización) tarde en el programa. La
arquitectura en todo el programa es la forma en que gestionamos ese
riesgo.Usted podría
necesidad defomentar la arquitectura iterativa e incremental, los
arquitectos pueden ayudar a exponer los riesgos y decidir cuándo debe
considerar la arquitectura Historias.
Los riesgos de decidir sobre los marcos por adelantado son

considerables
en un programa.Onelpor otra parte,noarchitla orientación ectural
podríaserun desastreensuprograma. Considere cómo su programa
puede
crear un enfoque iterativo e incremental de la arquitectura. Considere
también cuándo es el momentomás responsable para decidir
arquitectura de productos y los marcos.
De vuelta en ¿Con quéfrecuencia puede liberar su producto?, vio el
potencial de la frecuencia de lanzamiento,en función del tipo
productoque tiene. Ahora, considere cuándo tomar decisiones
arquitectónicas.
151
Pastor de la arquitectura ágil 152
Frecuencia de liberación y el costo de las decisiones arquitectónicas
Cuanto más cerca esté su producto de SaaS, más tiempo podrá esperar
para tomar muchas decisiones arquitectónicas. Es posible que tenga
que hacer
orientación de decisiones arquitectónicas, pero a menudono tiene que
make muchos grandes hacia arriba-decisiones de diseñofrontal. Cuanto
más cercaesté su producto del lado derechodel continuo, con hardware,
más podría tienen que utilizar enfoques de diseño basadosen conjuntos,
o proporcionar más
orientación arquitectónica anteriormente.
El arquitecto del programa no debe decidir solo. El programa archi

tect trabaja con equipos de características y otros arquitectos de todo
el pro gramo para colaborar y decidir cuándo seleccionar qué marcos .
Eso hace que el trabajo del arquitectodel programasea uno de pastorear
el valor comercial del arcohitecta, que es unsocial y colaborativo que
requiere comunicaciones. El arquitecto del programa ayuda a facilitar
la autonomía, la colaboración y la exploración de los equipos de
características.
12.1 Arquitectos escriben código
Si comenzamos con la premisa de que todos losrchitects en nuestro

programa escriben código, comenzamos bien.
En los programas de software, estamos acostumbrados a tener

arquitectos empresariales, de soluciones o de aplicaciones.A
menudo,esosla gentehacernosentarse
Pastor de la arquitectura ágil
153
con los equipos de proyecto. En su lugar,proclaman la arquitectura

desde lejos, al principio del programa.
Esono funciona en orleanprograms ágiles. Itdoesn'tworkinotros

programas tampoco, pero podemos discutir que más tarde, sobre una
bebida de
su elección.
En un programa ágil o magro, el arquitecto es responsabledel valor

empresarial de la arquitectura, no diciendola gentelo queahacer. El
arquitecto del programahace esto de muchas maneras:
• Equilibra los objetivosacortoplazo con el sistema general en

tegrity, riesgo, conveniencia, deuda técnica, cualquier otra cosa
que ustedo usted haríacomerciofueracortotérminoobjetivos en
contra.
• Sostiene el desarrollo frente a la deuda técnica.
Parapruebasystems, estees eledadproblemade pruebas
versusautomatización de las pruebas y cómo automatizar las
pruebas.Yo'mun enormeventiladordeautomatizar lo suficiente y
refactorizarsumaneraenlo quequenecesidad, porquequepuede
que no sepa lo quenecesidadhasta quevercómo evoluciona el
sistema en desarrollo.
• Escribe criterios de aceptación para las calidades del sistema y
los escenarios de calidad para el producto.
• Lidera la definición de cómo se estructura, organiza e
implementa un sistema complejo. Aterrizajezonaspuede ayudar
a guiar este esfuerzo.
• Funciona con un equipo de características de una manera
práctica.Noarquitectos de gaviotas. No hay arquitectos de
PowerPoint, (Consulte Prácticas de un desarrollador ágil para
obtener una excelente descripción de esto, SH06).Sin
profetas.Nopolicía.Arquitectos
ágilesdesarrollarcódigoydesarrollar pruebas.
• Trabaja con los usuarios (o con el propietario del producto del
programa en nombre de los usuarios) para entender lo que hacen
los usuarios, los usuarios trabajan, lo que los usuarios entienden
y no entiendenabo ut elsistema. ¿Cuál es la visión del
producto?(Consulte Desarrollar la visión del programa para
obtener más información.)
154
Los arquitectos trabajan con todo el equipo del proyecto, no solos. Los
arquitectos trabajan en todas las partes del producto, no sólo en las
piezas desafiantes o intercaladas.Enhecho,sinosonrotepartesopartes
aburridas, tal vez
quees donde más se necesita al arquitecto para automatizar algo para
que los humanos notengan quehacerlo.
Inmyworkshopsandinmyexecutivebriefings,Itheirtalentedarchitects,tell
managerstheythingsshouldponera lamayoríade lagente,también
conocidocomoen
impedimentos ágiles o magros. Para los programas complejos, son más

a menudo el sistema de compilación y la automatización de pruebas.
Sugiero que utilicen a los arquitectos para varias iteraciones para hacer
progresos significativos en esos roblemsp, yllegar aalgunosversiónde
hecho.
Software Off Shelf orif
integraciónYoumayhaveCommercialdifferentrolesforthesu
arquitecto,(COTS) especialmente
vendory
ouare
productos suministrados:
• Actuar como editor en jefe para las decisiones de arquitectura

en el equipo.
• Guíaque individual característica arquitectos de equipo que
hacen el trabajo real.
• Ayudar a establecer nuevos productos que se basan en la
arquitectura. Esto significa entender la reutilización y establecer
una visión de cómo la arquitectura evoluciona lentamente a
medida que llegan nuevos productos y vamos. ¿Podemos
cosechar marcos y productos de lo que tenemosahora?
• Ayude a los empresarios a comprender y aprovechar la
arquitectura de las nuevas características del sistema, las rejillas
inte de terceros y las nuevas líneas de productos. El arquitecto
podría usar el
visión del producto para discutir el valor relativo de las
características conlos propietarios de productos y el valor de los
marcos con los equipos de características.
Se puede ver que las personas que tienen la responsabilidad de la

arquitectura shep rebaño el valor empresarial de la arquitectura. Esta
no es la posición tra ditional "Yo'lte digo cómo construirlo porque sé
todo"posición deesa manera también muchos arquitectos toman.
12.2 Muchos desarrolladores se convierten en
Arquitectos
Si los arquitectos escriben código, y si todo el mundo es dueño del

código, y
llegar al producto final mediantela refactorización—que es lo ágil que
funciona—un númerosustancial de desarrolladores trabajan como
arquitectos en un momento dado. Sisus equipos también
emparejanoenjambre sobreelcódigo,no
uno será capaz de decir quién es el arquitecto y quién no. Eso está
bastante bien.
Es posible que necesite un arquitecto del programaque pueda discutir
los riesgos con los empresarios, especialmente en el equipoprincipal.
Un arquitecto de programas actúa comogestor de

riesgos.Ellaesexperimentadoycapaz depara hablar
con los negociosy
gestión con facilidad. S pastorea el valor
empresarial de la arquitectura.
En Evitar títulos jerárquicos, sugerí que nollamaraa un arquitecto del

programa un arquitecto "jefe". Desea que el arquitecto se identifique
con
el programa, no con la jerarquía de la
organización.Cuandoqueusepalabrastalescomojefe, maestro,oEber,
usted creaoreforzara
Jerarquía.
Es posible que los arquitectos necesitenentrenar a otros

desarrolladores, especialmente en cómo crear diseños iterativos e
incrementales,si saben cómo hacerlo.
12.3 Fomentar la iteración y

Arcoincremental cture
Muchos desarrolladores y arquitectos ven el panorama general del

architec ture, antes de escribir cualquier código.Ellossaber dónde
quierenairyquierenaimplementar eltodocaracterística, ahora. Esono es
útil en un programa ágil y magro.
156
En su lugar, solicite que los arquitectos colaboren en la evolución de la

imagen de la arquitectura a lo largo del tiempo.Siquever que tienen
"curlicue",solicitan que los arquitectos colaboren con los equipos para
simplificar el téms y las características.
A veces, esto podría significar que los equipos se dan cuenta de que no
un equipo multifuncional que puede ofrecer valor. Cuando el
los equipos se dan cuenta de esto, se agitaránpara el cambio. Los
directores de programas y los arquitectos de programas sonlíderes
técnicos que pueden
los equipos se reorganizan, si es
necesario.VerElEquiposTenerDependenciasenOtros equiposparauna
explicaciónderecto y
características rizadoras.
Todavía no he visto una arquitectura por última vez desde el diseño

inicial hasta el final de un programa unccolgado.Tal vezquetienen.
Los riesgos de diseñar una arquitectura son demasiado altos para un
programa ágil y ágil.Ayudalos arquitectosaprendercómoacrear
características iterativas e incrementales.
Aquíhay una manera de pensaren la alta tecnología y el diseño de arco

iterativo e incremental. Supongamos que tiene un producto con un nivel
detres
Arquitectura. Las personas tienen una imagen de la arquitectura y
aunque la seguridad impregna el producto, el componente de seguridad
base está en
la capa Plataforma.
A medida que todo el mundo crea características, la aplicaciónafirma

que el componente de seguridad base está violando el principio de
Sorpresa y el
Responsabilidad únicaPrincipio. (El principio deLeastSurprise dice que el
producto debe actuar como los usuarios esperan. ElSencillo
El Principio de Responsabilidad dice que un componente debe hacer una,
y sólo una cosa. De lo contrario, tiene acoplamiento.)
Este es un gran momento para refactorizar el código. La refactorización
del código podría no ser suficiente cuando la seguridad infringe dos
principios. Y, usted podría refactorizar y descubrirproblemas de
performance.Se'stiempoparaiterandoenla arquitectura.
Tiene varias opciones.ConsidereelopcionesenLos arquitectos pueden
157
Ayude a exponer riesgos y romper la arquitectura con propósito.

Nadie podía decir en labegining del programa que laseguridad,como
usted lo planeó,sería unproblema.Elmáselequipos crean
featuresandrefactortopatterns,thelesslikelytheproductwillhave abrittle
arquitectura. Con las características en primer lugar, todo el mundo
puede contribuir a
la arquitectura.
Recomiendocomo parte de los criterios de lanzamiento, los equipos de

características definen cualquier criterio de rendimiento o confiabilidad
para el producto o una pieza de
el producto.
12.4 Los arquitectos pueden ayudar a exponer los riesgos
Aparte del desarrollo iterativo e incremental, el programa unrchitect

puede ayudar a exponer los riesgos.Tal vezque'svale la pena el
tiempoparaunpico arquitectónicoaaprendersobrealgunosáreadeel
producto? De vuelta en Software es Aprendizaje, No Construcción, dije
que podemos aprender
sobre los riesgos temprano para manejarlos.
Algunas características del productoson bastante difíciles de

refactorizar. Estos
incluyecalabilidad, algunos problemas de rendimiento
yconfiabilidadtono sólo tres.Don'tprocedercon características
justascuandoestosatributos de calidad soncríticoa su productoEl éxito.
Una manera de manejar estos riesgos es verificar que su hoja de ruta
tiene un esqueleto andante (también conocido como la bala
rastreadora) enfoquea
desarrollo de características. Cuandoquemostrar equipos de
características y productospropietarioselesqueleto andante,
preguntarán,"¿Cómorápidoesesteparte?" o"¿Cómoesteparteescalade
3¿00 a 30.000 usuarios?"Túahora
las cualidades del sistema para el rendimiento o la escalabilidad.
Puede ajustar las cualidades del sistema a medida que avanza.
¿Y si necesitas saber sobre algunas partes de la arquitectura primero,
porque conducirán otros programas tradeoffs?Túpodría.Para
por ejemplo, en un teléfono inteligente, es posible quenecesite saber el
tamaño de la pantalla
158
porque eso impulsará las decisiones comunes de la GUI y los riesgos de

disipación de calor.
Hay varias opciones para este tipo de un producto potencial prob lem.La
solución queseleccionarpodría dependereneltipodeproducto
usted tiene,basadoensuproducto 'scomplexity. ConsulteComprenderla
complejidad del producto. Estas sonalgunas opciones que podrían
funcionar para usted:
• Haga un proyecto de investigación previo al

programa.Banillojuntos lo suficientela
genteoequiposaprototipoelarquitectura que losla
gentecreerapoyará el productoquenecesidad.Una vezquetienen
suficiente información,elprograma.
• Desarrollar una hoja de ruta arquitectónica integrada con los
hoja de ruta, por lo que crear características y administrar
riesgosturales architec a medida que avanza.
• Integratearchitecturespikeswithfeaturedevelopment.Maybe su
programa todavía puede desarrollar el sistema operativo (la
plataforma), y puede responder a otras preguntas a medida que
avanza.
Cuanto más grande sea el programa, más querrá ver los problemas
arquitectónicos temprano. No puedeshacer eso si no puedesmostrar el
funcionamiento del producto.
¿Quéseríaquetomarparasuprogramaamostrar un esqueleto
andantedetrabajandoproducto? Esa es la pregunta que los propietarios
de productos y architects pueden responder.
12.5 Lo que el Arquitecto del Programa

Realiza todos los días
Los arquitectos lideran haciendo. A veces hacen el trabajo duro para

pagar la deuda técnica queha estado acumulándose durante años. A
veces hacen el trabajo duro de ver cómo las características se
estánresolviendo en un marco eventual, o dos o tres.Y,cuandotienen200
159
o 300 o 400 personas en un programa, en todo el mundo, trabajando en

iteraciones de 2 semanas, es posible que necesite personas que explorar
sólo
por delante de los equipos de feature, para que los equipos de
características sean libres de desarrollar características.
Hay una diferencia entre ágil en un pequeño programa de unos tres

equipos y ágil en programas de más de 10 equipos.Partede
son las rutas de comunicación.Nono importa cuántoquetrya
comunicarse, el programa más grande tendrá más problemas de
comunicación, sólo porque hay más personas.
Coordinar el diseño y la arquitectura entre gramos profesionalesmuy
grandes es una tarea no trivial.Se'sen parte gerenciaal y en parte
gerenciastecnologíanical. Esuntrabajo social yde comunicación.
Consulte Arquitectura es una actividad social.
La evolución de la arquitectura no es un problema que un programa
puede resolver con jerarquía y mantener la agilidad. Y es un problema
difícil de resolver. Las comunidades de práctica pueden ayudar.
Consider estas opciones para el trabajo diariode un arquitecto:
1. Utilice un kanban arquitectónico basado en la hoja de ruta ágil.

Decida qué riesgos quiere abordar la arquitectura ahora y
Cómo.
2. Realice picos arquitectónicos con un equipo de características.
Esto ayuda a un equipo a aprender cómo piensa elarquitecto
sobre los problemas y las soluciones.Enadición,trabajandocon un
equipo difunde el conocimiento de la arquitectura para que todos
puedan trabajomejor.
3. Liderar (y nodirigir) una Comunidad de Arquitectura de Prac tice.
¿Qué quieres que sepa la gente, que evolucionelaarquitectura
de una manera coherente? ¿Qué arquitecturaproblemas¿Quieres
criar? ¿Qué quieren criar y dirigir se dirijan los demás?
4. Proporcionar coaching directo a las personas que lo desean.
5. Trabaje con personas y equipos en todo el trabajo

oganizationpara que entiendan cómo utilizar la arquitectura
actual y cómo
evolucionarlo.
El arquitecto del programa puede explorar los límites de la arquitectura

actual y proporcionar comentarios al propietario del producto del
programa.
Cuando llegueel momento de cambiar losariesenlazados, anime al
arquitecto a trabajar con un equipo, no solo.Todo el mundose
beneficiará. Ver Martin
de no hacer en un proyecto ágil.
Fowler'sWhoNeedsAnArchitect?,FOW03whatarchitectsmightandshoul
d forawonderfuldescrip-
12.6 La arquitectura es unaactividad social
La arquitectura es una guía que permite a los equipos de entidades

desenredar el general—y a medida que avanza el programa—más
específico —patternsandframeworkstouse. Esperamos que las
cosasnocambien una vez que entendamos hacia dónde nosdirigimos.
Sin embargo, debido a que los equipos de feature toman decisiones de
diseño cada
día,sabemos que la arquitectura puedetenertoadaptación,sinocambiar.
manera en que esto es
En lugar de pensar en los arquitectos como las personas que definen
la arquitectura,fomentar. Thearchitectthecan:architectto socialize su
concernsabout
• Utilice Comunidades de práctica para ayudara explorar
alternativas.
• Workwithafeature teamtospikeafeature con implicaciones
arquitectónicas.
• Pregunte y anime a las personas de todo el programa a analizar
las cualidades arquitectónicas a medida que crean
características.
• Evalúe los riesgos y la arquitectura a medida que los equipos de
entidadescrean características.
• Gestione esos riesgos para crear unproducto coherente.
• Pregunte "¿cómo cambió el código? ¿Cómo cambiaron las

pruebas?"cuandodiscutiendo la refactorizaciónyunaprobelán
incrementalachaarquitectura.
• Pregunte, "¿Cómo esta escala de 300 a 300.000 usuarios?," espe
si el propietario del producto desea una escala diferente a la de
cualquier persona esperada.
El arquitecto del programa es un líder sirviente, coaching, influir, y

trabajar a través de la program. El arquitecto del programaaprende de
los equipos y con los equipos—el aprendizaje noes una única-
Actividad.
12.7 Problemas con los que puede encontrar

Arquitectura
¿Qué pasa si los propietarios de sus productos quieren llenar sus

iteraciones con características y usted no tiene tiempoamirarpor
delanteparaarquitectura
¿Cuestiones? Haz tus historias más pequeñas.
Tienes varios problemas aquí. Tiene el problema Feature-it. Algunos

equipos pueden no haber pasado a ágil bien. Sus arquitectos pueden
ser arquitectos de PowerPoint. Feature-it es unaindicación que un
varietyofpeople maynotunderstandhowtodiscussbusinessvalue.
Haceelarquitecto del programanecesidadaserpartedela conversación
sobre Rank ItemsenelHoja de rutao¿Atrasos? A veces, el arquitecto
puede ayudar al propietario del producto del programa a entender el
valor
Mejor.
Considere estas opciones:
1. Si estás usando desitaciones, asegúrate de que las desitaciones

no sean más de dos semanas.Siya son
dossemanas,reducirlosaunosemana.Quevoluntadtienen el
efectodereducir suhistoriatamaño.Cuandoreducirsutamaño de la
historia,la gente se
162
grito, y decir: "No podemoshacer

eso!"Peroquevoluntaddescubrir
ya sea la esencia de la historia, o el equipo va a enjambre
alrededor de la historia. Cualquiera de los dos está bien.Siel
arquitecto puedeayudar areducirellotetamaño, vísperaryone
puede vercómopara evolucionarelproducto
hacia los marcos eventuales.
2. Asegúrese de que cada equipo proporciona unaimagen
actualizada de la arquitectura del producto.Usoel mundo
pequeñoredesahacersegurocadaotrosequipo
veesosimágenesyestá de acuerdocon
Ellos.
3. Pida al arquitecto del programa que dirija algunos picos
arquitectónicos para informar al equipo de valor del producto de
los riesgos. Estos picos también informarána los equipos de
características cuandosea el momento de que
trabajar en esas características.
4. Lidera el esfuerzo para determinar qué es un MVP y cómo crear
un esqueleto de caminar mínimo.
Los arquitectos podrían tener que trabajar con el administrador del

programa para ayudar a crear y utilizar las redes del mundo pequeño.
Los arquitectos podrían tener que trabajar con el equipo de valor del
propietario del producto para ayudar a crear
suficientes características o MVP para mostrar el progreso. Los
arquitectos pueden trabajar con equipos de características para
comprender los riesgos de una alternativa sobre otra.
¿Pueden sus arquitectos trabajar como líderes de siervos, centrándose
en el valor de la arquitectura en lugar de en lo que creen que laarciture
requiere?Estepodríaserun fundamentalpapelcambioparasus
arquitectos.
¿Cuándo deberías considerar las historias tecturales de

Archi?
A veces, el propietario del productonecesita aprender acerca

de las compensaciones para el producto. A veces, los equipos
necesitanque alguien haga un picoectural arcado para
entender los riesgos y el valor de implementación de una
manera u otra.
163
Tenga en cuenta lo siguiente al componer historias

arquitectónicas:
Cuando experimentas,tienes un objetivo de aprendizaje

específicoen mente.You aprender a
gestionareldesconocidosoriesgos. Usted podría
no desea más desarrollo de características hasta que
entienda las compensaciones de diferentes arquitecturas o
marcos.
Este es un trabajo diferente a una historia que comienza, "Como

desarrollador"
o "Como arquitecto." Cuandoquetienen historias
arquitectónicasopicos,quetienenaespecíficosaprenderobjeti
voque beneficia
alguien, no sólo un desarrollador o arquitecto. La ventaja es
para el usuario.Hacerquieresaaprendersobrerendimiento
antes dequecomprometera una arquitectura
particularodesign?Suhistoriapodríaseralgo como
esto:"Como usuario experimentado, quiero
para saber que mi búsqueda se completa en menos de un
segundo." Ustedpodríatienen pruebas que prueban una
variedadde tipos de búsqueda, los resultados se devuelven y
cómo elbúsquedaobrasdadounotamañodedatos de und
otrotamañodedatos. A continuación, los equipos pueden
explorar porque el propietario del producto(tal vez
trabajando con el arquitecto) limitó el problema.
Las historias arquitectónicas noson el problema.Historias

quehacernoentregarvalorson el problema. Asegúrese de que
todos los
yel valor de la entrega.
12.8 Romper la arquitectura con

Propósito
A veces, los equipos continúan a través de su trabajo, evolucionando la
diseño de características y la arquitectura general. Los equipos se
encuentran con un punto de decisión. Para citar a Yogi Berra, "Cuando
se llega a un tenedor en
el camino, tómalo!"
Las personas en el programa pueden darse cuenta de que para

implementar esta característica, necesitan romper el patrón de
diseñoaactual. Ellospodría darse cuenta de que
tienen que cambiar lacalidad de un arquitectoural por otro. O bien,

podrían decidir que necesitan alguna exploración para entender el costo
o
duración de alguna función o conjunto de entidades.
Es hora deexplorar algunos diseños de la

competencia.Aquísonalgunosopcionesconsiderar:
1. Pida al arquitecto del programa y almenos a un equipo de

características que desarrollen las preguntas que el programa
necesita responder.Sonquetratando
deacomerciofueracualidades arquitectónicas(tamaño,
rendimiento o usabilidad como tres ejemplos)?
2. Inicie un experimento de arquitectura. Lo que sucedesiquetratar
dequede esta maneraasopuestoaelmanera
actualquesonhaciendo¿?
3. Considere losdiseños "competidores"de diferentes equipos de
características.
En cada caso, el arquitecto del programa trabaja con los equipos para
desarrollar las respuestas que el programa
necesita.Elprogramaarquitecto
podría liderar la exploración como un líder sirviente.
Cuando digo diseños "competidores"de diferentes equipos de
características, la idea es evaluar los pros y los contras de los diseños,
noentregables del equipo. Ciertamente, no compare los equipos.
Su programa podría decidir romper el architecture. Mientras entiendan
sus objetivos, las preguntas que quieren responder y su trabajo, esto
puede crear mejor arquitectura y diseño para su programa. Pida a los
equipos que gestionen los riesgos e informen a menudo sobre su
progreso.
12.9 Principles de Shepherd the Agile

Arquitectura
1. Integre la arquitectura en lo que hace cada equipo, todo el
tiempo.Los principios son:"Las mejoresarquitecturas, requisitos y
165
diseños surgen de equipos auto-organizadores" y "Decidir en el

momento más responsable."
2. Cuanto más grande sea el programa y más complejo sea el
producto, más tendrá queconsiderar alguna ex ploración de
mirada anticipada. Los principios son: "Amplificarel
aprendizaje"y "Construir integridad en."
3. Espere que la arquitectura change. Pida a los arquitectos que
aprendan de los equipos de características, así como de los
equipos de características que aprenden de los
arquitectos.Elprincipio es:"Atención continua a losexcelenciay
buenodiseñomejora la agilidad."
13. Resolver problemas del programa
Como administrador de program,usted tendrá un montón de

problemasdel programa para
resolver.Túvoluntadtambiénnecesidadaayudar aequiposidentificar sus
problemas.Comoun líder sirviente,quequieroaayudar a la
gentetraerquemalonoticiassinsensaciónamenazadooenriesgo.Deje
quesus equipos saben quequesonnopara ayudarlesconsus
obstáculos,conocidoodesconocido, ynonoaculpaocastigarlos. Tus
equipos te traerán sus problemas antes cuando lideres así.
13.1 Preguntar por los problemas o

Impedimentos Primero
Cuando un equipo tetraiga un problem, haz estas preguntas:
• ¿Cuál crees que es la causa del problema?

• ¿Qué has intentado ya?
• ¿Tiene impedimentosyouneedme/elequipo del programa/el
equipo principal que desea eliminar?
Notienes que hacer estas preguntas en este orden.Sisus equipos son

cualquier cosa likeella genteYo'vetrabajadoconenelpasado,
hanunideadelo queelproblema es. Han probado algunas
soluciones.Ellosnecesidadyoutohelp de alguna manera:Tal
vezqueneedsomeextraservidores.
Tal vez necesite un equipo de lanzamiento/implementación. Tal vez sea
otra cosa.
Una advertencia: Nunca digas, "Nometraigas un problema sin un solu
tion. " Que's una gestióntrampay te impidededescubrir
y solucionar los problemas a tiempo cuando podrían ser
podría necesitar ayudar al(los) equipo(s) a hacer análisis de causa raíz,
166
Resolver problemasde gramoPro 167
retrospectiva, o lluvia de ideas de múltiples opciones si están atascadas.

Su trabajo como líder de sirvientes es ayudara desenredar el equipo.
Faciliteque las personas le traigansus preocupaciones.
De vuelta en la integración continua y pruebas soporta Collabora tion,
expliqué mis pautas para tratar de manejar problemas y eliminar los
impedimentos.Estas son algunas pautas
paraelprogramaequipoproblemase impedimentos:
1. Pregunte por el resultado que desea.

2. Supongamos que cada persona entiende su problema mejor que
tú. Pídale a esa persona que se lo explique a usted, o al programa
Equipo.
3. Utilice la regla de tres para cada soluciónpotencial. Ver detrás
Puertas Cerradas: Secretos de La Gran Gestión, BCD05 para
obtener más información sobre cómo utilizar esta regla para la
gestión prob lems.
4. Pida ayuda al equipo del programa para generar las soluciones
a estos problemas.
5. Nunca impongas una solución.Sinounoesdispuestoavoluntario
paratratar deuna solución, supongamos que'snorazonable.
Vuelva a la mesa dedibujo.
Algunos de los equipos necesitarán diferentes soluciones iniciales.

Algunos equiposnecesidadayudar a hacer sus historias más pequeñas.
Algunos equipos necesitarán
ayudar a aprenderaenen sus características, por lo que
terminancaracterísticas anteriormente en la
iteración.Queconjuntoscada equipohastaparaéxitopara
integración continua.
Pero esos impedimentos might ser sólo la punta del iceberg para su
Equipos. Una vez que empiece a generar algunas opciones, puede
empezar a ver cuáles son los costos, y puede empezar a comparar el
valor de esas opciones.
Anime a los equipos a experimentar con sus posibles soluciones,

especially si su programa está en la parte compleja de la Cynefin
Resolver problemas delprograma 168
Marco de referencia. Es posible que usted y los equipos no se den cuenta

de cuál es la solución "perfecta"(si existe). La experimentación con la
medición ayudará a las personas a darse cuenta de lo que they podría
hacer para resolver el problema.VerInvitarPersonasaExperimento.
13.2 Las personas en el equipo principal noentregan lo que

prometen
Cuando las personas delequipo principal no entregan, ponen en riesgo

todoel programa.Túpuedeexplicaresto cuandopreguntarellospara
commitments,comoenCuidadodeOlvidarNúcleoMiembros del equipo.
Tal vez tengas a alguien demasiado veterano,que puedafuncionar anivel
de programa.Tal veztienenalguientambiénjunior,quedoesn't
hanelcapacidad de hacer el trabajo o elinfluenciapara completarlo.
Usa un meeting uno-a-uno,como en Behind Closed Doors: Secrets of

Great Management, (BCD05), para que puedas aprender lo que está
sucediendo para esa persona en el trabajo, y usted puede resolver
problemas juntos.Hacerno esperararesolveraproblema de personas que
no entregan enapúblico
Reunión.
Usa tuapoyo de liderazgo sirvienteempatía y conciencia para resolver

este problema. Podrías necesitar ayudar a alguien a aprender a dar a
luz. Tú
podría necesitar pedir a alguien diferente para su equipo de programas.
Es posible que debas tener una conversación conel gerentede esa
persona o con el tuyo para resolver el problema.
13.3 Los propietarios de sus productos tienen

Feature-it es
El largometraje es cuandolos propietarios de productosdeciden que

sólo quieren saber acerca de las
características.Elproductopropietariohacenoquieroarango técnico
deuda, defectos, cualquier cosa que pueda interrumpir el flujo de
features.
El problema es este: a menos que tenga un producto nuevo, está

obligado a tener deuda técnica en cualquier número de áreas y ya
existentedefectosquetienensidoalrededorparaaños.
Puede optar por ignorar ese trabajo.Túpuededecirlos equiposaignorar
ese trabajo.Cuandolos equipos
abordandeudaydefectos,quearreglarcosasahacerquemás fácilparael
equipoatrabajomás rápidoenelfuturo.Sisu
productopropietariosquieroignorarsoluciones, quevoluntadralentizar el
equipoEstumecantes.Siseveproducto ralownersdoesto, su programa
puede chillar hasta detenerse.
¿Qué puedes hacer en su lugar?
Asegúrese de que las historias que los propietarios de productosescriben
con los equipos son pequeñas. A veces, los propietarios de productos
quieren ignorar el trabajo de fijación porque piensan que los equipos
gold-plsecomieron las características.Elmás pequeño
la historia, menos probable es que alguien va a la placa de oro.
Si sus equipos entregan historias en el producto todos los días más o
menos, el propietario del producto puede ver si el teamisgold-plating.
Cuando el propietario del producto confía en el equipo, el propietario
del producto puede relajarse sobre el problema
de la clasificación de la deuda técnica y defectos.
En cuanto a los equipos, a menos que tengas una razón para crear
deuda sórdica,
la deuda baja. cuandoel
diles que no quierespagartepuedes tenerdeuda. Pero,
entoncesdecidirSiustedtieneaplazo corto plazo,teamcun
Los equipos no deben crear defectos a medida que terminan las

características.Ellosnecesidadaobtener la característicaahecho.Silos
equipos pueden'thacerque, necesitanaentender lo quesuproblemasson,
y la direcciónellos.
Los propietarios de productos debenrevisar el trabajo pendiente de la
debt técnica y los defectos, además de las características de la hoja de
ruta. Los equipos necesitan una manera de mantener su código y
pruebas saludables.
Discuta el valor empresarial de cada elemento del trabajo pendiente,
no solo las características.
13.4 Las personas en los equipos son multitarea
Si tienes personas multitarea en tu programa y otro proyecto, tu

programa se retrasará. Túvoluntadincurrir enaCosto
deRetrasoquevoluntadafectancuandoquepuede liberar todo el
producto.
Los equipos necesitan aprender a administrar el trabajo de soporte en
su kanban o in sus
iteraciones.Siproductopropietariosquieroaequipoa"hacermás,"
elsólomaneraahacerqueesahacerelhistorias más
pequeñas.Conhistorias más pequeñas,que'sposibleacabadoy mantener
unaritmo,un ritmoasutrabajo.
Si los equipos tienen una tonelada de apoyo work para un producto
lanzado anteriormente que noes parte de esteprograma, queesun
riesgo para su
Programa. Es posible que tenga que abordar eso con las personas que
quieren el apoyo.
¿Tienes gente en otros proyectos?Queesasigno de una
gestiónteestoyqueesno gestionar el proyectocartera.Siqueson tasa de
ejecución de seguimiento, esteesun enormeproblema.Su
programaespagar (en silencio)paraotrosproyectooprogramatrabajo.
He hecho estas cosas en el pasado:
1. era un problema.
multitareaMedidolos gerentes de
CostofDelaysomyentendidopor
2. Preguntó a los equipos acortar sus desliteraciones, así que sólo

podrían comprometerse con un número menor de historias. Les
pedí que rastreaeran
nuevas historias a las que no se habían comprometido. Traje esos
datos conmigo a lareunión del Comité de Operaciones y le
expliqué por qué el programa llegó tarde. Esto proporcionaba la
transparencia que necesitábamos.
3. Pidió a los miembros del equipoque vinieran a mí si alguien quería
que hicieran algo que no estuvieraen el programa. A
continuación, tomaría la solicitud y la evaluaría.
Es posible que tenga otras opciones.Su primeratrabajoespara hacer la

multitareaingtransparente.
La multitarea ralentizará tu programa y evitará que las personas
progresen. Nolo permitas.
13.5 Cómo iniciar un programa con más personas de las que

necesita
Empiezasaprogramar. Su organización reconoce que tiene

un programa. Su equipo de administración se asegura de que tiene
todas las personas que necesita en este momento.Y,suprograma no
eslistopara
Ellos. Su programa eventual de 150 o 200 personas no necesita más que
un par de equipos de 5 a 7personas en estemomento, tal vez incluso
menos.¿Qué¿Lo haces?
Pida a la gente que se autoorganice en equipos multifuncionales

ubicados.Siquesontrabajandoenextensionesaun ya
existenteproducto,preguntarellos para seleccionaraatrasodefectos
deeldefecto trasistema de cking. Su trabajo en las próximas dos
semanas es: 1, corregir los defectos;y2, determinarlo queno tienen
comoaprocesooherramientasparaprocedimientoparael
programa.Siqueestán trabajandoenamarca
nuevo producto, pídales que trabajen enun producto ya existente con
las mismas herramientas que utilizarán para el nuevo
producto.Siquevoluntadsertrabajandoenuna
marcanuevoproductoconmarcanuevoidiomasyherramientas,
pregúntelesacrear el equivalentede"HolaMundo"conelnuevoidiomas y
herramientas.
Tal vez descubranque tienendeuda técnica en pruebas unitarias o del
sistema. Eso significa que la deuda técnica va en el trabajo pendiente
del programa, en la parte superior. Tal vez descubren que notienen
acceso suficiente al sistema de compilación o al sistema de control de
versiones. Es bueno saber ahora, antes de que setoque en las
características. O bien, descubrirán que necesitan formación o nuevas
máquinas o licencias para las nuevas herramientas. Es bueno saberlo
antes de que empiecen en serio.
Tal vez no puedan crear equipos multifuncionales

combinados.Ellosobteneradicidecómo
organizarse,odecirqueoaproyectogerente quequetienen
unproblemaquenecesidadayudar aresolver.
La idea es que al final de las dosprimeras- iteración de la semana, usted
sabe donde el conjunto inicial debasado en el
equiporiesgosson.Cadaproyectoyprogramlos tiene.Elmás
grandeelprograma,elmásesos riesgos se escondenasí queMurphy puede
saltarellosen tisólocuando no'tnecesidadellos. Cuando tengas a todos,
deja que todas esas personas descubran los riesgos para
ti.Ahoraquetienen forrajeparasuriesgolista y los equipos
conocer sus impedimentos. Todos ganan.
"Considerar un Hackathon"
He tenido "exceso"miembros delequipo hacer un hackathon

para empezar a construir enfoques de prueba
automatizados y arneses, prototipo
nuevas formas de llegar a la funcionalidad deseada, tal vez
iniciar la canalización de entrega de Continuous. Hay
muchas cosas que estas personas pueden hacer para
beneficiar el programa.
—Paul Ellarby, director delprograma
También podrías hacerHudsonBayStart,asinManageIt! YourGuideto

Modern, Pragmatic Project Management, (ROT07) en el propio
programa.Peroquealla mayoríasin dudano es necesariotodos200
personas paraeso.
Hagas lo que hagas, nodejes que todas esas personas obstaculicen el

programa
progressbystartingonel programa—a menos querealmentepuedas
usarlos
todo.
Como parte de esta primera iteración, pida al propietario del producto
del programa que cree una hoja de ruta ágil y un trabajo
pendiente.Enmiexperiencia, muy pocosprogramapropietarios de
productossonlistoconunhoja de ruta ágilenel
inicio del programa.Peroanotienencualquieridea de dónde¿Te
vas?Nobueno.
Si empiezas con Iteration Zero, puedespasar tu vida en

IterationZero,IterationMinusOne,andsoon. Esamuerte para tu
programa. Me gusta pasar un día más o menos empezando. Pero no
mucho más.Inclusoparagrandes programas. Las personas necesitan
reconocer la urgencia de
comenzando y entregando.
Once el propietario del producto del programa tiene la hoja de ruta ágil,
todos los propietarios de productos pueden trabajar con este
propietario del producto para generar el primer clasificado retraso para
todos los equipos. Ahora, al final de la primera iteración, el programa
tiene estos entregables:
• Todo el mundo sabe queaquí tienen deuda sin unidad es ni en
pruebas del sistema.
• Todo el mundo sabe si tienen herramientas adecuadas para
trabajar en el producto.
• Si están distribuidos geográficamente, saben si pueden
comunicarse entre sí.
• El propietario del producto del programa tiene unahoja deruta
gile.
• Los propietarios de productos han clasificado los atrasos para
sus equipos.
• Los equipos han practicado trabajar juntos, liberando algo.
• El equipo principal ha completado la carta del programa, por lo
que los equipos ahorasabenlo programvisionandreleasecriteria
Son.
Nohay mal tiempo durante dos semanas, ¿verdad?
13.6 Principios del Programade Solveción

Problemas
1. Asegúrate de saber qué está pasando con la gente detu equipo

de programa. Utilice uno-encendido-lospara resolver problemas
en privado. El principio es: "La conversación cara a cara es el
método más eficiente y eficaz para transmitir información."
2. No inicie un programa con más personas de las que

puedeplanificar
para el principio. Encuentra a esas personas para que
contribuyan mientras te preparas.El principioes:"Construir
integridaden."
3. Haga quesu equipo del programa pueda reunirse en persona
para aprender
cómo trabajar juntos. El principio es: "Cara a cara conver
sationisel método más eficiente y eficaz de transmitir
información."
14. Integración de hardware
Into Your Program
Cuando su producto tiene mássoftwaret han— tiene

componentes de hardware—es posible que no vea cómo utilizar
enfoques ágiles y lean para ver el producto evolucionar y obtener
comentarios al respecto.Tú
podría no serableusoagileandleanexterno,paralos clientes. Es posible
que solo pueda utilizar ágil y lean internamente, para ayudara crear el
mejor producto posible.Puede utilizar los principiosdeágil y ágil
ymagraaver el producto yproporcionarretroalimentación,
utilizandodiseño,
integración temprana, y ver demostraciones de todo el producto tan
pronto y a menudo como posible.
Lo único que'es inherentemente secuencial con partes que no son de
software de un producto es cuando están listos paraforma
física.Cadatiempo elingenieroscrearun físicoformularioparauna
parte,quecuesta dinero. Ese dinero se denomina gastos de ingeniería
norecurrente(NRE).
Los NREs son parte de los costos de su programa. Usted, como

administrador de programas, podría tener que gestionar esos costos,
así como cualquier otro costo que tenga. Esposibleque esos costos sean
un riesgo para su programa.
14.1 Los riesgos de hardware son diferentes

Riesgos de Software
Eldesarrollo de productos de hardware y software se enfrenta a riesgos

comunes:
• Quizá no sepamos cómo resolver el

problema.Nosotrosnecesidadmásinvestigación antes del
desarrollo.
175
Integración de hardware en su programa 176
• Es posible que tengamos que iterar para entender la mejor

manera de resolver el problema.s).
• Necesitamos obtener retroalimentación con la suficiente
frecuencia para saber si estamosresolviendo los problemas de
una manera que funcione.
Los riesgos asociados con el hardware son diferentes de los

asociados con el software. El "problema"con el hardware es que los
ciclos de hardware no son homogéneos. Es decir, los riesgosdel trabajo
mecánico están en un ciclo diferente de los riesgos dedigital
Trabajo. Los diferentes tipos de hardware iteran con simuladores en
diferentes momentos.Ellosir a físicoformularioendiferentetiempos.
Una pregunta importante para su programa esla siguiente: ¿Obtendrá
algún beneficio de la forma física temprana y a menudo para el
aprendizaje? El programa
incurrir en más costo. ¿Vale la pena el valor?
14.2 Comprender el costo y el valor de

Hardware
BackinSoftware isLearning, Not Construction, discutí la idea de que el

software está aprendiendo, nunca la construcción. Gran parte del
desarrollo de hardware también está aprendiendo.
Además del aprendizaje, parte del desarrollo de hardware está estando
listo para la fabricación, para la fabricación de eldiseñofinal.
Enprogramas de hardware altamente complejos, el diseño para la
fabricación podría sersupropiopequeño programa.
Debidoa que aprendemos mucho cuando nos casamos con el software
con el hardware, una pregunta es la siguiente: Cuando es el momento
adecuado para empezar a desarrollarprototiposfísicos? El prototipo
costará algo. ¿Quées elvalorelprogramapodríarecibir dequeaprender?
A menudo, los equipos de hardware y software utilizan eldiseño por
contrato para
determinar qué hacer donde—la interfaz entre el hardware
y software. Elantes el hardwarela genteentregarprototipos,elmás

rápidoelequipospuedeaprendersi el diseño es correcto. Los equipos
acortan los bucles de retroalimentación.Esque el
aprendizajevalorelcostodeel prototipo?
Una formade pensar en estevalor es considerar el costo del retraso.

¿Cuánto tiempo más setardará en terminar el producto si el software
los equipos no puedencomenzar hasta que el hardware está hecho?
¿Qué sucede si el hardware tiene que revisar sus diseños en función de
loscomentarios del software? Considere la
preguntas en Integrar hardware a menudo.
Estees un ejemplo de cómo considerar los costos. Imagine que tiene un
equipo de hardware y tres equipos de software, un programa
relativamente pequeño. ¿Cuál es el costo para que usted espere hasta
el noveno mes
de un program de doce mesespara un prototipo?
Tal vez sus prototipos cuestan $10,000 cada uno. Supongamos que
obtiene dos prototipos, uno para el equipo de hardware y otro para
compartir con los equipos de software, un total de $20,000.Deje
queSupongamos quequeencontrarenmenosdosproblemasenel
primersemanaque crean unretraso de una semanaensu programa.
Supongamos que la gente cuesta $75/hora de trabajo cargada. Tiene1
personas en los equipos de software y cinco personas en el equipo de
hardware.Que'satotalde 21$7540 paraauna semanaretraso:$63,000.
Compare ese costo con la iteración anterior en el hardware.

No tengo idea de si puedes crear un prototipo por
$10,000.SuNREspodríasermucho más alto.Se'sposible que
unchippodríacostohacia arribade$1.000.000y tomar
enmínimo,seissemanas. En ese caso, consulte algunas alternativas en
Administrar riesgos de hardware.
Si tiene un programa de unos 12 meses, ¿necesita ver un prototipo físico
antes de la los últimos tres meses, un tiempo tradicional para el
prototipo y luego el piloto? Depende de tus riesgos.
Incurrirá en algún tipo de costo (NRE) siempre que tenga

el material va a la forma física. La pregunta es la siguiente: ¿Cuál es el
valor de esa forma física para el programa general?¿Quéson
losriesgosdeiterando enfísicaforma?
Recuerde, si va a la forma física antes, es posible que

terminar el programa antes. Estose debe a que el producto es suficiente
tal como es.Quedoesn'tsuceden a menudo, pero sísuceden.
14.3 Comprender elvalor de cada parte
Supongamosque está desarrollando un robot.La máquina tiene

mecanicalbrazos, una boa
personalizadardconelrobot'soperandosistemaenque,
y un FPGA (Field-Programmable Gate Array) para personalizar elusodel
robot para usted.
Usted tendrá estos componentes de ingeniería para su robot pro
gram:
• Trabajo mecánico para crear los brazos

• Tablero de silicio
• Sistema Operating
• Fpga
Los equipos de softwarepuedencrear el sistema operativo de forma

inanágil, porque el sistema operativo es todo software.Sin
embargo,eloperatingsistema tiene interaccionesconeljunta,la FPGA, y
cómo el
trabajo de armas. Los equipos de software no puedenesperar aque los
equipos mecánicos y deingeniería completen su
trabajo.Elsoftwareequiposnecesidad
para empezar a trabajar ahora.
Ninguno de los componentes tiene mucho valor por sí mismos. Sin

embargo, tienen un enorme valor cuando todos trabajan juntos.
La hoja de ruta del producto escupiráel valor relativo de cada compo
nent.Los equipos necesitan la hoja de
rutaadeterminarcuandoatienencada uno
componente y conjunto de características de cada componente listo
para los otros equipos.
Esto es complicado.Ellos equipos necesitanaentregarel más
importanteyvaliosocomponentsprimero.Aquíeslo que una hoja de ruta
del primer trimestre
podría parecer. (Mi experiencia robot es bastante antigua, así que esta
es una hoja de ruta inventada.)
Hoja de ruta ágil de un trimestre para un robot
Debido a que el mechanical, eléctrico, FPGA, y el software no

puedeninte rejilla desde el principio, esta hoja de ruta se parece un
poco a un kanban con swimlanes. Puede que no te guste esta hoja de
ruta. Es posible que desee organizar su hoja de ruta de alguna otra
manera.Aquísonelprincipios
I Utilizado:
• Haga que las interdependencias sean transparentes.

• Demostrar el producto tan pronto comosea posible, incluso si
esa través de una tabla deplanchar.
Tenga en cuenta que parte del hardware básico y el trabajo mecánico

toma sólo una iteración de dos semanas.Sielproductopropietariose da
cuenta de que elworkvoluntadtomar más tiempo—tal vezella genteque
hacenelpartes de laequipoesperadoutilizarnomás tiempoproduciresas
partes—éloellaseríacambioelhoja de ruta para mostrar ese retraso.
La hoja de ruta hace que el valor sea visible. No wIII ser conjuntos de
característicasque nonecesita al inicio del
programa.Sielproductopropietarioy los
equipostrabajoporvalor,quevoluntadsermás fácilaver
cuandoque'stiempoainvertirenfísicaformularioycuandopuedes esperar.
14.4 Véase la obra
A veces, los equipos de ingenieríalecítrica mecánica y e pueden sentirse

como un agujero negro para el resto de la
organización.Yo'veoídodeclaraciones tales
como,"Nosotros'retrabajandoenel teclado. Lo tendremos para ti en un
par de meses."Ellospodría.Mi experiencia eslo quequeobtenerenuna
parejademonthseselprimeroprototipodevarios
necesitamos. Esono ha terminado de funcionar.
Una manera de ver el trabajo es pedir a los ingenieros que usen un
kanban
Tablero. Recomiendo que cada componente tenga su propio kanban
para ver el trabajo en curso.
Un kanban might de ingeniería mecánica se parece a esta imagen.

Posible Ingeniería MecánicaKanban
Un kanban de ingeniería de silicio podría parecerse a esta imagen.

Posible Kanban de Silicio

Un kanban FPGA podría parecerse a esta imagen.
Posible FPGA Kanban
El kanban FPGA podría parecerse mucho más a un software regular

kanban, hasta que tome la decisión de ir ala forma física.

14.5 Diseño Incremental y
Iterativamente
Los ingenieros mecánicos y los ingenieros de hardware iteran en sus

diseños.Se'sfácilybarato para iterar con simuladoresy
Emuladores.
Los ingenieros mecánicos utilizan simuladores para construir y

comprobar su trabajo.
De
stepSodoanaloganddigitalengineers-by-
stepthroughtheirpartthe.Theycanuseproduct. asimulatortowalk
Si le pide a los ingenieros mecánicos y eléctricos que diseñen de forma

tiva e incremental—antes de comprometersecon la forma física—
quepuede entonces preguntarparacontinuodiseñorevisión.
14.6 Usar revisióncontinua de diseño
para el trabajo Son principios de

Mechanicalandhardwaretheirastheysimulateengineerscanuse.applyco
ntinuousintegrationthose
ver retroalimentación continuamente con el resto del programa cuando

utilizan la revisión continua del diseño.
En Encourage Iterative and Incremental Architecture, sugerí que los
equipos evolucionaran la imagen de la arquitectura antes de finalizar
sus decisiones arquitectónicas. Su equipo de software podría elegir
tener unarevisión de diseño de la arquitectura después de tres
características.(Véase
Gestione! su guía para la gestión de proyectos modernos y pragmáticos,
ROT07 para una discusión más completa sobre la implementación
devarias características
antes de seleccionar una arquitectura.)
Usted puede hacer eso para el hardware piecesde su
producto.Dependiendo deen cuánto tiempo los ingenierosesperanel
esfuerzo(s) de hardware para tomar,que
podría pedirles que revisen los diseños cada semana o cada dos
semanas, sitrabajan en cajas de tiempo de dos semanas.
A medida que los engineers modifican sus diseños originales y
determinan lo que pueden hacer en laspartes mecánicas o de hardware
de el producto,
pueden explicar sus decisionesparaelsoftwarefeatureteamsand/o
arquitectos.
14.7 Integrar hardware con frecuencia
El costo de pasar a la forma físicaes alto con componentes mecánicos y

de silicio. Sin embargo, si el programa espera hasta el final para
combinar todos los componentes en un producto, se encontrará con el
90% Hecho juego de programación.
(Que'sdondequetienenterminado90%
de la obra y quedando el otro 90%.) (Consulte Administrar¡!Su guía
paraModerno,Gestión de Proyectos Pragmáticos, ROT07para
más información sobre este juego de programación.)
Cuantos más puntos de integración tenga su programa, más fácil será
ver todo el producto, no solo un componente.
El hardware y la ingeniería mecánica están en ciclos diferentesentre sí,
y cada uno es diferente del software.Inclusoconcada
unodisciplina,elriesgossondiferentecuandoelequipos colaboran
una entrega y cuando todo elprograma tiene que

recopilarorate para crear un producto.
Los equipos de ingeniería simulan ver problemas en su propio trabajo y
resolver esos problemas. Cada equipo está listo parala integración en
un
tiempo diferente. Puedenintegrarse hasta que hagan fabricación. Eso
cambia losciclos de retroalimentación para todo el programa.
Preguntas que puede hacer:
• ¿Hay alguna forma física provisional que nosproporcione valor?

• ¿Cuánto nos cuesta ese formulario para crear?

• ¿Cuánto tiempo es buenoese prototipo?
• Si no hay unaforma física provisional que nos proporcione valor,
¿cómo podemos obtener valor y reducir los riesgoscon¿Qué tipo
de forma o demostración?
Estos son algunos problemas de muestra que podría probar y evitar

con los primeros prototipos:
• La huella es demasiado grande/demasiado pequeña.

• El diseño portrabajo contractual que pensabas que era bueno
resulta ser incorrecto.
• Youhaveadesignthatworksbutno'tproduce el producto que
desea.
Esos son ejemplos. Usted puede tener otros problemas.

14.8 Gestionar riesgos de hardware
Debido a que las piezas de hardware se ejecutan en ciclos diferentes que

las piezas de software, tenemos al menos dos maneras de gestionar
estos riesgos: diseño basado enconjuntos (consulte ¿Qué es el diseño
basado enconjuntos?SIN09)yaterrizajezonas(Consulte Inicio de las
zonas de desembarque, (WIR11).
En el diseño basado en conjuntos, los diseñadores itean en el design. A
medida que avanzan, se reglan diseños de entrada o salida que no se
intersecan con el resto de los componentes de
diseño.Enaterrizajezonas,los diseñadores
discutir los parámetros de lo que hace que un diseño exitoso y luego
converger en ese éxito.
Ambos de estos oídos de la aplicaciónpara ser más como "implementar
varias características
y ver qué arquitectura emerge, en lugar de diseñar por
adelantado."Se'stambién sobre el uso deelinteligenciadeuntodoequipo.
Hay una tercera opción: ¿hay unamanera co st-efectiva de hacer un

prototipo que puede proporcionarle retroalimentación sin tener todos
las propiedades? Por ejemplo, ¿puede utilizar una impresora 3D para
huella física, incluso si usted no puedecomprobar la disipación de
calor?No sé si eso funcionaría para su programa o sería un desperdicio
de
hora. Sé que la impresión 3Des mucho más rápida que ir a fab para
muchas partes de su producto.
Usé una cuarta opción hace algunos años. Queríamos simular el tráfico
en una red interna para ver si el diseño que teníamos
funcionaría.Preguntésobre20personas acumplirel arquitectoyme(Yo era
el director del programa)enuna granconferenciahabitación.
Organizamos a la gente de acuerdoa los tipos de tráfico.
personas de la red cuando, con la gente. Teníamos

ametronometohelptraffic—qué pasaen dondewalkontimey. Simulamos
el
no erauna prueba perfecta, y le dijo al arquitecto una tonelada de

información
sobre cómo funcionaría el software con el hardware actual. No estoy
seguro de que haríamos eso ahora,noteníamos simuladores adecuados
en ese entonces.Eneltiempo,queera un enfoque barato y útil para
ayudar aelarquitectodarse cuentaqueelhardwareno se integraría
conelsoftwarecomoquedeseado.
Estos métodos no son infalibles. Sin embargo, todos proporcionan
más rápido y mejor que esperar hastael final del proyecto / pro gramo,
cuando usted ha gastado todo el dinero y eltiempo- yquetodavía
no tienen hardware que funcione.
14.9 Desarrollar el Software antes de la

Hardware está disponible
He visto muchos programas desarrollar el hardware al mismo tiempo

uns el software, o incluso de antemano. La gente de software y
hardware está de acuerdo en los diseños de antemano, y
escribirlos.Esteesaformulariode"diseñoporcontrato."
Sin embargo, hay otraalternativa:desarrollarel software antes que el

hardware. Uno de mis críticos, Ian Brockbank, dijo que
Esta manera:
Durante los últimos doce años he trabajado para una

empresa que desarrolla chips de audio, que han adquirido
cada vez más funcionalidad a lo largo de los años. Tuvimos
una implícita comosumption que el silicio era la parte más
importante del desarrollo
ment, con el software casi como una idea posterior. Después
de varios proyectos donde el softwareno estabalisto hasta
un año o más después del silicio (y un programa que
terminóhastasiendo cancelled después de dos fichas y 4
añosdedesarrolloporqueno-unopodríausarquesin
unmayorinversión
adicionalensoftwarequeelempresafue'tcapaz
deafinalmente reconocimos que en algunos casos hay
mucho más trabajo en el
lado del software que ellado hardware. Ahora estamos
llegando alpunto de iniciar el desarrollo de software mucho
antes de que haya
es hardware disponible.
Una de las cosas más importantes que hacer para permitir

esto es tener abstracciones que pueden actuar lo
suficientemente bien como para probar el software in
avance del hardware. Utilizamos una gama de
abstracciones con diferentes niveles de fidelidad, desde un
arreglo de discos simple, a través de bibliotecas de
emulación y simuladores hasta instancias FPGA de versiones
tempranasdeelchip,y hemos
encontradoquepuedehaceralotecon un veabstracción de
baja fidelidad. Nosotros
han desarrollado un paquete de configuración de chip
avanzado en el principal utilizando poco más que una matriz
detrás de una simulación
capa para las comunicaciones. Desarrollamos algoritmos
avanzados de procesamiento de señales paranúcleos DSP
integrados con
emulaciónlibrariesonthePC. Sólo una vez que funciona
inmulación consideramos probarlo contra el hardwarereal.
Por supuesto, esto proporciona una versión provisional del

software, que es tan bueno como eldesafiado de cómo el
hardware funciona, por lo que siempre tenemos que
verificar una vez que el verdadero
hardware está disponible. Las pruebas contra las FPGA son
las siguientes. Estos nos permiten probar las primeras
versiones/subconjuntos de los chips
contra el software, y permitir que las interfaces sean valicon
fecha, depuración y refinada antes de comprometerse con el
gasto de un
juego de máscara sano completo y ejecución de fabricación.
Se necesita trabajo para permitir que los diseñosde silicio
sean adecuadospara FPGA—la portabilidad es un papel a
tiempo completo incluso con diseños de silicio adecuados- –
-peroquedefinitivamentepaga porsí mismosi
ahorrainclusoasinglerespin,quepuede
costarmillonesdedólaresy(incluso peor)ponerel programade
nuevo
por meses.
Una vez que el silicio real regresa, todavía hay más trabajo
de verificación— el tiempo en FPGA nunca es exactamente
el mismo que el silicio, y hay rendimiento analógico a
considerar también, pero en mi experiencia incluso el
abstracciones más simples pueden
reducir entre el 80y el90% de la dependencia del hardware
real durante el desarrollo y ahorrar meses o incluso años en
el proyecto
línea de tiempo. "
—Ian Brockbank, comunicación privada
¿Puedes desarrollarel software antes del hardware? ¿Esitaposibilidad
para su programa? ¿Qué tendría que ser verdad para quelo hicieras?
14.10 Principios de integración de hardware

Into Su Programa
1. Decida cuándo tiene sentido pasar a la forma física. ¿Temprano

y a menudo, o más tarde?Elprincipioes:"Mira el todo."
2. Fomentar el producto de trabajo. El principioes:"Entregar
temprano ya menudoasatisfacerelcliente."
3. Fomentar laarquitectura y el diseño
técnicos.Elprincipioes:"Atención continuaaexcelencia técnica
lenceyun buen diseño mejora la agilidad."
15. Solución de problemas agile
Problemas del equipo
Como administrador de programas, verá muchos tipos de problemas

en el
Equipos. Algunos de los them son problemas de proceso,¿cómo puede
el equipo ser mejor en ágil o magro para entregar valor mejor o más
rápido? A veces, las personas de los equipos nosaben cómo ser un
equipo o cómo
diagnosticar sus problemas de equipo.
Usted puede ver estos problemasousted puedeteneraqueaskel témto-

auto-evaluación para ver los problemas. Puede solucionar estos
problemas.
Recuerda, eres un sirviente líder. Engrasar los patines, eliminar los
impedimentos, empoderar a las personas para resolver los problemas
por sí mismos.
15.1 Los equipos no son equipos destacados
He visto a los equipos de component y alos equipos de una sola función

intentar trabajar de una manera ágil. Eso podría ser mejor que lo que
hacían antes, perono es ágil.
A menos que libere bibliotecas, los equipos de componentes no envían

características en ejecución y probadas.Ellosnecesidadaorganizar a lo
largo deconseveralotros
componentteamstoreleaserunning,testedfeatures. Si su producto es
bibliotecas, necesita equipos de componentes.
Los equipos de una sola función violan el principio ágil de que el
equipo es multifuncional y tiene todas las funciones que necesita para
terminar las características.
Los equipos de componentes y los equipos de una sola función crean

ciesinterdependen.
Si tiene un gran número de problemas de interdependencia entre
equipos,
190
Solución de problemas de equipo ágil 191
podría tener el problema de que los equipos están organizados

alrededor de architec ture y no alrededor de características.
La mayoría de los equipos de componentes y de una sola función que he

visto son un legado de los días de cascada de la
organización.¿Cómoelhecksonquevaacrear características e integrar
una función todos los días,trabajandoa través deelarquitectura en su
lugardea través deh? Eso es un gran
impedimento.Siquetienencomponenteequipos, que'sinclusomás
importante quetrabajoenpequeñohistorias.Que's porque los equipos
tendrán undifíciltiempo conseguir las historiashechoa través de la
arquitectura.
No le pidas a la gente que reorganice. En su lugar, preguntela

genteaexperiment.He tenido buenos resultados pidiendola
genteaexperimentar para ver lo que funciona conself self-
organización,para emparejar o enjambre.Cuandoque
preguntar, explicar por qué recomendarestas alternativas: múltiples
ojos en el código, todo el mundo wo rks juntos para reducir WIP y mover
un
característica en todo el tablero, y los resultados que desee.
15.1.1 Pida a los equipos que experimenten con la

autoorganización en torno a las características
• Explique a los equipos que este es un experimento que "nosotros

como organización estamosejecutandodurante las próximas x
semanas." Hacer xsercorto,como en uno o dossemanas.
• La única medida de éxito es ejecutar características probadas.
Gerentesnocomparar equipos. Ifmanagerscompareteams,
el experimento no funcionará.Esteesun experimento que la
organizaciónesgoingaaprenderde. Algunos equipos tendrán
características pequeñasy fáciles. Algunos equipos no lo harán.
Esto noes una competencia.Sinadie compara equipos, los
equiposvoluntadjuego esta medida yquevoluntadperderel
aprendizaje.
• Detenga la multitarea. Haz que todos trabajen enun solo project
a la vez en este momento. Lo sé, esto podría ser lo más difícil que
su organización ha intentado.Ignorarelhechoquenecesitan
expertos en todas partes.Asignarpersonas asóloun proyecto.
• Pida a los equipos de componentes queseorganicen como

equipos de entidades por ahora. No hay gerentes cambiantes. No
hay vestuarios. Ellos pueden decidir cómo.Siqueson
gerentes,nodecretandoquees
Para
afeatureteamconwhomwhomthemtoselfask-
organize.asIfyouhavefeatureteamssingle-functionteams,ahora.
• Pida a los propietarios de product que hagan que las historias

sean tan pequeñas como puedan hacerlas, preferiblemente uno
o dos días de equipo en tamaño o menos. Dile a los equipos que
si notienen al experto que necesitan para una historia,
estábien.Ellospuede emparejar, enjambre,oturba
juntosaobtenerelhistoriadone. Pero,nose les permite interrumpir
a otro equipo.
• Cree una hoja de ruta ágilde las características que desee en
qué versión interna.
• Los equipos trabajan en su trabajo pendiente, o trabajan en flujo
durante esta semana o dos semanas (no más) para ver lo que
sucede
cuando la vísperaryone trabaja en equipos de características de
su propia fabricación y nadie multitareas, para hacer las
características. Recuerde, estoesunexperimento.
• Haga que los equipos hagan retrospectivasel la parte final de la
caja de tiempo corta para que pueda ver lo que sucede. Es posible
que los gerentes necesiten suministrar facilitadores
retrospectivos.
• Decida qué hacera continuación. Esto es un experimento.
Al final del experimento, pida a los equipos que evalúen la

experiencia, utilizando estas preguntas:
1. ¿Qué ha pasado?
2. ¿Los equipos de características experimentales fueron capaces
de lanzar la características?
3. ¿Qué pasó con los equipos que necesitaban expertos?
4. ¿Qué fue un reto de este experimento?
5. ¿Qué tuvo éxito con este experimento?
6. ¿Qué falló con este experimento?
7. ¿Qué aprendistede este experimento?
8. ¿Quéharás en el futuro?
Esta es una manera de ayudar a los equipos a aprender a colaborar y

explorar entre sí.
15.1.2 Pida a los equipos que se emparejen

Cuando se emparejan, dos personas trabajan juntas para terminar un
pedazo de trabajo.Tradicionalmente,dos se desarrollanrs
emparejado.El"conductor" escribeelpiezadetrabajo.Elotra
persona,el"navegador," observa latrabajoy
proporcionarevisión, a medida que las dos personas completan el
trabajo. Mientras trabajan juntos, intercambian lugares, dicen cada 15-
20 minutos.
Arlo Belshee escribió un gran arteicle llamado Promiscuous Pairing y
Beginner'sMind: Embrace Inexperience, (BEL06) donde
explicacómousted don'tnecesidadaser un expertoaser uneficazpar opar
Miembro.
Cuando los miembros del equipo se emparejan para las características,

entregan.Ellosenfoque.Siquenecesidadquelp,quedon't se queda
atascado, porque siempre hay dos
personas que trabajan en una característica, discutiendo qué hacer a
continuación.
Fomentar diferentes variedades de emparejamiento: desarrollador /
desarrollador; de veloper / tester; o incluso una tríada, que comienza
a parecer un enjambre.
15.1.3 Pida a los equipos que enreden alrededor de las características
Cuando los equipos se enjambre, todo el equipo trabaja para terminar

una característica. A veces, los equipos se dividen en trozos más
pequeños, donde las personas trabajan en lo que pueden y luego se
unen al equipo. A veces,
todos trabajan juntos, como en la programación de la mafia.
Cuando enseño uno de mis talleres ágiles, desafío a la gente a tomar
una característica como equipo y completarla dentro de una hora.
Algunos equipos lo hacen haciendo que el propietario del producto
explique cuál es la característica en detalle.Entonceslos
desarrolladoresparytél probador (s)escribir
pruebas, tanto automatizadas como manuales.Ellostodosvienenjuntos

en aproximadamente la marca de 45 minutos. Ven si lo que han hecho
funciona.(A menudo no lohace.) Entonces el equipo comienza a trabajar
juntos, a realmente estácaliente."¿Quésiquehacer
estoaquí?¿Cómosobresiesto va allí?"
Algunos equipos trabajan juntos desde el principio."¿Quéeselprimero
cosa que podemos hacer para agregar valor?" (Esa es una excelente
pregunta.)Ellospodríamoveren pares más pequeños,sinecesario. quizás.
Tal vez
necesitan puntos de contacto cada 15-20 minutos para reorientarse a
decir: "¿Dónde estamos?"Ellosencontrarquesi piden comentarios del
propietario del producto, que funcionabueno.
Si primero preguntas: "¿Qué es lo primero que podemos hacer para
agregar valor y completar esta historia?" ustedsonenel camino correcto.
Tenga en cuenta cómo con el emparejamiento y el enjambre, la gente
no se atasca.Ellosreducir su WIP.Ellosentregar.
15.2 Los equipos piensan que son ágiles, pero
No son
Hay muchos ejemplos de equipos que piensan que son ágiles. Algunos
tienensprints ardientes. Algunas organizaciones tienen equipos de
desarrollo y equipos de pruebas. Lo que veo a menudo es que los
desarrolladores trabajan en una característica, seguidos por los
evaluadores que trabajan en esa misma característica. Un sprint de
endurecimiento es un ejemplo de probadores y desarrolladores que
trabajan para finish el software, para obtener que hacer.
Ayude a los equipos a aprender cómohacer cada historia en uno o dos
días.
15.2.1 El equipo trabaja en iteraciones secuenciales de

desarrollador/probador
Los equipos trabajan en iteraciones secuenciales, donde primero hay

una iteración de desarrollo durante dos semanas, y luego una iteración
de pruebas
durante dos semanas. Si eres como algunos de mis clientes, incluso te

superpones a la primera semana de pruebas, pero tienesuna semana
pruebas que se extiendemás más allá de la última semana de
desarrollo.Lo hice't mostrar queenesta foto. Eso extendería eltimebox
total por otra semana.
Desarrollo y pruebas escalonados
Cuando miramos la imagen de StaggeredDevelopmentandTesting,

noimporta cuánto tiempo sean la fuga de desarrolloo las iteraciones de
prueba. Seimporta cómolargola sumadelas iteraciones son.Sicada
iteración es de dossemanas,entonceselsumaes cuatrosemanas.Si pasa
dos semanas desarrollandoytres
semanaspruebas,quetienenacincosemanaiteración.Setomacincoseman
asaobtener retroalimentación yasabersila
característicaquedesarrolladoesbueno.Elcaracterística es'thechohasta
que el
pruebas.
Puede pedir a los equipos que experimenten con una autoorganización
alrededorcaracterísticas. Podrías preguntarlea a los equipos con las
"afines".
Podríaseteamstopairaroundfeatures. Thosearejustthree
Opciones.
Tal vez algo más funcione para su entorno. Recuerde, si la prueba
ocurre después del desarrollo, el desarrollo

ersare yaenlas próximascaracterísticas. El equipo incursa el retraso en

los comentarios.Eldesarrolladoresincurrir en un retraso
porquedeelmultitarea: detener lo quetrabajoenahora,fijaciónel
problema, y volver
a la característica en desarrollo. Evite el desarrollo y las pruebas
escalonadas. Los equipos que escalonan eldesarrollo ir y las pruebas
encuentran la integración continua o proporcionan unflujo continuo de
valor difícil, si noimposible.
En el equipo del programa, pida a los propietarios de productos que
reduzcan el tamaño de la característica. Cuanto más pequeña sea la
característica,elmásel
equipopuedecolaborarjuntosamantenerelretroalimentaciónbuclepeque
ño y tener éxitoenentrega.
15.2.2 Algunos equipos tienen sprints de endurecimiento
Los sprints de endurecimiento son un riesgo tremendo para su

programa.
Los sprints de endurecimiento son una indicación detrabajo incompleto.
Equiposhizonoobtenersu
featuresa"hecho"enelcomprometidostiempo.Personaspuedecometer
erroresensu estimación. Pero, si los equipos necesitan esprints de
endurecimiento, necesitan cambiar su enfoque. Tienen deuda técnica y
esa deuda puede convertirse en un riesgo a nivel de programa.
Si tiene equipos que discover y corregir defectos de características
tarde en
el juego—cuando el equipo piensa que la característica está completa—
has añadido un riesgo tremendo a tu programa. Los desarrolladores
multitarea—detienen el trabajo en la función enlaque están trabajando
ahora, vuelven a unacaracterística anterior es posible que norecuerden
todo el contexto, lo arreglen— y luego volver a la característica que
estaban trabajando
En.
Comoadministrador de programas, esté atento a estos problemas. Lo
verás en
equipos de
característicasnotcompletandocaracterísticasesperaban,orinfeature
equipos diciendo que necesitan tiempo para corregir defectos o realizar
endurecimiento
Sprints.
Sugiero que el equipo mida su flujo acumulado para mostrar dónde

está el trabajo.
Haz que sea fácil para la gente traerte malas noticias. No seas
desagradable sobre este problema. Ayuda a que sequede nueces sobre
dónde seencuentran en su viaje ágil o magro.
El endurecimiento de sprints o la corrección de defectos en una
característica mucho después de que se creó son dos ejemplos de un
problema similar: no llegar a hacer
sobre historias. Puede haber muchas razones para esto: pruebas
insufficient, automatización de pruebas insuficiente, equipos parciales,
personas multitarea,para
nombre sólo unos pocos.
Como director de programa, anime a los equipos de características a

realizar retrospectivas y descubrir por qué tienen estos
problemas.Enademás, fomentar laproductpropietariosparaesos
equipos destacadosa
hacer las historias más pequeñas. Las historias más pequeñas ayudarán
a los equipos a ver sus problemas más rápido y a solucionarlos más
rápido. Un sprint de endurecimiento no le permite tener un producto
releable en todo momento.
Sepa si tiene equipos parciales o personas multitarea en su programa,
especialmente si tiene fechas de destino o un presupuesto objetivo. Sus
riesgos aumentan con equipos parciales o multitarea.
15.2.3 Usted tiene equipos de características parciales
Un equipo de características tiene todos los roles que necesita para

crear entidades. Es un equipo multifuncional, de no más de nueve
personas.(Prefiero equipos de 4-6 personas.)
Es posible que no tenga equipos de características porque a un equipo

le falten evaluadores, personas de experiencia de usuario o
administradores de bases de datos. Elequipo se está perdiendo
algunospapelorolesy no puede compcaracterísticas de leteporsí mismo.
Es posible que tenga este problema porque la organización estaba "lop
sided" para comenzar.Elgerentes,antes
dequecomenzóausarágil,pensamientoquefuebienpara tener
muchosdesarrolladoresy"compartir" probadores, experiencia de
usuariola gente,oDBAs.Ena serialvidaciclo,tal vezquefueEstá bien.Se's
noestá bienen ágil.
No agregueequipos equipos de desarrolladores y cree equipos

incompletos y desequilibrados.
No se obtiene más rendimiento con desarrolladores adicionales sin
additionaltestersor businessanalysts o escritores o lo que hace
desarrolladores de trabajocanyetto a travésdeso-
funcionalteaminyourorganizationyproducefeaturesbythemselves,. Si
está bien. Tengo
ver a los desarrolladores hacer eso, y no ser ciego a sus propios defectos.
Lo que le importa en su program es el rendimiento de las características
probadas en ejecución. No desea que los equipos parciales creen
trabajo en curso.QueDesperdicio.
Los equipos de características parciales son un artefacto de
pensamiento de cascada, optimizando para la eficiencia de los recursos
como en This is Lean: Resolving la Paradoja de LaEficienciaFiciency,
MOA13. Su dirección quiere lanzar a la gente al producto. Nolos dejes.
Si todo el mundo es ágil, es posible que no necesite tantas personas como su
la administración cree que sí. Tienes integración continua. Tienes
equipos de características. Noempiecesa tener más gente de la que
necesitas. Di, "Gracias. Elprogramadoesn'tnecesidadmás personas
quequepuedetienenencompletamenteequipos de características con
personal.A menos queusted puedepersonal cuentan con equipos
conprobadoresy los propietarios de productos, puedoNo use estos
desarrolladores.
Nos ralentizarán. Detodos modos, eso te ha fracasado. "
Haga hincapié en que deseafluefficiency,movingfeatures—entregables—a
través del programa.
Si esono los convence, estima el Coste del Retraso para los equipos
parciales, como en Buceo para Tesoros Ocultos: Encontrar el valor en su
proyecto Portfolio (RE14). "En algún momento, necesitaremos
probadores para esos desarrolladores",o cualquier rol te estás
perdiendo. "En ese momento, o tenemos un retraso mientras tratamos
de integrar aalguien en el equipo, o tendremos que pedir a la gente a
multitask. Ese retraso, que calculo queserá de algún número,
afectan a todo el programa."
15.2.4 Necesita expertos para completar una historia
Si estásen medio de tu transición a ágil, tienes muchos expertos. Es

posible que no tenga personas que sean especialistas en
generalización,personas quese especializan en un área y son capaces de
flexionando su
intelectuales en áreas relacionadas.
Estees un ejemplo de lo que quiero decir con un especialista en

generalización.Como
un desarrollador, me encantó escribir capas de forma de platy
middleware. No estabatan entusiasmado con la interfaz de usuario. Me
especialicéenelplataforma
y en segundo lugar en el middleware.
Sin embargo, afeature no esuna característica a menos que el usuario
pueda verla.YonecesarioInterfaz de
usuariohabilidades.Yotrabajadoduro, y a menudo conotherpersonas,
para desarrollara
suficiente conocimiento de lo que constituyerazonable interfaz de
usuario enfoques.Yoa menudotrabajadoconDiseñadores de interfaz de
usuarioqueutilizadoprototipos de papel para
determinar cuál sería la interfaz de usuario. Tenía pautas. Pude crear
características.
Pasé de ser una especialidaden la plataforma a ser un desarrollador de

"pilacompleta". Nunca me llamaría un gurú de la interfaz de usuario.
Por otro lado,
con algo de ayuda en toda la organización, podría crear
características. Hay otros tipos de especialistas, como administradores
de bases de datos, o
personas que hacen las finanzas, o diagnósticos. Estas personas se han
centrado en un área de la base de código. Podrían ser capaces de crear
características, pero sólo en esa área.
Los equipos sin conocimientos específicos en un área a menudo son
reacios a cambiar el código en esa área. O bien,esposible que el equipo
quiera esperar aun experto. Tienes otro riesgo, otro costo de retraso.
Los equipos tienen que aprender a convertirse en los expertos que
necesitan para poderayudar a crear características en todo el código
Base. Pueden encontrar esto
bastante difícil.
Usted puede ayudar en las maneras de several:
• Reconocer que este trabajo será difícil para el equipo.

• Si el experto está disponible, pídale al experto que trabaje con el

equipo en un corto cuadro de tiempo, como una semana, para la
transición de los conocimientosdel experto parael
equipo.Hacerseguroel experto trabaja con el equipo
paraquetimebox,yentonceselexperto
transiciones de distancia. Sielequiponecesidadesayuda
adicional,puedeel expertotienenoficinahoraspara el
equipoallamarlo o ella?Elobjetivoesanonecesitan laexpertomás
tiempo.
• Pida a los miembros del equipo que se emparejen de las
características que creenque necesitan un experto para
completar.A veces, el equipo mem berscanenentender lo
que'sgoingonaspairs. A veces, dos
cabezas son mejores que una.
• Pida a los miembros del equipo que se enjambren en el trabajo.
Esto funciona
especially bien cuando los miembros del equipo utilizan pruebas
impulsadas por el velopment y generan pruebas automatizadas
primero, por lo que las pruebas apoyan el equipotrabajo.
Es posible que tenga que ayudar a los equipos a pasar por el

pensamiento especializado.
15.3 Los equipos tienen dependencias

Otros equipos
¿Sus equipos de desarrollo de productos pueden trabajara través de

toda la pila para producir una característica?
Implementar por característica
En la imagen Implementby Feature, puede ver cómo los equipos de

entidades implse encomienda una pequeña característica completa a
través de la pila.Siaequipodoesn't tienen el derechola
genteaentregaruna característica completa, lo que los impedimentos
puedenqueeliminarasí queelequipohacetienen todos losla
gentequerequiereenel equipoaimplementar unllenocaracterística?
A veces, los equipos tienen características mucho más complejas
porque
dependencias de otros equipos. Veo esto mucho con los equipos de
componentes. Cada equipo escapaz depara implementar su parte.Sin
embargo,nadie
puede darse cuenta del valor de una entidad hasta que todos los equipos
de componentes terminen sus piezas.
Características de Curlicue
Un equipo que entrené explicó que tenían características "curlicue".

Notenían rasgos de línea recta. Teníaninterdependencias
con otros equipos queledtolargefeaturesthatlookedlikethe imagen,
Características de Curlicue.
A veces, las características rizadas pueden ser un artefacto de la Ley de

Conway. Imagínese que en su programa, la gente de middleware está
en París, la gente de la interfaz de usuario está en Edimburgo, la
aplicación capa 1 personas están en Denver, la App layer 2 personas
están en Raleigh, y la gente de la Plataforma está en San Francisco.
Necesitas que todos esos equipos entreguen
una característica. Las características son grandes y tienen
dependencias en otros equipos.
Cuando escucha "dependencias en otros equipos" o expertos, sabe que
los equipos no son equipos de características.Yo'vesiempre y cuandosug
para ayudar a los equipos a convertirse en equipos destacados.Enlo
menos, pregunte a los equiposacrear kanbantablerosasí quetodo el
mundopuedevisualizardondeelcaracterísticaestá en su desarrollo.
Solución de problemas de Agile Team Issues 203
15.4 Sus características abarcan varias
Iteraciones
Lo que veo en algunos equipos bastante nuevo en ágil: ¿Sus

características abarcan iteraciones?¿Son ellos tambiéngrandespara
terminar enadíao así?
Si es así, haga que sus características sean más pequeñas. Hacer que
las funciones sean más pequeñas ayudará a
el teamsee suprogreso. Las características más pequeñas también
proporcionan comentarios al propietario/cliente del producto. Esos
comentarios ayudarán al propietario del producto a hacer las historias
más pequeñas y ayudarán al equipo a completar su trabajo dentro de
la iteración.Siqueestán usando kanban,
esteessimilaraverajuntanocambioparasemanasmientras que las
mismas características siguen siendoeneljunta,nada en movimiento.
También es probable que esté haciendo
Integración.
Si necesitas ayuda para hacer historias más pequeñas,intenta definir

escenarios,
en lugar de historias. A continuación, vea si youcanworkbyvalue en el
escenario.
Véase User Story Mapping de Jeff Patton,(PAT14), Gojko Adzic's, Impact
Mapping: Making a big impact with software products and projects,
(ADZ12), and Adzic and Evans' FiftyQuickIdeasaMejore sus historias de
usuario,(ADZ14). RevisiónPawel Brodzinski's
Conjunto de características mínimamente indispensables, (BRO14).
15.5 Ustedno tiene frecuente-Suficiente

Entregas
Si tiene versiones internasfrecuentes,independientemente de si libera o

nosu producto, todo elmundo puede ver el producto crece.
Si notienes entregas mensuales, pídele saque a los equipos que
publiquen algo completo cada semana.Queayudará aellosversuimpedi
"liberación mensual".
Cuando todo el mundo puede ver crecer el producto, todo el mundo
puede
feedbackontheproduct'sprogress. Theproductownerslearn sobre
las historias:lo valiosas que son, lo grandes o pequeñas que son, y lo

fáciles o difíciles que son de implementar. Los desarrolladores y
testerslearnhowwelltheydoatdevelopingandtestingtheproduct.
ElDiseño UXersaprenderlo bien quequehacer
enusuarioexperienciadiseño
para este producto. Y así sucesivamente.
Cuando hace que su producto sea releable a menudo, practique.
Algunos de ustedes están diciendo: "Liberamos varias veces todos los
días. Noveo lo quees tan bueno sobre el lanzamiento una vez every
mes."
Si youhavealargeprogramofmorethan15teams—especialmenteapro-
gram con hardware—puede ser bastante difícil liberar nada, nunca
liberación mental de un producto de valor una vez al mes.
15.6 Los equiposno terminan cuando dicen

Están hechos
Algunos téms, especialmente los nuevos en ágil o magro, tienen

problemas con la idea de
"hecho."Que'scuandoiniciaraudienciasobre"hecho
hecho" o "hecho-hecho."
La forma de hacerlo es utilizar las prácticas técnicas: pruebas

automatizadas del sistema, pruebaautomatizada-desarrollode driven
(ATDD), prueba
En
drivendevelopment(TDD)orespeciallycontinuousintegrationbehaviorbe
haviorand-drivendevelopment(BDD),smallstories.
Algunos equipos y propietarios de productos tienen muchosproblemas

con la idea de pequeñas historias. Algunos equipos tienen un gran
número de problemas para integrating las prácticas técnicas, porque no
las han practicado diariamente como parte de su vida profesional.
Usted, comodirector de programas, no puedehacer que los
equiposcambien. Puede invitarlosa cambiar. Puede solicitar los
resultados que desee. Puedes apoyarlos y preguntar: "¿En qué puedo
ayudar?"
Explique: "No meimporta cuántas características termines en una
iteración
orinflow. Me importa que la función esté hecha. Una vez que
realmente termines
confiablemente, podemos empezar a pensar enel aumento de loquecity,

si quieres. Sin embargo,enmiexperiencia,pequeñas características
quesonnomás quedosdíaslargovoluntadayudar austed
logravarioscosas:
• Terminando tus rasgos cuando dices que lo harás.

• Ver mejor tu progreso.
• Hacer cuando haya terminado, y no hacer más de lo
necesario,para una característica determinada.
15.6.1 Desarrollar comunidades de práctica para ayudar a los

equipos como pares
Si algunos equipos tienen problemas conalgunas prácticas, necesitan

ayuda con el cambio. Recuerda, la gente cambia una persona a la vez.
Prueba esto
lista de verificación:
1. ¿Sabe people lo que tienen que hacer?Tal vezla gente necesita

capacitaciónprimero.
2. ¿Las personas tienen herramientas adecuadas para realizar su
trabajo? Tal vez la genteno tiene las herramientas que
necesitan.Sisuprograma es
nada como los programas quehe visto, algunos equipos no tienen
acceso a la misma infraestructura que otros equipos.Se'sloco,
pero cierto. Solucione elproblema de infraestructura y
hayasolucionado el problema.
3. Explicar los riesgos de incumplimiento delos resultados deseados.
Algunas personas y equipos nose dan cuenta del efecto que sus
acciones tienen en laspersonas y equipos.
Recuerda, en un programa ágil, el ágil gestor de programas facilita el

trabajo de los proyectos/equipos de características. El gestor de
programas ágil no exige. El gestor de programas ágil no
establecer la ley.Elgestor de programas ágilno dice,"Aquí's
cómoque'svaaser,amigos."
Porotro lado, el gestor de programas ágil puede señalar las

consecuencias o riesgos de no tomar ciertas
acciones."Siquedon'tintegrarse
comoqueir,quevoluntadnevercumplirestefecha de demostración." O, la
fecha de la feria,oeldeseadofecha de lanzamiento,oalguna otra cita. O,
manejar algún otro riesgo.
Estoy muy feliz de explicar los riesgos a los equipos de

características.Ellosson adultos. Pero si el administrador del programa
de software explica los riesgos, o incluso dice, "Tengo una sentir esto,
y nopuedo explicarlo, pero creo que esto es arriesgado, y me gustaría
su ayuda en la gestión del riesgo de no integrarse a medida que
avanzamos ",la mayoría de la gente responder
y decir, "Bien, vamosaver cómo c un acercarnos a la integración
continua."O, dirán,"Oye, esteesmuy duro,"o"Esteesmuy
caro,"o"Sabemos cómohacerqueconlotesderamas que
esloco,"o"Nosotrossólosabercómopara hacerlo si
rompemoselconstruir"ocualquiernúmerodeotsuproblemadeclaraciones
.
Noson estúpidos.Ellospuedeserintimidadoporprácticas
técnicas,peroquesonnoestúpido. Y, pueden tener dudas sobre el costo
de los servidores o romper las compilaciones,dudas que son reales.
15.7 Principios de solución de problemas de Agile

Problemas del equipo
1. Ayude a cada equipo a entregar lo más a menudo

posible.Elprincipioes:"Entregartrabajandosoftware con
frecuencia."
2. Invitar a los equipos a cambiar. Noexijas un cambio.En su
lugar,crear una visióndeamejorprogramaconlos cambios. El
principio es: "Construir projects alrededor de individuos
motivados. Confía en ellos para hacer el trabajo."
3. Si los equipos noestán haciendo una retrospectiva para ver qué
les causa problemas, pídales que lohagan. Elprincipio
es:"Reflejaryajustar a intervalos regulares."
16. Integración ágil y
Los equipos de Not-Agile en su
Programa
Es posible que desee utilizar enfoques ágiles o ajustados en sus

programas.
Pero, ¿qué pasa si tienes una mezcla de equipos ágiles y de cascada? O,
tal vez tenga equipos de componentes en lugar de equipos de
entidades.Tal vezquetienenpersonas quehablarágil,perodon'ttrabajar
en unágilmanera.
Si usted está en esa posición, aquí hay algunas alternativas para

ayudara su programa a ser más ágil.Túvoluntadtienenpara
decidircómomuchoayuda
externaquenecesidaddeentrenadoresoentrenadores.Hacernoesperarqu
equepuedemoveruntodoprogramo—especialmente no un granuno—a
ágil por sí mismo.
Agile y lean se basanaroundtrust, autonomía ycolaboración. Confías en

la gente para entregar a menos que nolo hagan.
Siquedon't,quepuedepreguntarelloslo quesus
obstáculossonysiquenecesidadayudar a eliminar them. Tratar a las
personas como adultos, y tener expectativas de adultos de
ellos, le da la mayoría de los mismos resultadospreguntando por las
mismas cosas y llamándolo "ágil."
La gente estará a la espera de sus expectativas de ellos.
Usted puede decir, "Aquí están los resultados que quiero como el
administrador de
program.Siquepuedetrabajoestemanera,quevoluntadobtener los
beneficios."
Si las ideas aquí nofuncionan, considere las ideas en ¿Qué pasaría si ágil
y Lean noson adecuadaspara tú. Se supone que la gestión ágil y magra
del programa hace su vida más fácil, no más difficult.
207
Integración de equipos ágiles y no ágiles en su programa 208
16.1 Los equipos de cascada son parte de su

Programa
Algunos equipos nosaben o no quieren usar enfoques ágiles en sus

proyectos. Y.están en tu programa. Tienes posibilidades de manáging
las interdependencias con los equipos ágiles.
1. Asegúrese de utilizar la planificación basada en entregas para

todos los proyectos.Sisuprogramautiliza las ideasenCree
elAgileHoja de ruta,quevoluntad utilizar la planificación basada
en entregas.
2. Pida a los proyectos no ágiles que determine sus hitos basados en
entregas, preferiblemente uno cada mes. Usted puede preguntar
los proyectos no ágiles para entregar sus entregables una vez al
mes.
3. Pida a todos los proyectos que utilicen un enfoque incremental
para la entrega. No hay que esperar hasta el final del programa
para dehígado. Para muchas personas en los equipos de cascada,
este es un gran cambio. Es posible que los desarrolladores no
quieran liberar su código en la base de código hasta que esté
"todo hecho." Los probadores podríannosaber
cómopruebacaracterísticas parcialmente implementadas.Y,silos
probadoresenlos proyectos no ágilessontodavíaprobando un
proyecto anterioroliberación,quevoluntadtienen que eliminar ese
obstáculo multitarea. Es necesario trabajar con los propietarios
de productos para los equipos no ágiles, por lo que crean un hoja
de ruta ycortoliberaciones provisionales.
4. Nosotrose la ondarodante planeando planificar el programa. No
tienes que mantener una onda de cuatrosemanas—puedes usar
una onda más corta. Hacernoutilizar una onda más larga
quecuatrosemanas.Elprograma necesitaliberaciónalgo cada
mes.
5. Pida a los equipos de cascada que usen kanban para que puedan
ver su WIP.Túynecesitansabersitienenatonelada de
trabajoenprogresoque sonnoentrega.
6. Pida a cada proyecto que mida su flujo acumulativo.Belistopara
explicaraelequiposoproyectogerentescómoahaceresto.
Integración deequipos ágiles y ágiles en su programa 209
Cada equipo necesita ver todo su trabajo en curso. Esto les

ayudará a todos a ver sus
dependencias.Elmásinterdependencies los equipos
tienen,elmásquetienenahablarconunos a otros para
romperellos.Podríannecesidadmoreentregables.
Es posible que necesiten un tablero kanban para ver los cuellos
de botella en todo el programa. Usted, el equipo del programa de
software y el equipo principal pueden ayudar con estos
problemas. Pero, hasta que vean el trabajo en progreso, no
sabrán lo que necesitan.
Los projects noágilescomenzarán a parecerse a la entrega por etapas

o
proyectos de ciclo de vida de diseño a programación. Enuna sensación,
queEs hacer trampa,porquesonnomás tiempocascada
estrictaproyectos.Quefuncionará.
Nadie obtiene crédito por la estricta adhesión a la cascada o ágil. People
obtener crédito porproyectos y programasexitosos.
Si tienes personas que auditan tu programa por astrictadad a cualquier
enfoque, eso es un riesgo para tu programa. Usted puede mostrar bien
prácticas de software con cualquier enfoque, incluso utilizando tanto
ágil es como no ágil en el mismo programa. Pero no necesitasque nadie
te mire por encima del hombro.
Si sus proyectos no ágiles tienen gerentes de proyectos, es posible que
tenga que
programa para
proyectar
coachtheYou,
projectmanagersintoworkinginnewmanager,haveunderstandanddiffer
entwaysall.
dirección y liderazgo de los funcionarios. Explicar los resultados que

desea y cuándo los necesita. Trate a los directores de proyecto como si
fueran adultos. Ayude a los directores de proyecto a aprender a
administrar de una manera de liderazgo de servidores.
El personal no ágil del proyecto puede sentirse como si usted los

estuviera "obligando" a la transición a ágil.No lo eres. Sin embargo,
pueden ser desenatos a los hitos de
entrega.InvitarPersonasaExperimento
y medir sus resultados.
Tal vez necesites entrenaro o acoach para estos equipos. No espere que
people con una mentalidad de proyecto de control se ajuste
automáticamente a una mentalidad de proyecto adaptable.
16.2 Tienes equipos que producen de forma incremental, pero

no en un ágil
sentido
Algunos equipos piensan que sonágiles si usan las palabras. Estos

equipos tienen grandes características que tardan al menos una
iteración de dossemanaso más para liberarse.Elequipostrabajar
encaracterísticas,por lo que se están desarrollando
Incrementalmente. Sin embargo, sus incrementos son tan grandes que

tienen un trabajo tremendo en progreso, o que tardan meses en
terminar algo antes de recibir cualquierretroalimentación. Estos
equipos no pueden completar una característica en dos o incluso tres
semanas.
Pida a los propietarios de productos que creen conjuntos de
características que el equipo puede ayudar
descomponerse en más pequeños. Explique que desea que el equipo
integre algo que parezca una característica en la base de código todos
los días.
Es posible que deba proporcionar al equipo algo de entrenamiento o

entrenamiento. He conocido a muchos equipos que ni siquiera han leído
un libro ágil y no se dan cuenta de cómo trabajar deforma ágil o magra.
16.3 Tienes equipos que prototipon y nocompletan

características
Algunos prototipos pueden ser muy útiles. Por ejemplo, en un pico tural
architec, la salida podría ser una prueba de concepto o un prototipo. Sin
embargo, si un equipo sólo prototiposy nunca termina características,
que
es un problema.
Pida al equipo que cree un tablero kanban para que todos puedanver el
estado de las características.Pregunteelequipoadefiniry
gestionarsuWIP.
Pida al equipo que defina lo que significa hacer para ellos. Pida al
equipo que
llevar a cabo una retrospectiva para que entiendan lo que hicieron y
cómo lo hicieron.
Ahora, el equipo y tú tienes datos.Tal vezel equipo puede tomarquede

Aquí. Tal veztheteamneedshelp insomewayandthekanbanboard
mostrará a todos los datos.
Trabajé con un equipo que tenía este problema. Sus probadores fueron
multitarea en tantos otros proyectos me pregunté cómo el equipo
incluso tenía la retroalimentación sobre sus prototipos.
Otro equipose dio cuentade que onofdonetionofdoneera.
Los equipos que no completan características necesitan algún tipo de

consejo de resolución de problemas. Noimponga ayuda al equipo hasta
que tenga los datos.Considereayudando aellosaprendercómo descubrir
susdatospara
Sí mismos.
16.4 Principios de integraciónde equiposágiles y no ágiles en su

programa
1. Utilice la planificación basada en entregas para el programa y

para cada
Equipo. Cuanto más a menudo cada equipo tenga entregables,
más verá lo que tiene que entregar al programa y cuándo. Con
esos entregables, usted será capaz de ver cualquier
obstáculos del equipo. Los principios son: "Eliminar residuos"y
"El software de trabajo es la principal medida de progreso."
2. No hay premios para "lo ágil que es cualquier
equipo."Elsólocosaquecuentaestá entregando el
trabajoproducto.Elprinci plesson:"Entregar a tiempoya menudo
asatisfacerelcliente"y
"Empoderar al equipo. "
3. Solo tome equipos con todo el personal y personas totalmente
asignadas en su programa.Hacerno tomar multitaskedla
genteensuprogramo.Elprincipioes:"Elmejorarquitecturas,
requisitos ydiseñosemergendeequipos auto-
organizadores."Siusted tiene
problemasconesteprincipio,verSolución de
problemasAgileProblemas del equipo.
17. Qué hacer si agile y Lean no son adecuados para
tú
Ustedha leído este libro, y usted piensa, "Bien, esto es great, pero
novaatrabajoparayo,nuestro programa,onuestroorganización."
Tal vez ustedha decidido que la culturano apoyará ágil y se inclina nado
ahora, o usted tiene muchos proyectos de cascada además a algunos
proyectos ágiles en su programa. Tal vezeres nuevo en agile, tus
iteraciones son más de dos semanas, y tu riesgo es demasiado alto.Tal
vezsus gerentesquieroaejercertambiénmuchocontrolenlos proyectos
sobrelo quela gentehacer(mover a la gente comopiezas de ajedrez),
ynogestionar elproyectocartera.
Tienes opciones. No tienes que ejecutar un programa en cascada.
acerca de alrededor de
envejecimiento,Usted puedetomar ventajadeliverableeverything-
basedplanning,ya sabes acerca decrossprojectman-funcional-
equipos colaborativos, sobre la reducción del trabajo en curso,todolo

que conoces a partirde prácticas ágiles, ágiles y buenas de gestión de
proyectosahacer que suproyectoéxito.
Esto se llama "pensar."
Su organización le paga a usted, y a cualquier persona involucrada en
un programa, para pensar. Especialmente si usted es el administrador
del programa y se supone que
para gestionar los riesgos y eliminar obstáculos.
Algunas de las ideas de este capítulo podrían funcionar para usted. Te
animo a que los pruebes. En el camino, comola genterelajarse y
aprender más acerca de los enfoques ágiles y magros, tal vezquepuede
aplicar másideas.
No llames a estas ideas ágiles o ajustadas.Ellos'renot. Son enfoques
razonados, prácticos y pragmáticos para completar programas.Ver
212
Qué hacer si Agile y Lean no son adecuados para usted
21
3
lo que podría funcionar para usted. Te animo a que
involucres el programa. Hagas lo que hagas, no los llames personas
"mejor en
Prácticas.
"
Eso matará a la gente porintentar algo. Si necesita un nombre para
estas ideas, llámelas "prácticas potencialmente útiles."
Invite a personas y equipos a experimentar, medir su progreso y
reflexionar.Sieldatos dice cosasson'ttrabajandoyque'vedado
elideasuficiente tiempo, pruebe otra cosa.
Lo peor que pasa es que vuelves a la cascada sin
replanificación.Comoquesaber, queesello peor que puede pasar.
Porque en un programa, Murphyestá esperando que suceda. Murphy te
hará replanificar.
Estas son algunas posibilidades, dependiendo de los riesgos de su
programa.
17.1 Pruebe un ciclo de vidaincremental
Durante muchos años, utilicé la entrega por etapascomo mi enfoque

preferido, y lo encajonó todo, así que tuvimos una
oportunidaddehaciendo gestionar mentFechas encomendadas.
Ciclo de vida de entrega escenificado

Qué hacer si Agile y Lean no son adecuados para usted 214
Diseño para programar el ciclo de vida
Una entrega por etapas o un ciclo de vida de diseño a programación

son incrementales
ciclos de vida. Estos ciclos de vida le para construir
permiten características, una fea
a medida que avanza. Para
a la vez, la integración y las pruebas más información
información sobrelos ciclos de vida incrementales,
consulteAdministrarlo!Su guíaaGestión de Proyectos Modernos Y
Pragmáticos,(ROT07).
Fíjate ent hatnotallofthefeaturesarethesamesize. Theteamsdono se

alinea necesariamente en los límites de la entidad.Hacernoniñoa ti
mismo.Estepodríaserdifícilsisulas características son
grandes,yquehacernotimebox
las características. Es posible que sus equipos no puedanintegrarse sin
el culode una ingeniería delanzamientos o algún tipo de equipo de
integración
si las características no son pequeñas.
He utilizado Staged Delivery para administrar un programa. Encontré

que timebox ing era de gran ayuda.I timeboxedelrequisitos iniciales de
reunión
a no más de una o dos semanas. Le expliqué a los gerentes de productos

oa cualquier otra persona involucrada, "Por favor, proporcione una lista
clasificada, como en 1, 2, 3, 4, hasta 57 o 98 o lo que sea dentro de dos
semanas. Túpuedecambioquemás tarde.Peroquenecesidadpara
empezarenel más importante
Funciones. Las características más importantes impulsarán nuestras
decisiones arquitectónicas." Nosotroshizonodescender en"requisitos
infierno."
También he cajado el tiempo de la pieza BDUF (Big Design Up Front).
Todosdemiexperiencia me dicethenelinicialarquitecturaestará
mal.Yomucholo preferimos cuando hacemos
trescaracterísticasprimeroyentoncesseleccionar una arquitectura. Sin
embargo, no siempre tengo éxito convenciendo a los arquitectos de
esto.Siqueson'téxito, ya sea,timeboxesteesfuerzoa ninguna mmineral
de dos semanas.
Si ya tiene sin muchas personas en el programa, asegúrese de que hay

personas que trabajan en aprender a trabajar Juntos. Vea Cómo iniciar
un programa con más personas de las que necesita y aplique esos
principios a este enfoque.
Ahora, usted puede timebox las características.Paraejemplo, se puede
decir,"Que'sasegúrese dequepuede entregar algocadames. Deje queel
timebox de todas nuestras características se ajuste a un timebox de un
mes."
Estos ciclos de vida no son enfoques ágiles. No van a revolucionar su

cultura inde la misma manera que ágil hace.Sin embargo,siqueno puede
moverseaiteraciones de dos
semanas,ycompletacaracterísticascadadíaoasí queensuequipos de
características, intenteestosenfoques.
Principios que utilizo en un ciclo de vida incremental:
1. Timebox todo. No tienes que trabajar en iteraciones, pero

asegúrate de que las características del cuadro de tiempo.
2. Utilice los hitos mensuales e integre todo al menos cada
mes.Más a menudo esmejor.
3. Asegúrese de tener un lanzamiento de productoo una
demostración al menos cada vez al
trimestre.Cadamesesmejor.Why?Así quepuedever el producto.
Este es un trabajo incremental, no iterativo e incremental. Sin embargo,

veráque el producto crece, mes a mes, especialmente si utiliza un
timeboxede dos semanas o un mes.
17.2 Organizar por equipo de características
En lugar de organizar por componente arquitectónico, considere orga

nizing por equipo de características. No tienes que cambiar dónde se
sentela gente.
Eso podría ser demasiado cambio.Perohacercambiar su lealtad,desu
función,atherederocaracterísticaconjunto.
No se equivoquen, esto tiene el potencial de manifestar un enorme
cambio en la organización.
Lo presento de esta manera: "Voy a pedir entregas mensuales y visibles
por característica.Elmejor
maneraYosabercómoaaccomplishqueesparapersonas
atrabajojuntosenequipos de características. Me doy cuenta
Les pido que dividan al desarrollador, probador, escritor, analista de
negocios y todos los demás equipos que se sentan juntos. Estábien si
gemir ahora. He visto equipos multifuncionales que crean features
trabajan juntos muy bien.
"Además, para asegurarse de que ustedes todavía saben quiénes son, y
saben los problemas que son difíciles para usted,
me'dcomoaverquetienen"Comunidadde
Práctica"reunionescadaweekorcada dos semanas. Se trata de sesiones
de aprendizaje o sesiones de intercambio de conocimientos. Estos son
para su desarrollo profesional.
"Me doy cuenta de que este es un gran
cambio.¿Cómosobresiqueexperimento,ytratar dequeparaun mes
yver¿Qué pasa?"
Cuando enmarcas las cosas como un experimento, invitas a la gente a
probarlo. Yousonnomanicomiandocualquiercambio. Les estás pidiendo
que prueben algo. Asegúrese de programar una retrospectiva para ver
lo que funciona yno funciona a finales de mes. Incluya la retrospectiva
en la programación cuando solicite esta reorganización.
17.3 Aprender a liberar en el centro de la inconsemun

Entregas
Antesde aprender sobre ágil, tenía una directriz de que todo el

programa tenía que entregar algo cada mes.Quees, nosotros, comoa
programa, tenía que ver algovisible todos los meses. Créeme, esto fue
una lucha con el hardware. A menudo teníamos que ver una simulación.
Lo mejor que puede hacer por su programa es aprender aentregar
frecuentemente. ¿por qué? Tú construyes confianza entre los equipos de
características entregándose el unoal otro. Usted genera confianza
entre el programa y su equipo de administración mediante la
entrega.Entregaescrucial.
Si usted dice a los equipos técnicos en el programa, "Es posible que no
estemos listos para ágil. Perohay una idea ágil que creo que podemos
hacer: entregables mensuales.Hacerjóveneskquepuede
tenercadaequipoentregar
algo cada mes?"
Ahora, siéntate y escucha a la gente.A veces, cuandoquedecir cosas
como,"Nosotrospodríanoserlisto..."la gentetomarquecomoun
desafío."Sí,queson,"dicen. Otras personas están de acuerdo contigo.
Siempre se puede decir: "Aquí están los principios por los que queremos
vivir;"y luego sugerir que la liberación temprana ya menudoesunodeel
Principios.
17.4 Aprender a reducir el tamaño del lote con unprograma

grande
De vuelta en Crear la hoja de ruta de Big Picture, expliqué las

diferentesences entre épicas, temas y conjuntos de
características.Siquetienen grandes características
en suprograma,'softenbecausetheproductownersnosabe cómo dividir
los conjuntos de características en pequeño, uno o dos-día
Funciones.
Los equipos pueden tener que ayudar a sus propietarios de productos a

romper las epopeyas,
temas, ycaracterísticas setsen pequeñas historias. Es posible que los
propietarios de productos no tengan la experiencia del producto para
saber cómo hacerlo.
Si los propietarios de productosno tienen tiempo para dividir las epics,
temas o conjuntos de características en pequeños historias, usted tiene
un riesgo importante y un impedimento para su programa.¿Quéotros
sonestosla gentehacer?
Estoy seguro de que no están moviendo sus pulgares. Sospecho que no
están trabajando a tiempo completo en su programa. Puedes arreglarlo.
Cuanto menor sea el tamaño del lote, lahistoria,más rápido
trabajaránlos equipos. Elmás rápido quetrabajo,cuanto más
rápidovoluntadintegrar, manteneringimpulsoensu
programa.Ayudaelproductopropietariosreducir
tamaño de lote. La hoja de ruta del producto y backlogcreationiskey
para eléxito de suprograma.
17.5 Pruebe los trenes de liberación
Si no está listo para ser ágil, puede usar trenes de liberación y ver crecer
su producto con cada versión.
Los equipos pueden trabajar en minicascadas enlugar de por
característica. El valor de un tren de lanzamiento es que tienes que
liberar algo cada
Tren.
Cuando utiliza trenes de liberación externamente, se compromete con

usted y con sus clientespara liberar su producto en una fecha particular
cada Cuarto. El trimestre es la iteración.Siusted es unprogramagerente,
ustedpuedepreguntarsuequiposconsideraruniteraciónde algún lugar
entreseissemanasyochosemanas. En peorés, puede pedir a su
equipos para comprometerse a una iteración de 12 semanas.
En un programa, no es un clienteexterno—es
interno.Porquequesontrabajando conprojectequipos— equipos de
características—usted
no necesita garantía de marketing o capacitación para estar listo
internamente; sólo necesita que el software esté integrado y
posiblemente para ser
casado con el hardware. Eso es bastante difícil—quieres que el
equipos de proyectos noágiles para empezar aaprendera usar la

planificación basada en entregas en pequeños fragmentos, y para
centrarse en lo que el cliente
podrá utilizar.
El tren de lanzamiento no es ágil, ya que se tarda demasiado tiempo en

obtener comentarios sobreel propietario de unproducto o un Cliente. Sin
embargo, la liberación
trenes le permiten gestionar el riesgo. Estos equipos probablemente
usarán pequeñas cascadas, a menos que pueda convencerlosde usar
vida iterativa o incremental
ciclos.Peroquecomoaprogramagerentepuedegestionar la priesgo de
rogrammejorcon eltrenporquequepermitequeaobtener esos pequeños
resultados periódicamente. Claro, los entregablesno son cada dos
semanas;probablementeson'tcadacuatrosemanas, ya sea. Pero son más
a menudo que cada seis meses, y que's
una mejora.
Los trenes de liberación desacoplan la liberación del producto de los
proyectos.Quees,trenes de
liberaciónconjuntosufechasenpiedraenavanzar, y sona
menudoatadoaunfechaeneltrimestreoelmes, como
horario de untren. Entonces los contents del tren están determinados
por lo que los equipos piensan que pueden lograr. Cuando se realizauna
función, es elegible para ser lanzada. Los trenes de liberación nunca
extienden la caja de tiempo, así como los trenes nunca cambian la hora
en que salen de la estación.
Así es como se ve un tren release:
Tren de liberación: Cada tren se libera en el mismo día relativo cada

trimestre
Estoy usando cuartos aquí porque la imagen se ve mejor;quepodría usar

mesescomouna alternativa. Puede utilizar cualquier iteración periódica,
como seis semanas u ocho semanas,siempre y cuando utilice un
iteración consistente. Las iteraciones crean uncadenciaparasu
programa.
Entre las versiones, puede pedir a los equipos que se organicen para
queconstruyan
por característica.A menudo, los equipos usanunincrementalvidaciclo
talescomodiseño a programaoun escenificadoentregavidaciclo
porqueajustelos parámetrosdeeltren de liberaciónasí
quebueno.Algunos equiposqueson
cómodosconRacionalUnificadoProceso(RUP)usar eso.
Puede usar un tablero kanban para limitar el trabajo en curso y
asegurarsede que las características se hagan. Recuerde, noimporta el
ciclo de vida que utilice el equipo; quesóloasuntos quequetienen
características terminadasenla base de códigoporelfindela
iteración,cuandoeltrenesreadyatirarde distanciadela estación.
Un tren de lanzamiento no tiene el mismo enfoque y urgencia que tiene
un cuadro de tiempo más corto. Cuando su cuadro de tiempo es de ocho
o 12 semanas, pueden surgir otros problemas y cambiar el trabajo
pendiente del cuadro de tiempo.Recuerda,el equipo del proyecto
sóloobtenersretroalimentación una vez que su tren
sale de la estación.
En los programas, comprometerse con un trabajo pendiente clasificado

para un tren puede ser complicado. ¿por qué? Debido a que el
propietariodel producto querrá cambiar
la hoja de ruta más frecuentede una vez al trimestre. Cambiar la hoja
de ruta puede impedir que los equipos completen nada.
Irecommendyouusekanbanforthenon-agileteam.Theteamtakes tomar
el trabajo fuera de la cola, siempre trabajando en la característica más
importante. Desdequeestán trabajando enatimebox,lo hacemateriaque
cuenta quetrabajoen?No, no.
Los trenes de liberación le proporcionan más previsibilidad. Reducen el
riesgo, en comparación con una cascada. No proporcionan la
capacidad de cambiar
frecuentemente.
Mida su tiempo a una entrega liberable, como en Medir el

Tiempo para su entrega liberable. Asegúrese de que su tiempo de
liberación se queda en cualquier cadencia que decida, y que noaumente
porque necesitas esprints endurecidos.
¿Y qué pasa con aquellos de ustedes que tienen artículos de largo plazo,
como hardware de alguna variety omecánicoingenieríapartes? Uso
planificación basada en entregas y programación de ondas rodantes, y
mantener esas partes delprograma utilizando trenes de liberación para
su diseño.
Gestionar un programa de proyectos ágiles y no ágiles es un hecho de
la gestióndel programant life;que'snovaairse. Necesitarás todos los
consejos y trucos para que sea fácil. Los trenes de liberación son una
técnica antigua,pero puede aplicarlos de una manera nueva. ¿Qué
tienes que perder?
17.6 Principios para qué hacer si Agile y Lean no son adecuados

para usted
Si ágil es ágil y magro no va a funcionar en su organización, tenga en

cuenta estos principios:
1. Trabaje por función, siempre que sea posible. Haga que esas
características sean pequeñas, para que los equipos puedan
integrar elm continuamente. El principio es: "Entregar temprano
y a menudo para satisfacer al cliente."
2. Dile a los equipos que quieres quetrabajen en una red de
pequeño mundo
no ser ágil o no lo hace porque trabaja, que'reautónomo,
colaborativo, lean y exploratorio. Sólo
cun't pedir a la gente que trabaje de una manera altamente

colaborativa.Hacerasí que.Elprincipios son:"Empoderar al
equipo" y"Elmejorarquitecturas, requisitos y diseños
surgendeself self
equipos de organización. "
3. Mantengan su postura como líder sirviente. Mantenga su
enfoque en laresolución de problemasy eliminación de obstáculos
para los equipos de características. Todavía puede ejecutar los
equipos del programa como si fueran equipos ágiles o magros,
resolviendo problemas en toda la organización.Elprincipioes:"Los
negociosla genteydesarrolladoresdebetrabajo
Juntos. "
Bibliografía anotada
[ADZ12] Adzic, Gojko. ImpactoMapeo: Hacer un gran impacto con los

productos de software yproyectos. Provocando Pensamientos,
2012.Entender lo quequequieroaconstruir.
[ADZ14] Adzic, Gojko y David Evans. Cincuenta ideas rápidas para
mejorar su usuario Stories. Neuri Consulting LLP,
2014.Muchosequiposluchaconusuariohistorias.Estepequeño
libropuedeayudarlemejorarlo quequeplanaentregar.
[AMA11] Amabile, Teresa y Steven Kramer. ElProgress Princi
ple:UsingSmallWinsto IgniteJoy,Engagement, and Creativity at
Work. Harvard Business Review Press, Boston, 2011.Han
completadoelinvestigación quedicequecomoaacabadotrabajoen
pequeños trozos para que podamos hacer progresos.
[BEL06] Belshee, Arlo. Emparejamiento Promiscuo y Mente de
Principiante: Abrazar laInexperiencia.IEEEComputer
Sociedad,2005. A menudo pensamos en
truethinkhastobeentrepersonas con experiencia. No
[BRO14] Brodzinski, Pawel. Minimal Indispensable Feature Set en

http://brodzinski.com/2014/12/minimal-indispensable-feature-set.html,
2014. ¿Qué¿realmente necesitaaconstruir?¿Cómopocopuedequeser?
[BRO95] Brooks, Frederick P. The Mythical Man-Month: Essays on

Software Engineering, Anniversary Edition (2a edición) Addison-
Wesley, Boston, 1995.Aprenderdeun maestro.
[DER06] Derby, Esther y Diana Larsen.Agile Retrospectivos:
Hacer buenos equipos geniales. Pragmatic Bookshelf, Dallas, TX y
Raleigh, Carolina del Norte,
2006.Elclásicotrabajosobreretrospectivas.
[DWE07] Dweck,Carol. Mindset: La Nueva Psicología del Éxito.

Ballantine Books, Nueva York, 2007. Este libro discute el fijo
223
Bibliografía anotada 224
mentalidad y la mentalidad de crecimiento. Si tienes la mentalidad

fija, crees que sólo puedes hacer lo que naciste. Si tienes la
mentalidad de crecimiento, crees que puedes adquirir nuevas
habilidades y aprender. La mentalidad de crecimientote permite
mejorar,
poco a poco.
[EDM12] Edmondson, Amy C. Teaming: Cómo las organizaciones

aprenden, innovan y compiten en la economía del conocimiento.
Jossey-Bass, San Francisco, 2012. Cómo funcionan realmente los
equipos autoorganizados, y
lo que necesitamos para hacerlos work en diferentes culturas.
[FOW03] Fowler, Martin. ¿Quién necesita un arquitecto?, SOFTWARE IEEE
Julio-agosto de 2003, pp 2-4, también en

http://martinfowler.com/ieeeSoftware/whoNeed Lea esto si desea entender lo que
los arquitectos pueden hacer por usted, y lo que should no hacer. Maravilloso
artículo sobre el
valor de la arquitectura.
[GLI15] Gonalves, Luis y Ben Linders. Obtención de valor de Agile

Retrospectives: Una caja de herramientas de ejercicios
retrospectivos. Leanpub, 2015. Más ejercicios retrospectivos para
su consideración.
[GRE02] Greenleaf, Robert K. Servant Leadership: A journey into the

Nature of Legitimate Power and Greatness, 25th Anniver sary
Edition. Paulist Press, Nueva York, 2002. El texto original y definitivo
sobre el liderazgo de los siervos. Las palabras clave y después de las
palabras provide valor significativo para entender cómo el siervo
líderes trabajan.
[HAC02) Hackman, J. Richard. Equipos principales: Establecer el

escenario para grandes actuaciones. Harvard Business Review
Press, Boston, 2002. El trabajo clásico sobre lo que es un equipo,
incluyendo lo que es unequipo auto-gestionante o auto-
organizador.
[HAM14] Hammarberg, Marcus y Joakim Sundén. Kanban en acción.

Manning, Shelter Island, NY, 2014. Excelente introducción
a kanban.
[KEIO8] Keith, Kent M. El caso para el liderazgo de los siervos. Greenleaf

OgrafíaBibli anotada 225
Center for Servant Leadership, Westfield, IN,

2008.Útilsercausaque'scorto, dulce y específico.
[MOA13] Modig,Niklas yPárrEl str.m.EsteesLean:ResolverelParadoja de
la eficiencia.RheologicaPublicación,2013. Posiblemente el mejor
libro sobre cómo los gerentes deben considerar ágil y
magro.Amaravillosodiscusióndeeficiencia de los recursosVs.flujo
Eficiencia.
[PAT14] Patton, Jeff.UsuarioStory Mapping: DescubreelEnteroHistoria,

ConstruirelProducto correcto. O'Reilly, Sebastopol, CA, 2014.Un
excelentemanera deexplicarsuhistorias paraa ti mismo.Estelibro
seayudar aquemoverdeépicas ytemasahistorias de su característica
los equipos pueden construir.
[POP03] Poppendieck, Mary y Tom Poppendieck.Software Lean

Desarrollo: Un kit de herramientas ágil. Addison-Wesley, Boston,
2003.
El primer libro que proporciona un enfoque lean al software.
[REI09] Reinertsen, Donald G.ElPrincipiosde Flujo de operación de
desarrollo del producto: segunda generaciónLeanDesarrollo de
productos. Celeritas Publishing, Redondo Beach, CA, 2009.Un
clásicoparacomprensiónlotetamaño y más corto
ponderadotrabajoprimero.
[BCD05] Rothman,JohannaandEstherDerby.BehindClosedDoors:
Secretos de la Gran Gestión. Pragmatic Bookshelf, Dallas, TX y
Raleigh,NC, 2005.Nosotrosdescribir la Regla deTresymuchosotros
enfoques de gestión y techniquesenaquí.
[ROT07] Rothman, Johanna. Administrar¡! Su guía para la modernidad,
Gestión de Proyectos Pragmáticos. Pragmatic Bookshelf, Dallas, TX
y Raleigh, Carolina del Norte, 2007. Si quieressaber más sobre
cómo estimar eltamaño de la tarea, establecer un ritmo de
proyectoo ver un tablero de control project, este es el libro para
usted.Yotienenreferencias sobrepor quémultitareaeslocoenaquí.
[ROT09] Rothman, Johanna. Gestione su cartera de proyectos: en
creaseYourCapacityandFinishMoreProjects.PragmaticBook-shelf,
Dallas, TX y Raleigh, NC, 2009.A veces, el programa
los gerentes se encuentran con las decisiones de la cartera de

proyectos con el conjunto de características o la solicitud de que las
personas multitarea. Este libro le ayuda a gestionar todo el trabajo
de su cartera de proyectos. También tengo más referencias acerca
de por qué multitarea es una locura aquí.
[RE14] Rothman, Johanna y Jutta Eckstein. Buceo para tesoros ocultos:

Encontrar el valor real en su cartera de proyectos. Tinta práctica,
2014. Un libro sobre el costo del retraso y cómo esos costos afectan
a su cartera deproyectos.
[ROT15] Rothman, Johanna. Predicción de lo impredecible: Enfoques

máticos de Prag para estimar el programa o el costo del proyecto.
Prac tical Ink, 2015. Lo que necesita saber acerca de la estimación y
qué hacer cuando su estimación es incorrecta.
[SHI08] Muymolesto, Clay. Aquí viene todo el mundo: El poder de Orga

nizing con las organizaciones. Penguin Books, Nueva York, 2008.
Por qué funciona la colaboración, incluso cuando la gente
noseconoce. Esfascinante. Donde aprendí por primera vez el
término "pequeño
redes mundiales. "
[SIN09] Cantante, David J., Ph.D., Capitán Norbert Doerry, Ph.D., y
Buckley. ¿Qué es el diseño basado en conjuntos? http://www.doerry.org/norbert

2009. Un artículo legible sobre qué es el diseño basado en conjuntos y cómo
para usarlo.
[SNB07] Snowden, David J. y Mary E. Boone. Un marco de líder es
trabajo para la toma de decisiones en Harvard Business Review,
Novem ber 2007. El artículo introductorio sobre el Cynefin Frame
Trabajo.
[SH06] Subramaniam, Venkat y Andy Hunt. Prácticas de un

desarrollador ágil: Trabajando en el mundo real. Pragmatic
Librería, Dallas, TX y Raleigh, Carolina del Norte, 2006. Me enteré
por primera vez sobre el término "arquitectosde PowerPoint"de
Venkat y Andy. Había visto ese tipo de arquitectos, por supuesto. Si
quieres convertirte en un desarrollador ágil, o un arquitecto ágil,
comienza aquí.
[TIK14]Tikka, Ari. Caos de coordinación en http://www.slideshare.net/aritikka/coordi

caos-41883070, 2014. Descubra cómo los expertos pueden hacer

la vida mucho más complicada.
[WIR11] Wirfs-Brock, Rebecca. Comenzando con las zonas de aterrizaje en

http://wirfs-brock.com/blog/2011/07/20/introducing-landing-zones/ de
2011. Cómo cambiar las cualidades arquitectónicas en el camino a
Hecho.
[SHU14] Desconocido. Secreto para los equipos técnicos de Shutterstock en

http://bits.shutterstock.com, secret-to-shutterstock-tech-teams/ What a real
manager does
con equipos reales.
Glosario
Sino está familiarizado con los términos quehe usado, aquí están las
definiciones.
Adaptativo: Cualquier enfoque que te permita ajustar tus prácticas o

comportamiento a la realidad actual.
Agile: Usted trabaja en pequeños trozos,terminando el trabajo que es
valioso para el cliente en el orden de ser cliente
especifica.Elvalordetrabajandoenunágilmaneraesquequetienen la
capacidadacambiar rápidamente, porquecompletatrabajo.
Trabajo pendiente: lista clasificatoria de los artículos que deben
completarsepara el producto.
Costo del retraso: el impacto de los ingresos en el que incurre al retrasar

un proyecto.Apartede"desaparecidos"adeseadoliberaciónfecha, se
puedeincurrir en
teamCost for or waitingforAll ofor fromone
deDelaywaiting conotramultitarea, el programa.
expertos,these
problemas—
ymás:conduzca a un retraso en el lanzamiento del producto.

Comunidad de Práctica: Una forma de compartir conocimientos entre
personas que pertenecen a diferentes equipos, y compartir los mismos
intereses o
Función. Forexample,inaprogram,youmighthaveanarchitecture
communityof práctica queayudacualquierdesarrollador aprendercómo

evolucionar el diseño del producto. Una comunidad de prueba de
práctica proporcionaría un foro para que los evaluadores discutan qué
y cómo probar.
Flujo: El equipo toma un número limitado de elementos para completar,
y utiliza el WIP limit en lugar de un cuadro de tiempo como una manera
de controlar cómo
mucho trabajo que el equipo toma.
Especialista en Generalización: Alguien que tiene una habilidad en
profundidad y es lo suficientemente flexible como para poder trabajar
en todo el equipo para ayudar a
una característica que hacer.
228
Glosario 229
Sprint duro: Si un equipo no completa todo el trabajo que necesita para

una liberación, es posible quenecesiteun sprint de
endurecimientoacompletatodas las pruebasparauna
liberación.Esteesunindicaciónelequipos sonnorealmente
conseguiracada iteración. Tienen trabajo en progress
más allá del final de la iteración.
Inch-pebble: Inch-pebbles son una-a-dos tareas de día que son
cualquiera de los dos
hecho o no hecho.
Iteración: un cuadro de tiempo específico. Para ágilproyectos,esa

vezesni
maley de una a cuatro semanas.Enprogramas, yocomoinclusoitera más
pequeñaciones porque desea retroalimentación mása menudoy
quieroaconstruir momen
Tum.
Kanban: Literalmente la palabra japonesa para "signboard." Un sistema

de programaciónparalimitandoelcantidaddetrabajoenprogresoen
cualquiera de lostiempo.
Lean: Un enfoque de extracción para administrar el trabajo que busca
residuos en el sistema.
MVP: Producto mínimo viable. ¿Cuál es el mínimo que puede hacer para
crear un producto aceptable?Esteesnoapenasbuenosuficiente
Calidad. Thisisshippableproduct.However,thisisminimalinterms of
features.
Emparejamiento: Cuando dos personas se juntan en una tarea.

Estacionamiento: Este es un lugar para poner los problemas que don't
desea perder, perodon't necesariamente desea para abordar en este
momento.
con para aprender Entonces será
(preferiblementeSpike:Ifyou
cannotestimatetheentireteam)astory,timeboxsomeit. cantidad
detrabajoque
capaz de saber qué hacer después del día o dos timebox.

Liderazgo de los sirvientes: Un enfoque para administrar y liderar donde
el líder crea un entorno en el que las personas pueden hacer su mejor
trabajo.Ellíder no'tcontroleltrabajo;elequipolo hace. El líder confía en el
equipo para proporcionar los resultados deseados.
Sprint: Una iteración en Scrum.
Glosario 230
Enjambre: Cuando el equipo trabaja juntos para mover una

característica a hacer, todos juntos.
Deuda técnica: Accesos directos que un equipo toma para cumplir con
un entregable. Los equiposincurren en deuda técnica a propósito, como
una decisión táctica. Los equipos técnicos pueden tener deudas de
arquitectura, diseño, codificación y/o pruebas. Los equipos del
programa podrían tener riesgoodeuda de decisión—la
insuficienciadetrabajoparagestiónriesgosotomar decisiones.
Timebox: Unacantidad específica de tiempo en la que la persona
intentará realizar una tareaespecífica.
WIP o Trabajo en curso: Cualquier trabajo queno esté completo. Cuando
piensas en términos magros, es un desperdicio en el
sistema.Notaqueusted hacenoobtenercréditoparaparcialmente
completedtrabajoenágil.
Más de Johanna
Consulto, hablo y entreno sobre todos los aspectos de la gestión del

desarrollo de productos. Le doy consejos francospara sus problemas
difíciles. Yo'm másinteresadoenayudando aqueser más eficazqueYo
estoy en seguir con algún enfoque específico. Hayuna razón por la que
mi boletín se llama el "Gerente Pragmático"—¡esoes porque losoy!
Si te gustó este libro, también te pueden gustar los otros libros
queheescrito:
Buceo para tesoros ocultos: Encontrar el valor realen su proyecto

Portfolio
Predicción de lo impredecible: enfoques pragmáticos para estimar el

calendario o el costo del proyecto
Consejos de la cartera de proyectos: Doce ideas para enfocarse en el
trabajo que necesita para comenzar y terminar
Administrar su búsquedade empleo
Contratación de geeks que encajan
Gestione sucartera de proyectos P: aumente su capacidad y termine
Más proyectos
Manage It!: Your Guide to Modern, Pragmatic Project Management

Behind Closed Doors: Secrets of Great Management Además, tengo
ensayos en:
Lecturas para el liderazgo para resolver problemas
Center Enter Turn Sustain: Ensayos sobre el arte del cambio
Me gustaría estaren contacto contigo.Siquedon'tya suscríbete, por
favorsignohastaparami boletín de noticias por correo
electrónico,elGerente Pragmático,en
231
Más de Johanna 232
mi sitio web. Por favor, invítame a conectarme con you en LinkedIn, o

sígueme en Twitter, @johannarothman.
Me encantaría saber qué piensasde este
libro.Siqueescribirarevisióndequeen algún lugar, por favor hágamelo
saber. ¡Gracias!
Johanna

Agile and Lean Program Management

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

Agile and Lean Program Management

Cargado por

Copyright:

Formatos disponibles

AGILEAN LEAN

Escalado de la colaboración en toda la organización

Ninguna parte de este libro puede ser reproducida o transmitida en

Muchas de las designaciones utilizadas por los fabricantes y

© 2016 Johanna Rothman

1. Definición de la gestión ágil y ajustada de programas . . . 1

2. Considere el contexto de su programa . . . . . . . . . . . . . . . 6

Cynefin ayuda con las decisiones . . . . . . . . . . . . . . . . . Liderar el

La planificación de ondas de entrega y rodadura ayuda

5.9 trabajos pendientes . 62

6. Crear un entorno de entrega. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.9 Principles

7.10 Principios de Fomento a la Autonomía, Collabora

8. Lleve a cabo reuniones útiles para su programa . . . . . . . . . . . . . .

9. Estimación del programa o costo .. . . . . . . . 108

Medir la frecuencia de liberación . . . . . . . . . . . . . . . . . .

13.5 Cómo iniciar un programa con más personas que

14. Integración de hardware en su programa . . . . . . . . . . . . . . . . . . . . .

16. Integración de equipos ágiles y no ágiles en su gramoPro . .

16.4 Principios de integraciónAgileandNot-AgileTeams

Lo que dicenlos lectores

Agile and Lean Program Management: Escalado de la colaboración en

—Shane Hastie, ingeniero jefe de conocimientos y líder de práctica

"JohannaRothman'snew bookisthe definitivo guidetoprograma de

hace un gran trabajo proporcionando enfoques prácticos y

—Matt Barcomb, Director Principal, Tidal River Consulting

—Gary Pedretti, Entrenador y Propietario Agile, Sodoto Solutions

evoluciona."—DeclanWhelan, Entrenador ágil,

"Lee este libro y regalalo a tu jefe.Sujefe le agradecerá. Agileno se

Agradezco a mis lectores de blog de desarrollo de productos de gestión.

Portada: © Csuzda Dreamstime.com - Foto de crecimiento del equipo

Los primeros capítulos no exigen un proceso, y hay pocos de

necesidades mal articuladas, necesitamos más de este pensamiento

Escuchamos mucho rumor acerca de "escalar ágil."

La administración de programas se utiliza en cualquier momento que

• Usted es un gerente de proyecto, tratando de acorralar

Es posible que tenga una circunstancia diferenciapara su

Los programas son colecciones estratégicas de proyectos con un único

Al coordinar en toda la organización, reconoce la necesidad de que los

Si usted es un miembro del equipoen un equipo de características, un

Imagine este escenario:

Usted're el programmanager paratodo un producto.

Hoyse reunirán con el equipo principal. Ellie, la

Una vez que explicaste cómo configurar un kanban en Mar

entregables se cruzan con todos los resultados de todos

El arquitecto del programa estaba preocupado por la

Sorprendentemente, el producto es más simple de lo que

La alta dirección está contenta contigo, porque cada mes

¿Es una fantasía? No. Así es como funciona la gestión de programas

1.1 Revisar los Doce Principios de Agile

La siguiente lista parafrasea a los doce

1. Entregar temprano y a menudo para satisfacer al cliente.

El punto de los principios de ungile es que usted colabora en toda la

1.2 Revisar los Siete Principios Lean

Desarrollo de software: Un kit de herramientas ágil, POP03,

1. Elimine los residuos.

Los principios ajustados le ayudan a ver todo el proceso (para un equipo

Los principios leayudan a entender cómo usar ágil y apoyarse en su

1.3 Agile y Lean Together Crear

Cuando utilizas principios ágiles y magros, puedes crear y dirigir un

1.4 Un programa es una colecciónestratégica de

Un programa es una colección de proyectos, donde el valore está en la

¿Puedes tener equipos de cascada con tus equipos ágiles y magros

1.5 La gestión de programas facilita