PDF de programación - Scrum y XP desde las trincheras

Una historia de guerra Ágil






SCRUM Y XP DESDE LAS

TRINCHERAS
Cómo hacemos Scrum



Henrik Kniberg
Prólogos de Jeff Sutherland y Mike Cohn















VERSION GRATUITA ON-LINE

(versión gratuita no-imprimible)

Si te gusta el libro, por favor, apoya al autor y a InfoQ

comprando la edición impresa:
http://www.lulu.com/content/899349

(sólo $22.95)

Este libro está disponible por cortesía de



















Traducido al castellano por





www.proyectalis.com

Este libro se distribuye gratuitamente en InfoQ.com y

en proyectalis.com.

Si ha recibido este libro desde otra fuente, por favor,
ayuda al autor y al editor registrándote en InfoQ.com.

Visita la página Web de este libro en:

http://infoq.com/minibooks/scrum-xp-fromthetrenches






Scrum y XP desde las trincheras
Como hacemos Scrum

Escrito por:
Henrik Kniberg


Versión Online Gratuita.
Apoya este trabajo, compra la copia impresa:
http://infoq.com/minibooks/ scrum-xp-from-the-trenches

© 2007 C4Media Inc
Todos los derechos reservados.
C4Media, editor de InfoQ.com.

Este libro es parte de la serie de libros sobre Desarrollo de Software Empresarial
de InfoQ.
Para más información sobre cómo adquirir este u otros libros de InfoQ, por favor
contacte con [email protected].

Ninguna parte de esta publicación puede ser reproducida, almacenada en un
sistema o transmitida mediante ningún medio electrónico, mecánico, fotocopia,
recodificación, escaneado o de otras formas, excepto en las permitidas por las
secciones 107 o 108 del acta de derechos de copia de 1976 de los Estados
Unidos, sin el permiso por escrito del editor.

Las designaciones usadas por las empresas para distinguir sus productos se
consideran marcas registradas. En todos los casos en los que C4Media Inc. es
consciente de que existe un registro de marca, los nombres de productos
aparecerán con la inicial en Mayúscula o TODO EN MAYUSCULAS. Los
lectores, en cualquier caso, deberán contactar con las correspondientes
empresas para más información acerca de las marcas registradas.

Editor Jefe: Diana Plesa
Portada: Dixie Press
Composición: Dixie Press
Traducción al castellano: Ángel Medinilla ([email protected])
Datos de catalogación de la Biblioteca del Congreso:
ISBN: 978-1-4303-2264-1
Impreso en los Estados Unidos de América









Agradecimientos

El primer borrador de este libro solo me tomó un fin de semana, pero sin duda
fue un fin de semana intenso (¡150% de factor de dedicación! :o).

Gracias a mi esposa Sophia y a mis hijos Dave y Jeremy por aguantar mi poca
sociabilidad ese fin de semana, y a los padres de Sophia, Eva y Jörgen, por
pasarse a cuidar de la familia.

Gracias también a mis colegas de Crisp en Estocolmo y a la gente del grupo
scrumdevelopment de Yahoo por corregir los borradores y ayudarme a mejorar el
libro.

Y, finalmente, gracias a todos mis lectores, quienes han proporcionado un
constante flujo de comentarios útiles. Estoy particularmente contento de
escuchar que este libro ha empujado a tantos de vosotros a darle una
oportunidad al desarrollo Ágil de software!





Índice


AGRADECIMIENTOS

PRÓLOGO DE JEFF SUTHERLAND

PRÓLOGO DE MIKE COHN

PREFACIO - ¡HEY, SCRUM FUNCIONA!

INTRODUCCIÓN

Limitación de responsabilidad

Por qué he escrito esto

Pero ¿Qué es Scrum?

COMO HACEMOS PILAS DE PRODUCTO

Campos de historia adicionales

Como mantenemos la Pila de Producto a nivel de negocio

4

10

12

13

14
16
16
16

17
18
19

COMO NOS PREPARAMOS PARA LA PLANIFICACIÓN DE SPRINT

20

COMO HACEMOS LA PLANIFICACIÓN DE SPRINT

Por qué la calidad no es negociable

Reuniones de planificación de Sprint que duran, y duran…

Agenda de la reunión de planificación de Sprint

Definiendo la duración del Sprint

Definiendo la meta del Sprint

Decidiendo qué historias incluir en el Sprint

22
24
25
25
26
27
27

¿Cómo puede el Dueño de Producto alterar las historias que se incluyen en el
Sprint?

¿Cómo decide el equipo qué historias incluir en el Sprint?

Por qué usamos tarjetas

Definición de “terminado”

28
30
35
38



Estimación de tiempos usando planning poker

Clarificando historias

Dividiendo historias en historias más pequeñas

Dividiendo las historias en tareas.

Definiendo el sitio y la hora para el Scrum diario

Dónde trazar la línea

Historias técnicas

Sistema de seguimiento de errores vs. Pila de Producto

¡Por fin acabó la reunión de planificación de Sprint!

COMO COMUNICAMOS LOS SPRINTS

COMO HACEMOS PILAS DE SPRINT

Formato de la Pila de Sprint

Cómo funciona el tablón de tareas

Ejemplo 1 – tras el primer Scrum diario

Ejemplo 2 – tras unos cuantos días

Como funciona el diagrama burn-down

Señales de alarma en el burn-down

Hey, ¿Qué pasa con la trazabilidad?

Estimando en días vs horas

COMO DISTRIBUIMOS LA SALA DEL EQUIPO

La esquina de diseño

¡Sienta al equipo junto!

Mantén al Dueño de Producto a mano

Mantén a los gerentes y coachs a mano

CÓMO HACEMOS SCRUM DIARIOS

Cómo actualizamos el tablón

Tratando con tardones

Tratando con “no se qué hacer hoy”

39
41
42
42
43
44
45
47
47

48

50
50
51
52
53
54
55
57
57

59
59
60
61
62

63
63
64
64



CÓMO HACEMOS LA DEMO DE SPRINT

Por qué insistimos en que todos los Sprints acaben con una demo

Lista de comprobación para demos de Sprint

Tratando con historias “indemostrables”

CÓMO HACEMOS RETROSPECTIVAS DE SPRINT

Por qué insistimos en que todos los equipos hagan retrospectivas

Cómo organizamos las retrospectivas

Difundiendo las lecciones entre los equipos

Cambiar o no cambiar

Ejemplo de cosas que pueden surgir en las retrospectivas

DESCANSOS ENTRE SPRINTS

Define tus umbrales de aceptación

Estimación de los elementos más importantes

Estimar la velocidad

Uniéndolo todo en un plan de entregas (release plan)

Adaptando el plan de entregas

CÓMO COMBINAMOS SCRUM CON XP

Programación por parejas

Desarrollo guiado por pruebas (TDD)

Diseño incremental

Integración continua

Propiedad colectiva del código

Espacio informativo

Estandarización de código

Ritmo sostenible / trabajo enérgico

CÓMO HACEMOS PRUEBAS

Probablemente no puedas renunciar a la fase de pruebas

Minimiza la fase de pruebas

66
66
67
67

69
69
69
71
71
72

74
76
77
78
79
80

81
81
82
84
84
85
85
85
86

87
87
88



Incrementar la calidad incluyendo encargados de pruebas en el equipo

Incrementar la calidad haciendo menos en cada Sprint

¿Deberían las pruebas de aceptación ser parte del Sprint?

Ciclos de Sprint vs. ciclos de pruebas

No sobrecargues el eslabón más débil de tu cadena

De vuelta a la realidad

CÓMO MANEJAR MÚLTIPLES EQUIPOS SCRUM

Cuántos equipos crear

¿Sprints sincronizados, o no?

Por qué introdujimos un rol de “guía de equipo”

Como asignamos personas a los equipos

¿Equipos especializados – o no?

¿Redistribuir equipos entre Sprints – o no?

Miembros a tiempo parcial

Como hacemos Scrum de Scrums

Intercalando los Scrums diarios

Equipos apagafuegos

¿Dividir la Pila de Producto – o no?

Ramificación del código

Retrospectivas multi-equipo

CÓMO GESTIONAMOS EQUIPOS DISTRIBUIDOS
GEOGRÁFICAMENTE

Offshoring

Miembros de equipo que trabajan desde casa

LISTA DE COMPROBACIÓN DEL SCRUM MASTER

Comienzo del Sprint

Todos los días

Final de Sprint

89
91
91
92
95
96

97
97
100
101
102
103
105
106
107
108
109
110
114
114

116
117
118

119
119
119
119



EPÍLOGO

LECTURAS RECOMENDADAS

SOBRE EL AUTOR







120

121

122

10 | SCRUM Y XP DESDE LAS TRINCHERAS




Prólogo de Jeff Sutherland

Los equipos de trabajo deben conocer los principios de Scrum. ¿Cómo se crea y
se estima una pila de producto? ¿Cómo se transforma en una pila de Sprint?
¿Cómo se gestiona un gráfico de burn-down y se calcula la velocidad del
equipo? El libro de Henrik es un “kit de inicio” con las prácticas básicas que
ayudan a los equipos a avanzar de “intentar emplear Scrum” a ejecutar Scrum
correctamente.

La ejecución correcta de Scrum se está convirtiendo en un factor cada vez más
importante para los equipos que buscan inversión de capital. Como Coach Ágil
de una firma de capital riesgo, ayudo en su objetivo de invertir sólo en compañías
Ágiles que ejecuten las prácticas Ágiles correctamente. El Socio Senior del grupo
pregunta a todas las compañías del portfolio si conocen la velocidad de sus
equipos. Actualmente tienen dificultades para responder esta pregunta. Las
oportunidades de inversión en el futuro requerirán que los equipos de desarrollo
comprendan el concepto de su velocidad de producción de software.

¿Por qué es esto tan importante? Si los equipos no conocen su velocidad, el
Dueño de Producto no puede crear una hoja de ruta del producto con fechas de
lanzamiento creíbles. Sin fechas de lanzamiento fiables, la compañía podría
fracasar y los inversores perder su dinero.

Compañías grandes y pequeñas, nuevas y viejas, con inversores o sin ellos, se
enfrentan a este problema. En una discusión reciente en sobre la implantación de
Scrum en Google que tuvo lugar durante una conferencia en Londres, pregunté a
una audiencia de 135 personas cuantas de ellas estaban haciendo Scrum, y 30
respondieron positivamente. A continuación les pregunté si estaban haciendo
desarrollo iterativo según el estándar de Nokia. El desarrollo iterativo es una
parte fundamental del Manifiesto Ágil – liberar software funcional cuanto antes y
frecuentemente. Después de años de retrospectivas con cientos de equipos
Scrum, Nokia desarrollo algunos de los