SCRUM y XP desde las Trincheras

I. Cmo Hacemos Pilas de Producto

La Pila de Producto es una lista priorizada de requisitos, o historias, o
funcionalidades, o lo que sea. Cosas que el cliente quiere, descritas
usando la terminologa del cliente.
La pila de producto no es el punto de partida. Un buen producto
comienza con una necesidad del cliente y una visin de cmo
resolverlo. La pila de producto es el resultado de refinar esa visin en
resultados concretos.
Los campos principales de las historias de usuarios son:
ID: Un identificador nico.
Nombre: Una descripcin corta de la historia. Por ejemplo, Ver
tu historial de transacciones. Suficientemente claro como para
que el Dueo de Producto comprenda aproximadamente de qu
estamos hablando.
Importancia: El ratio de importancia que el Dueo de Producto
da a esta historia. Por ejemplo, 10 o 150. Ms alto = ms
importante. Se suele evitar el trmino prioridad porque
tpicamente 1 se considera la mxima prioridad, lo que es
muy incmodo si posteriormente se decide que algo es ms
importante.
Estimacin Inicial: La valoracin inicial del Equipo acerca de
cuanto trabajo es necesario para implementar la historia,
comparada con otras historias. La unidad son puntos de
historia y usualmente corresponde a das-personas ideales.
Como Probarlo: Una descripcin a alto nivel de cmo se
demostrar esta historia en la Demo al final del Sprint. Se trata,
esencialmente, de una simple especificacin de un test: Haz
esto, entonces haz lo otro, y entonces debera ocurrir aquello.
Notas: Cualquier otra informacin, clarificacin, referencia a
otras fuentes de informacin, etc. Normalmente muy breve.

Los campos adicionales de las historias de usuario son:

Categora: Una categorizacin bsica de la historia. Por ejemplo:
backoffice u optimizacin.

Componentes: Usualmente implementado en la forma de

checkboxes. Esto permite que el dueo del producto pueda
identificar qu componentes tcnicos estn involucrados en la
implementacin de la historia.
Solicitante
Bug Tracking ID: Con un sistema de bug tracking, se permite
realizar el seguimiento de errores, para mantener un historial de
cualquier correspondencia directa entre una historia y uno o ms
errores reportados
Otras personas aparte del Dueo de Producto pueden aadir sus
historias a la Pila de Producto. Pero no pueden asignarles niveles de
importancia, ese es un cometido exclusivo del Dueo de Producto.
Tampoco pueden establecer estimaciones, ese es un1 cometido
exclusivo del equipo.
Actualmente, no hay ninguna columna de "importancia. En segundo
lugar, no hay das-personas ideales. Las estimaciones estn en puntos
de la historia o en los tamaos (S / M / L), o incluso hay ninguna
estimacin en absoluto.
La pila del producto necesita estar en un documento compartido en
lnea para que cualquier persona puede acceder y editar fcilmente y
al mismo tiempo. Por ejemplo en cualquiera de las herramientas de
gestin de disponibles como Trello y LeanKit y Jira, o una hoja de
clculo de Google.
Para mantener las historias de usuario a nivel del negocio, hay una
plantilla vieja y bien establecida para realizar eso: "Como X, yo quiero
Y, de modo que Z." Por ejemplo: "Como comprador, quiero salvar a mi
carrito de la compra, de modo que pueda continuar con la compra de
maana".

II. Cmo Hacemos la Planificacin del Sprint

La planificacin de Sprint es una reunin crtica, probablemente la
ms importante de SCRUM. Actualmente ya no; la retrospectiva es el
evento ms importante. Debido a que las retrospectivas que
funcionan bien van a ayudar a solucionar otras cosas que se rompen.
La planificacin de Sprint tiende a ser bastante trivial, siempre y
cuando las otras cosas estn en su lugar (una buena pila de producto,
un dueo comprometido de productos y equipo, etc).
Una planificacin de Sprint mal ejecutada puede arruinar por
completo todo el Sprint.
El propsito de la planificacin de Sprint es proporcionar al equipo
suficiente informacin como para que puedan trabajar en paz y sin
interrupciones durante unas pocas semanas, y para ofrecer al Dueo
de Producto suficiente confianza como para permitrselo.
Una planificacin de Sprint produce, concretamente:
Una meta de Sprint
Una lista de miembros (y su nivel de dedicacin, si no es del
100%)
Una Pila de Sprint (lista de historias incluidas en el Sprint)
Una fecha concreta para la Demo del Sprint.
Un lugar y momento definidos para el SCRUM Diario.

 Cada historia contiene tres variables que son muy dependientes unas
de otras:
Alcance (Lo fija el Dueo del Producto)
Estimacin (Lo fija el Dueo del Producto)
Importancia (Lo fija el Equipo)
La cuarta variable que es la Calidad se puede distinguir entre:
Calidad externa: es lo que perciben los usuarios del sistema. Un
interfaz de usuario lento y poco intuitivo es un ejemplo de baja
calidad externa.
Calidad interna: se refiere a aquellos aspectos que normalmente
no son visibles al usuario, pero que tienen un profundo efecto en
la mantenibilidad del sistema. Cosas como consistencia del
diseo del sistema, cobertura de pruebas, legibilidad del cdigo,
refactorizacin, etc.
Normalmente, el Dueo de Producto comienza la reunin resumiendo
cul es su meta para el Sprint y las historias ms importantes. A
continuacin, el equipo las repasa y les asigna una estimacin,
comenzando con la ms importante. Conforme van hacindolo,
aparecern dudas importantes respecto al alcance: esta historia
sobre borrar usuario, incluye repasar todas las transacciones
pendientes del usuario y cancelarlas?. En algunos casos, las
respuestas sorprendern al equipo y les obligarn a cambiar sus
estimaciones. En algunos casos, la estimacin para una historia no
ser la que el Dueo de Producto esperaba. Esto puede forzarle a
cambiar la importancia de la historia o su alcance, lo que obligar al
equipo a re-estimarla, etc., etc.
Este tipo de colaboracin directa es fundamental en Scrum. De hecho,
en todo el Desarrollo gil de software. Qu ocurre si el Dueo de
Producto insiste en que no tiene tiempo de unirse a las reuniones de
planificacin de Sprint? Usualmente intento alguna de las siguientes
estrategias, en el siguiente orden:
Intentar que el Dueo de Producto comprenda por qu su
participacin es crucial y esperar que cambie de parecer.
Intentar que alguien del equipo se presente voluntario como
delegado del Dueo de Producto durante la reunin. A
continuacin, decirle al Dueo de Producto ya que no puedes
venir a nuestra reunin vamos a dejar que Jeff te represente.
Tendr poder de decisin pleno para cambiar las prioridades y el
alcance de las historias por ti durante la reunin. Te sugiero que
te sincronices con l lo mximo posible antes de la reunin. Si no
te gusta Jeff como delegado, por favor, sugiere a otro, siempre
que ese otro pueda asistir a toda la reunin.
Tratar de convencer a la gerencia de que asigne un nuevo Dueo
de Producto.
Posponer el lanzamiento del Sprint hasta que el Dueo de
Producto encuentre el tiempo para asistir a la reunin. Mientras
tanto, no comprometerse a ninguna entrega y permitir que el
equipo pase el da haciendo cualquier cosa que les parezca
importante hacer.

 Si no han producido un Plan de Sprint decente en 2 8 horas (o lo que

sea que duren las reuniones de planificacin), probablemente no se
lograr en otra hora ms.
Tener algn tipo de agenda u orden del da de la reunin de
planificacin de Sprint reducir el riesgo de sobrepasar la duracin
determinada. Adems, la agenda no es en absoluto inamovible, ya
que el SCRUM Master puede ampliar o acortar los periodos segn sea
necesario conforme progresa la reunin.

La duracin del sprint puede ser corta o larga. Generalmente, los

Dueos de Producto prefieren los Sprints cortos y a los
desarrolladores les gustan los Sprints largos.
Bueno, los Sprints cortos estn bien. Permiten a la compaa ser
gil, es decir, cambiar de direccin frecuentemente. Sprints
cortos = ciclo de feedback corto = ms entregas y ms
frecuentes = ms feedback del cliente = menos tiempo
desarrollando en direccin incorrecta = aprender y mejorar ms
rpido, etc.
Pero los Sprints largos tampoco estn mal. El equipo tiene ms
tiempo para conseguir impulso, tienen ms espacio para
recuperarse de los problemas que surjan y aun as cumplir la
meta del Sprint, tiene menos carga de gestin en trminos de
reuniones de planificacin de Sprints, Demos, etc.
La meta del Sprint debera ser algo que no se haya logrado an.
Una de las principales actividades durante la planificacin de Sprint
es decidir qu historias se incluyen en el Sprint. Ms especficamente,
qu historias de la Pila de Producto copiar en la Pila de Sprint.
El equipo decide cuntas historias incluir en el Sprint, no el Dueo
de Producto ni nadie ms. Se plantea 2 cuestiones:
Cmo decide el equipo qu historias incluir en el Sprint?
A ojo de buen cubero
Clculos de velocidad (Medida de cantidad de trabajo realizado)
Clculo de velocidad basado en el tiempo que hizo
ayer y clculo de velocidad basado en das-hombre
disponibles y factor de dedicacin.
Cmo puede el Dueo de Producto alterar la decisin del
equipo?
Una es re-priorizar. Si le da al elemento D la mayor
importancia, el equipo se ver obligado a aadirlo al Sprint
en primer lugar (descartando en ese caso la historia C).

La segunda opcin es cambiar el alcance reducir el

alcance de la historia A hasta que el equipo crea que la
historia D podra caber en el Sprint.
La tercera sera dividir una historia. El Dueo de Producto
podra decidir que hay algunos aspectos de la historia A
que no son tan importantes, as que dividira la historia A
en dos historia A1 y A2 con diferentes niveles de
importancia.
Es importante que el dueo de producto y el equipo estn de acuerdo
en una definicin clara de terminado. Est terminada una historia
cuando todo el cdigo ha sido chequeado? O est terminada cuando
se ha instalado en un entorno de pre-produccin y ha sido verificada
por un equipo de pruebas de integracin? Probablemente se debera
tener un campo definicin de terminado en cada historia individual.
Es labor del encargado de pruebas asegurarse de que la intencin del
Dueo de Producto es correctamente entendida por el equipo, y que
el elemento est lo suficientemente terminado como para cumplir
con la definicin de terminado.
La estimacin es una labor de equipo, todos los miembros del equipo
deben involucrarse en estimar cada historia.
A la hora de planificar, normalmente no sabemos exactamente
quin implementar qu partes de cada historia.
Las historias normalmente involucran a bastantes personas y de
diferentes reas de experiencia (diseo de interfaz de usuario,
programacin, pruebas, etc.).
Para poder proporcionar una estimacin, un miembro del equipo
necesita comprender de alguna forma de qu trata la historia.
Pidiendo a todo el mundo que estime la historia nos aseguramos
de que cada miembro del equipo comprende de qu trata cada
elemento. Esto incrementa las posibilidades de que unos
miembros del equipo ayuden a otros durante el Sprint.
Cuando pedimos a todo el mundo que de estimaciones muchas
veces encontramos discrepancias en las que dos miembros del
equipo tienen estimaciones tremendamente distintas sobre la
misma historia.
Las historias no deberan ser demasiado pequeas ni demasiado
grandes (en trminos de estimacin). Casi siempre es posible dividir
una historia grande en historias ms pequeas, simplemente hay que
asegurarse de que las historias pequeas siguen representando
entregables con valor de negocio.
La diferencia de historias y tareas es muy simple. Las historias son
entregables de los que el Dueo de Producto se preocupa. Las tareas
son no-entregables, o aspectos de los que el Dueo de Producto no se
preocupa.
Ejemplo de divisin de una historia en historias ms pequeas:

Ejemplo de divisin de una historia en tareas:

TDD (Test Driven Development, desarrollo orientado a test) significa

que la primera tarea para casi todas las historias es escribir una
prueba y la ltima es refactorizar (es decir, mejorar la legibilidad
del cdigo y eliminar la duplicacin).
El primer SCRUM diario es esencialmente el lanzamiento, donde todo
el mundo decide por dnde va a empezar a trabajar.
Las historias tcnicas o elementos no-funcionales son cosas que
deben hacerse pero que no son un entregable ni estn directamente
relacionadas con ninguna historia especfica, y no son de valor
inmediato para el Dueo de Producto. Ejemplos:
Instalar un servidor de compilacin continua
Escribir una descripcin general del diseo
Refactorizar la capa de acceso a datos
Actualizar Jira (Seguimiento de Errores)

III. Como Comunicamos los Sprints

Utilizamos una pgina de informacin de Sprint para esto.

 A veces incluimos tambin informacin sobre cmo se demostrar

cada historia.

Tambin tenemos un panel de control en el Wiki, que enlaza con

todos los Sprints que estn teniendo lugar

Adicionalmente, el Scrum Master imprime la pgina de informacin de

Sprint y la pega en la pared fuera de la sala del equipo. Cuando el
Sprint se acerca a su final, el Scrum Master recuerda a todo el mundo
que se acerca la demo.

IV. Como Hacemos Pilas de Sprint

Usando un tabln de tareas.

Ejemplo de Uso del Tabln Diario

 Seales de Alarma

V.

Como Distribuimos la Sala de Equipo

Tratamos de organizar un rea como una esquina de diseo
explcitamente.

No hay mejor manera para obtener una visin general del sistema
que estar de pie en la esquina de diseo y observar ambas paredes,
entonces echar un vistazo en el ordenador y probar la ltima
compilacin del sistema.
La pared de diseo es slo una pizarra grande que contiene los
garabateos ms importantes sobre el diseo y la documentacin
impresa ms importante (diagramas secuenciales, prototipos de la
interfaz de usuario, modelos de dominio, etc.).
Se debe tener al equipo sentado juntos, lo cual significa:
Audibilidad: Cualquier miembro del equipo puede hablar con
cualquier otro sin tener que levantarse de su sitio.
Visibilidad: Todo el mundo puede ver a los dems. Todo el mundo
puede ver el tabln de tareas. No necesariamente tan de cerca
como para poder leerlo, pero si por lo menos verlo.
Aislamiento: Si todo el equipo necesitase levantarse y agruparse
para una animada y espontnea discusin sobre el diseo, nadie
fuera del equipo est tan cerca como para ser molestado. Y
viceversa.
Mantn al Dueo de Producto a mano.
Mantn a los Gerentes y Coachs a mano.
VI. Como Hacemos SCRUM Diarios
Nuestros Scrum diarios vienen a ser como describen las reglas.
Empiezan exactamente a su hora, cada da en el mismo sitio. No hay
nada mejor que eso.
El Scrum diario es muy importante. Es el punto donde la mayora de
sincronizacin ocurre y donde el equipo plantea obstculos
importantes. Sin embargo, si se hace mal pueden llegar a ser

realmente aburrido. La Gua de Scrum, para contrarrestar eso, plantea

las tres siguientes preguntas:
Qu hice ayer que ayud a nuestro equipo a cumplir el objetivo
del Sprint?
Qu voy a hacer hoy para ayudar a nuestro equipo a cumplir el
objetivo del Sprint?
Veo cualquier impedimento que yo o nuestro equipo impidan
satisfacer el objetivo del Sprint?
Cmo actualizamos el Tabln
Normalmente actualizamos el tabln de tareas durante los
Scrum diarios. Conforme cada persona describe lo que hizo el
da anterior y lo que har hoy, mueve los post-it en el tabln.
Conforme describe elementos no planificados, pone un pos-it
nuevo para cada uno de ellos. Conforme actualiza sus
estimaciones, escribe una nueva estimacin en el post-it
correspondiente y tacha la anterior estimacin. A veces el Scrum
Master hace todo esto mientras los dems hablan.
El propsito del scrum diario es seguir sincronizado, por lo que
suelen encontrar lo mejor para actualizar la tabla de "en tiempo
real" (es decir, durante la jornada de trabajo como sucede cosas)
y omitir estimaciones de tareas en su totalidad. De esta forma el
scrum diario se utiliza para comunicarse efectivamente en lugar
de administrar.

Normalmente actualizamos el tabln de tareas durante los SCRUM

diarios. Conforme cada persona describe lo que hizo el da anterior y
lo que har hoy, mueve los post-it en el tabln. Conforme describe
elementos no planificados, pone un pos-it nuevo para cada uno de
ellos. Conforme actualiza sus estimaciones, escribe una nueva
estimacin en el post-it correspondiente y tacha la anterior
estimacin. A veces el SCRUM Master hace todo esto mientras los
dems hablan.

d
VII.
VIII.
IX.
X.
XI.
XII.
XIII.
XIV.
XV.
XVI.
XVII.
XVIII.

D
D
D
D
D
D
D
d
d
d
d
d

XIX.