Gua Prctica Nivel Inicial

Tabla de Contenidos

Nota del Autor ........................................................................................ 3

Qu es la metodologa gil o Agile? ...................................................... 4
Qu es Scrum? ...................................................................................... 8
Un ejemplo prctico en SCRUM: .......................................................... 9
Todo bien, pero Qu es Scrum? .................................................... 12
Empirismo .......................................................................................... 12
Los Pilares de Scrum ............................................................................. 14
Compromiso ....................................................................................... 14
Concentracin .................................................................................... 15
Franqueza........................................................................................... 15
Respeto: ............................................................................................. 15
Coraje ................................................................................................. 16
El Equipo Scrum .................................................................................... 17
El Dueo de Producto......................................................................... 18
El Equipo de Desarrollo ...................................................................... 19
El Scrum Mster ................................................................................. 20
Lista de Producto en Scrum (Product Backlog) ..................................... 21
Los requerimientos del cliente ........................................................... 21
Qu contiene una Lista de Producto?............................................... 23
Cmo le ayudamos al Dueo del Producto a elaborar la Lista de
Producto? ........................................................................................... 24
Lista de Tareas de Sprint (Sprint Backlog) ............................................. 27
 Refinamiento de la Lista de Producto ................................................ 30
El Sprint o la Iteracin en Scrum ........................................................... 32
Planificacin del Sprint .......................................................................... 35
La Meta del Sprint ................................................................................. 36
El Scrum Diario Daily Scrum ............................................................... 38
Retrospectivas en Scrum ....................................................................... 41
Revisin del Sprint Sprint Review ....................................................... 44
Tpica Agenda: Reunin de Revisin ................................................... 46
KANBAN ................................................................................................ 48
Nota del Autor

Muchas gracias por ser parte del Proyecto de Cadena Crtica.

Este es la primer gua, de las tres que estn en carpeta sobre el tema Agile & Scrum.

Aqu vas a encontrar las definiciones formales pero tambin muchos consejos
prcticos aprendidos de aos trabajando en este tipo de proyectos. Espero que te
resulte entretenido.

Si no has descubierto esta gua a travs de www.cadenacrtica.com, te invito a que

te acerques y descargues todo el material que te parezca interesante.

Atentamente

Carlos Diaz Calvi

Qu es la metodologa gil o Agile?

Dicen que el resultado de un proyecto est ntimamente ligado con la calidad de

las relaciones entre los miembros del equipo. Quizs lleven razn.

Lo cierto es que en los proyectos que existen equipos en los

que da gusto trabajar, y otros en que no vemos la hora de
volver a casa, o que se termine de otra vez. Si eso afect la
calidad de mi trabajo, no lo s. Pero ciertamente no tena
ms ganas de estar all.

Otras veces son factores externos los que hacen el proyecto insufrible. En particular
proyectos largos, donde el objetivo se pierde, y ms que avanzar estamos da tras
da luchando con estructuras muy fijas, etapas, documentacin, plazos tallados en
piedra que fueron poco realistas desde su concepcin; a veces meses antes.

De ah que surgi una nueva forma de trabajar; de esto ya casi quince aos: La
metodologa gil. Aunque algunos tambin la llaman XP (Extreme Programming), o
Programacin Extrema, entre otros nombres.

Bsicamente la palabra gil, es usada para englobar una estrategia de desarrollo

de Software que tiene como premisas la estrecha colaboracin de los equipos, los
ciclos de desarrollo y el compromiso del equipo como un todo.

Sigue los lineamientos de las proposiciones escritas en el Manifiesto gil:

1. Los Individuos e interacciones por sobre los Procesos y Herramientas

2. El Software Funcionando por sobre la Documentacin Extensiva
3. La Colaboracin con el Cliente por sobre la Negociacin Contractual
4. La Respuesta Ante El Cambio por sobre el Seguir un Plan

El Manifiesto gil da ms importancia a los tems de la izquierda que a los de la

derecha, pero ambos siguen siendo necesarios.
Y hace nfasis en los siguientes principios

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega

temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardas del
desarrollo. Los procesos giles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos
meses, con preferencia al periodo de tiempo ms corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de
forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que
darles el entorno y el apoyo que necesitan, y confiarles la ejecucin del
trabajo.
El mtodo ms eficiente y efectivo de comunicar informacin al equipo de
desarrollo y entre sus miembros es la conversacin cara a cara.
El software funcionando es la medida principal de progreso.
 Los procesos giles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
La atencin continua a la excelencia tcnica y al buen diseo mejora la
Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
Las mejores arquitecturas, requisitos y diseos emergen de equipos auto-
organizados.
A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para
a continuacin ajustar y perfeccionar su comportamiento en consecuencia.

Scrum es uno de los mtodos giles que se desarrollaron tras el manifiesto.

Qu es Scrum?

Confieso que hasta hace muy poco yo pensaba que era una de esas formas de
trabajo, medio bohemia y "a lo que salga, que poda ser utilizada solo en empresas
pequeas, con proyectos poco importantes. Pero en realidad Qu es Scrum?

Todos los proyectos que vena haciendo yo en consultora, por ms de quince aos,
fueron solo en Cascada, y no solo eso: Cascadas muy pero muy elaboradas, como
la de la Compaa de Energa, que tena su propio manual de metodologas tipo
PMP para la entrega de proyectos.; eso sobre el Manual que ya llevaba yo de mi
propia empresa de como entregar proyectos en cascada segn nosotros. PERO
al final - ESTABA EQUIVOCADO AL PENSAR AS.
Tuve oportunidad de hacer cursos de SCRUM, tanto como DESARROLLADOR como
tambin de SCRUM MASTER (el que facilita y lleva a trmino cada una de las
iteraciones); el Jefe de Proyectos de la forma de trabajo SCRUM.

Luego tuve la suerte de trabajar dentro de un proyecto gil por un par de

iteraciones. Y al final tuve que ir con una pala a enterrar todos mis preconceptos y
malas ideas sobre el tema.

Es un marco de trabajo magnifico.

Un ejemplo prctico en SCRUM:

Para que lo entendamos con claridad. Una vez que tenemos el objetivo que nos da
el cliente (una pgina web, una serie de componentes, lo que sea), debemos
sentarnos a preparar el proyecto Scrum, conseguir el equipo adecuado, y dividir el
trabajo que nos pide el Dueo del Producto (Product Owner, o PO) normalmente
el cliente - , trozndolo en tareas ms pequeas en una Lista de Producto (Product
Backlog). Todo el equipo hace un ejercicio de estimacin de esfuerzo para cada una
de esas tareas, al menos las iniciales. Se decide cuantos Sprints (o Iteraciones)
haremos, de acuerdo al tiempo de proyecto, y por ende cuantas Entregas (Releases,
a produccin). Por ej.: Un proyecto de 8 semanas, con Sprints de dos semanas y
dos releases, una a la 4 (cuarta) y otra a la 8 (octava) semana.

Entonces cada lunes que comienza un sprint de dos semanas, se rene el equipo y
elige que tareas de la Lista de Productos va a realizar durante esas dos semanas, en
esa iteracin. Las tareas se reparten intentando cubrir las prioridades dadas por el
Dueo del Producto, pero no hace falta tomar la #1. Entonces de una lista de 100
tareas totales, elegimos 10, por ejemplo, de distinta complejidad. La estimacin del
esfuerzo que hicimos antes nos permite intuir que podemos hacer entre todos los
del equipo unas 2 tareas complejas, 4 de mediana complejidad, y 4 simples.

Entonces cada uno trabaja en esas tareas con el objetivo de terminarlas bien, de
darlas por Terminada, testeada, integrada, potencialmente entregable al usuario
final (sino no se considera terminada por ms que casi casi ya este). Hay reuniones
muy cortas todos los das llamada el Scrum Diario (el Daily Scrum), y cada miembro
del equipo tiene la oportunidad de contar lo que hizo el da anterior, lo que espera
hacer hoy, y que obstculos le preocupan. Es tarea del Scrum Mster el quitar esos
obstculos del camino (llamados tambin impedimentos); luego se encarga de
promover el dialogo, facilitar el trabajo.. y por ultimo no menos importante
ocuparse de escudar/proteger el equipo de cualquier interaccin con el mundo
exterior, el cliente, o nuevos requerimientos, hasta que las dos semanas se
terminen.

Al final del Sprint, o Iteracin, (al final de la segunda semana) se presenta lo

Terminado y solo lo terminado, nada a medias al Dueo del Producto, que da
sus impresiones; se realiza luego otra reunin de Retrospeccin para hablar todos
con honestidad y decir que se hizo mal (estimaciones por ejemplo), y como mejorar
esas cosas. Las lecciones aprendidas. Y por ejemplo, decidir que la prxima
iteracin tomaremos mas o menos trabajo respecto al esfuerzo que hemos
calculado. Esto define lo que es la Velocidad del equipo (podramos llamar
productividad).

Entonces cuando empiece el prximo Sprint, el lunes siguiente, el ejercicio se

vuelve a repetir, la toma de tareas pendientes, la re-estimacin de esas tareas
basndose en lo que hemos aprendido, y a trabajar nuevamente.
Todo bien, pero Qu es Scrum?

Empecemos por el principio, pero no voy a hacer historia, tranquilos.

Todos conocemos de la metodologa en Cascada (o Waterfall) para la entrega y

desarrollo de proyectos, esa que va paso a paso, desde la toma de requerimientos,
control, ejecucin, test, y produccin, bsicamente. Pues lo que tiene de efectiva,
lo tiene de aburrida. Y tienda a matar lisa y llanamente a la creatividad. De ah
que grandes empresas se hayan planteado utilizar metodologas ms dinmicas,
agiles y entre ellas, la ms usada es esta, llamada SCRUM.

Al ser un marco, no una metodologa que hay que seguir a rajatablas, SCRUM puede
ser adaptado a las necesidades del proyecto, es flexible, y tiene en la mira
permanentemente el tema de la mejora incremental del producto que se pretende
entregar.

Entonces, en vez de tener que esperar hasta la Etapa de Produccin (o

Mantenimiento), dentro de varios meses, lo que SCRUM promueve es que al final
de cada iteracin (o Sprint) haya una serie de componentes que el dueo del
producto pueda presentar a los usuarios; esto es en una, dos o tres semanas, y
entonces volver a repetir el proceso y entregar algo mejorado luego, y as
sucesivamente.

Empirismo

Es la palabra clave que describe de que se trata SCRUM. Que en realidad significa
que conoceremos mejor aquello que experimentamos, por tanto iremos
mejorando nuestra calidad, cantidad, capacidades, y muchos otros parmetros tras
cada iteracin del proyecto.

Y entonces se apoya en tres pilares que hay que tener siempre en cuenta:
TRANSPARENCIA, INSPECCION y ADAPTACION

Transparencia:

Que todos los interesados, el equipo, el dueo del producto (el cliente); todos
sepan cmo est la situacin en cualquier momento dado. Que las reglas sean
claras, por ejemplo la de los criterios que usaremos para dar por Terminado un
trabajo. Tiene que haber sido testeado? Tiene que haber sido revisado por un
colega? etc. Todo muy claro, si es posible, impreso y a vista de todos en la oficina.

Inspeccin:

Que tenemos que controlar, revisar, permanentemente como estamos ejecutando

los procesos y utilizando los artefactos que nos provee la tcnica SCRUM. No tan
frecuente como para que lleve mucho tiempo, pero lo suficientemente efectiva
como para que cada nueva iteracin (o Sprint) notemos una mejora.

Adaptacin:

Como resultado de la Inspeccin, quizs tengamos que cambiar, y eso es muy

bueno. Cuanto antes lo hagamos, mejor.
Los Pilares de Scrum

Lo primero que me viene a la cabeza cuando pienso en los Pilares de Scrum es

precisamente una imagen de una batalla de caballeros honorables. El rival, en este
caso, sera la sobre-planificacin.

Para trabajar en un proyecto Scrum tenemos que entender cules son los pilares
de los proyectos Scrum. Y estos son: Compromiso, Concentracin, Franqueza,
Respeto y Coraje... lo necesario para ir a cualquier batalla.

Es importante que entendamos porqu son fundamentales:

Compromiso
Que el equipo tenga un deber con la calidad; con la colaboracin y el deseo de
aprender e intentar ser cada da mejores, ms eficientes en su trabajo. Que no sea
una obligacin pero un acuerdo ser profesionales, auto-organizarse, y el
compromiso de entregar un software funcional, ni ms ni menos.

Sentirse atados a la definicin de trabajo Terminado, y qu es lo que significa

para el resto del equipo. Jurarse entregar un producto de valor al cliente; y
finalmente, el compromiso a tener autocritica, mirar como grupo hacia adentro y
sacar las mejores conclusiones y lecciones para el prximo ciclo.

Concentracin:

Y foco en lo que sabemos, en nuestras capacidades. Tambin en lo ms importante.

Y principalmente en aquellas cosas simples que agregan valor a nuestro trabajo.
Desmontar el bosque, rbol a rbol.

Franqueza:

Ser transparentes sta es una palabra clave en Scrum -. Ser sinceros en el estado
actual de nuestro trabajo. Y ser abiertos a dar una mano al compaero que puede
necesitarla. Dar opiniones leales, y aceptar valoraciones de nuestro trabajo por
parte de otros miembros del equipo.

Respeto:
Estar siempre consciente que todos somos distintos. Y en organizaciones globales,
especialmente, el hecho que los miembros del equipo pueden provenir de culturas
distintas. Y, en particular, respetar la experiencia y forma de pensar del otro; sus
derechos y sus responsabilidades.

Coraje:

Mostrar audacia por ejemplo en no hacer una tarea que no aporta ningn valor
al producto final. Bravura en ser sinceros y transparentes, aunque nos afecte.
Admitiendo que nadie es perfecto, y que podemos equivocarnos Y cambiar de
rumbo si fuera necesario. Y, por ltimo, en saber pedir ayuda.
El Equipo Scrum

Vaya diferencia de roles para un Jefe de Proyectos, el participar en un proyecto

Scrum. Pasas de ser el que toma las decisiones a ser un pobre tipo que la misma
metodologa quiere hacer desaparecer.

No lo dicen abiertamente, pero los creadores de SCRUM tienen en claro que se

quieren sacar a los Jefes de Proyectos de encima. Un buen equipo Scrum es auto
gestionado, auto controlado, se inspecciona a si mismo y elige como mejorar para
la prxima iteracin (o sprint).

El equipo Scrum consta de tres roles muy bien definidos:

 El Dueo del Producto (o Product Owner, o PO)
El Scrum Mster (el Facilitador)
El Equipo de Desarrollo (Development team). y una muy buena aclaracin:
En Scrum, la palabra Desarrollador no connota a un Programador, todos
desarrollan algo en Scrum, ya sea un experto en Bases de Datos, o un
Arquitecto. En s, el Equipo de Desarrollo es el que trabaja en cada tem y
lo desarrolla.

Los equipos auto gestionados eligen ellos que trabajo hacer; cmo hacerlo; y que
criterios usar para darlo por Terminado en cada Entrega Incremental

La idea es que un equipo Scrum no necesite de otras personas (externas) para

entregar el producto/programa objetivo.

El Dueo de Producto

No hablamos de un equipo, siempre de una persona, incluso cuando esta sea la

cabeza visible de un equipo del cliente, o de analistas de negocio, detrs de l.

Lo dicho, normalmente es parte del cliente, pero puede ser una persona que
conoce muy bien el negocio, y el sistema a ser entregado; lo suficiente como para
definir granularmente las tareas a ser completadas. Es la nica persona que es
RESPONSABLE de gestionar la Lista de Producto (Product Backlog) o sea, la lista
discreta de tareas que el Scrum Mster y el Equipo de Desarrollo debe entregar
sprint a sprint. Aunque puede delegar esa tarea, la responsabilidad no se delega.

Entre sus objetivos estn:

 Crear y mantener la Lista de Producto
Ordenarla y Priorizarla
Clarificarla, que nadie tenga dudas, y todos entiendan cada tem.

Al ser el nico responsable, es tambin el nico que puede venir con nuevos
requerimientos de parte del cliente. Y es trabajo del Scrum Mster de controlar que
esos nuevos pedidos no interfieran con lo que el equipo ya esta haciendo en este
periodo (sprint)

El Equipo de Desarrollo

Son las personas que tienen que entregar las tareas de cada iteracin o sprint en
un formato Terminado. No a medias tintas.

Se trata de un equipo multidisciplinario y jerrquicamente plano. No hay ttulos

para nadie, todos son Desarrolladores, aunque haya arquitectos, programadores,
testers, etc.

No existen tampoco sub-equipos. Y todos, TODOS, son responsables del objetivo

del sprint, por ms que se distribuyan las tareas. As que idealmente tienen que
ayudarse entre s.

En cuanto a su nmero, se acuerda que tiene que estar entre 4 y 9 miembros (ni
tan pocos como para que haya problemas de capacidad al realizar las distintas
tareas, ni tantos como para que no puedan trabajar en equipo). A esto hay que
agregarle que no podemos agregar nuevos miembros durante el sprint porque
rompe con la sinergia del grupo (y obligatoriamente debemos re-comenzar el
sprint si as fuera)
El Scrum Mster

Aunque exista la tentacin de pensarlo como un Jefe de Proyectos, el Scrum Mster

es un Facilitador. Alguien que se encarga de que todos los miembros del Equipo
Scrum se adhieran a su marco de trabajo. Es un lder AL SERVICIO del equipo.

Entre otras tareas tiene que:

Ayudar al Dueo de Producto a lograr una Lista de Producto aceptable.

Facilitar durante los eventos del Scrum (las reuniones, etc.)
Gua (no ordena) al Equipo de Desarrollo para que se auto gestione
Eliminar obstculos que el Equipo vaya encontrando.
Guiar a la Organizacin, a la Compaa, en lo que significa un proyecto Scrum,
y manejar sus expectativas.
Motivar a que haya mejoras en cada iteracin.

En otras palabras, es quien debe dar la cara ante la Organizacin, pero por sobre
todo llevar el librito bajo el brazo para explicar una, y mil veces, que es Scrum y
cmo sacarle mayor valor a la experiencia de utilizarlo.
Lista de Producto en Scrum (Product Backlog)

Los requerimientos del cliente

No hay nada peor en Scrum que tener un Dueo de Producto (Product Owner) que
no le da importancia a la Lista de Producto en Scrum (Product Backlog).

Recordemos, la Lista de Producto es una lista ordenada de tareas (o en realidad:

acciones) que son necesarias para completar el producto final. Esto es, creacin del
webservice, por ejemplo, o creacin de la pantalla principal.

La importancia de la Lista de Producto radica que en Scrum es el nico listado

de Requerimientos vlido.
Se puede tener un mal Dueo de Producto (o inexperto); para eso est el Scrum
Mster, para ayudarlo a entender y aduearse de ese listado de requerimientos y
su priorizacin. El Dueo de Producto es el nico responsable de la Lista de
Producto, de su contenido, su disponibilidad, y el ordenamiento, claro.

Cada tem de la Lista de Producto sera el equivalente al WBS (Work Breakdown

Structure) o EDT (Estructura de Decomposicin de Trabajos) en los sistemas de
Cascada.

En definitiva: El listado de todo lo que hay que hacer, componente por

componente, pantalla por pantalla.
Qu contiene una Lista de Producto?

En una Lista de Producto suele contener caractersticas, funciones, requerimientos,

mejoras y correcciones que an estn pendientes para completar el sistema (o
producto). Obviamente de ese listado saldrn las tareas que elegiremos en cada
Sprint o Ciclo de nuestro proyecto Scrum.

Cada uno de esos items suele llamarse PBI (Product Backlog Item) o ILP (tem de la
Lista de Producto).
Cada Item debera tener las siguientes caractersticas:

Deben estar expresados en un lenguaje claro (tanto para el equipo Scrum

como para el negocio del cliente.
Tener valor esto es fundamental -. Recordemos que en Scrum no hacemos
nada al divino botn.
Puede ser creado o desarrollado por (casi) cualquiera.
Deben ser propiedad del Dueo de Producto.
Deben estar ordenados de una forma coherente para alcanzar el objetivo.
El esfuerzo debe ser estimado por el Equipo Scrum (no por el Dueo)

Cmo le ayudamos al Dueo del Producto a elaborar la Lista de Producto?

Aunque un PBI puede ser una pantalla, un requerimiento, o un error-bug incluso

una historia de usuario, no es sencillo a veces obtener un listado de parte del
cliente. Por eso es importante que el Product Owner el Dueo de Producto sea
realmente un Analista de Negocio (Business Analyst), o alguien con profundo
conocimiento de las necesidades del cliente.

Una buena forma de lograr descomponer la solucin es mediante el uso de

Historias de Usuario, a las que le dedicaremos un artculo en breve.

Mediante las historias de usuario que son de un nivel muy alto podemos
extrapolar acciones, y de esas acciones, finalmente tareas (que son las que
necesitamos en nuestro PBI.
Las Historias de Usuario, en general tienen una estructura estable: Como un <tipo
de usuario>, necesito <alguna funcionalidad> con la finalidad de <razn o
resultado>.

Por ejemplo: Una historia de Usuario podra ser:

Como usuario, necesito poder enviar un correo electrnico, con la finalidad de

confirmar la participacin del evento.

Esto nos lleva a inferir las siguientes acciones:

1. Pantalla para enviar correo.

2. Detalles del formulario con Seleccin del Evento
3. Botn de Envo y funcionalidad.

Y de esas, podemos concluir los siguientes tems.

1. Agregar opcin de enviar correo (botn)

2. Diseo del Botn
3. Codificar la Re-direccin a la nueva pantalla
4. Testear Botn
5. Crear formulario-pantalla para detalles del correo
6. Configurar la Base de Datos para los nuevos campos
7. Crear Procedimientos Almacenados para la n
8. Agregar campos y opciones a la pantalla de acuerdo a documento de diseo.
9. Comprobar que el destinatario del correo es usuario valido.
10.Configurar textos, ttulos, contenidos y validaciones del correo electrnico.
11.Codificar el envo del correo.
12.Testear el formulario
13.integrar la solucin
14.Hacer pruebas del correo
15.

Y as seguiramos pero ya son tems accionables por parte de los desarrolladores

(diseadores, expertos de base de datos, programadores y testers).

Imagen de Ejemplo:

Ejemplo de Descomposicin de Historia de Usuario a Tarea.

Lista de Tareas de Sprint (Sprint Backlog)

La Lista de Tareas de Sprint (o de una iteracin o ciclo) est muy unida a la Rapidez
(Velocity) de nuestro equipo. Cunto trabajo puede dar por "Terminado" en el
perodo de tiempo convenido del Sprint.

Hablaremos de la Rapidez en otro artculo, pero debo insistir en cun importante

es: La Rapidez o Velocity es lo que nos va a decir que podemos tomar slo cuatro o
cinco tareas del total que hay en la Lista de Producto.
Por definicin una Lista de Tareas de Sprint (Sprint Backlog) son una serie de tems
seleccionados (PBIs), incluyendo un "plan" para entregarlos, o terminarlos al
finalizar el Sprint.

En realidad es tambin un "pronstico" en s mismo, que incluye un subconjunto

de funcionalidades que el equipo espera terminar en este ciclo o incremento, y el
trabajo que hay que hacer para lograrlo.
 Podemos ver el trabajo pendiente por cada da del Sprint. Cada da se
actualiza la Lista de Tareas de Sprint, con el trabajo pendiente.

El plan debe tener suficiente detalle como para poder ser seguido, evaluado,
mientras avanza su desarrollo durante el Sprint. Para eso es comn utilizar una
pizarra con columnas, as nos vamos ubicando en qu estado est cada tem en un
momento dado.

Cada vez que se identifica una nueva tarea (por ejemplo: la correccin de una
funcionalidad entregada anteriormente, un nuevo bug, puede ser agregada a la
Lista de Tareas del Sprint. Slo el Equipo de Desarrollo puede agregar tareas
durante el Sprint (nunca el Dueo de Producto, que debe saber esperar; ni mucho
menos el Scrum Mster, que est slo para facilitarle las cosas al equipo).

La Lista de Tareas de Sprint es muy visible, ya que casi siempre est puesta en la
pared, con sus papeles de colores movindose hacia la columna de "Terminado".

Siempre hay riesgo que el equipo tome demasiados tems (o por el contrario muy
pocos) durante los primeros ciclos o Sprints. Esto sucede hasta que encuentre su
"Rapidez" y pueda pronosticar mejor cunto trabajo puede realizar en ese perodo.

En el ejemplo que vemos a continuacin, el Grfico de Pendientes (Burndown

Chart), que veremos en otro artculo, nos indica que inicialmente el equipo tom
demasiadas tareas, y por tanto no poda completarlas. Entonces, de acuerdo con el
Dueo de Producto, y con tal de entregar varios "Terminados" al final del ciclo,
accede a quitar algunos tems de la Lista de Tareas de Sprint y as lograr los
objetivos propuestos.

Cmo lograr una mejor seleccin de las tareas que vamos a hacer en un Sprint?:
Una alternativa son las reuniones de Refinamiento de la Lista de Producto

Refinamiento de la Lista de Producto

Como sabemos, la mayora de las reuniones en Scrum tienen la duracin muy

restringida, para que el equipo empiece a trabajar cuanto antes en las tareas.

Hay una nueva corriente de pensamiento que cree que en crear una reunin
semanal peridica, de "Refinamiento de la Lista de Producto". Una reunin
donde todos (incluso el Dueo del Producto) puedan sentarse a discutir y agregar
detalles a cada una de las tareas. Hay un alto riesgo que ser termine con ms tems
en la cola de tareas, as que hay que estar muy atentos.

Esta reunin puede ayudar a la hora de elegir las Tareas que vamos a incluir en
un Sprint.

El objetivo de este refinamiento tiene que ser:

Una lista de tareas bien definidas. No es necesario que sean todas las del
Sprint
o Logran una buena estimacin del esfuerzo.
o Un entendimiento profundo de cada tarea, al punto que el equipo de
desarrollo pueda tomarla sin miramientos,
Importante: No perder mucho tiempo en el diseo. Recordemos
que en Scrum, todo es incremental.
o Dividir las tareas donde haga falta.
o Agregas Historias de Usuarios y Detalles.
Lograr que haya suficientes detalles en los tems de la Lista de Producto, que
el equipo pueda tomar esos tems en - por los menos - dos futuros Sprints.
El Sprint o la Iteracin en Scrum
No existira Scrum si no fuera por los Sprints. Eso est claro.

El Sprint o Iteracin (o Ciclo) es el Evento ms importante y primario de la

metodologa Scrum.

El Sprint es el corazn de la prctica Scrum, un evento con un tiempo acotado (de

hasta un mes) en el que se debe entregar "Terminado" una serie de componentes.
Terminado se entiende como aceptable por el cliente, debidamente testeado y
probado (aunque sea limitado en sus funcionalidades). Todo lo que se entrega,
tiene que estar funcionando. Lo que no est "Terminado" no se muestra.

Los Sprints deben tener una duracin estable durante a lo largo del proyecto. Y un
nuevo Sprint comienza ni bien termina el anterior, tantas veces como se haya
decidido al principio.
Dentro del Sprint se definen una serie de Eventos que son todos fundamentales:

La Planificacin del Sprint

La Ejecucin en s misma.
Los Scrums Diarios (Reuniones rpidas de alineacin)
La Revisin del Sprint.
La Retrospectiva del Sprint.

Durante un Sprint, no puede haber cambios que afecte el Objetivo del Sprint. Por
ejemplo, no puede agregarse ms gente al equipo - por ms que se pudiera pensar
que eso es algo favorable. La naturaleza dinmica y complementaria de las
capacidades del grupo hace que el agregar un nuevo componente rompa la
relacin del grupo (ya que no sabemos probadamente que capacidad aporta).

Tampoco deben bajarse las expectativas de calidad, durante el Sprint. Lo que se

considera como "Completo y Terminado" es constante.

Lo nico que es flexible es la Negociacin de los Objetivos (en particular de las

Tareas del Sprint), junto al Dueo del Producto, en caso que se note la necesidad.

De cierta forma, podemos considerar cada Sprint como un mini-proyecto en si

mismo; un "mini-proyecto" con un mes de horizonte, como mximo.

La razn por la que se limita la duracin mxima de un Sprint a un mes es porque,

sencillamente, el alargar provocara ms complejidad, mayor riesgo - por lo menos
eso se ha comprobado. Es mejor tener horizontes cercanos para poder sentarse a
revisar, discutir, corregir errores y comenzar otro nuevo Sprint.
Quizs esa sea la caracterstica ms loable de los Sprints cortos: Mayor
predictibilidad, ya que vamos a estar inspeccionando el progreso y adaptndonos
a los cambios al menos una vez al mes (normalmente dos).

Tambin eso implica que el riesgo de prdida - o el costo de lo que se haya hecho
mal, decrece a un mes.

Una prctica comn es comenzar un Sprint los martes, mircoles o jueves. Ya que
los lunes y viernes son considerados das menos productivos.

Tambin, cuando los equipos estn repartidos en diferentes ubicaciones

geogrficas (no recomendado). Es comn que las reuniones de Revisin de Sprint
(muestra de resultados), la de Retrospectiva (correccin de errores) y la de
Planeamiento del - prximo - Sprint, se realicen al mismo tiempo.

Pero no es necesario que estas se lleven a cabo el mismo da, ni mucho menos.
Planificacin del Sprint

Como ocurren en los proyectos en Cascada, cuando se planifica mal, se acaba mal.
La Planificacin del Sprint es igualmente importante. Despus de todo es - como
decamos antes - un mini proyecto en s mismo.

El trabajo que tenemos que realizar durante una Iteracin, o Sprint, se planea
precisamente en la reunin de Planificacin del Sprint. Todo el equipo debe
participar: El Equipo de Desarrollo, el Dueo del Producto y el Scrum Mster.

Como todos los dems eventos en Scrum, la reunin de Planificacin del Sprint
tiene un tiempo muy acotado, en promedio de 8 horas por cada mes de Sprint (as
que si tenemos Sprints de dos semanas, debemos sentarnos en esta planificacin
el primer da, y por un mximo de cuatro horas).
Por cierto, no s si lo mencion antes, en Scrum el "Resultado" que se entrega al
final de cada Sprint se llama "Incremento".

Los Objetivos de la Reunin de Planificacin son:

Decidir qu vamos a entregar (Terminado) en el Incremento resultante del

Sprint.
Cmo vamos a trabajar para lograr alcanzar ese Incremento?

La Meta del Sprint

Despus que el Equipo de Desarrollo haya decidido que tems incluir en la Lista de
Tareas del Sprint, tienen que ponerle nombre a la "Meta del Sprint". Por
ejemplo: Mejorar la experiencia del usuario en las Pginas de Mis Pedidos.

La Meta del Sprint es un objetivo que se debera alcanzar, si se finalizan todas las
tareas que pusimos en la Lista, y proveen una gua al Equipo de Desarrollo
como referencia de porqu est creando ese Incremento en particular. Una
orientacin y motivacin.

Al mismo tiempo, una buena Meta de Sprint, da al Equipo de Desarrollo cierta

flexibilidad en cuanto a la funcionalidad que tiene que incluir en el Sprint, y por
tanto intenta ser lo que "une" todo lo que los diferentes miembros del equipo est
haciendo por separado.

Otros ejemplos:
 Hacer que la aplicacin funcione tanto en la Web como en un telfono mvil.
Mejorar la habilidad del Panel de Control
Mejorar los tiempos de respuesta de la Aplicacin.

Como vemos, las Metas de Sprint suelen ser bastante "generales" o difusas, Y AS
DEBEN SER. La idea es que si bien nos podemos ver forzados a quitar un tem de
la Lista porque no llegamos con el tiempo, podamos decir al Dueo del Producto,
en la Revisin del Sprint, que la Meta ha sido cumplida.
El Scrum Diario Daily Scrum
El Scrum Diario, el momento en que comentamos cmo va la serie o la peli que
vimos la noche anterior. Naah, es broma. Es en esta mini reunin (de quince
minutos, no ms) en la que nos ponemos al da de cmo va el proyecto.

Consejo: El scrum diario tiene que ser siempre en el mismo lugar y a la misma
hora. Es ms, propongo hacerlo de pie, que sea dinmico, frente a la pizarra. Que
nadie se ponga cmodo.

En el scrum diario tienen que estar todos, el Dueo del Producto, el Scrum Mster,
y claro... el Equipo de Desarrollo. Puede haber otros invitados, pero estn slo para
observar. Es el momento donde se discute todo lo que hay que hacer en el da, el
momento de informarse qu es lo que tiene que pasar hoy.

Cada miembro del equipo tiene que responder a tres preguntas:

 Qu hiciste ayer?
Qu planeas hacer hoy?
Qu obstculos tienes en el camino para hacerlo?

El scrum diario - o daily scrum - no es para "controlar" lo que cada uno est
haciendo. Sino el momento donde cada miembro del Equipo de Desarrollo se
compromete, cara a cara, a hacer lo que dice. Este punto es muy importante, es
donde nuestro compromiso queda grabado en la memoria de todos. No podemos
fallarles.

Otra alternativa, en vez de ir persona por persona, es ir tem por tem en la Lista de
Tareas. Asi hay ms oportunidades de interactuar para cada persona.

Otro punto importante - si eres el Scrum Mster - es el de los impedimentos (u

obstculos). En los que tienes que aduearte de los problemas e intentar
solucionarlos. Ese es t trabajo. Si no lo puedes hacer inmediatamente te debes
encargar de pedir ayuda. Si algo no se puede resolver en 24 hs, el Scrum Mster
debe elevarlo en la compaa.

La reunin de scrum diario debe ser de 15 minutos, no ms. No hay que perder el
tiempo. Lo que necesite ms tiempo para ser discutido debe ser agregado al listado
de tareas y punto.

Y recuerda, si eres Scrum Mster, ests all slo para facilitar, no para gestionar ni
asignar tareas.

Si ves a alguien yendo a la reunin de scrum diario apesadumbrado, o sin ganas de

estar ahi. Es claramente una seal que hay problemas. La idea del scrum diario es
que salga todo el mundo motivado tras escuchar los progresos de los dems. Es
ms, procura tener chocolates, o caramelos, como premio. Hacer la reunin
entretenida.

Otro consejo que me han dado, que an no puedo llevar a la prctica, es el de NO

HACER CONTACTO CON LA MIRADA, con quin est reportando su trabajo. Lo de
hacer contacto visual es humano, natural, pero si as sucediera estaramos forzando
la imagen del manager-examinador a los miembros del equipo; y Scrum no se trata
de gestionar, sino de facilitar. Los miembros del Equipo de Desarrollo estn
reportndose a sus pares, no al Scrum Mster.

Y finalmente, como en toda reunin de Scrum, puedes jugar a darles el trabajo de

facilitador a otros miembros del equipo para crear "entendimiento" con el rol que
te toca como Scrum Mster.
Retrospectivas en Scrum
Cuando escuch por primera vez lo de Retrospectivas en Scrum supuse que cada
uno tena que ponerse a pensar en que hizo mal, o bien, como ir al confesionario...
y eso que hace rato no piso una iglesia. Una especie de momento de relajacin zen
para luego compartir lo descubierto con el equipo. Pero me encontr con algo
mucho ms interesante.

En Scrum, el proceso de Retrospectiva (que se hace al final del Sprint, luego de que
se enseasen los resultados al Propietario del Producto - el cliente -), es un ejercicio
para re-alinearse con las nuevas lecciones aprendidas. En particular, tiene que ser
una charla abierta, sincera y honesta, entre todo el equipo.

Preguntarse:

Qu funciono bien?
 Qu cosas deberamos intentar mejorar en la prxima iteracin (sprint)?
Qu lecciones hemos aprendido?
Y MUY IMPORTANTE: contarle al Scrum Master, el Facilitador, cuales son los
obstculos previstos (para que se ponga a trabajar en removerlos)

El objetivo es que gracias - y mediante - el ejercicio de Retrospectiva, todo el

equipo de Scrum se beneficie de un crecimiento sostenido, en calidad,
productividad, y motivacin.

Lo que suele suceder - lamentablemente - es que mucha gente dentro del proyecto
piense que el ejercicio de Retrospectiva no sirve para mucho, y entonces
desperdician ese tiempo (aunque suelen reservar ese espacio ya que creen que es
una de las partes necesarias - por definicin - de un Scrum).

Para no perder el tiempo en una Retrospectiva, tenemos que focalizarnos en lograr

Puntos de Accin por cada tem, decidir que vamos a hacer al respecto. Algo
debemos haber aprendido de la ltima iteracin (sprint). Si la respuesta a todo es
"Va Bien", "Hubo problemas", o expresiones no "accionables" o concretas, seguro
ser una prdida de tiempo.

La cuestin es no ver la Retrospectiva (en Agile, Cascada, lo que sea) como

una reunin OBLIGATORIA sino como una NECESARIA.

Hay varias formas de hacer las Retrospectivas entretenidas y hasta divertidas; hay
muchas diferentes tcnicas tambin, ninguna en particular ms til que la otra.
Como la de la Estrella de Mar (que veremos luego).
Pero tambin es un problema hacerlo "divertido"; Hay muchos consultores, o
programadores, que se toman sus trabajos muy enserio y que suelen esconderse o
desconfiar si ven alguna actividad de grupo que parezca divertida. Pero
necesitamos de esas cosas. Est claro.

Organizar una reunin de Retrospectiva no es fcil. Hay que crear el ambiente y

pensar en actividades para "extraer" la informacin y lograr puntos de accin. Una
buena alternativa, para jugar un poco con los roles, es asignar a una persona
distinta, cada tanto, para que haga de "Facilitador" de la Retrospectiva. Puede
darse cuenta lo complicado que es, o puede extraer otro tipo de informacin del
equipo.

No solo se trate de escuchar lo que el equipo dice, sino tambin de lo que no dicen,
de los gestos corporales, las inquietudes aparentes, o el tono de voz.

El consejo que Norm Kerth - un gur en estos temas - da, respecto a Retrospectivas,
es intentar que todo el equipo vaya a ellas con el pensamiento de que cada uno de
los dems presentes ha hecho lo mejor posible para lograr sus objetivos; evitar
estar a la defensiva, pensando en los prejuicios o pre-conceptos que tenemos de
esa persona, o que tienen una agenda (o plan ulterior) y que no es sincera. Es como
que nos pusiramos filtros, y realmente no "escuchamos".
Revisin del Sprint Sprint Review
Al fin y al cabo, lo nico importante en Scrum es lo que est "Terminado", lo que el
cliente puede empezar a usar ya mismo si quisiera. Para eso, debemos pasar la
Revisin del Sprint - Sprint Review. La reunin de "presentacin" del Incremento, o
en otras palabras, de lo que hemos logrado, del resultado del ciclo.

El objetivo de la reunin de Revisin del Sprint es la de inspeccionar el Incremento,

si es necesario volver a analizar la Lista de Producto (la lista general de tareas). Es
una reunin informal, de mximo cuatro horas al mes (o dos horas si nuestro ciclo
- o sprint - tiene dos semanas).

En esta reunin tiene que participar todo el mundo: El Dueo de Producto, el

Scrum Mster, el Equipo de Desarrollo... e incluso expertos del negocio, u otros
invitados que puedan dar una opinin al respecto.
Lo fundamental es que en la reunin slo mostraremos Software que est
funcionando. Que agregue valor al cliente. No mostraremos nada a medio
terminar.

Mi recomendacin es preparar la presentacin de forma que las pantallas se

muestren o proyecten desde un segundo monitor, en especial si estamos
mostrando algo en debugging. EVITAR QUE EL CLIENTE VEA EL CDIGO FUENTE en
todo momento. Otra opcin es capturar pantallas y hacer una presentacin
PowerPoint (aunque este ltimo punto, lo de preparar una presentacin, suele ser
muy discutido ya que va a contramano del carcter "informal" que se espera de la
reunin"

Como decamos, es sta una reunin informal, para mostrar progresos y captar
comentarios; refinar si acaso el Backlog.

Otros conceptos para tener en cuenta en la Reunin de Revisin del Sprint:

El Dueo del Producto es quien decide al final qu fue lo realmente

"Terminado" y lo que an no lo est.
El Equipo de Desarrollo discute cuales fueron los problemas que se
encontraron y cmo los resolvieron.
Hay que hacer una demostracin en pantalla de lo Terminado.
Discutir unos momentos cmo luce ahora la Lista de Producto, y qu
expectativas hay para el prximo Sprint con las experiencias del que acaba
de terminar.
Todos deben discutir sobre qu es lo prximo para hacer.
Recuerda: El resultado de esta reunin es una Lista de Producto (la general -
insisto -) refinada, y ya una buena idea de qu tems van a ser incluidos en la Lista
de Tareas de Sprint del prximo ciclo.

Es durante la reunin de Revisin del Sprint tambin que todos evalan si la META
del Sprint se ha cumplido o no. ??Recuerdan? La meta es aquel nombre - un tanto
genrico - con el que bautizamos el objetivo que tenamos para ese ciclo.

Y por ltimo, insistir en una premisa: No se trata de cmo funciona la pantalla o el

software en el que hemos trabajado, sino de qu valor tiene para el cliente, en qu
le es til. Hay que contarles historias, ejemplos, un poquito de actuar diferentes
roles para que se entiendan los beneficios. Un poco de Show, pero... a no olvidarse,
todo lo que se muestre tiene que estar funcionando.

Tpica Agenda: Reunin de Revisin

1. El Scrum Mster abre la reunin y recuerda a todos el objetivo de ella

o Muestra lo que se ha conseguido
o Cuenta historias, la experiencia del usuario
o Pide opiniones a los presentes. Qu piensan del producto?
2. El Dueo de Producto explica cules eran "sus objetivos" para ese sprint
o Describe la Meta del Sprint
o Explica por qu es tan importante esa meta para el negocio.
o Hace referencia a dnde estamos en el panorama del proyecto.
3. El Scrum Mster presenta el Sprint.
o Cuenta la historia de cmo fue todo durante el perodo. Con qu
problemas se encontraron, nuevos miembros del equipo, etc.
 o Da un estado del Sprint y cuenta qu tareas se completaron, y cules
se quitaron o modificaron.
4. Finalmente las Demos. El Equipo de Desarrollo elabora cada historia de
usuario.
o El presentador explica qu se intent hacer con esa historia de
usuario.
o Demostrar el funcionamiento en el sistema real.
o Responder preguntas.
o Repetir este punto por cada historia de usuario.
5. El Scrum Mster cierra la reunin.
 KANBAN

KANBAN
Un placer tener que escribir sobre Kanban. Pocas veces uno se encuentra con un
sistema "nuevo" - por as decirlo - que pueda agregar mucha productividad a un
equipo de trabajo. As de til result ser, en Proyectos giles, una pizarra Kanban.

Bsicamente el trmino Kanban viene de Japn y significa ms o menos "Tarjeta

Visual", y en s es un sistema que ya viene siendo usado hace sesenta aos en la
produccin de productos y el abastecimiento de partes. Ahora bien, poniendo esos
conceptos al servicio del software, nos encontramos con una metodologa de
trabajo que nos permite hacer que las componentes vayan "fluyendo", lenta y
sostenidamente, desde la concepcin hasta la produccin.

A ver si puedo dar un ejemplo:

En las metodologas giles, como en Scrum, una de las partes importantes de cada
ciclo o Sprint es cuando los desarrolladores escogen una tarea (o ms) de la Lista
de Pendientes. En Scrum esto se suele hacer de modo voluntario, de acuerdo a las
capacidades de cada persona en el equipo. Ellas se encargan de llevar esa tarea a
un nivel necesario (definido por lo que el equipo considera como "Terminado".
Hasta ah lo que sabamos, y nos iba muy bien.

En una pizarra Scrum, normal tenemos una columna para las tareas:

Pendientes / En Desarrollo / Finalizadas.

En Kanban, reemplazamos esa columna del medio "En Desarrollo" y la dividimos en

tantas columnas como nuestro "flujo de trabajo" o Workflow necesite, por ejemplo
en:

Pendientes / Especificaciones / Diseo / Ejecucin / Test / Finalizadas

Hasta ah no parece que hiciramos mucho ms, pero el secreto est en que, de
acuerdo a la capacidad de nuestro equipo, demos a cada columna un "Tope" de
capacidad. Por ejemplo que no podamos estar "Diseando" ms de tres
componentes en un momento dado, y que si quisiramos meter un cuarto tem,
deberamos mover a Ejecucin alguno. De esa forma se crea un flujo de tems que
se van "empujando" unos a otros, como si fueran una cadena de produccin hasta
que se den por finalizadas todas las tareas.
Terminaramos con algo as:

Pendientes (10)/ Especificaciones (3) / Diseo (3) / Ejecucin (4) / Test

(2) / Finalizadas

La ventaja que tiene este modelo es que vamos generando tems finalizados
constantemente.

Aqu algunos ejemplos (podemos ver arriba, donde est el nombre de la columna,
la cantidad de tems que puede aceptar)
La caracterstica principal que tiene Kanban, es que limita el trabajo que se puede
hacer en un momento dado. Es ms realista que otros paradigmas.
Los primeros - conocidos - en utilizar Kanban, aunque no lo llamaran as, fueron los
equipos de produccin de Toyota, con sus entregas "Just in Time" o JIT (en el
tiempo preciso). Los tems, ordenes, tareas, entran en una cadena de pasos que
fluye haca su entrega o culminacin, pero es consciente de las limitaciones que
puede haber para trabajar en un nmero de piezas o tems en una misma maquina
o proceso (para nosotros son columnas).

As como Scrum es muy bueno en limitar el nmero de tareas o trabajos que se

pueden terminar en un Ciclo o Sprint, Kanban es muy bueno para limitar el nmero
de tareas similares por tanto eliminado as mucho de los problemas de la
estimacin para todo el lote.

Para mi, personalmente, es una adicin a los conceptos de Scrum que mejora la
metodologa. Esto no es decir que Kanban es mejor que el Scrum tradicional. De
hecho, en la prctica, Kanban es ms lento, pero constante. A veces eso puede ser
importante para el cliente.

Otro gran valor de Kanban es que hace que el equipo de trabajo aprecie cun
importante es terminar lo que se comienza. Porque Kanban necesita que los tems
vayan movindose para hacer lugar a otros. Como una autentica cadena de
produccin.

Yo no veo la hora de empezar a usar Kanban en proyectos Scrum en el futuro. Estoy

seguro que mejora la moral del equipo.

Otra caracterstica que tiene Kanban es lo de las Retrospectivas un poco diferentes

a las que tenemos en Scrum. En Kanban las retrospectivas se llaman Kaizen (que en
japons sera algo as como "Mejora continua". Se diferencian de las tpicas
reuniones de Scrum en el hecho de que son ms positivas, pierden menos tiempo
en lo que fue mal y mucho ms en cmo ajustar cada columna, la capacidad y la
velocidad en la que podemos encarar el prximo ciclo. Mirando al futuro. Hay
menos gente a la defensiva, y por ende, los desarrolladores estn ms
entusiasmados.

La nica crtica que tiene Karban, en general, es que la estructura es tan dinmica
y la secuencia de pasos tan explcita, que se pierde un poco el sentido de urgencia
en algunas tareas. Muchos equipos optan por hacer otra lnea en la pizarra
marcando las urgencias y as contrarrestar ese efecto.
En conclusin: Si van a empezar un proyecto gil. Prueben con Kanban, al menos
un par de Sprints o Ciclos. Se pueden llevar una sorpresa muy agradable.
MUCHAS GRACIAS