managementPlaza Espaa jlvg@managementplaza.

Scrum:

Scrum es seguramente el marco Agile ms conocido y empleado;

alrededor del 70% de las empresas giles emplean Scrum, o una
combinacin de Scrum con otro sistema Agile como XP (eXtreme
Programming).

Es importante que entiendas que Scrum y Agile no son la misma

cosa. Agile es un concepto sobre el que se han creado muchos
marcos y metodologas, y Scrum es uno de ellos. En otras palabras,
Scrum es una manera de practicar o llevar la agilidad al mundo real.

Los sistemas Agile ms conocidos son:

- Scrum - existe desde finales de los 90. Es un marco muy simple y

ligero, por que se refiere a su estructura y requisitos.

- DSDM - tiene la misma edad que Scrum, y sobre todo es conocido

por su sofisticacin y por el hecho de haber sido diseado para ser
compatible con PRINCE2.

- XP existe desde 1999, y es conocido sobre todo para sus prcticas

giles (programacin por pares, desarrollo basado en pruebas,
propiedad de cdigo compartido, etc.)

- Kanban (ScrumBan) - Kanban es una tcnica utilizada

principalmente en la manufactura. Puede combinarse con sistemas
Agile, o convertirse en un sistema Agile integrando algunos
elementos adicionales.

Para aquellos de vosotros que estis interesados en comparar la

edad de los diferentes sistemas, a continuacin os dejo una sencilla
lista: PRINCE (1989), PRINCE2 (1996), PMBOK (1996), Agile Manifesto
(2001).
He mencionado varias veces el trmino "Agile", pero qu es? Cmo
lo definiras?

2. Muchas personas tienen dificultades para definir el

concepto "Agile", y para ser honesto, muchas personas no lo
comprenden correctamente. A m me parece que es muy simple: ser
Agile implica utilizar un sistema de desarrollo adaptativo, un lugar de
uno predictivo.

Bueno tal vez ahora tengamos dos problemas: 1) qu son los

sistemas adaptativos?, y 2) Qu son los predictivos? Vayamos paso a
paso.

El desarrollo predictivo se emplea cuando sabes exactamente el tipo

de producto que deseas crear, y es posible definirlo plenamente por
adelantado. Por lo tanto, lo que hacemos es predecir toda la
planificacin y el diseo del producto por adelantado. Luego nuestro
objetivo es seguir el plan y producir el producto previamente
diseado.

Comnmente se conoce como el mtodo "tradicional". En la industria

de TI, se le denomina como "cascada".

Bien, la cuestin es, por qu en algunos proyectos no podemos ser

predictivos? En tales casos, qu podemos hacer?

Lo veremos en nuestra prxima leccin.

3. Ayer estuvimos hablando sobre los sistemas predictivos. Cuando
no podemos usar un sistema predictivo, los adaptativos son una muy
buena opcin. Los sistemas adaptativos se conocen comnmente
como "Agiles" (Agile cuando se emplea el trmino en ingls).

Este sistema se utiliza cuando tenemos un resultado en mente, pero

no podemos estar seguros de qu tipo de producto puede crearlo, y
por lo tanto la "prediccin" no es posible. Es el caso, por ejemplo de
los mercados que cambian rpidamente, o cuando no es posible
entender realmente las necesidades del mercado o del cliente.

En este caso trabajaremos por ciclos. En cada ciclo se disea,

planifica, construye, y prueba un subconjunto del producto final que
debe quedar listo para su implementacin. Es decir, que al final de
cada ciclo proporcionaremos al cliente final o usuario, un
subconjunto del producto final sobre el que recibiremos un feedback.
En base a dicho feedback, comprenderemos mucho mejor cual deber
ser el resultado del prximo ciclo.

Los ciclos se ejecutan uno tras otro hasta que se genera el valor
suficiente, y estamos lo suficientemente cerca del resultado
esperado. Estos son los sistemas adaptativos, y es la idea que
subyace en la gestin de proyectos Agile.

Generalmente los sistemas giles se conocen como "modernos", en

comparacin con los mtodos de prediccin que se conocen como
"tradicionales". Bien, ahora que ya conoces la diferencia entre un
sistema adaptativo y uno predictivo, cul es tu opinin al respecto?

4.

Puedes imaginar que nadie en los ltimos 2.000 o 3.000

aos concibiera la idea de la Agildad? Yo no puedo. Simplemente no
me creo que haya sido inventado en los ltimos 20 o 30 aos.

Por supuesto que antes no tenamos nombres tan modernos como

Agile, o marcos de trabajo como Scrum, pero los conceptos estaban
all. Al menos, eso pienso yo.

La clave est en que en que los mtodos de trabajo predictivos han

sido considerados como la manera correcta de desarrollar los
proyectos durante los ltimos 100 aos. Ahora sin embargo, estamos
empezado a aceptar la adaptacin como la manera correcta de
hacerlo. Ese es realmente el cambio que hemos tenido en los tiempos
modernos, pero no hemos inventado nada nuevo.

Me encanta la agilidad, pero a diferencia de algunas personas, no

considero que los mtodos predictivos estn "equivocados". Ambos
son vlidos y debemos ser capaces de entenderse cual se adapta
mejor a nuestro proyecto.

OK, suficiente por hoy. Es hora de empezar a hablar sobre el marco de

trabajo Scrum, de acuerdo? Empezaremos maana, y lo haremos
hablando sobre cmo se inicia un proyecto Scrum.

5.

Cuando trabajamos con Scrum, lo primero que debemos hacer es

crear el "Product Backlog" o Backlog de Producto en castellano. Este
no es ms que la lista de caractersticas que hemos pensado para el
proyecto. Es lo mismo que si estuviramos hablando de la definicin
del alcance.

Recuerda que Scrum no es predictivo, por lo que no planificamos por

adelantado; en lugar de crear un completo y detallado Backlog del
Producto, simplemente aadimos los suficientes elementos para los
prximos ciclos (tambin conocidos como iteraciones o Sprints). A
continuacin, empezamos inmediatamente con el primer ciclo y
mantenemos el Backlog del Producto continuamente actualizado
("adaptativa"). Esto significa que iremos aadiendo o
eliminando elementos conforme surjan, o dejen de ser necesarios.
La simplicidad es uno de los principios giles. Por ello, preferiremos
crear el Backlog de Producto en un tablero fsico, en lugar de utilizar
un software. Para capturar los elementos del Backlog de Producto,
emplearemos tarjetas o notas adhesivas. En una ocasin empleamos
tantas notas adhesivas que alguien me pregunt, muy en serio, si 3M
haba sido el inventor de Scrum!

Bien, en tu opinin Cmo deberan ser los elementos del Backlog

Producto? Por ejemplo, estara bien que su contenido fuera algo
como "crear el diseo de la solucin"?

6.

Respecto a mi pregunta de ayer, djame decirte que la respuesta es

NO; no, no est bien tener un artculo del Backlog del Producto qu
sea algo como "crear el diseo de la solucin", porque eso es
predictivo, y cuando trabajamos con scrum debemos hacerlo
de forma iterativa.

El Backlog de Producto debe estar compuesto nicamente por

funciones; cosas que el cliente pueda entender, y cuando se
hayan desarrollado, pueda probar y darnos su opinin. Es por eso que
los elementos del Backlog de Producto deben tener dos
caractersticas:

Deben ser no tcnicos, porque los usamos para comunicarse

con el cliente y la comprensin mutua es la clave.
Normalmente el cliente no es, o no tiene un carcter
tcnico. As pues, no utilizamos un tipo de documentacin
sofisticada para hablar con el cliente sobre la definicin del
producto; necesitamos que se sienta cmodo y colabore.

Deben ser independientes entre s, porque queremos ser

capaces de ordenarlo libremente en funcin de su valor de
 negocio (importancia) y centrarnos primero en los elementos
ms importantes.

Una muy buena opcin para redactar los elementos del Backlog de
Producto es utilizar "historias de usuario". Pero, qu es una historia
de usuario? Lo veremos maana.

7.

Como te comentaba ayer una buena manera de redactar los

elementos del Backlog de Producto es utilizando "historias de
usuario". Este es un ejemplo de una historia de usuario:

Como usuario final, quiero obtener un informe sobre la actividad de

mi cuenta, para comprobar si todo est bien.

S, es my breve. Pero es que esa a es la clave! En Agile preferimos

tener objetos pequeos, ya que hace ms fcil el control del
proyecto. Adems, durante una iteracin tambin podemos producir o
completar al 100% varios artculos pequeos, mientras que si los
artculos son grandes, es difcil saber cundo se completan
realmente.

La plantilla genrica para una historia de usuario es la siguiente:

Como (rol) , quiero (funcin) , para (propsito)

El tercer elemento de la plantilla es opcional y no lo mencionaremos

cuando sea obvio. Fjate en el siguiente ejemplo:

Como administrador del sistema (rol), quiero poder restablecer las

contraseas (funcin), para (no es necesario mostrar el propsito).

Es tu turno! qu piensas acerca de la siguiente historia de usuario:

Como administrador del sistema, quiero tener una base de datos SQL
para el sistema.
Te parece que es una historia de usuario correctamente
formulada? No. La segunda parte de la historia de usuario debe ser de
una accin; se trata de hacer las cosas, en lugar de tener las cosas.

Es todo respecto a las historias de usuario. Sabes quin es el

encargado de crear los elementos del Backlog de Producto? Lo
comentamos maana.