Agilidad y Lean. Gestionando los proyectos y negocios del s.

XXI
Leccin 0
Hola!
Quiero darte la bienvenida a "Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI".
Me presento, soy Javier Garzs, y soy el coordinador del curso.
Mi primer proyecto gil... fue en 2001. Incluso an guardo las diapositivas que usamos para arrancar
aquel proyecto
eXtreme Programming y los mtodos giles (2001) from Javier Garzs
Brevemente, soy Mentor gil, Scrum Mster, experto en gestin de proyectos y equipos. Hasta la fecha,
he trabajado para ms de 80 empresas (como INDITEX, TELEFNICA, SIEMENS, INDRA, AENOR,
BBVA, etc.). Aqu te dejo mi CV completo.
En lo que refiere a formacin, soy postdoctorado e investigador invitado en la Universidad Carnegie
Mellon (Pittsburgh, EE.UU), donde trabaj en Agilidad y Scrum, Doctor (Ph.D.) (cum laude por
unanimidad) e Ingeniero Superior en Informtica (premio extraordinario) por la UCLM.
He sido programador, jefe de proyecto, consultor, director de informtica, CIO, diseador, he pasado por
casi todas las dedicaciones del desarrollo software. Llevo ms de 17 aos en el mundo profesional IT.
Ahora, profe de la Rey Juan Carlos y colaboro con 233 grados de TI, en todo lo relacionado con agilidad.
Desde 2006 escribo un blog sobre tecnologa, ya con ms de 1100 post: javiergarzas.com
Recomendamos:
Participar activamente, debatiendo, compartiendo ideas y realizando los talleres.
Investigar sobre los temas tratados y debatir en grupo cada leccin.
Compartir sugerencias y dudas tanto en el foro general como en los foros de debate especficos.
Incorporarse al grupo de usuarios de
Agilidad y Calidad en el Software y los Sistemas de
Informacin para mantener el contacto entre los asistentes tras la finalizacin del curso.

Y si ests en Madrid, tambin puedes mantener el contacto presencialmente en estos temas unindote a
las reuniones mensuales, gratuitas y desinteresadas, que organizamos desde el grupo de
Meetup Liderazgo tcnico - Peopleware - Management 3.0.
Tambin puedes darte de alta a nuestra newsletter en la que peridicamente enviamos noticias y
novedades en el mundo de la gestin de proyectos, agilidad, gestin de equipos, etc.
Aqu comienza la historia....
(https://www.youtube.com/watch?v=pNsMZJLHQTE)

Objetivos del curso

Los objetivos del curso son que el alumno conozca la gestin gil de proyectos tecnolgicos para
gestionar con xito el da a da de los proyectos.
Prcticas y tecnologas que aborda el curso:
SCRUM, HISTORIAS DE USUARIO, GESTIN DE EQUIPOS, PEOPLEWARE, PRODUCT
OWNER, ESTIMACIN GIL, PUNTOS HISTORIA, PRODUCT BACKLOG, CICLOS DE VIDA
GILES, LEAN, KANBAN, etc.
Desglose de objetivos

Conocer las bases de las metodologas giles y su diferencia con las metodologas tradicionales.
Conocer las prcticas giles propias de Scrum, sus particularidades e importancia actual de dicha
metodologa gil en el sector.
Conocer las claves ms importantes en la gestin de equipos.
Conocer LEAN Y Kanban.
Presentar cules son los mtodos de estimacin ms eficientes en el rea de las metodologas
giles. Veremos cmo funciona el Planning Poker Y LOS PUNTOS HISTORIA
Otros aspectos relacionados, como la relacin de las metodologas giles, como Scrum, con
modelos de procesos como CMMI o ISO/IEC 15504.

Dirigido a

Estudiantes de carreras tecnolgicas.

Desarrolladores.
Quienes quieran aplicar la agilidad a otros contextos
Profesionales de informtica en general
Directivos, Jefes de proyecto, responsables de calidad

Consultores
Personal de gerencia media y tcnica del rea de TI.

Modalidad de evaluacin

El curso est compuesto de 6 lecciones de contenido audiovisual, textual y presentaciones.

No est previsto restringir los horarios de acceso por lo que el estudiante podr acceder a las
lecciones a partir del momento en que se habiliten y hasta la finalizacin del curso.
Al finalizar cada leccin, el usuario obtendr una nota con su calificacin despus de
realizar el test correspondiente, siendo todos estos obligatorios. Esa nota no tendr ningn
valor sobre la calificacin final del curso. Solo se utilizar para que el estudiante conozca cmo
ha realizado esa leccin. Cada test podr realizarse una nica vez, y es obligatoria su realizacin
para pasar al siguiente mdulo.
Las lecciones han de realizarse en orden secuencial, es decir, para acceder a una leccin es
necesario haber completado la leccin anterior.
Para obtener el certificado que indica que se ha superado el curso, es necesario obtener una
calificacin del 50% en el examen final. Este examen estar disponible para su realizacin tras
la publicacin de todas las lecciones del curso.
Utiliza el "Foro" para cualquier tipo de duda que te surja sobre el curso o su contenido. En este
foro sers respondido por otros alumnos o por los profesores del curso.

Normas de los foros

Para que la participacin en los foros del curso sea satisfactoria para todos los alumnos, se deben seguir
las reglas que se detallan a continuacin.

Debe mantener una conducta apropiada con el resto de miembros.

Escriba en la seccin o foro adecuado (foro general o foro especfico de lecciones).
Trate temas que estn relacionados con la temtica del curso.
No publique contenido indebido o censurable.
No incluya anuncios con fines comerciales o publicitarios.
No publique contenido que infrinja cualquiera de los derechos legales de terceros, como pueden
ser derechos de propiedad intelectual.
El foro podr ser abierto algunos das antes del comienzo del curso, y ser cerrado al finalizar el
mismo (aunque el examen final del curso continue abierto), por lo que si deseas realizar
comentarios en el foro podrs hacerlo hasta el ltimo da del curso.
En caso de incumplimiento de alguna de las reglas especificadas, los administradores y/o moderadores
podrn tomar las acciones que consideren oportunas.

Fuentes, referencias y agradecimientos

Agradecer a los compaer@s de la Academia online de 233 Grados de TI por sus comentarios,
sugerencias y materiales cedidos gratuitamente.
Una gran parte del material del curso est sacado de las fuentes detalladas a continuacin. Por lo que si en
algn momento necesitas ms material para ampliar el contenido del curso, puedes encontrarlo en:

Libro: Cmo sobrevivir... A la planificacin de un proyecto gil, Javier Garzs

Libro: Gestin de Proyectos gil...y las experiencias de ms de 12 aos de proyectos giles

Y de la seccin de agilidad del blog de javiergarzas.com:

Agilidad
Mi agradecimiento a aquellos con los que he compartido proyectos profesionales, a los asistentes a los
diferentes webinars, seminarios y conferencias que hemos organizado sobre diferentes aspectos de la
calidad software y proyectos giles, por habernos transmitido en qu temas debera incidir el curso,

destacando a los lectores del blog www.javiergarzas.com , y sus comentarios de incalculable valor para
motivar este curso.
Quera destacar especialmente la labor de revisin, maquetado, sugerencias y los comentarios realizados
por:
- Ana Mara del Carmen Garca Oterino
- David Garca Fernndez
- M ngeles Morales Muoz
- Noem Navarro Snchez

Leccin 1: Construir software no es como construir coches o casas

La predictibilidad, ciclo de vida en cascada o desarrollo tradicional
En su nacimiento, la gestin de proyectos software intent imitar la gestin de proyectos de otras
disciplinas, como la arquitectura, las industria o la ingeniera civil, hasta el punto de heredar y adaptar al
mundo del software muchos de sus roles (p.e. arquitectos software) y tipos de organizaciones (p.e.
fbricas de software).
Hoy en da una de las prcticas ms discutidas y polmicas de las que se han querido heredar desde otras
disciplinas es la llamada predictibilidad, tambin conocida como gestin de proyectos dirigida por la
planificacin, desarrollo tradicional o incluso tambin conocida como desarrollo pesado.
"Vdeo resumen de qu es la Agilidad"
https://www.youtube.com/watch?v=oShXAC26rcs
La predictibilidad se basa en dividir un proyecto en fases, por ejemplo, de manera simplificada,
requisitos, diseo y construccin, y que cada una de estas fases no comience hasta que termine con
xito la anterior.
Se le llama predictibilidad porque cada fase intenta predecir lo que pasar en la siguiente; por
ejemplo, la fase de diseo intenta predecir qu pasar en la programacin, y esos diseos intentarn ser
muy precisos y detallados, para ser cumplidos sin variacin por los programadores.
Adems, en este tipo de gestin, cada una de estas fases se realiza una nica vez (no hay dos fases de
requisitos). Y las fases estn claramente diferenciadas (en teora, est claro cundo termina el diseo y
comienza la programacin), hasta el punto de tener profesionales claramente diferenciados y
especializados en cada una de ellas: analistas de requisitos, arquitectos de diseo software,
programadores, personas para pruebas, etc.

Normalmente cada fase concluye con un entregable documental que sirve de entrada a la siguiente
fase, la especificacin de requisitos software es la entrada al diseo, el documento de diseo la
entrada a la construccin, etc.
"Conferencia (15 min.) sobre las bases de la agilidad y sus diferencias con las disciplinas tradicionales"
https://www.youtube.com/watch?v=L9qlrgKWqfI&list=PL-bVpgNOlmip9lfzxpdW2sDeigRkarNgk
La gestin de proyectos predictiva es tpica en disciplinas como la arquitectura. Y desde sus orgenes, la
ingeniera del software intent perseverantemente emular a las ingenieras clsicas. Tener una fase de
diseo muy claramente separada de la programacin (hasta el punto de intentar tener una organizacin
cliente que detalle los diseos y otra organizacin, normalmente llamada fbrica de software, que los
implemente). Que la programacin no comenzase hasta que terminase el diseo. Que el diseo concluya
con unos planos precisos que guen totalmente la construccin. Que una vez que se hace un diseo ste no
se modifique; de hecho, notaciones como UML (Unified Modeling Language es un lenguaje grfico para
visualizar, especificar, construir y documentar un sistema) se concibieron para construir los planos
detallados del software.
Al anterior tipo de gestin de proyectos predictiva, en el mundo del software se le conoce como ciclo
de vida en cascada (ver Figura 1).

Figura 1. Ejemplo de ciclo de vida predictivo o en cascada

LECTURAS PARA AMPLIAR EL TEMA:

Diagramas Gantt cmo arma de destruccin masiva de proyectos. Maneras de usar un Gantt para matar un
proyecto

gil vs. Tradicional

Construir software no es como construir coches o casas
En software, la experiencia nos dice que es muy difcil especificar los requisitos en una nica y
primera fase. Por la complejidad de muchas de las reglas de negocio que automatizamos cuando
construimos software, es muy difcil saber qu software se quiere hasta que se trabaja en su
implementacin y se ven las primeras versiones o prototipos [1].
Tambin es muy difcil documentar de una nica vez, a la primera, antes de la codificacin,un diseo
que especifique de manera realista y sin variacin todas las cuestiones a implementar en la programacin.
Las ingenieras clsicas o la arquitectura necesitan seguir este tipo de ciclos de vida en cascada o
predictivos porque precisan mucho de un diseo previo a la construccin, exhaustivo e inamovible:
disponer de los planos del arquitecto siempre antes de empezar el edificio. Nadie se imagina que una vez
realizados los cimientos de un edificio se vuelva a redisear el plano y se cambie lo ya construido.
Adems, los planos para construir son precisos y pocas veces varan, ya que la mayora de los diseos
de las ingenieras clsicas, arquitecturas, etc., pueden hacer un mayor uso de las matemticas o la fsica.
En software no es as. Y aunque se pretenda emular ese modo de fabricacin, en software no funciona
bien, y debemos tener muy claro que es casi imposible cerrar un diseo a la primera para pasarlo a
programacin sin tener que modificarlo posteriormente.
Evolucin fabricacin software
Por lo general, realizar un cambio en el producto final que construyen las ingenieras clsicas o la
arquitectura es muy costoso. Cambiar, por ejemplo, la posicin de una columna en un edificio o realizar
modificaciones a la estructura de un puente ya construido tiene un alto coste. Y de ah que la arquitectura
o las ingenieras clsicas pretendan lograr a toda costa diseos o planos de un alto nivel de detalle, para
que una vez que comience la fase de construccin no tengan que ser modificados. Adems,
normalmente, en la arquitectura o en las ingenieras clsicas los costes de construir son muy
elevados en comparacin con los de disear. El coste del equipo de diseadores es sustancialmente
inferior al de la realizacin de la obra, del puente, edificio, etc.
La anterior relacin de costes no se comporta igual en el caso del software. Por un lado, el software,
por su naturaleza (y si se construye mnimamente bien), es ms fcil de modificar. Cambiar lneas de
cdigo tiene menos impacto que cambiar los pilares de un edificio ya construido. De ah que existan
numerosas propuestas que recomiendan construir rpido una versin software y modificarla

evolutivamente (la tcnica de la refactorizacin trabaja sobre esta idea). En software no existe esa
divisin tan clara entre los costes del diseo y los de la construccin.
Tambin en las ingenieras clsicas o la arquitectura los roles y especializacin necesaria en cada
fase son diferentes. Los planos o diseos los realizan arquitectos que no suelen participar en la fase de
construccin. La construccin tiene poco componente intelectual y mucho manual, al contrario que
el diseo. Y todo apoya a que existan dos actividades claramente diferenciadas: el diseo y la
construccin.
En nuestro caso, el producto final, el software, tiene diferencias muy sustanciales con estos productos
fsicos. Estas diferencias hacen que el proceso de construccin sea diferente. Durante muchos aos,
quizs por la juventud de la ingeniera del software, se han obviado estas diferencias, e incluso se han
intentado encontrar metodologas que imitasen y replicasen los procesos de construccin tradicional al
software. Ejemplo de ello son las primeras versiones y usos de lenguajes de diseo como UML, o
metodologas como RUP [2] o Mtrica v3 [3].
Sin embargo en muchas ocasiones, estos intentos de emular la construccin de software a productos
fsicos han creado importantes problemas y algunos de los mayores errores a la hora de gestionar
proyectos software.
Diferenciar el cmo se construye software del cmo se construyen los productos fsicos es uno de los
pilares de las metodologas giles (M. Fowler, 2005) [4]. De hecho es un tema del que se ha escrito
mucho .Y tambin se ha debatido bastante, desde hace muchos aos, con posturas a favor y en contra.
Y es que en software,es frecuente que diseo y construccin muchas veces se solapen, y por ello se
recomiende construir por iteraciones, por partes, y el uso de prototipos incrementales.

[1] En este caso se utiliza la palabra prototipo como sinnimo de un producto software con
caractersticas que pueden ser utilizadas por el cliente
[2] RUP, por sus siglas en ingls que significan RationalUnifiedProcess es un proceso de desarrollo de
software utilizado junto con UML y que constituye una metodologa para el anlisis, diseo,
implementacin y documentacin de proyectos software orientados a objetos.
[3] Mtrica v3 es una metodologa de planificacin, desarrollo y mantenimiento de sistemas de
informacin, mayormente promovida y utilizada en el mbito de las administraciones pblicas.
[4] Fowler, M. (2005). The new methology.

Frente a la prediccin adaptacin, o el ciclo de vida iterativo e incremental

Es curioso ver como el concepto ciclo de vida, una de las piezas ms fundamentales, y trascendentales,
de la gestin de un proyecto software produce tanta confusin.
En parte, tampoco es de extraar, debido a que no existe una nica terminologa al respecto, existen
muchas definiciones, conceptos confusos, etc. Por eso vamos a aclarar los principales tipos de ciclos de
vida que hay:

Cascada
Las fases del ciclo de vida (requisitos, anlisis, diseo, etc.) se realizan (en teora) de manera lineal,
una nica vez, y el inicio de una fase no comienza hasta que termina la fase anterior.
Su naturaleza es lineal, tpica de la construccin de productos fsicos y su principal problema viene de
que no deja claro cmo responder cuando el resultado de una fase no es el esperado.
El ciclo de vida ms criticado en los ltimos aos. En muchos proyectos su implantacin ha sido un
fracaso, mientras que hay otros proyectos que trabajan perfectamente de esta manera.

El ciclo de vida incremental

Cada iteracin (una iteracin es un periodo de tiempo, no confundir con el ciclo de vida iterativo, que
veremos luego, siendo este punto confuso, por las definiciones) contiene las fases del cascada estndar,
pero cada iteracin trabaja sobre un subconjunto de funcionalidad. La entrega total del proyecto se
divide en subsistemas priorizados.
Desarrollar por partes el producto software, para despus integrarlas a medida que se completan.
Un ejemplo de un desarrollo puramente incremental puede ser la agregacin de mdulos en diferentes
fases. El agregar cada vez ms funcionalidad al sistema.

El ciclo de vida iterativo

En cada ciclo, iteracin, se revisa y mejora el producto. Un ejemplo de desarrollo iterativo es aquel
basado en refactorizaciones, en el que cada ciclo mejora ms la calidad del producto.
Es importante sealar que este ciclo no implica aadir funcionalidades en el producto, pero si la
revisin y la mejora.

Iterativo e incremental
Incremental = aadir, iterativo = retrabajo

Se va liberando partes del producto (prototipos) peridicamente, en cada iteracin, y cada nueva
versin, normalmente, aumenta la funcionalidad y mejora en calidad respecto a la anterior. Aqu
hay un post con ms informacin.
Adems, el ciclo de vida iterativo e incremental es una de las bases de un proyecto gil, ms
concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente
ms de dos
http://www.youtube.com/watch?v=EwmI5NDKLBo&feature=youtu.be
El ciclo de vida iterativo e incremental es una de las buenas prcticas de ingeniera del software ms
antiguas, su primer uso en el software se data en los 50 (pincha aqu, te dejo este post donde hablamos del
tema).
Sobre estos dos ciclos de vida te dejo un artculo de Cockburn especialmente aclaratorio.

Ciclo de vida gil

Sera un ciclo de vida iterativo e incremental, con iteraciones cortas (semanas) y sin que dentro de
cada iteracin tenga porqu haber fases lineales (tipo cascada). A partir de la anterior, matizaciones,
adaptaciones, etc., hay por cada metodologa gil que existe.
Quiz el caso ms popular es el de Scrum. Hace ya sus aos, en el 85, y en la primera presentacin oficial
de Scrum, Ken Schwaber, uno de sus creadores, hablaba sobre el ciclo de vida de Scrum, y sus diferencias
con los anteriores ciclos de vida
Segn comenta Ken Schwaber, el ciclo de vida en Cascada y el Espiral cierran el contexto y la entrega
al inicio de un proyecto. La principal diferencia entre cascada, espiral e iterativo y los ciclos de vida
giles, concretamente en Scrum, es que estos ltimos asumen que el anlisis, diseo, etc., de cada
iteracin o Sprint son impredecibles. Los Sprints, o iteraciones cortas, no son (o a priori no tienen
porqu) lineales y son flexibles.
Pero, como comentaba, cada metodologa de las llamadas giles, FDD, Crystal, DSDM, XP, etc.,
matizar su ciclo de vida.

CURIOSIDADES: El ciclo de vida iterativo e incremental es incluso ms antiguo

que el cascada!
Con la creciente popularidad de los mtodos giles en muchas ocasiones se cree que el ciclo de vida
iterativo e incremental es una prctica moderna, nueva frente al antiguo ciclo de vida en cascada, pero su
aplicacin data de mitad de los aos 50, y desde entonces ha sido ampliamente usado y se ha escrito
mucho sobre l (C. Larman & V. Basili, 2003) [1].

En 1950 la construccin del avin cohete X-15 supuso un hito en la aplicacin del ciclo de vida iterativo
e incremental, hasta el punto de que dicho ciclo de vida fue una de las principales contribuciones al xito
del proyecto
Link al texto completo. Veterano ciclo de vida iterativo e incremental (J. Garzs, 2010).
[1] Larman, C. & Basili, V. (2003). Iterative and incremental Development: A brief History. Computer
36(6), 47-56

El proyecto gil
https://www.youtube.com/watch?v=MOucV2m56rA
Comentaba Ambler [1], que un proyecto gil se podra definir como una manera de enfocar el
desarrollo software mediante un ciclo iterativo e incremental, con equipos que trabajan de manera
altamente colaborativa y autoorganizados. Es decir, un proyecto gil es un desarrollo iterativo ms la
segunda gran caracterstica implicada directamente por la iteracin extrema: equipos colaborativos y
autoorganizados.
A diferencia de ciclos de vida iterativos e incrementales ms relajados, en un proyecto gil cada
iteracin no es una mini cascada. Esto no es as, porque el objetivo de acortar al mximo las
iteraciones (normalmente entre 1 y 4 semanas) lo hace casi imposible. Cuanto menor es el tiempo de
iteracin ms se solapan las tareas. Hasta el punto que implicar que de manera no secuencial, muchas
veces solapada, y repetitivamente, durante una iteracin se est casi a la vez diseando, programando y
probando.
Lo anterior implicar mxima colaboracin e interaccin de los miembros del equipo.
Implicar equipos multidisciplinares, es decir, que no hay roles que slo diseen o programen todos
pueden disear y programar. E implica auto-organizacin, es decir, que en la mayora de los proyectos
giles no hay, por ejemplo, un nico jefe de proyecto responsable de asignar tareas.
Un proyecto gil lleva la iteracin al extremo:
1. Se busca dividir las tareas del proyecto software en incrementos de una corta duracin
(segn la metodologa gil, tpicamente entre 1 y 4 semanas).
2. Cada iteracin suele concluir con un prototipo operativo. Al final de cada incremento se
obtiene un producto entregable que es revisado junto con el cliente, posibilitando la aparicin
de nuevos requisitos o la perfeccin de los existentes, reduciendo riesgos globales y permitiendo
la adaptacin rpida a los cambios.

Normalmente un proceso gil se basa en un ciclo de vida iterativo e incremental pero no todo
proceso iterativo e incremental es un proceso gil. Adems, estn la colaboracin y los equipos
autoorganizados, entonces, qu caracteriza un proyecto gil? en el siguiente captulo veremos que
derivado de todo lo anterior se debe cumplir adems otros valores y principios.
[1] Ambler, S. (2008). Acceleration: An agile productivity measure. Disponible en:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/a
mbler/entry/metric_acceleration?lang=en

El Manifiesto gil
El 12 de febrero de 2001,17 destacados y reconocidos profesionales de la ingeniera del software
escriban en Utah el Manifiesto gil. Entre ellos estaban los creadores de algunas de las metodologas
[1] giles ms conocidas en la actualidad: XP, Scrum, DSDM, Crystal, etc. Su objetivo fue establecer
los valores y principios que permitiran a los equipos desarrollar software rpidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las
actividades desarrolladas.
De esta forma se establecieron cuatro valores giles:

Valorar a los individuos y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. Se tendrn en cuenta las buenas prcticas de desarrollo y gestin de los
participantes del proyecto (siempre dentro del marco de la metodologa elegida). Esto facilita el
trabajo en equipo y disminuir los impedimentos para que realicen su trabajo. Asimismo
compromete al equipo de desarrollo y a los individuos que lo componen.

Desarrollar software que funciona ms que conseguir una documentacin exhaustiva. No es

necesario producir documentos a menos que sean necesarios de forma inmediata para tomar una
decisin importante. Los documentos deben ser cortos y centrarse en lo fundamental. La
variacin de la cantidad y tipo de documentacin puede ser ampliada dependiendo el tipo de
cliente o de proyecto. El hecho de decir que la documentacin es el cdigo fuente y seguir esa
idea sin flexibilidad puede originar un caos. El problema no es la documentacin sino su utilidad.

La colaboracin con el cliente ms que la negociacin de un contrato. Es necesaria una

interaccin constante entre el cliente y el equipo de desarrollo. De esta colaboracin depende el
xito del proyecto. Este es uno de los puntos ms complicados de llevar a cabo, debido a que
muchas veces el cliente no est disponible. En ese caso desde dentro de la empresa existir una
persona que represente al cliente, haciendo de interlocutor y participando en las reuniones del
equipo.

Responder a los cambios ms que seguir estrictamente un plan. Pasamos de la anticipacin y

la planificacin estricta sin poder volver hacia atrs a la adaptacin. La flexibilidad no es total,
pero existen muchos puntos (todos ellos controlados) donde se pueden adaptar las actividades.

LO QUE NO DICE
Ausencia total de documentacin.
Ausencia total de planificacin: planificar y ser flexible es diferente a improvisar.
El cliente debe hacer todo el trabajo y ser el Jefe de Proyecto.
El equipo puede modificar la metodologa sin justificacin.

LEE LAS ENTREVISTAS QUE HICIMOS A LOS FIRMANTES DEL

MANIFIESTO GIL:
Entrevista a Alistar Cockburn
Entrevista a Robert C. Martin
Entrevista a Jeff Sutherland

[1]El trmino metodologa es utilizado de manera coloquial, siendo rigurosos las metodologas son ms
bien marcos de trabajo o frameworks.

Los Principios giles

De estos cuatro valores surgen los doce principios del manifiesto. Estos principios son caractersticas
que diferencian un proceso gil de uno tradicional. Los principios son los siguientes:
1. La prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software que le
aporten valor.
2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja
competitiva.
3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses,
con el menor intervalo de tiempo posible entre entregas.
4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.

6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro
de un equipo de desarrollo.
7. El software que funciona es la medida fundamental de progreso.
8. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y
usuarios deberan ser capaces de mantener una paz constante.
9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.
10. La simplicidad es esencial.
11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s
mismos.
12. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn
esto ajusta su comportamiento.

Comparativa resumen de agilidad vs tradicional

A modo de resumen, esta son las principales diferencias entre las metodologas giles y tradicionales:
https://www.youtube.com/watch?v=gnam324znBk

Para saber ms: Desarrollo gil o tradicional: Existe el punto intermedio?

Unin los modelos de procesos y metodologas giles

En ocasiones existe la percepcin de que es incompatible unir modelos como CMMI o ISO/IEC 15504
ISO/IEC 12207 con metodologas giles. Sin embargo, esta concepcin no es correcta, ya que los
modelos y las metodologas se encuentran en distintos niveles de abstraccin.
https://www.youtube.com/watch?v=Ukx3sGGTENY
Los modelos de procesos establecen qu es lo que espera encontrarse en los procesos, pero son las
metodologas las que indicarn cmo deben realizarse. Es por esto que el uso de modelos de procesos y
metodologas giles no debe considerarse un aspecto contradictorio sino complementario.

Can Scrum help to improve the project management process? A study of the relationships between Scrum
and Project Management process areas of CMMI-DEV 1.3.
Si quieres saber ms sobre CMMI

Gua Prctica de Supervivencia en una Auditora CMMI

Enlaces y lecturas recomendadas

Gestin gil de Proyectos Software.

Video muy interesante y dinmico de la reunin en el Dcimo Aniversario del Manifiesto gil
Una metodologa por cada proyecto
Manifiesto gil
Procesos software

Test Leccin 1
El software se construye siguiendo los mismos pasos que si construyramos una casa.
Verdadero
Falso
Si seguimos un ciclo de vida en cascada, podemos cambiar los requisitos en cualquier momento.
Verdadera
Falso
El ciclo de vida iterativo e incremental es una de las bases de un proyecto gil.
Verdadero
Falso
El ciclo de vida en cascada...
Nunca hay que usarlo en un proyecto software.
Siempre hay que usarlo en un proyecto software.
Lo usaremos dependiendo del producto software a desarrollar.

Un proyecto giles es ...

Un desarrollo iterativo
Un desarrollo en cascada con equipos autoorganizados y colaborativos
Una manera de enfocar el desarrollo software mediante un ciclo iterativo e incremental, con
equipos que trabajan de manera altamente colaborativa y autoorganizados
Ninguna de las anteriores
En un proyecto gil cada iteracin concluye...
Con un prototipo operativo
Con un prototipo no operativo
No se entrega ningn prototipo.
Ninguna de las anteriores.

Leccin 2: Peopleware
Gestin de equipos
En esta leccin se tratarn los puntos ms importantes que debemos tener en cuenta a la hora de gestionar
los equipos software en general y giles en particular. A continuacin os dejo un vdeo resumen de dichos
puntos, y una conferencia que di en Valencia con las diapositivas que utilic.
https://www.youtube.com/watch?v=o90o6Oassec&feature=youtu.be
https://www.youtube.com/watch?v=CyqQry7wrS8
Peopleware: y como no gestionar un equipo de desarrollo software from Javier Garzs

Este tema es muy importante y est muy estudiado, pero a la vez es poco conocido; la pieza fundamental
del xito de una empresa de base tecnolgica son las personas.
Comenzamos enumerando 5 caractersticas de los equipos de alto rendimiento (entendiendo por
rendimiento productividad, minimizar el desperdicio de tiempo, hacer el mximo con las personas
necesarias, evitar sobrecostes...):
1. Buscar a los miembros ms adecuados y retenerlos: es esencial el talento, hay que buscar la persona
ms adecuada para el tipo de tecnologa y proyecto que se est desarrollando, y una vez que se tiene a la
persona idnea conseguir retenerla.
2. Trabajar en un entorno de productividad, sin interrupciones: los entornos fsicos tienen un
impacto altsimo en la productividad. Uno de los principales impactos vienen de las interrupciones, como
solucin encontramos la tcnica pomodoro (tcnica de gestin personal) que dice que trabajas en

intervalos de 25 minutos dedicados exclusivamente a una tarea sin que haya cambio de contexto ni
interrupciones y luego 5 minutos de descanso.
3. Conocer el impacto de la NO calidad: si un software est mal hecho, la mantenibilidad baja, y
conlleva a que la productividad baje (como una mala solucin a ello meten ms gente a trabajar, esto hace
que vaya peor; una buena solucin es refactorizar) y como consecuencia se disparan los costes. La calidad
afecta mucho a la productividad.
4. Equipos pequeos: el tamao de los equipos es una de las claves ms importantes en la gestin de
equipos. Aadir gente a un proyecto retrasado hace que te retrase ms.
5. Equipos multifuncionales (sin hroes ni apagafuegos): un buen equipo no tiene apaga fuegos. Un
equipo multifuncional es un equipo en el que hay un equilibrio entre sus miembros, es decir, cada uno
tiene su tarea, pero en momentos especficos puede realizar otras.
LECTURAS PARA AMPLIAR EL TEMA:
Gestin de proyectos gily las experiencias de ms de 12 aos de proyectos giles.

Trabajar en ms de un proyecto a la vez genera prdida de tiempo y disminuye la

productividad
El libro Quality Software Management Volume 1. Systems Thinking escrito por Gerald M. Weinberg
en 1992, fue famoso principalmente por un estudio en el que explicaba el desperdicio de tiempo que
supona tener a las personas trabajando en varios proyectos a la vez. Concretamente, Weinberg lo
sintetizaba en la siguiente tabla:
Nmero de proyectos
simultneos
1

% de disponibilidad para el
proyecto
100 %

Prdida debido al cambio de

contexto
0%

40 %

20 %

20 %

40 %

10 %

60 %

5%

75 %

Tabla 1. Disponibilidad y prdida de tiempo en funcin del nmero de proyectos a la vez en el que se
trabaje.
Como se puede observar en la Tabla 1, a mayor nmero de proyectos trabajando simultneamente, la
disponibilidad para cada proyecto va disminuyendo, y la prdida de tiempo en aumento, debido al

cambio de tareas, de estar trabajando en un proyecto a pasar los pensamientos a otro. A esto se le
llama cambio de contexto, el tiempo perdido entre que cambias de una tarea a otra y te concentras en
ella. Este efecto es muy similar a las interrupciones (que se ver ms adelante).
Lo ideal es abrir y cerrar tareas, no tener muchas abiertas.

Interrumpir a quin programa, o al que realiza cualquier actividad intelectual, hace

que su productividad caiga
En trabajos intelectuales, como programar, escribir artculos, post, disear, etc., las interrupciones son
un mal que afecta enormemente a la productividad, a continuacin se explican las causas y qu medios
se pueden utilizar para que esto no suceda.
Parnin y Rugaber hicieron un estudio sobre las interrupciones en el ao 2010, siendo su conclusin ms
destacada la siguiente:
Lo normal es que a un programador le lleve de 10 a 15 minutos volver al estado de concentracin
previo al haber sido interrumpido.
La interrupcin pueden ser externa, por ejemplo, que venga alguien y te interrumpe, llamadas al
mvil, etc. O puede ser interna, leer el correo, el twitter, etc., lo que tambin es conocido como
procrastinacin.
Dos consejos son:

Para luchar contra interrupciones internas. Utilizar la tcnica pomodoro, que es bsicamente
dedicar intervalos de 25 minutos, llamados pomodoros, a una nica tarea, sin distraccin o
dedicacin a otra tarea durante la duracin del pomodoro (ni mvil, ni correo, ni twitter, etc.).
Para luchar contra interrupciones externas. Aslate, en la medida de lo posible, maanas, horas o
das, a entornos sin interrupciones.
Debemos ser conscientes del problema que esto supone, es decir, de que las interrupciones hacen que
nuestra productividad caiga, nuestro trabajo efectivo al final del da, y seguidamente poner medios para
luchar contra ellas.

Los equipos con mucha gente son menos productivos

Hay quien piensa que en un equipo, cuanta ms gente haya mejor. Esto no es as, es uno de los errores
ms frecuentes en gestin de proyectos software.
Cuando el tamao del equipo crece ms all de un nmero de personas el tiempo de proyecto no
se reduce.
Lawrence Putnam, elabor en 2003 una investigacin cuyos resultados fueron que cuando el tamao del
equipo creca ms all de un nmero de personas, el esfuerzo aumentaba y el tiempo de proyecto no se
reduca.

Imagen 1. Putnam, 2003.

Cuando el tamao del equipo incrementaba de 1 a 7 personas, el tiempo se acortaba y el esfuerzo
incrementaba. Pero cuando pasaba de 7 personas, tanto el esfuerzo como el tiempo incrementaban. Esto
ocurre a causa de:
- La coordinacin que requieren los equipos grandes es mayor.
- Hay un incremento en las rutas de comunicacin.
Para lograr la mxima eficiencia, los equipos deberan ser de 5 a 9 personas.
Para ms informacin consultar aqu.

Hay un lmite en el que no puedes recortar ms el tiempo de un proyecto aadiendo

ms gente
A la hora de planificar un proyecto, muchos responsables de proyecto ven razonable pensar que si
aaden ms gente al proyecto, el proyecto se terminar antes, y podrn encajarlo en esas complicadas
fechas.
Lo primero que hay que tener en cuenta es que hay una temporalidad llamada imposible, por mucha
gente que aadas al proyecto no podrs reducir su tiempo ms all de un tope.
Muchos investigadores han estudiado los efectos de comprimir el calendario de proyecto, todos
concluyen en que acortar el tiempo de proyecto por debajo del tiempo ideal incrementa el esfuerzo de
manera no lineal. Es decir, que si el tiempo ideal es 12 meses y 7 desarrolladores, no vas a poder
recortar el proyecto a 7 meses con 12 desarrolladores vas a necesitar muchos ms.
La siguiente tabla es popular en el mundo de la gestin de proyectos software, elaborada por Putnam,
que muestra, despus de estudiar un gran nmero de proyectos, cmo segn la reduccin el tiempo se
incrementa el esfuerzo.
Compresin/Expansin del

Incremento/Reduccin del esfuerzo

tiempo
-15%

+100%

-10%

+50%

-5%

+25%

Tiempo ideal

0%

+10%

-30%

+20%

-50%

+30%

-65%

More than +30%

Not practical

Tabla 1. Putnam and Myers 1992

Una de las razones de este efecto viene del desperdicio de esfuerzo que aparece por aumentar el nmero
de miembros del equipo, que como veamos en el anterior apartado, es un desperdicio mucho mayor, se
dispara, si el equipo se incrementa en ms de 7 personas.
Despus de tanta investigacin sobre el tema, existe el consenso de que reducir ms de un 25% el
tiempo ideales imposible.

Quemar y saturar de trabajo al equipo no se traduce en mayores resultados

Tom DeMarco en Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency escrito en
2001, insiste en eso de que un equipo est muy ocupado y sobresaturado no da lugar a una mayor
efectividad y beneficios.
En la actualidad, hay empresas que sobrecargan a sus trabajadores, con el objetivo de terminar antes, o
ms tareas en menos tiempo, no teniendo as en cuenta el carcter humano y emocional de los equipos.
Tom DeMarco propone que debera haber ms slack, lo que se traduce en libertad para la gente de
la empresa, tener un margen de actuacin, ya que es prcticamente imposible que una persona invierta
todo su tiempo laboral en realizar cosas productivas, si una persona est agotada es probable que no
pueda hacer nada ms, bloqueando ideas creativas las cuales son necesarias para el desarrollo de la
empresa.
Que en una empresa haya slack permite a los empleados ser ms productivos e innovar.
Ya que Qu es lo ms determinante para el xito o fracaso de un proyecto? Las personas.

Aadir gente a un proyecto retrasado hace que se retrase an ms

Brooks fue director del desarrollo del famoso OS/360 de IBM, y a raz de sus experiencias, xitos y
fracasos escribi The Mythical Man-Month: Essays in Software Engineering, libro al que deben su
mayor fama, aunque no suficiente, frases como:

Aadir recursos humanos a un proyecto con retraso provocar un retraso mayor.

En un proyecto la figura del arquitecto software es esencial.
Medir el progreso de un proyecto en funcin del tiempo que lleva desarrollndose es un error
Cmo puede un proyecto acumular un retraso de un ao? acumulando retrasos da a da.

La principal causa de los problemas en el desarrollo software est en la planificacin y distribucin de

recursos, la idea de que horas y recursos humanos son intercambiables lleva a que si un proyecto est
retrasado la solucin sea agregar ms mano de obra. Pero el factor humano y las horas no se pueden
conmutar como en una multiplicacin: el tiempo extra que se aade por cada persona va a parar a
reuniones, planes, e-mails, negociaciones, discusiones, revisiones, coordinacin de reuniones, actas,
explicaciones, formacin, etc. Y por otro lado existen tareas que simplemente no se pueden dividir y
deben ser realizadas por la misma persona.
Brooks compara el desarrollo software con las arenas movedizas que durante la prehistoria engullan
animales gigantes que cuanto ms luchaban por escapar ms rpido se hundan. La nica salida de este

pozo de arenas movedizas es aplicar un proceso de ingeniera consciente y mtodos probados en la

gestin de proyectos.

Para ms informacin consultar aqu.

Programar con msica hace que seas menos productivo

En los aos 60, se realizaron experimentos sobre los efectos de programar mientras se escucha msica
en la Universidad de Cornell (EEUU). Lo vamos a explicar para razonar por qu escuchar msica hace
que seas menos productivo.
Los investigadores de la Universidad, hicieron dos grupos con estudiantes de informtica, uno grupo
con aquellos estudiantes a los que les gustaba estudiar con msica y otro con aquellos a los que no.
A los participantes se les entreg un problema de programacin en Fortran para trabajar en l con
ciertas especificaciones, y prcticamente realizaron el ejercicio con la misma velocidad y precisin. La
parte del cerebro que se requiere para la aritmtica y la lgica no se ve influenciada por escuchar
msica, pero hay parte del centro que s.
La especificacin requera una transformacin de nmeros y el resultado final de las operaciones era
que cada nmero de salida era igual a su nmero de entrada. La mayora de los estudiantes que se dieron
cuenta de ello, pertenecan al grupo de la habitacin en silencio.
Es el lado derecho del cerebro el que procesa la msica, los trabajos intelectuales, de concentracin, no
slo necesitan el lado izquierdo del cerebro, sino tambin requieren de lgica e ingenio, que se procesan
en el derecho.
Si escuchas msica, puedes perder la oportunidad del salto creativo, ya que influye en la
reduccin de la creatividad, y este efecto es acumulativo.
Es un tipo de interrupcin como hemos hablado de ello anteriormente.

Puedes leer ms en Peopleware de DeMarco y Lister.

La organizacin de la sala y las mesas de un equipo de desarrollo software influye

en la productividad
Cul es la mejor manera de organizar la sala y las mesas de un equipo de desarrollo software.
Este apartado tiene relacin con el apartado interrumpir a quien programa o quien realiza cualquier
actividad intelectual, hace que su productividad caiga ya que hay oficinas que no separan las salas de
recreo de los lugares de concentracin, por lo tanto la persona que est concentrada es interrumpida por
sus compaeros que estn de descanso y esto hace que esa persona pierda mucho tiempo.
La cuestin es que en la oficina en la que un grupo de desarrolladores (o cualquier grupo de
profesionales que realicen tareas que requieran concentracin) trabaje debiera ayudar a eso, a evitar las
interrupciones y la falta de concentracin, y eso es lo que vamos a ver en este apartado.
Uno de los aspectos fundamentales para un buen entorno de trabajo es que no haya ruido. Por tanto,
elementos como puertas, aislantes de ruido, algn mecanismo para evitar las interrupciones entre los
propios compaeros, se hacen indispensables.
Respecto al puesto de trabajo las recomendaciones son las que se describen a continuacin.
Un espacio iluminado con luz natural y con ventanas, tambin incrementa la productividad. Por otra
parte, es primordial que la gente est cmoda, con espacio suficiente para trabajar.
Est la opcin de poner las mesas sin ningn elemento de separacin entre las mismas, y da ms
sensacin de amplitud, pero eso solo se recomienda a aquellos cuya cultura de empresa es consciente
del impacto de las interrupciones y saben gestionarlas.
Ms all de la opcin anterior, est la tpica prctica de usar cubculos. Facilita la comunicacin cara a
cara, no hay puertas, es ms rpido llegar a los sitios o a las mesas de otros compaeros, etc.
La siguiente opcin, es que cada persona tenga un despacho que disminuye radicalmente las
interrupciones, pero la desventaja es el sentimiento de soledad.
En cualquiera de los anteriores es necesario complementar estos entornos con salas de reuniones para
actividades que requieran trabajo en equipo, evitando molestar al resto del equipo. Y espacio para
relajarse (con sofs, etc).
Una buena prctica es que cuando alguien quiere algo de otro se lo escribe por chat, en vez de gritrselo
y hacer que el resto de la gente gire la cabeza y empiece a opinar sin necesidad. Tambin, al pedirnos

las cosas por chat, el que responde no tiene por qu contestar inmediatamente, interrumpiendo aquello
en lo que estaba.

Test Leccin 2
1- En qu consiste la tcnica Pomodoro?
a. Es una tcnica utilizada para evitar las interrupciones externas.
b. Hacer descansos frecuentes.
c. Dedicar intervalos cortos de tiempo a una nica tarea sin distraccin.
d. Ponerse msica para aislarse de un entorno ruidoso de trabajo.
2- Qu causa que la productividad disminuya cuando trabajas en ms de un proyecto a la vez?
a. Cambio de contexto.
b. Tcnica Pomodoro.
c. Un entorno que evite las interrupciones.
d. Ninguna de las anteriores.
3. Qu ocurre cuando se reduce el tiempo del proyecto muy por debajo del tiempo ideal?
a. Aumenta el esfuerzo de manera lineal.
b. No aumenta el esfuerzo.
c. Aumenta el esfuerzo de manera no lineal.
d. Ninguna de las anteriores.
4- Segn Putnam, Cul es el rango ptimo del tamao del equipo? (ya que superado ese nmero
no se reduce significativa y proporcionalmente el tiempo y el esfuerzo)
a. A partir de 3-5 personas.
b. A partir de 5-7 personas.
c. A partir de 7-9 personas.
d. Ms de 10 personas.
5- Si a un proyecto con retraso le aadimos personas (de manera no estructurada), seguiremos
teniendo problemas respecto al tiempo?
a. No ya que las horas y los recursos humanos son intercambiables.
b. No, ya que si aadimos el doble de personas recortaremos el tiempo a la mitad.
c. S, ya que aparecen prdidas de tiempo debidas al aumento de la comunicacin, la
coordinacin, la formacin.
d. Todas las anteriores son correctas.
6- Afecta escuchar msica en la actividad de programar?
a. S, afecta en la creatividad pudiendo perder la oportunidad de un salto creativo.
b. No, no afecta.
c. S, afecta a la parte del cerebro que se requiere para la lgica y la aritmtica.

 d. Ninguna de las anteriores.

7- Qu es el slack?
a. Saturar al equipo de trabajo para pretender que sea ms productivo.
b. Dar libertad al equipo, tener un margen de actuacin.
c. Ninguna de las anteriores.
d. Es una tcnica de estimacin.

Leccin 3: El Product Owner y las historias de usuario

El product owner (o propietario del producto) es aquella persona con una visin muy clara del
producto que se quiere desarrollar, que es capaz de transmitir esa visin al equipo de desarrollo y,
adems, est altamente disponible para transmitirla.
https://www.youtube.com/watch?v=NqMNMb36P80
La figura del product owner es clave en un proyecto gil, en su planificacin y seguimiento. Es una
figura que cuando no realiza correctamente su funcin el proyecto tiene un serio riesgo, y problema,
llegando incluso a dejar de ser gil, o incluso dejando de ser proyecto.
Desgraciadamente, es frecuente encontrar implantaciones errneas alrededor de este rol. En unas
ocasiones sus tareas se minimizan, en otras suelen pasarse por alto muchas de sus importantes
responsabilidades, etc.
La mayora de las ocasiones, el negocio, los usuarios, etc., van proporcionando una cantidad de ideas a
implementar, que se van convirtiendo en historias de usuario, muy superiores en nmero. La funcin del
product owner es vital, debe ser quien decida qu historias de usuario entran en el product backlog,
cules no, y adems la prioridad de las historias del product backlog.
Para saber ms...
Claves para implantar el rol de Product Owner, uno de los roles clave en un desarrollo gil (1/2)
Claves para implantar el rol de Product Owner, uno de los roles clave en un desarrollo gil (2/2)
7 responsabilidades vitales de un product owner
Video viernes: Esto es lo que hace un Producto Owner, explicado en 15 min. y de manera
divertida

Historias de usuario
En las metodologas giles la descripcin de las necesidades se realiza a partir de las historias de usuario
(user story) que son, principalmente, lo que el cliente o el usuario quiere que se implemente; es decir,

son una descripcin breve, de una funcionalidad software tal y como la percibe el usuario (M. Cohn,
2004) [1].
https://www.youtube.com/watch?v=-mbAXwB1q2M
El concepto de historia de usuario tiene sus races en la metodologa eXtremeProgramming o
programacin extrema. Esta metodologa fue creada por Kent Beck y descrita por primera vez en 1999 en
su libro eXtreme Programming Explained. No obstante, las historias de usuario se adaptan de manera
apropiada a la mayora de las metodologas giles, teniendo por ejemplo, un papel muy importante en la
metodologa Scrum.
[1] Cohn, M. (2004). User stories applied: For agile software development Addison-Wesley

Qu informacin contiene una historia de usuario

Aunque dependiendo del proyecto se podra incluir cualquier otro campo que proporcionase informacin
til, en este apartado se describen aquellos campos que se consideran ms necesarios para describir de
manera adecuada una historia de usuario. Estos campos se pueden observar en la siguiente figura:

Figura 4. Historia de usuario

De esta manera, una historia de usuario est compuesta por los siguientes elementos:

ID: identificador de la historia de usuario.

Ttulo: ttulo descriptivo de la historia de usuario.

Descripcin: descripcin sintetizada de la historia de usuario. Si bien el estilo puede ser libre, la
historia de usuario debe responder a tres preguntas: Quin se beneficia? Qu se quiere? y Cul

es el beneficio? Cohn (M. Cohn, 2004) [1] recomienda seguir el siguiente patrn: Como [rol del
usuario], quiero [objetivo], para poder [beneficio]. Con este patrn se garantiza que la
funcionalidad se captura a un alto nivel y que se est describiendo de una manera no demasiado
extensa.

Estimacin: estimacin del tiempo de implementacin de la historia de usuario en unidades de

desarrollo, conocidas como puntos de historia (estas unidades representarn el tiempo terico de
desarrollo/persona que se estipule al comienzo del proyecto).

Valor: valor (normalmente numrico) que aporta la historia de usuario al cliente o usuario. El
objetivo del equipo es maximizar el valor y la satisfaccin percibida por el cliente o usuario en
cada iteracin. Este campo determinar junto con el tiempo, el orden con el que las historias de
usuario van a ser implementadas.

Dependencias: una historia de usuario no debera ser dependiente de otra historia, pero en
ocasiones es necesario mantener la relacin. En este campo se indicaran los identificadores de
otras historias de las que depende.

Pruebas de aceptacin: pruebas consensuadas entre el cliente o usuario y el equipo que el

cdigo debe superar para dar como finalizada la implementacin de la historia de usuario. Este
campo tambin se suele denominar criterios o condiciones de aceptacin".

Cohn en (M. Cohn, 2004) [1] comenta que si bien las historias de usuario son lo suficientemente
flexibles como para describir la funcionalidad de la mayora de los sistemas, no son apropiadas
para todo. Si por cualquier razn, se necesita expresar alguna necesidad de una manera diferente a
una historia de usuario, recomienda que se haga. Por ejemplo, las interfaces de usuario se suelen
describir en documentos con muchos pantallazos. Al igual puede ocurrir con documentos especificaciones
de seguridad, normativas, etc.
No obstante, lo que s es importante con esta documentacin adicional es mantener la trazabilidad
con las historias de usuario. Por ejemplo, a travs de hojas de clculo donde se lleve el control de a qu
historia pertenece cada documento adicional, o especificando el identificador de la historia en algn
apartado del documento, etc.
[1] Cohn, M. (2004). User stories applied: For agile software development Addison-Wesley

Malas interpretaciones del concepto de historia de usuario I

Las historias de usuario equivalen a requisitos funcionales?
Popularmente se asocia el concepto de historia de usuario con el de la especificacin de un requisito
funcional. De hecho, muchas veces se habla de que a la hora de especificar una necesidad del cliente o
del usuario, las metodologas giles usan la historia de usuario y las tradicionales, el requisito funcional.
Sin embargo, detrs del concepto de historia de usuario hay muchos aspectos que lo diferencian de
lo que es una especificacin de un requisito, diferencias que muchas veces son poco conocidas y que
llevan a muchos equipos a dudas y confusiones.
Una historia de usuario describe funcionalidad que ser til para el usuario y/o cliente de un
sistema software. Y aunque normalmente las historias de usuario asociadas a las metodologas giles,
suelen escribirse en psit o tarjetas, son mucho ms que eso. Como se ha comentado anteriormente, una
historia no es slo una descripcin de una funcionalidad, sino tambin es de vital importancia la
conversacin que conllevan.
Las historias de usuario, frente a mostrar el cmo, slo dicen el qu. Es decir, muestran
funcionalidad que ser desarrollada, pero no cmo se desarrollar. De ah que aspectos como que el
software se escribir en Java no deben estar contenidos en una historia de usuario.
De esta manera, equiparar las historias de usuario con las especificaciones de requisitos no es
demasiado correcto ya que por definicin, las historias de usuario no deben tener el nivel de detalle que
suele tener la especificacin de un requisito
Una historia de usuario debera ser pequea, memorizable, y que pudiera ser desarrollada por un
par de programadores en una semana. Debido a su brevedad, es imposible que una historia de usuario
contenga toda la informacin necesaria para desarrollarla, en tan reducido espacio no se pueden describir
aspectos del diseo, de las pruebas, normativas, convenciones de codificacin a seguir, etc.
Para resolver el anterior problema hay que entender que el objetivo de las historias de usuario es, entre
otros, lograr la interaccin entre el equipo y el cliente o el usuario por encima de documentar
(manifiesto gil, ver leccin 1) por lo que no se deben sobrecargar de informacin. Sin embargo, la
realidad de los proyectos y de los negocios es otra y hace que la teora se deba ajustar a la prctica, por lo
que se pueden dar varias soluciones para reflejar toda esa informacin que en un primer momento parece
que no cuadra en las historias de usuario:

Relajar la agilidad usando los tradicionales requisitos en ciclos de vida gil.

Usar casos de uso en vez de historias de usuario.
Utilizar tcnicas de trazabilidad para relacionar las historias de usuario con otros documentos: de
diseo, normativas, etc.

[1]Cockburn, A. (2002). Agile software development. Boston, MA, USA. Addison-Wesley Longman
Publishing Co., Inc.

Malas interpretaciones del concepto de historia de usuario II

Las historias de usuario equivalen a casos de uso?
Otro concepto que suele crear confusin sobre las historias de usuario son los casos de uso. Aunque
hay quien ha logrado incluir casos de uso en su proceso gil, no quiere decir que las historias de usuario
sean equivalentes a los casos de uso. Realmente, como comenta Cockburn (A. Cockburn, 2002) [1], las
historias de usuario estn ms cerca de la captura de requisitos (aquella fase que sirve para extraer las
necesidades del usuario).
Bsicamente, si decamos que una historia de usuario es el qu quiere el usuario, el caso de uso es
un cmo lo quiere.
Generalmente, cuando un proyecto comience a seguir una metodologa gil, se deberan olvidar
completamente los casos de uso y el equipo debera centrarse en la realizacin de historias de usuario.
Segn Cockburn(A. Cockburn, 2008) [2], esto puede producir los siguientes problemas:

Las historias de usuario no proporcionan a los diseadores un contexto desde el que trabajar.
Pueden no tener claro cul es el objetivo en cada momento. Cundo le surgira al cliente o
usuario esta necesidad?
Las historias de usuario no proporcionan al equipo de trabajo ningn sentido de completitud. Se
puede dar el caso que el nmero de historias de usuario no deje de aumentar, lo que puede
provocar desmotivacin en el equipo. Realmente, cmo de grande es el proyecto?
Las historias de usuario no son un buen mecanismo para evaluar la dificultad del trabajo que est
an por llegar.

Por tanto, si en un proyecto ocurre alguno de estos problemas se puede barajar la posibilidad (relajando la
agilidad) de complementar las necesidades descritas en las historias de usuario con casos de uso donde
quede reflejado el comportamiento necesario para cumplir dichas necesidades.

En el caso de que se usen las historias de usuario y los casos de uso de manera complementaria, una
historia de usuario suele dar lugar a la especificacin de varios casos de uso.
[1]Cockburn, A. (2002). Agile software development. Boston, MA, USA. Addison-Wesley Longman
Publishing Co., Inc.
[2]Cockburn, A. (2008). Why I still use use cases. Disponible
en:http://alistair.cockburn.us/Why+I+still+use+use+cases

Creando buenas historias de usuario

Para asegurar la calidad de una historia de usuario, Bill Wake describi en 2003 un mtodo llamado
INVEST (Wake, 2003) [1]. El mtodo se usa para comprobar la calidad de una historia de usuario
revisando que cumpla las caractersticas descritas en la Tabla 1. Descripcin del INVEST.
Independient Es importante que cada historia de usuario pueda ser planificada e
(independiente) implementada en cualquier orden. Para ello deberan ser totalmente
independientes (lo cual facilita el trabajo posterior del equipo). Las
dependencias entre historias de usuario pueden reducirse
combinndolas en una o dividindolas de manera diferente.
Negotiable
(negociable)

Valuable
(valiosa)

Estimable
(estimable)

Small
(pequea)

Una historia de usuario es una descripcin corta de una necesidad

que no incluye detalles. Las historias deben ser negociables ya que
sus detalles sern acordados por el cliente/usuario y el equipo
durante la fase de conversacin. Por tanto, se debe evitar una
historia de usuario con demasiados detalles porque limitara la
conversacin acerca de la misma.
Una historia de usuario tiene que ser valiosa para el cliente o el
usuario. Una manera de hacer una historia valiosa para el cliente o
el usuario es que la escriba l mismo.
Una buena historia de usuario debe ser estimada con la precisin
suficiente para ayudar al cliente o usuario a priorizar y planificar su
implementacin. La estimacin generalmente ser realizada por el
equipo de trabajo y est directamente relacionada con el tamao de
la historia de usuario (una historia de usuario de gran tamao es
ms difcil de estimar) y con el conocimiento del equipo de la
necesidad expresada (en el caso de falta de conocimiento, sern
necesarias ms fases de conversacin acerca de la misma).
Las historias de usuario deberan englobar como mucho unas pocas
semanas/persona de trabajo. Incluso hay equipos que las restringen
a das/persona. Una descripcin corta ayuda a disminuir el tamao

de una historia de usuario, facilitando su estimacin.

Testable
(comprobable)

La historia de usuario debera ser capaz de ser probada (fase

confirmacin de la historia de usuario). Si el cliente o usuario no
sabe como probar la historia de usuario significa que no es del todo
clara o que no es valiosa. Si el equipo no puede probar una historia
de usuario nunca sabr si la ha terminado o no.

Tabla 1. Descripcin del mtodo INVEST

[1] Wake, B. (2003). INVEST in good stories, and SMART tasks. Disponible
en:http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Asignar valor a una historia de usuario

Como se comentaba en la introduccin del tema, los tems del Product backlog, deben estar priorizados,
es decir, deben tener asignados un valor. Dicho valor es asignado por el Product Owner, y pondera
bsicamente las siguientes variables:

Beneficios de implementar una funcionalidad

Prdida o coste que demande posponer la implementacin de una funcionalidad
Riesgos de implementarla
Coherencia con los intereses del negocio
Valor diferencial con respecto a productos de la competencia

Uno de los aspectos ms importantes aqu es que la definicin de "valor" para cada cliente puede variar.
Por lo tanto es muy recomendable incluir algn tipo de escala cualitativa.
Una manera rpida de empezar a asignar valor a las historias es dividirlas en 3 grupos, segn sean
imperativas, importantes o prescindibles. Dentro de cada grupo nos resultar ms fcil realizar una
ordenacin relativa por valor numrico y despus asignarlo. Todo ello servir para que en cada iteracin
entreguemos el producto al cliente maximizando su valor.
Existen otro tipo de ponderaciones, por ejemplo la tcnica MoSCoW. Esta tcnica fue definida por
primera vez en el libro Case Method Fast-Track: A RAD Approach, en el ao 2004. Su fin es obtener el
entendimiento comn entre cliente y el equipo del proyecto sobre la importancia de cada requisito o
historia de usuario. La clasificacin es la siguiente:
M - MUST. Se debe tener la funcionalidad. En caso de que no exista la solucin a construir fallar.
S - SHOULD Se debera tener la funcionalidad. La funcionalidad es importante pero la solucin no
fallar si no existe.
C - COULD Sera conveniente tener esta funcionalidad. Es en realidad un deseo.

W - WON'T No est en los planes tener esta funcionalidad en este momento. Posteriormente puede pasar
a alguno de los estados anteriores.

Lecturas y enlaces recomendados

Cohn, M. (2004). User stories applied: For agile software development Addison-Wesley
Ejemplos y buenas prcticas de descomponer historias de usuario en tareas (1/2)
Ejemplos y buenas prcticas de descomponer historias de usuario en tareas (2/2)

Test Leccin 3
Las funciones del product owner son ...
Tener una visin muy clara del producto que se quiere realizar, poder transmitirlo al grupo de
desarrollo y gestionar la comunicacin entre equipos y el orden en el que se desarrollarn las
tareas.
Ser el Jefe de Proyecto.
No son prioritarias sus funciones, es un elemento opcional en un proyecto gil.
Qu es una historia de usuario?
Un post-it que se utiliza para escribir la especificacin de requisitos.
Una descripcin breve, de una funcionalidad software tal y como la percibe el usuario
Una descripcin de todo lo que tiene que hacer el software
Ninguna de las anteriores
Una historia de usuario es equivalente a ...
Casos de uso
Requisitos

 Todas las anteriores

Ninguna de las anteriores
Una historia de usuario nos dice ...
El "qu" ser desarrollado no el "cmo" se desarrollar
El "cmo" se desarrollar una funcionalidad, no el "qu" se desarrollar
Ninguna de las anteriores
Todas las anteriores
Para asegurar la calidad de una historia de usuario, es necesario que stas tengan una descripcin
pormenorizada.
Verdadero
Falso
El tamao de una historia de usuario es ...
Grande, puede durar todo el tiempo que se quiera, incluso meses o aos.
Pequea, incluso hay equipos que las restringen a das/personas.
Ninguna de las anteriores.

Taller de historias de usuario

Explicacin de la tarea
Para terminar de entender los conceptos, y crear buenas historias de usuario, os vamos a proponer un
ejercicio colaborativo, un taller de historias de usuario como tarea P2P, el resultado del ejercicio es
elaborar un product backlog con 10 historias de usuario.
Una tarea con evaluacin entre pares (P2P) consiste en crear un documento donde incluyas la resolucin
al ejercicio que te pedimos, entregarla en la plataforma y evaluar las tareas que han hecho varios de tus
compaeros. no se considera completada la tarea si no evalas al nmero de compaeros que te pida la
plataforma, no basta con entregar tu tarea, hay que evaluar a los dems.
En este caso, tenis que crear 10 historias de usuario para el juego del Space Invaders.
Para refrescaros un poco la memoria con respecto a este juego, Space Invaders es el tpico juego de matar
marcianos, en dos dimensiones.El jugador controla un can que puede moverse a la derecha o izquierda
y disparar. El objetivo del juego es ir destruyendo los extraterrestres invasores disparando con el can,
que van acercndose a la tierra cada vez ms rpidamente a medida que el jugador va destruyendo a los
enemigos. Este ciclo se puede repetir en forma indefinida. Si los invasores llegan al can controlado por
el jugador, el juego termina.
http://www.youtube.com/watch?v=437Ld_rKM2s

Cada cierto tiempo aparece en la pantalla, por encima de los extraterrestres, un platillo volador que se
mueve aleatoriamente de derecha a izquierda o de izquierda a derecha. Si el jugador le dispara y destruye,
suma una serie de puntos aleatorios. Adems hay una fila de 4 escudos de proteccin, justo delante del
jugador, para protegerlo de los disparos aliengenas. Estos escudos son destruidos gradualmente por los
disparos de los invasores o del propio can del jugador.
Nos vamos a poner en la situacin de que empezamos de cero a crear el juego a da de hoy (no vamos a
evolucionar el space invaders existente, vamos a crear uno nuevo de cero).

Cmo entrego el ejercicio?

Paso 1 Ejercicio resuelto.Deberis incluir las 10 historias de usuario en un archivo, y adjuntarlo ms
abajo, en la seccin de Entrega tu tarea. Recomendamos que el archivo sea preferentemente en formato
pdf (para que luego tus compaeros puedan abrirlo sin problemas). En la caja de texto, puedes copiar el
mismo texto que hayas escrito en el archivo, escribir cualquier comentario, o simplemente poner un ".".
Este comentario lo leer la persona que te evale.
Paso 2 Evaluar a tus compaeros. Despus de entregar tu tarea, la pgina pasar a la fase 2 ("2.
Valora a tus compaeros"), donde te mostrar una lista de varios ejercicios de tus compaeros, y tendrs
que evaluarlos. La evaluacin consiste en leer lo que tu compaero ha escrito, y escribir una valoracin en
la caja de texto. Al contrario que cuando envas la tareas, al evaluar no es obligatorio adjuntar ningn
archivo (tienes la opcin, pero solo es una opcin y mejor si los comentarios los haces SOLO en el cuadro
de texto).
Por poneros un ejemplo, estos seran algunos de los aspectos que podras evaluar:
1. Ha incluido 10 historias de usuario?
2. Las historias de usuario siguen el formato apropiado? (p.e Como [jugador] quiero)
3. Cada historia de usuario incluye los elementos necesarios? (p.e. Estimacin, valor, ttulo,
descripcin-Ver seccin de Qu informacin contiene una historia de usuario-)
4. Est priorizada la lista de historias de usuario? Recuerda que un product backlog debera estar
priorizado (puedes ayudarte del mtodo MoSCoW)
5. Se contempla cmo validar cada historia de usuario (condiciones de satisfaccin o aceptacin)
por parte del product owner una vez completada?
6. Se cumple el mtodo INVEST?
7. Tienen demasiado texto las historias?
8. Son demasiado genricas? Recuerda que una historia debera poderse desarrollar en un Sprint o
iteracin (para este ejercicio supondremos iteraciones de 30 das y un equipo de 5 personas)
No obstante, esta parte est abierta a cualquier valoracin o recomendacin que se te pudiera ocurrir. Ten
en cuenta que este es un ejercicio abierto para que podis aprender y mejorar unos de otros J.

Paso 3 Ver las evaluaciones que han hecho tus compaeros sobre tu ejercicio. Cuando valores a
todos los compaeros, la pgina pasar a la fase 3 y te mostrar cmo han valorado tu trabajo. Es posible
que todava no te haya valorado nadie, pero puedes acceder de nuevo cuando quieras para ver las
valoraciones.
Paso 4 Fin de la tarea.Si has valorado todos los trabajos pedidos, debera aparecerte la tarea como
completada, con un "tick" verde.
ATENCIN! Es importante que hagas la valoracin de tus compaeros cuando tengas tiempo y ests
preparada/o. La asignacin de trabajos cambia CADA vez que accedes a la pgina de la tarea P2P. Es
decir, si descargas los trabajos a valorar y ests ausente de la plataforma ms de DOS HORAS, se cerrar
tu sesin. Cuando vuelvas, e introduzcas de nuevo tu usuario y contrasea, la plataforma te ofrecer
TRABAJOS DIFERENTES a los que tenas al principio; si ya los has ledo y valorado, no te habr
servido de nada porque tendrs que valorar otros diferentes para completar la actividad. Del mismo modo,
si sales de la pgina para consultar un video, por ejemplo, al volver te habr cambiado las tareas. Esto es
debido al algoritmo establecido por el equipo de MiriadaX (y no podemos cambiarlo). Si necesitas
consultar otras secciones mientras valoras, hazlo desde otra pestaa o ventana de tu navegador.
Si eres de los primeros en subir tareas, la plataforma no podr asignarte tareas de otras personas para
valorar. Vuelve uno o dos das despus y ya podrs completar esta fase.

Leccin 4: Scrum
https://www.youtube.com/watch?v=KA9A9eRXhLo
Scrum es una metodologa gil que proporciona un marco para la gestin de proyectos. Podramos decir
que hoy en da es la metodologa gil ms popular, y, de hecho, se ha utilizado para desarrollar productos
software desde principios de la dcada de los 90.
El conjunto de buenas prcticas de Scrum se aplica esencialmente a la gestin de proyectos.
Por otro lado, aunque normalmente hablamos de la metodologa Scrum, lo correcto sera decir el
framework Scrum, porque realmente es un conjunto de buenas prcticas que necesita su adaptacin en
cada organizacin, o, incluso, a cada equipo. [1].
https://www.youtube.com/watch?v=GGVrxFlfbZA
Como se indica en la Scrum Guide [1] , existen tres pilares en los que se basa:

Transparencia: todos los aspectos del proceso que afectan al resultado son visibles para todos
aquellos que administran dicho resultado. Por ejemplo, se utilizan pizarras y otros mecanismos o
tcnicas colaborativas para mejorar la comunicacin.

Inspeccin: se debe controlar con la frecuencia suficiente los diversos aspectos del proceso para
que puedan detectarse variaciones inaceptables en el mismo.
Revisin: el producto debe estar dentro de los lmites aceptables. En caso de desviacin se
proceder a una adaptacin del proceso y el material procesado.

Puedes ver una entrevista que realic a Sthuerland aqu.

[1] Schwaber, K., & Sutherland, J. (2013). Scrum guide. Disponible en:https://www.scrum.org/ScrumGuides

El equipo en Scrum
Uno de los aspectos ms importantes en cualquier proyecto, y tambin en los proyectos giles, es el
establecimiento del equipo. Los roles y responsabilidades deben ser claros y conocidos por todos los
integrantes del mismo.
Infografas de los roles de Scrum:
Infografa del Product Owner
Infografa del Scrum Master
Cada equipo Scrum tiene tres roles:

Scrum Master: es el responsable de asegurar que el equipo Scrum siga las prcticas de Scrum.
Sus principales funciones son:

Ayuda a que el equipo Scrum y la organizacin adopten Scrum.

Liderar el equipo Scrum, buscando la mejora en la productividad y calidad de los
entregables.
Ayudar a la autogestin del equipo.
Gestiona e intenta resolver los impedimentos con los que el equipo se encuentra para
cumplir con las tareas del proyecto.

Propietario del Producto (ProductOwner): es la persona responsable de gestionar las

necesidades que sern satisfechas por el proyecto y asegurar el valor del trabajo que el equipo
lleva a cabo. Su aportacin al equipo se basa en:

Recolectar las necesidades o historias de usuario.

Gestionar y ordenar las necesidades (representadas por las historias de usuario,descritas
en la leccin 2 ).
Aceptar el producto software al finalizar cada iteracin.
Maximizar el retorno de inversin del proyecto.

Equipo de desarrollo: El equipo est formado por los desarrolladores, que convertirn las
necesidades del ProductOwner en un conjunto de nuevas funcionalidades, modificaciones o
incrementos del producto software final. El equipo de desarrollo tiene caractersticas especiales:

Auto-gestionado: el mismo equipo supervisa su trabajo. En Scrum se potenciarn las

reuniones del equipo (aqu tienes un post sobre ese tema), aumentando la comunicacin.
No existe el rol clsico de jefe de proyecto. El Scrum Master tiene otras
responsabilidades vistas en el apartado anterior.
Multifuncional: no existen compartimientos estancos o especialistas, cada integrante del
equipo puede encargarse de tareas de programacin, pruebas, despliegue, etc. Asimismo
las personas pueden tener capacidades diferentes o conocimientos ms profundos en
diferentes reas. Lo importante es que cualquier integrante del equipo sea capaz de
realizar cualquier funcin.
No distribuidos: es conveniente que el equipo se encuentre en el mismo lugar fsico.
Esto facilita la comunicacin y la autogestin que nace del mismo equipo.No obstante se
ha conseguido realizar proyectos Scrum con equipos distribuidos gracias a herramientas
de trabajo colaborativo (Hossain et al., 2009) [1].
Tamao ptimo: un equipo de desarrollo Scrum (sin tener en cuenta al Product Owner y
al Scrum Master) estara compuesto por al menos tres personas. Con menos de tres
personas al interaccin decae y con ella la productividad del equipo. Como lmite
superior, con ms de nueve personas la interaccin hace que la autogestin sea muy
difcil de alcanzar.

[1] Hossain, E., Babar, M. A., & Hye-young Paik. (2009). Using scrum in global software development:
A systematic literature review. Artculo presentado en Fourth IEEE International Conference on Global
Software Engineering, 2009. pp. 175

El Product Backlog
https://www.youtube.com/watch?v=OEurlA_3xq0
La pila de producto o Product Backlog (utilizaremos las palabras en ingls al ser la forma ms utilizada
en los proyectos) en Scrum es uno de los elementos fundamentales. A partir del Product Backlog se
logra tener una nica visin durante todo el proyecto. Y, por lo tanto, los fallos en el Product Backlog
repercutirn profundamente en el proyecto.
El Product Backlog consiste en un listado de historias del usuario que se incorporarn al producto
software a partir de incrementos sucesivos. Es decir, sera similar a un listado de requisitos de usuario
y representa lo que el cliente espera. Una de las principales diferencias respecto de un proceso
tradicional es la evolucin continua del Product Backlog, buscando aumentar el valor del producto
software desde el punto de vista del negocio.
Para ello, este listado estar ordenado. Aunque no existe un criterio preestablecido en Scrum para
ordenar las historias de usuario, el ms aceptado es partir del valor que aporta al negocio la
implementacin de la historia de usuario. El responsable de ordenar el Product Backlog es el
Product Owner, aunque tambin puede ser ayudado o recibir asesoramiento de otros roles como, por
ejemplo, el Scrum Master y el equipo de desarrollo.
Tal y como se describe en (Pichler, 2010) [1] un Product Backlog cuenta, esencialmente, con cuatro
cualidades: debe estar detallado de manera adecuada, estimado, emergente y priorizado:

Detallado adecuadamente: el grado de detalle depender de la prioridad. Las historias de

usuario que tengan una mayor prioridad se describen con ms detalle. De esta manera las
siguientes funcionalidades a ser implementadas se encuentran descritas correctamente y son
viables. Como consecuencia de esto, las necesidades se descubren, se descomponen, y
perfeccionan a lo largo de todo el proyecto.

Estimado: las estimaciones a menudo se expresan en das ideales o en trminos abstractos. Saber
el tamao de los elementos del Product Backlog ayuda a darle prioridad y a planificar los
siguientes pasos. Una de las tcnicas que se pueden emplear para estimar las historias de usuario
es el Planning Poker, que veremos en la Leccin 4.
https://www.youtube.com/watch?v=6aeTlbOeVmI

Emergente: las necesidades se van desarrollando y sus contenidos cambian con frecuencia. Los
nuevos elementos se descubren y se agregan a la lista teniendo en cuenta los comentarios de los
clientes y usuarios. As mismo, otros elementos podrn ser modificados o eliminados.

Priorizado: los elementos del Product Backlog se priorizan. Los elementos ms importantes y de
mayor prioridad aparecen en la parte superior de la lista. Puede no ser necesario priorizar todos
los elementos en un primer momento, sin embargo s es conveniente identificar los 15-20
elementos ms prioritarios.

Puedes leer ms sobre el product backlog aqu.

[1] Pichler, R. (2010). Agile product management with scrum: Creating products that customers love
Addison-Wesley Professional.

El Sprint
Como hemos visto anteriormente, una de las bases de los proyectos giles es el desarrollo mediante las
iteraciones incrementales. En Scrum a cada iteracin se le denomina Sprint. Scrum recomienda
iteraciones cortas, por lo que cada Sprint durar entre 1 y 4 semanas. Y como resultado se crear un
producto software potencialmente entregable, un prototipo operativo. Las caractersticas que van a
implementarse en el Sprint provienen del Product Backlog.
El equipo de desarrollo selecciona las historias de usuario que se van a desarrollar en el Sprint
conformando la pila de Sprint (Sprint Backlog). La definicin de cmo descomponer, analizar o
desarrollar este Sprint Backlog queda a criterio del equipo de desarrollo.
https://www.youtube.com/watch?v=paZkbQwZpCY
Importante: Aunque todos los Sprints dan como resultado un incremento del producto software, no todos
implican un paso a produccin. Es responsabilidad del ProductOwner y los clientes decidir el momento en
el que los incrementos son puestos en produccin.
Una posibilidad para realizar la puesta en produccin es con los denominados "Sprints de Release". Estos
Sprints contendrn, en general, tareas solamente relacionadas con el despliegue, instalacin y puesta en
produccin del sistema. Es decir, no existen tareas donde se agreguen nueva funcionalidad.
http://www.youtube.com/watch?v=sfWfHPsHm6o&feature=youtu.be
Adems, el equipo de desarrollo deber estimar el esfuerzo que nos llevarn las tareas del Sprint Backlog
(un mtodo de estimacin muy usado en Scrum y que veremos ms adelante es el Planning Poker,
descrito en la leccin 4 ).

Importante: En Scrum el Sprint Backlog indica solamente lo que el equipo realizar durante la iteracin.
El ProductBacklog, por el contrario, es una lista de caractersticas que el ProductOwner quiere que se
realicen en futuros Sprints.
El Product Owner puede visualizar, pero no puede modificar el Sprint Backlog. En cambio, puede
modificar el ProductBacklog cuantas veces quiera con la nica restriccin de que los cambios tendrn
efecto una vez finalizado el Sprint.
Para mejorar la gestin de las historias de usuario y las tareas de cada Sprint usualmente se utilizan
pizarras u otros mecanismos que brinden informacin inmediata al equipo. En el siguiente video puedes
ver un ejemplo de lo que podra ser un tablero Scrum en un proyecto real.
Impresionante, tablero Scrum en pizarra que actualiza automticamente un Jira. Pdeselo a los Reyes

Reuniones
Las reuniones son un pilar importante dentro de Scrum. Se realizan a lo largo de todo el Sprint como
muestra la Figura 4, representadas en los cuadros con color gris. Se definen diversos tipos de reuniones:

Reunin de planificacin del Sprint (Sprint Planning Meeting): se lleva a cabo al principio de
cada Sprint, definiendo en ella que se va a realizar en ese Sprint. Esta reunin da lugar al Sprint
Backlog. En esta reunin participan todos los roles. El Product Owner presenta el conjunto de
historias de usuario en el ProductBacklog y el equipo de desarrollo selecciona las historias de
usuario sobre las que se trabajar. La duracin de la reunin no debe ser mayor de 8 horas y como
resultado de la misma el equipo de desarrollo hace una previsin del trabajo que ser completada
durante el Sprint.
https://www.youtube.com/watch?v=QQcKjsk9_gg

Reunin diaria (Daily Scrum): es una reunin diaria de no ms de 15 minutos en la que

participan el equipo de desarrollo y el Scrum Master. En esta reunin cada miembro del equipo
presenta lo que hizo el da anterior, lo que va a hacer hoy y los impedimentos que se ha
encontrado.
https://www.youtube.com/watch?v=pfQeF4OGOdU

Reunin de revisin del Sprint (Sprint Review Meeting): se realiza al final del Sprint.
Participan el equipo de desarrollo, el Scrum Master y el Product Owner. Durante la misma se
indica qu ha podido completarse y qu no, presentando el trabajo realizado al Product Owner.
Por su parte el Product Owner (y dems interesados) verifican el incremento del producto y
obtienen informacin necesaria para actualizar el Product Backlog con nuevas historias de
usuario. No debe durar ms de 4 horas.

Retrospectiva del Sprint (Sprint Retrospective): tambin al final del Sprint (aunque puede que
no se realice al final de todos los Sprints), sirve para que los integrantes del equipo Scrum y el
Scrum Master den sus impresiones sobre el Sprint que acaba de terminar. Se utiliza para la
mejora del proceso y normalmente se trabaja con dos columnas, con los aspectos positivos y
negativos del Sprint. Esta reunin no debera durar ms de 4 horas.
https://www.youtube.com/watch?v=WwHZwBWIvM8

Medir el progreso del proyecto

En el caso de las prcticas giles y en particular de Scrum uno de los mecanismos ms utilizados es el
grfico BurnDown [1].
Este grfico representa el trabajo que queda por hacer en un Sprint en funcin del tiempo y compara
el progreso real del Sprint con su planificacin inicial, facilitando las labores de seguimiento del
mismo.
https://www.youtube.com/watch?v=IU1-ZLk5fQQ

[1] Sutherland, J. (2001). Agile can scale: Inventing and reinventing scrum in five companies.14(12)

Acordar una buena definicin de "done"

Por lo general, la gente que empieza a implantar agilidad, o los que lo han intentado pero no con mucho
xito, suelen tener en comn el pasar por alto un grupo de aspectos que son de los ms importantes: los
que definen las relaciones y compromisos entre los diferentes roles que participan en el desarrollo
software.
Todo el mundo es consciente y se preocupa por establecer iteraciones, Sprint, prototipos, historias de
usuario, etc. Pero hay otros aspectos en un proyecto gil igualmente importantes, como son los de
compromiso, por ejemplo, que todo el mundo tenga claros los roles y responsabilidades de todo el mundo,
que al comenzar un Sprint el product owner deje clara la visin y el objetivo, etc.
O, como es el caso que aqu aplica, que tanto equipo como product owner estn de acuerdo y definan qu
significa que algo est terminado. Por dejarlo ms claro, haciendo referencia a un tablero Scrum qu
significa que algo est en la columna done (terminado).
Lo de qu significa done, terminado, se obvia muchas veces y no es algo trivial. No aclarar este punto
suele dar lugar a problemas.
Puedes encontrar ms informacin sobre este tema aqu

Beneficios de Scrum
Para ayudarte a la hora de implantar Scrum y la agilidad en tu empresa, te dejo un mapa de ideas clave
que debes tener en cuenta.
Mapa mental de buenas prcticas y claves a la hora de implantar Scrum y agilidad
La implantacin de las metodologas giles, y, por lo tanto, de los principios giles, aporta una serie de
beneficios como el aumento de la transparencia a lo largo de la gestin del proyecto, la mejora de la
comunicacin y la autogestin del equipo de desarrollo. As mismo, existen otras ventajas que se obtienen
al utilizar Scrum.

Entrega peridica de resultados. El Product Owner establece sus expectativas indicando el

valor que le aporta cada historia de usuario y cuando espera que est completado. Por otra parte,
comprueba de manera regular si se van cumpliendo sus expectativas.

Entregas parciales (time to market). El cliente puede utilizar las primeras funcionalidades de
la aplicacin software que se est construyendo antes de que est finalizada por completo. Por
tanto, el cliente puede empezar antes a recuperar su inversin. Por ejemplo, puede utilizar un
producto al que slo le faltan caractersticas poco relevantes, puede introducir en el mercado un
producto antes que su competidor, puede hacer frente a nuevas peticiones de clientes, etc.

Flexibilidad y adaptacin respecto a las necesidades del cliente. De manera regular el Product
Owner redirige el proyecto en funcin de sus nuevas prioridades, de los cambios en el mercado,
de los requisitos completados que le permiten entender mejor el producto, de la velocidad real de
desarrollo, etc. Al final de cada iteracin el Product Owner puede aprovechar la parte de producto
completada hasta ese momento para hacer pruebas de concepto con usuarios o consumidores y
tomar decisiones en funcin del resultado obtenido.

Mejores estimaciones. La estimacin del esfuerzo y la optimizacin de tareas es mejor si la

realizan las personas que van a desarrollar la historia de usuario, dadas sus diferentes
especializaciones, experiencias y puntos de vista. De la misma manera, con iteraciones cortas la
precisin de las estimaciones aumenta. En el captulo siguiente veremos las tcnicas de
estimacin en proyectos giles.

Adems te recomiendo el siguiente video. En l, Joe Justice, un desarrollador de software aficionado a

tunear coches, cuenta cmo aplic la agilidad para, de manera colaborativa, crear un nuevo prototipo de
coche. Y cmo lo logr, con el apoyo de un montn de gente de muchos sitios, con un modelo de
crowdfunding, que bajo el proyecto Wikispeed cre de manera gil un coche real, rpida y
econmicamente.
http://www.youtube.com/watch?v=x8jdx-lf2Dw

Animacin de despedida
https://www.youtube.com/watch?v=43IZRmJeMwI

No olvides las buenas prcticas tcnicas

http://www.youtube.com/watch?v=ha1LJHHfiCg&feature=youtu.be
eXtreme Programming y los mtodos giles (2001)

Lecturas y enlaces recomendados

Gua Scrum
Mapa mental de buenas prcticas y claves a la hora de implantar Scrum y agilidad
Scrum para Dummies (1/2). Las ideas de Scrum en 2 post de 5 min.

Test Leccin 4
Seleccione la opcin correcta sobre Scrum:
Se adapta de forma temprana a los cambios de requisitos.
Est especialmente indicado para proyectos sin cambio en los requisitos.
No se tiene en cuenta el valor aportado al cliente.
Elegir la afirmacin correcta:
No pueden existir dependencias entre historias de usuario.
Para mejorar la creatividad del equipo es necesario evitar la realizacin de estimaciones.
El valor lo da el Product Owner.
El Scrum Master es el jefe de equipo y todos los dems miembros han de rendirle cuentas.
Verdadero.
Falso.

Verdadero o Falso: En la retrospectiva del Sprint se inspeccionar el producto resultante y se

revisar el Sprint pasado y se determinarn qu adaptaciones se harn en el siguiente Sprint
Verdadero.
Falso.
Qu compara el diagrama burndown?
Compara el trabajo real y el trabajo ideal.
Compara el trabajo real con la siguiente iteracin
Compara el trabajo ideal del Sprint actual respecto del trabajo ideal del siguiente Sprint
Qu caractersticas principales tiene Scrum?
Reuniones e iteraciones incrementales
Reuniones y modelo en cascada
Reuniones
Ninguna de las anteriores
Todas las empresas que usan Scrum lo aplican de la misma forma?
Si, ya que es una metodologa gil, lo conocemos por metodologa Scrum.
No, ya que al ser un framework, es necesario que cada empresa lo adapte.

Leccin 5: La planificacin gil

En la actualidad el desarrollo software sigue afectado por graves problemas:

los proyectos no se ajustan al presupuesto inicial

son entregados fuera de plazo
existe una baja calidad del software generado
el software no cumple las especificaciones
y el cdigo muchas veces es inmantenible,...

...lo cual dificulta la gestin y evolucin del proyecto. Las prcticas giles no escapan a este problema y
de hecho, por estar asociadas a requisitos cambiantes el desafo es mayor.
La mayora de los errores que se producen con ms frecuencia en los proyectos software estn
relacionados con aspectos de estimacin. Entre estos errores se pueden destacar:

Calendario optimista: la tendencia al estimar es hacerlo de manera optimista. Esta tendencia es

general y se va disminuyendo con la experiencia. An as en un histrico de estimaciones estimar
por encima es mucho menos frecuente que estimar por debajo.

Expectativas no realistas: muchas veces las tareas sobre las que se ha estimado son ambiguas.
Posteriormente el equipo seguramente se llega a un consenso comn pero el cliente puede
mantener otra expectativa. Y presionar para obtener el resultado que l cree es el correcto.

Confundir estimaciones con objetivos: al estimar tenemos que tener en cuenta nuestra
capacidad actual real y el histrico de productividad de la empresa. Es decir, si queremos
terminar en 3 meses (un objetivo) puede que lo consigamos o no sabiendo que contamos con 2
programadores y que el 20% del tiempo estamos respondiendo incidencias de otros proyectos.

Omisin de estimar tareas necesarias: las pruebas, la documentacin, las tareas relacionadas
con la gestin de configuracin o la calidad puede que no se planifiquen. Pero muchas veces
consumen tiempo.

La unidad de estimacin: Puntos historia

Histricamente, la unidad clsica de estimacin del tamao de un requisito ha sido el Punto Funcin.
Pero, en los ltimos aos, los puntos historia se han convertido en una unidad de tamao muy usada,
principalmente en proyectos giles. Por ejemplo, la tcnica de estimacin Planning Poker, que
explicaremos ms adelante, emplea los Puntos Historia.
https://www.youtube.com/watch?v=ITrz9efyXdM
A la hora de asignar puntos historia a cada historia de usuario lo que importa son los valores relativos
de una historia frente al resto: una historia a la que se le asignan dos puntos historia debe requerir
el doble de esfuerzo, complejidad o tamao que una historia a la que se le asigna un nico punto.
Y normalmente hay dos formas de hacer esta asignacin:

Seleccionar una historia de las ms pequeas y asignarle 1 punto historia. Esta historia de
usuario con 1 punto historia har de unidad, y al resto se le asignarn puntos historia en funcin
de su complejidad respecto a sta.

Seleccionar una historia de tamao medio y asignarle un nmero en la mitad del rango de
puntos historia a utilizar. Normalmente, se usan rangos de puntos historia entre 1-10. Segn
esto, buscaramos una historia de tamao medio y le asignaramos cinco puntos historia. Cada
historia adicional se calcula comparndola con la primera historia.

Para saber ms sobre otros mtodos de estimacin

Estimacin software, una breve introduccin (1/4)

Planning Poker
Una vez elegidas las funcionalidades a realizarse en un Sprint, de acuerdo con lo priorizado por el
cliente, es necesario realizar una estimacin ms detallada, utilizando por ejemplo, la tcnica de
Planning Poker.
El Planning Poker es una tcnica que se utiliza para asignar los puntos historia a las historias de
usuario. Esta tcnica recibe el nombre de Planning Poker ya que cada una de las personas implicadas en
el proceso de estimacin toma un mazo de cartas que suelen estar numeradas con alguna de las secuencias
que vimos antes (por ejemplo la de Fibonacci).
La tcnica de Planning Poker est basada en el consenso y es utilizada para estimar el esfuerzo o el
tamao relativo de las tareas de desarrollo de software. Est muy arraigado en las tcnicas giles por su
sencillez, facilidad y bajo coste. No es una prctica de Scrum pero se suele utilizar con esta metodologa
gil.
Los pasos a seguir en el Planning Poker son los siguientes:

1. Se presentan las historias de usuario a estimar uno por uno haciendo una descripcin de los mismos.
Y se procede a discutir aquellos detalles ms relevantes o que no hayan quedado claros. Suele darse un
tiempo mximo de discusin para mejorar la productividad.
2. Tras este perodo de discusin cada una de las personas implicadas en el proceso de estimacin toma
un mazo de cartas (que estn numeradas segn la serie de Fibonacci, como objetivo de reflejar la
incertidumbre inherente en la estimacin). De ah escoge la carta que representa su estimacin del
trabajo que implica implementar el requisito que se est discutiendo. Las estimaciones son privadas.
3. Las unidades utilizadas pueden ser variadas y deben estar definidas previamente. Pueden ser das
reales, das ideales o puntos de la historia. Como consenso se denominan puntos de poker. La diferencia
entre das ideales y reales est en la cantidad de horas a tener en cuenta. En los proyectos en los que se
suceden muchas interrupciones es conveniente estimar en das reales (o incluso en horas).
4. Finalmente se publican todas las estimaciones, es decir, cada integrante del equipo muestra a la vez
la carta seleccionada (esto es as para evitar que las estimaciones de unos modifiquen las de otros). Si
existe una gran dispersin entre las estimaciones (unos dicen 2, otros 21) se vuelve al discutir el requisito
y se vuelve a realizar el proceso de estimacin.
5. Generalmente la dispersin en las estimaciones es sntoma de que la informacin que manejan parte
de los involucrados en el proceso de estimacin no es completa o exacta. La segunda ronda de discusin
permite aclarar aquellos puntos poco claros, diferencias de criterio y desvelar informacin que pueda no
ser obvia sobre el requisito. En la siguiente ronda de estimacin la dispersin de las estimaciones ser
mucho menor y se podr llegar fcilmente a un consenso.
Usando Planning Poker es fcil estimar las historias de usuario de una manera gil y rpida
combinando la analoga y el juicio experto a un entorno grupal democrtico. Nos lleva a
estimaciones respaldadas por todos los involucrados y basadas en consensos.

Un ejemplo de convergencia en Planning Poker

A continuacin os mostramos un ejemplo de estimacin y el problema de lograr la convergencia.
Como hemos visto anteriormente, ser necesario lograr la convergencia en caso que las estimaciones de
los integrantes del equipo no estn del todo de acuerdo y persistan algunas estimaciones muy diferentes.
Las personas cuya estimacin est ms alejada del consenso debern explicar en un tiempo corto (2
minutos, por ejemplo) por qu su votacin es ms alta o ms baja.
A continuacin se presenta un histrico de Planning Poker. Donde los cuatro desarrolladores de un equipo
que usa metodologas giles planean estimar 3 historias de usuario.

*Usando la notacin PP = puntos de poker.

Planning Poker II
A continuacin plantearemos un ejemplo ms complejo de estimacin con Planning Poker.
Supongamos que en la prxima iteracin debemos implementar 3 historias de usuario. Nuestro equipo
est formado por 4 desarrolladores: D1, D2, D3 y D4. La unidad que usaremos sern los Puntos Poker.
Se presenta el siguiente histrico de estimaciones:

Siendo la estimacin final de la iteracin 22 puntos poker.

Ahora vamos a analizar cada uno de los histricos de las estimaciones de las historias de usuario.

En la historia de usuario 1, se aprecia cmo D1 y D4 tenan una diferencia de informacin. Por

ello, tras exponer sus razones vemos cmo realmente D4 era el mejor informado ya que a lo largo
de los turnos, con sus respectivas exposiciones, los dems convergen a su estimacin inicial.

En la historia de usuario 2, hay una informacin asimtrica entre los desarrolladores D1 y D4

respecto a D2 y D3. Ello puede ser debido a desconocimiento de la tarea, o del campo a tratar,
etc. Por ello tras una exposicin de las razones, todos convergen en sus puntuaciones.

El caso de la historia de usuario 3, es aquel en el que tanto D2 como D4 carecen de la

informacin completa. Ello se ve ya que, al avanzar el histrico, convergen a la estimacin
inicial de los otros desarrolladores.

Importante: Este modo dinmico de estimacin hace participar a todos los asistentes,reduce el
tiempo de estimacin de una funcionalidad, y lo ms importante, se consigue alcanzar una
convergencia en la estimacin de las historias de usuario.

Peligros al estimar
Al realizar estimaciones teniendo en cuenta jornadas de trabajo es necesario recordar lo siguiente: los das
son "ideales". stos son aquellos en los que se cumplen las horas de trabajo definidas sin interrupciones,
interferencias o distracciones de ningn tipo.
Entre un 25% y 35% del tiempo se invertirn en otras actividades (imprevistos, llamadas, correo,
etc.). Asimismo es bueno recordar que el trabajo se expande hasta ocupar todo el tiempo del que se
dispona para su realizacin.
Estos dos aspectos significan que si realizamos una estimacin por arriba (es decir que indicamos 3 das
a una tarea que se realiza en 2 das) por lo general los equipos van a utilizar todo el tiempo del que
disponen. Y si estimamos por debajo (decimos 3 das reales para una tarea de 3 das ideales) tendremos
retrasos.

La velocidad
La velocidad es la cantidad de trabajo que un equipo puede hacer en una iteracin. En el inicio de la
iteracin el equipo estima el trabajo que ser medido tomando un sistema de referencia de puntos,
llamados puntos de sistema. stos sern arbitrarios, y pueden tomar numerosas unidades: historias de
usuario, tareas tcnicas, etc.
http://youtu.be/X66vfjW0yWI

Histrico del equipo

Ajustando las estimaciones
Ahora imaginemos que en el proceso de estimacin nuestro equipo ha realizado una estimacin poco
realista. Esto se puede dar por diferentes causas, por ejemplo nuestro equipo de desarrollo est
compuesto por 3 personas y los 3 tenan un da "optimista".
Es decir, es necesario tener en cuenta la historia del equipo y la velocidad de desarrollo para comprobar
si las estimaciones han sido demasiado optimistas o pesimistas.
En el siguiente ejemplo, vemos un histrico de la velocidad media por iteracin de nuestro equipo.
Para este caso la velocidad vendr determinada por el nmero medio de puntos historia que ha

realizado nuestro equipo en las iteraciones de un proyecto. En el eje vertical se encuentra la cantidad de
puntos historia desarrollados. En el eje horizontal se indican los proyectos realizados.

Esto nos sirve desde dos puntos de vista:

Antes del inicio de una estimacin: para que el equipo conozca su capacidad
Despus de realizar la estimacin: para que se controle que tan bien o mal se ha realizado la
estimacin.

Importante: Hemos dicho que las estimaciones suelen ser optimistas. Por lo tanto, una vez se van
afianzando las tcnicas de estimacin la estimacin por debajo disminuye.
De esta manera, como puede verse en el grfico, al inicio del proyecto las estimaciones suelen ser
dispersas e imprecisas. Sin embargo, segn avanza el proyecto, a travs del histrico, la introduccin
de nuevas prcticas de estimacin y la experiencia conseguida en las mismas se tiende a una mejora en
las estimaciones futuras.

Estimando el nmero de iteraciones necesarias para el proyecto

Si sumamos los puntos historia de todas las historias de usuario a desarrollar tendremos una
estimacin del tamao total del proyecto. Y si conocemos la velocidad del equipo, por datos histricos,
podremos dividir el tamao entre la velocidad para llegar a una estimacin del nmero de
iteraciones necesarias.
Por ejemplo, supongamos que todas las historias de usuario se han estimado y que la suma de esas
estimaciones es de 100 puntos historia. En base a la experiencia previa sabemos que la velocidad media
del equipo es de 11 puntos historia por iteracin de dos semanas. Ya que 100/11 = 9,1 se puede estimar
que el proyecto necesita 9,1 iteraciones, con un enfoque conservador redondeando a 10 iteraciones. Dado
que cada iteracin es de dos semanas, nuestra estimacin de la duracin es de veinte semanas.

En cualquier caso, no olvides que cuando hablamos de velocidad hacemos referencia a una media. Si
necesitas hacer estudios ms profundos sobre la velocidad de un equipo, o comparar ms fielmente a
dos equipos segn su velocidad, etc., deberas acompaar la velocidad media de otros valores, por
ejemplo, la desviacin tpica.

Cunto debe durar una iteracin

Un punto clave a la hora de planificar un proyecto iterativo es decidir la duracin de las iteraciones
(o de los sprint en terminologa Scrum). En la siguiente figura se puede ver un ejemplo con iteraciones de
3 semanas de duracin.

Ejemplo de planificacin de un proyecto iterativo con iteraciones de 3 semanas.

Ten cuidado, que en este punto la terminologa puede ser confusa
Una iteracin, es un periodo de tiempo, no confundir con el ciclo de vida iterativo.
Para seleccionar la duracin de una iteracin, podemos encontrar recomendaciones de todo tipo.
Por ejemplo, metodologas como XP recomiendan iteraciones de un par de semanas, mientras que lo
habitual en Scrum es que sean de un mes de duracin. Y lo normal que nos solemos encontrar en
proyectos son iteraciones que estn entre una semana y un mes.
Qu debera determinar la duracin ms recomendable para una iteracin? Sin que exista una
norma exacta, los siguientes factores pueden servirnos de ayuda:

La frecuencia con la que hay que mostrar el software a los usuarios. Normalmente, el
software se puede mostrar al final de una iteracin (demos de prototipos), por lo que a mayor
frecuencia requerida para mostrar demos y avance, menor debiera ser la duracin de la iteracin.

En lnea con el anterior, debiramos pensar con qu frecuencia hay que medir, o mostrar, el
progreso del proyecto. En teora slo al final de una iteracin podemos medir con precisin la
cantidad de trabajo que realmente ha sido completado.

La frecuencia con la que se pueden reajustar objetivos del proyecto. No debiramos hacer
cambios de objetivo, funcionalidad, o alcance, una vez que ha comenzado una iteracin. Los
ajustes y cambios deben esperar hasta el momento en que una iteracin termina. Por ello, si se
requiere mayor ratio de cambio de alcance, menor debiera ser la duracin de la iteracin. Por lo
tanto, el tiempo que se puede aguantar sin cambios de prioridad es un factor determinante a la
hora de fijar la temporalidad de una iteracin.

Con todo, por ejemplo, si tenemos cuatro meses de proyecto, y nuestras iteraciones son de un mes de
duracin, tendremos tres momentos (al final de la iteracin 1, 2 y 3) para tomar feedback, medir
progreso y re-ajustar prioridades.
Otra consideracin clave es el tiempo que tarda una idea (un requisito funcional, una historia de
usuario) en transformarse en software. Por ejemplo, consideremos de nuevo iteraciones de cuatro
semanas. Suponiendo que una nueva idea aparece en el medio de una iteracin, esa idea solo puede
introducirse en la prxima versin, que comenzar en dos semanas. Dos semanas que quedan de la
iteracin en que aparece el nuevo requisito, ms cuatro de la siguiente, hacen que la nueva idea est
implementada en 6 semanas, y si 6 semanas es mucho para nuestro negocio... habr que considerar
iteraciones menores.
Una ltima consideracin. No olvides que a menor tiempo de iteracin mayor nivel y sofisticacin
debe tener el equipo de desarrollo, por lo que la madurez, compenetracin, experiencia, cualidades
tcnicas, etc., juegan un papel importante.
A iteraciones ms cortas, hars ms entregas, con mayor frecuencia, y menor ser la desviacin
respecto a lo que el usuario espera.

Deberan las iteraciones durar el mismo tiempo?

En nuestra experiencia, hemos visto equipos trabajar muy bien con iteraciones, o sprint, de duracin
variable, es decir, que justo antes de comenzar el mismo, en su planificacin, se decida la duracin que
tendra la iteracin.
Es recomendable que todas las iteraciones duren lo mismo, esto sincroniza a la organizacin,
permite hacer clculos de velocidad ms exactos y detectar problemas en el proyecto
Pero conviene decir que han sido ms los equipos que trabajan bien con iteraciones de la misma duracin.
Es ms, en equipos poco experimentados, variar la temporalidad de la iteracin suele conducir a
problemas.

Lecturas y enlaces recomendados

Libro: Cmo sobrevivir... A la planificacin de un proyecto gil, Javier Garzs

Agile estimating and planning
Medicin y estimacin del software: Tcnicas y mtodos para mejorar la calidad y la productividad
Los peores bugs de la historia
Cuntos proyectos fallan?
Aplicacin web de Planning Poker
Agile Estimating & Planning

Test Leccin 5
Entre los errores clsicos del desarrollo software que provocan un mayor impacto y que estn
relacionados con aspectos de estimacin se encuentran:
Omisin de estimar tareas necesarias y falta de implicacin.
Expectativas no realistas y calendario demasiado optimista.
Verdadero o Falso: Las tcnicas de estimacin sustituyen al juicio experto.
Falso, lo complementa.
Verdadero.
A quin pertenece la funcin de asignar valor a las historias de usuario?
Equipo de desarrollo.
Product Owner.
Jefe de proyecto.
A priori, qu historias de usuario sern las que primero se tengan en cuenta para llevarlas al
Sprint Backlog?
Las que aporten menos valor para el cliente y adems se necesite mucho tiempo para llevarlas a
cabo
Las historias de usuario que menos tiempo necesitemos para llevarlas a cabo, porque as
podremos implementar ms tareas en una misma iteracin.
Las que aporten mayor valor para el cliente.
Seleccione la opcin INCORRECTA:
Antes de publicar la estimacin se puede compartir con otros compaeros con el fin de no
desviarse.
El planning poker es una manera fcil de estimar las historias de usuario de una forma
democrtica, gil y rpida.
Los puntos de poker son unidades ficticias definidas previamente. Pueden ser das de duracin,
das ideales o puntos de historia.
Qu puede generar la falta de compromiso con la estimacin?
Estimacin por debajo.
Estimacin por arriba
Buena estimacin
Cunto tiempo debera durar una iteracin?
1 semana
1 mes
Lo que se suele encontrar es que las iteraciones de los proyectos duran entre una semana y un
mes, pero esto depende del tipo de proyecto y del equipo

Leccin 6: Lean y Kanban

El trmino Lean o Lean Manufacturing (cuya traduccin sera fabricacin esbelta) es otro trmino
que, al igual que el Kanban (como ya veremos ms adelante), tiene su origen en Toyota. De hecho,
Lean es sinnimo de Toyota Production System, una estrategia de fabricacin aplicada con mucho xito
en Japn y ahora muy famosa en el mundo del software, muchas veces bajo el trmino de Lean Software
Development.
En los 50 la industria japonesa estaba recuperndose de la segunda guerra mundial y logr con gran xito
aplicar a sus fbricas de coches los conceptos de calidad en la produccin creados por los principales
gurs estadounidenses, de entre los que destaca Deming. La paradoja fue que siendo mtodos idealmente
originados por estadounidenses fueron aplicados por los japoneses, convirtiendo a Japn lder en la
industria automovilstica, pasando por encima de los EEUU.
El artfice del Lean, quien introdujo esta nueva manera de fabricar en Toyota, fue Taiichi Ohno (1912
1990), cuya estrategia se fundament en tres bases:
- Construir slo lo necesario.
- Eliminar todo aquello que no aade valor.
- Parar si algo no va bien (lo que est relacionado con el principio de cero defectos).
Adems conviene destacar que el Lean incluye siete importantes principios , que son los siguientes:

Eliminar desperdicios (eliminating waste)

Amplificar el aprendizaje (amplifying learning)
Decidir lo ms tarde posible (decide as late as possible)
Entregar lo ms rpido posible (delivering as fast as possible)
Capacitar y potenciar al equipo (empowering the team)
Construir con calidad (build quality in)
Ver el todo (seeing the hole)

Lean Startup

Relacionado con esto, Eric Ries en su libro The Lean Startup, propone utilizar Lean, en vez de para
desarrollar software (tema que se explicar en las siguientes secciones), para crear empresas y negocios.
La metodologa que propone Eric Ries se basa en enfocar la creacin de la empresa en la mxima y ms
frecuente interaccin con los posibles clientes. Es decir, que en vez de hacer un gran plan de negocio y
terminar un producto mucho tiempo despus (algo as como un ciclo de vida en cascada), con el riesgo de
haber invertido mucho en algo que no vale para nada, cntrate en sacar rpidamente pequeos prototipos
del negocio, aunque no estn totalmente terminados, y valdalos con usuarios reales (iterativo,
incremental gil.
El libro se centra en que el conocimiento vlido es aquel que obtenemos probando cosas en la realidad,es
el que realmente nos ayuda a tomar decisiones. Esfuerzo que no nos sirva para aprender e ir ajustndose a
las necesidades de los futuros clientes es un gasto intil.
La propuesta del Lean Startup es aplicar un ciclo de construir medir aprender, iterar constantemente
para ir ajustando y aprendiendo. Cada iteracin o bucle debe terminar con un MVP (Minimum Viable
Product), un producto mnimo, y que recuerda tanto al prototipado de un ciclo de vida iterativo gil. Todo
orientado a aprender rpidamente el qu quiere el cliente con el mnimo desperdicio (o esfuerzo en cosas
que no van a servir).
Para saber ms sobre el Lean Startup te dejo este vdeo:
https://www.youtube.com/watch?v=fEvKo90qBns

Lean software development

En el mundo del software, fue el libro Microsoft Secrets el que primero habl de la similitud de la
estrategia de daily builds que usaba Microsoft (similar a la integracin continua pero planificada, en
la que diariamente se compila el software y se pasan algunas pruebas unitarias automatizadas, o el
smoke test), donde los ingenieros software tenan que parar y corregir errores diariamente y la filosofa
de produccin de Toyota JIT, donde los trabajadores paraban las lneas de montaje cuando detectaban
problemas, solucionndolos inmediatamente.
El libro Microsoft Secrets no utiliz el trmino lean, ni lean software development, aunque hablaba
de la aplicacin de JIT, del control de calidad, y la reduccin de la burocracia en Microsoft.
Hay claramente muchos elementos comunes entre estilo el de produccin de Toyota, el estilo
iterativo de Microsoft y el desarrollo gil (teniendo en cuenta que en Microsoft no siempre se desarroll
as, a finales de 1990 y principios de 2000 trabajaban con equipos de desarrollo exageradamente grandes).

La popularizacin del trmino lean aplicado al software, el lean software development, y su

asociacin a lo gil aparece principalmente con el libro Lean Software Development de Mary y
Tom Poppendieck.Estos tambin hacen hincapi en la eliminacin de desperdicios, eliminar la
burocracia en el desarrollo de productos, fomentarse el aprendizaje por ciclos cortos y frecuentes,
iteraciones rpidas, etc.,obteniendo una rpida retroalimentacin que tire (pull) del producto, en
lugar de documentos de requisitos y planes rgidos que empujen (push) el trabajo de desarrollo.
Y la diferencia entre mtodos antiguos y ms basados en mano de obra, burocrticos, pushstyle,
inicialmente asociados con el negocio de las computadoras mainframe.
El lean, y el lean software development, no es una metodologa de ingeniera de software en el sentido
convencional.Es ms una sntesis de principios y una la filosofa para construir sistemas de software.Si
lean se considera un conjunto de principios ms que prcticas, la aplicacin de conceptos lean al
desarrollo software y la ingeniera software tiene ms sentido y puede ayudar a mejorar la calidad.

Agilidad y lean no son exactamente lo mismo

El desarrollo gil es un paraguas que incluye varias metodologas (Scrum, XP, FDD, etc.). Todas ellas
tienen en comn que siguen en mayor o menor medida los valores y principios del manifiesto gil. Y hay
incluso quien afirma que las ideas de Lean y las ideas agiles son tan similares que se dice que aplicar la
filosofa gil es aplicar la filosofa Lean. Y un proceso Lean, es un proceso gil.
La conexin de lo gil con el Lean viene de que muchos creadores de mtodos giles estuvieron
influenciados por los mtodos Lean, como por ejemplo Mary y Tom Poppendieck.
Mary, esposa de Tom, trabaj en una fbrica que usaba el mtodo Lean, y Tom era un desarrollador
software. De ah que Mary y Tom Poppendieck sean los pioneros en la aplicacin del Lean al software. Y

que escribieran el libro que ha inspirado las ideas del Lean aplicado al desarrollo software (Lean Software
Development).
Una paradoja ms: aunque la filosofa gil rechaza que el proceso de desarrollo software sea un proceso
de fabricacin industrial tradicional (como el que sucede al construir un coche o una casa)los agilitistas
han tenido una gran influencia y adopcin de los mtodos de fabricacin de Toyota.
Hoy agilidad y lean han llegado casi a ser sinnimos. Los principios giles son compatibles con los
principios lean. Sin embargo, los principios lean son de mayor alcance, aplican a la hora de seleccionar
prcticas de desarrollo apropiadas a otras situaciones, ms all del desarrollo software, y ms all de los
entornos en los que la agilidad funciona bien.
A continuacin te enumero las principales diferencias entre agilidad y lean:
1 El lean software development se ve al desarrollo software como un paso dentro de un flujo
global, un paso dentro de un todo. Lean no slo trata el desarrollo, trata hasta la puesta, y xito,
en el mercado del producto.

2 En lean no hay product owner o roles de cliente, tpicos del desarrollo gil.
3 En lean existen figuras cercanas a jefes de proyecto o product managers. En el lean
software development los equipos estn dirigidos por alguien que ocupa el rol de ingeniero jefe
(como se llamaba en Toyota), el gerente de programas o program manager (Microsoft), o
product champion (3M).
4 Otra diferencia entre agilidad y lean es que en lean no hay un rol que priorice el trabajo del
equipo de desarrollo, como suele suceder en las metodologas giles. Los mtodos giles suelen
proponer al cliente o representante del cliente (product owner) que priorice el trabajo del equipo
software.
5 Muchas veces respecto a las metodologas giles existen interrogantes sobre cmo hacer
frente al diseo. Las iteraciones hacen complejo este punto. Dado que el desarrollo lean
establece una serie de principios que exigen tratar al producto como un todo, un ciclo de
vida completo, enfoque multifuncional, ponen ms nfasis en cmo organizar una combinacin
de diseo, desarrollo, implementacin y la validacin.

Desperdicios de Lean I
El Lean, y el Lean Software Development (como ya vimos), se centra en la eliminacin continua de
desperdicios, los desperdicios del lean software son todo aquello que no aporta valor y que ocurre tanto
en todo proyecto.
Aunque el Lean se ha aplicado histricamente a la industria, ha sido en los ltimos aos cuando se ha
adaptado al software, donde las cosas no son exactamente iguales (recuerda aquello de que fabricar
software no es lo mismo que fabricar coches o casas). Y en esta seccin vamos a ver los desperdicios del
lean software, desperdicios reales de da a da de un proyecto software.
Ya veris que los desperdicios del lean software pueden aplicar a tu da a da, a cualquier cosa que
hagas en tu vida, desde estudiar para un examen, a mantener un blog, a mejorar tu vida social.
Hay 7 tpicos desperdicios del lean software (segn los clasificaron Mary and Tom Poppendieck en el
mejor libro que hay sobre el tema):

Desperdicios del lean software 1: Trabajo realizado parcialmente

Aquella documentacin que tardamos meses en elaborar pero que qued sin codificar (esto me recuerda a
mis tiempos haciendo diseos UML al detalle y que luego al chocar con la realidad no los seguamos).
Los requisitos, y las historias de usuario obsoletas.
Ese cdigo en el PC de un desarrollador durante mucho tiempo, tanto que integrarlo ya es complicadsimo
es un desperdicio. O esas ramas de cdigo en la herramienta de control de versiones que viven durante
meses antes de mergearse con la lnea principal, desperdicio.
O el cdigo no probado: sin pruebas, no hay manera de saber que el cdigo funciona (ni con pruebas
tenemos seguridad, pues imagnate sin ellas).

Desperdicios del lean software 2: Caractersticas extra

Aquello que creemos que el cliente va a necesitar pero que cliente no ha pedido. Cuando un comercial,
cliente, etc., insiste en incluir cosas en el producto,que al final no se usan tenemos un enorme
desperdicio. La funcionalidad que ha quedado obsoleta es un desperdicio.
Y no olvidis que las caractersticas introducidas slo para probar la ltima moda y esa tecnologa
moderna acaban siendo un desperdicio.

Desperdicios del lean software 3: Reaprendizaje

Cuntas veces has resuelto un problema y no has implantado inmediatamente la solucin? Cuntas
veces has tenido que redescubrir semanas despus la misma solucin? Desperdicio de tiempo, otro de los
desperdicios del lean software.

Por otro lado, muchas veces no preguntamos, ni hacemos caso a expertos, y trabajamos en solitario. Cada
minuto que pasamos redescubriendo cosas que rpidamente nos podran haber contado es tiempo
perdido.
Y tambin est el cdigo mal escrito o indocumentado que conduce a una incalculable cantidad de
reaprendizaje, desperdiciando tiempo.
Por ltimo, otro clsico y repetido desperdicio: desarrolladores que estn constantemente siendo
reasignados a funciones diferentes, dejando sin terminar su trabajo actual.

Desperdicios de Lean II
Desperdicios del lean software 4: De mano en mano
Documentos de anlisis de requisitos, que luego pasan a las manos de un diseador. El diseador
elabora un diseo y entonces pasa a manos de los programadores. O lo que viene a ser el ciclo de vida
en cascada. Por desgracia, poco conocimiento puede transmitirse SOLO con documentos y
diagramas, por lo que mucho papel acaba siendo un desperdicio.
Desperdicios del lean software 5: Las pausas
Empezar a trabajar en el desarrollo de un proyecto mucho tiempo despus del contacto inicial con el
cliente. Esperar a que el equipo est disponible para empezar a trabajar. Esas largas fases de
documentacin de requisitos (esto tambin me recuerda a mis tiempos haciendo diseos UML al
detalle) que tratan de especificar de forma exhaustiva todos los aspectos de un proyecto.
Y no slo eso, la revisin o aprobacin de procesos que actan como puertas entre fases y que requieren
de un individuo apenas disponible.
Desperdicios del lean software 6: Cambio de Tarea
El coste de cambiar de tarea durante el desarrollo de software ha sido un problema de siempre.Tom
DeMarco y Timothy Lister ya lo trataban en su libro Peopleware (muy recomendable, por cierto).
Desgraciadamente, concentrarse es extremadamente difcil. De esto hay mucho escrito, pero se dice que
necesitamos por lo menos quince minutos para concentrarnos en algo. Y durante esos quince minutos,
estar concentrndose. Una vez concentrado, cualquier interrupcin nos obliga a empezar de nuevo, lo
que cuesta otros quince minutos de tiempo improductivo. Cuatro interrupciones cuestan una hora de
productividad. Treinta y dos interrupciones un da.
Desperdicios del lean software 7: Defectos
Por ltimo, quizs uno de los ms obvios: los defectos. Todo aquello que no se hace bien, es un
desperdicio, no aporta valor, y consume tiempo a la hora de repararlo.

Kanban
Kanban es una palabra japonesa que significa tarjetas visuales (kan significa visual, y ban tarjeta).
Esta tcnica se cre en Toyota, y se utiliza para controlar el avance del trabajo, en el contexto de
una lnea de produccin. Actualmente est siendo aplicado en la gestin de proyectos software.
https://www.youtube.com/watch?v=uGKHBHzG0jM

Las tres reglas de este mtodo son las siguientes:

A su vez hay una regla 0 o inicial: el trabajo que se gestione estar dividido en bloques o tareas
pequeas. Como ejemplos de bloques o tems a gestionar tenemos: los requisitos, las historias de
usuario, una funcionalidad a ser desarrollada, etc.
Nota: una de las publicaciones ms interesantes al respecto es el libro: Kanban and Scrum - making the
most of both de Henrik Kniberg, Mattias Skarin.

Ejemplo I: Flujo de Kanban

En el siguiente ejemplo vemos una representacin simplificada de Kanban y cmo se limita el trabajo
en cada fase a partir del WIP.
El jefe de proyecto de nuestro equipo de desarrollo ha implementado un flujo de trabajo representado
con 3 fases. stos son Por hacer, En Progreso y Terminado. Adems, el nmero 1 de la fase
En Progreso nos indica que nuestro equipo no podr trabajar en ms de un tem (en este caso
historias de usuario) a la vez.
Principalmente se realiza un ciclo de 4 pasos:
1.Comenzamos el proceso. Podemos trabajar con una historia de usuario, ya que el estado del flujo En
Progreso est libre.
2.Trabajamos con la primera historia de usuario. Al estar limitado el WIP a 1, no podemos
introducir ms historias de usuario, hasta que hayamos finalizado con la tarea actual.
3.Una vez terminada la primera historia de usuario, podemos incluir ms historias de usuario de la
fase "Por hacer".
4.Volvemos a comenzar el proceso.
Grficamente representado a continuacin:

Todo ello ayudar en la gestin del desarrollo ya que, entre otras cosas, mostrar los cuellos de
botella, colas, variabilidad y prdidas de eficiencia. Esto lo veremos ms adelante.

Ejemplo II: Kanban y un Sprint Backlog

Vamos a ver otro ejemplo de la aplicacin de Kanban.
1- En el Sprint backlog hay 4 tareas, de las cuales pasamos a introducir dos tareas a progreso:

2- Dos das despus habremos terminado la tarea 3.1:

3- Al quedar un hueco libre, se puede introducir la tarea 3.2:

4- Un da despus termina la tarea 1, y podemos introducir directamente la tarea 4 (simplificamos en un

paso)

5- El da 5 nuestro equipo termina 3.2:

6- Y finalizado el da 6 termina la iteracin:

Ejemplo III: Kanban con elementos de Scrum

Para afianzar los conceptos y ver claramente las diferencias con Scrum vamos a continuar el ejercicio de
la leccin anterior. A continuacin se facilita el enunciado:
Supongamos que tenemos un equipo de desarrollo software el cual usa Kanban. Nuestro rol es de jefe
de proyecto y un cliente nos ha pedido que desarrollemos una potente calculadora para mviles.
El cliente nos ha trasladado las historias de usuario (user stories). Nuestro equipo ya las ha agrupado por
valor (dado por el cliente) y tambin ha estimado el tiempo que tardaremos, en das, en completarlas. El
cliente desea la implementacin de:

El primer paso que debemos hacer es dividir las historias de usuario en tareas de un tiempo
homogneo:

Para formar el Sprint Backlog y simplificar el problema, supondremos que las historias de usuario son
indivisibles. Adems las tareas a implementar en cada historia de usuario tienen que guardar el orden
establecido.
sto es: si se quiere implementar el requisito 3, ha de realizarse 3.1 y 3.2 en la misma iteracin, y en
ese orden.

Este es el muro Kanban que tenemos inicialmente

Segn el muro del ejemplo vemos que:

En el Sprint Backlog lo tenemos que cumplimentar con 4 tareas para este Sprint. Aqu se ve
claramente que Kanban limita el WIP por estado en flujo de trabajo (columna del tablero);
en cambio Scrum limita el flujo de trabajo por iteracin, al indicar en el Sprint Backlog
cuntas tareas se pueden realizar en esa iteracin (recordemos que una vez comenzada una
iteracin en Scrum, no debera modificarse el Sprint Backlog).

En la fase de En progreso podrn estar dos tareas desarrollndose paralelamente, indicado

por el nmero 2.

Ahora bien, tenemos que seleccionar las tareas que, para estas historias de usuario, maximizan el valor
dado por el cliente (suponiendo que las historias de usuario son indivisibles).

Para el primer Sprint, las historias de usuario que maximizan el valor percibido por el cliente son 1, 3 y
4. Por lo que nuestro muro inicial quedara as:

De esta manera podemos ver que es fcil estimar en Kanban. Son tareas ms o menos homogneas en
tiempo. Por lo que, realizando unos pequeos clculos podemos determinar nuestro tiempo estimado.
En este caso, como el WIP de estado del flujo "En progreso" es 2, el tiempo mximo vendr
determinado por el promedio de tiempo de todas las tareas dividido 2 (ver frmula).
Por tanto:
3 das (de la tarea 1) + 2 das (de la tarea 3.1) + 3 das (de la tarea 3.2) + 3 das (de la tarea 4)
2 (WIP "En progreso")
El resultado de esta operacin es aproximadamente 6 das. Por lo tanto, para terminar las historias de
usuario, el equipo tardar aproximadamente 6 das.

Midiendo el flujo de trabajo en Kanban

Las dos mtricas ms importantes para medir el flujo de trabajo en Kanban son el lead time y el cycle
time.
Qu es el lead time? Para verlo de forma grfica, el lead time es el tiempo que ha pasado desde que el
tem (historia de usuario, tarea, etc.) ha entrado en la pizarra Kanban hasta que ha pasado a la ltima
fase (terminado, en produccin, etc.). Este es el tiempo ms importante desde el punto de vista del
cliente quien es el que recibe el producto final que satisface sus especificaciones:

Asimismo, existen otros tiempos incluidos dentro del lead time. El cycle time, que es el tiempo que pasa
desde que se empieza a trabajar con el tem hasta que pasa a un estado finalizado. Es decir es el tiempo
que se ha estado trabajando sobre la historia de usuario, tarea, etc. Como se ve en la figura, se intentar
hacer ambos tiempos similares mediante la evolucin de los lmites y de la misma pizarra Kanban.

Limitar el WIP- asignando lmites concretos. Determinando cuntos elementos pueden estar
en progreso en cada estado del flujo de trabajo. A esto se aade otra idea tan razonable como
que para empezar con una nueva tarea alguna otra tarea previa debe haber finalizado.

Los cuellos de botella y el WIP

Recordemos que en Kanban, el WIP ("Work In Progress") es el nmero mximo de tareas que
pueden realizarse en cada fase del ciclo de trabajo.
Si una columna de un tablero Kanban (es decir, una fase del ciclo de produccin) tiene, por ejemplo,
un WIP 5, esto quiere decir que si el equipo (ojo, equipo, no las personas, porque el WIP de un
Kanban afecta a una parte del proceso, en la que participan n personas) en esa fase est trabajando en
cinco tareas no podrn trabajar en ninguna otra hasta que terminen alguna de estas cinco.
Un recurrido ejemplo que ilustra el WIP de un KANBAN es el de la impresora. El WIP de una
impresora es 1, slo se imprime una pgina a la vez. As, si una pgina se atasca, y no se puede
imprimir, se da la alarma inmediatamente, y se para el proceso, en vez de comenzar a imprimir otra
hoja, lo que complicara ms el problema.
Aunque esto del WIP de un Kanban pueda parecer algo muy simple, su ajuste tiene un gran
impacto en la productividad de un equipo. Y saber ajustar el mejor WIP en cada fase del proceso
productivo no es una tarea fcil.
Por ejemplo, supongamos que utilizamos la pizarra descrita en el siguiente prrafo y existe un problema
en las pruebas. En ese caso en algn momento se llega al mximo dado por el WIP en la etapa de
desarrollo y el equipo no puede seguir trabajando.

En ese caso tenemos un cuello de botella en la etapa de pruebas por lo que los equipos de desarrollo
pueden ayudar. De hecho podan haberlo hecho antes, en el caso de que algn integrante del equipo
quedar ocioso. Por lo tanto, si el equipo o el desarrollador no tiene posibilidad de continuar
trabajando debe buscar el cuello de botella en las siguientes etapas.
Durante la utilizacin de Kanban los lmites del trabajo en progreso (WIP) irn evolucionando.
Para ello es indispensable tener en cuenta los sntomas de lmites errneos para converger a los
valores ptimos:

Qu suele suceder cuando el WIP de un Kanban es muy bajo?

Si el WIP es muy bajo (imaginemos un WIP 1 en una de las fases para un equipo de 4 personas),las
tareas se realizarn rpido (ya que podra tener hasta 4 personas trabajando sobre una tarea)pero
probablemente tendr miembros del equipo ociosos (ya que normalmente no todas las personas
podrn trabajar a la vez sobre la misma tarea).
Adems, las tareas estarn en estado de pendientes de empezar a ser realizadas demasiado
tiempo, en espera de que el equipo comience a trabajar sobre ellas. Y el lead time (una mtrica
Kanban que mide desde que se hace una peticin hasta que se realiza la entrega) ser mayor de lo
necesario.
Un WIP ajustado, a la baja, har que problemas que pudieran bloquear la finalizacin de una
tarea se resuelvan lo ms pronto posible, ya que hasta que no se resuelvan no se podr comenzar a
trabajar en otra cosa (filosofa Lean soluciona los problemas cuanto antes).
A menor WIP mayor colaboracin del equipo, ms tareas se harn por ms de una persona,
teniendo en cuenta que hay un lmite de personas que pueden trabajar a la vez sobre una misma
tarea. Por ello, otro propsito de limitar el WIP es evitar el exceso de multitareas y la sobrecarga
de una parte del proceso.

La esencia de los lmites WIP de un KANBAN es enfocar al equipo en finalizar cosas ms que
en comenzar cosas.

Qu suele suceder cuando el WIP de un Kanban es muy alto?

En contraposicin, si el WIP de un KANBAN es muy alto (imaginemos un WIP 8 para un equipo de 4
personas) existe el riesgo de empezar muchas tareas y terminar pocas, de estar trabajando en varias
cosas a la vez sin cerrar muchos temas.
Frente a cualquier contratiempo en una tarea, el equipo puede optar por comenzar con otra y demorar el
terminar aquellas que presenten contratiempos.
En este sentido se observa cmo ajustar el lmite WIP de un Kanban acta como una seal de
alerta, avisando de un problema antes de que se nos escape de las manos y siga avanzando (esto es
filosofa Lean soluciona los problemas cuanto antes), ya que el equipo se centrar en resolver
problemas que impiden cerrar tareas, ya que hasta que no lo hagan no podrn comenzar a
trabajar en otras.

Cmo saber el WIP de un KANBAN correcto?

Pues como te puedes imaginar no hay una regla exacta que lo calcule. Y adems de depender del
equipo, del producto que se desarrolle, etc., para un mismo equipo el WIP suele variar con el
tiempo, lo que implica un ajuste y mejora continua (tambin muy en la filosofa Lean Kaizen).
Pero s que hay algunas heursticas a observar, para detectar si tenemos algn problema con nuestro
WIP, por ejemplo:
- Si en una fase del ciclo de produccin se observa que hay tareas sobre las que nadie trabaja
durante mucho tiempo es porque el WIP de esa fase probablemente es alto. Esto tambin lo puedes
observar en que el lead time ser alto.
- Si en una fase hay gente parada durante mucho tiempo el WIP de un KANBAN probablemente
es bajo. La productividad ser baja. Y esto ocurre porque no todo el equipo puede trabajar a la vez
sobre una tarea.
Otra cuestin es con qu WIP comenzar la primera vez. Hay quien usa la regla de 2n-1, donde n es
el nmero de miembros del equipo, y el -1 se aplica para aumentar el grado de colaboracin.Pero no es
ms que una regla, que no tiene mayor base que algo de sentido comn. Al final, cada equipo debe
buscar su WIP.

Una pizarra ms compleja

Los ejemplos anteriores se han centrado en la operativa general. Hemos comentado que uno de los
primeros pasos al implementar Kanban en la organizacin, en un equipo de desarrollo, de
mantenimiento o de soporte es definir la pizarra.
Por lo tanto ser necesario definir las columnas de la pizarra de Kanban. Estas podrn ser de dos
tipos: columnas de estado y columnas de espera o de buffer.
Para definir las columnas es indispensable pensar en el proceso actual que queremos organizar mediante
Kanban. Por ejemplo, si quisiramos organizar el desarrollo de parches para un producto software, se
podran incluir las siguientes columnas:

El flujo de trabajo es el siguiente: llega una peticin de parche y el jefe de proyecto la selecciona
envindola a la columna de "peticiones seleccionadas". En el siguiente paso el equipo de desarrollo
elegir el siguiente parche a desarrollar. Una vez el parche se encuentre desarrollado quedar a la
espera de ser elegido para realizar la actividad de pruebas. Por lo tanto, entre la la etapa de
desarrollo y prueba puede existir un tiempo de espera.
Por eso es necesario dividir la columna de desarrollo y la columna de pruebas en dos partes, una para el
trabajo que se est realizando (columnas de estado) y otra para el trabajo ya realizado (columnas
de espera).

Lo ms importante aqu es que el lmite WIP es de la suma de ambas columnas. Es decir que si la
columna "desarrollo" tiene un lmite WIP de 4 no se podr empezar nuevas tareas de desarrollo aunque
tenga los 4 tems en la sub-columna "hechos". Esto es para evitar los cuellos de botella.
Recomendacin: empezar de menos a ms en cantidad de columnas. Como hemos visto se puede
complicar facilmente.

Enlaces y lecturas recomendadas

Scrum y Kanban making the most of both, Henrik Kniberg y Mattias Skarin
Qu es el mtodo Kanban para la gestin de proyectos?
Kanban vs. Scrum by Henrik Kniberg & Mattias Skarin

Definicin de Lead Time y Cycle Time

Tipos de Sistema Kanban
XKanban: Kanban + eXtreme Programming
On the Impact of Kanban on Software Project Work: An Empirical Case Study Investigation
Video: gestin Lean en 90 segundos

Test Leccin 6
Kanban permite tomar prcticas de otras tcnicas giles como SCRUM?
S, siempre y cuando se mantenga el WIP. Al ser adaptable y tener solo tres reglas siempre puede
tomar las medidas que le convengan con el fin de ser ms eficientes.
No, dejara de ser Kanban.
Si tengo un WIP de 3 en la fase "En progreso" y tengo 2 historias de usuario Puedo traer ms
historias de usuario de la fase "Pendiente"?
No, tengo que esperar a que todas las historias de usuario en las que actualmente estoy trabajando
pasen a la fase de "Terminado".
S, puedo trabajar con 3 historias de usuario ms. El WIP es de 3.
S, puedo trabajar con 1 historia de usuario ms.
Seleccione la opcin correcta:
Si al inicio del proyecto establecemos un WIP de 2, ese WIP no puede cambiar hasta que no
finalice el proyecto.
Lo ideal sera que el lead time y el cycle time llegaran a ser similares
El tamao de las historias de usuario es indiferente.
Suponiendo que estamos aplicando las tcnicas giles propias de Kanban, podremos aadir
historias de usuario (user stories) al Sprint Backlog?
Si
No
Agilidad y Lean son conceptos idnticos?
No, son trminos incompatibles
No, aunque los principios giles y Lean son compatibles.
S, porque muchos creadores de las metodologas giles estuvieron influenciados por principios
Lean.

Cmo se limita el trabajo en progreso en Kanban?:

Usando grficos BurnDown
Estableciendo un WIP para cada estado del tablero.
Con el Product Backlog, al empezar una iteracin este no se puede modificar.

En el ejemplo de pizarra ms compleja...Por qu las columnas de INSTALACIN y

PRODUCCIN no tienen sub-columnas?
Porque en INSTALACIN se incluyen los tems realizados de PRODUCCIN.
Solo las actividades de desarrollo tienen subcolumnas
Porque en PRODUCCIN se incluyen los tems realizados de INSTALACIN.
Qu indica un cuello de botella?
Que el WIP debera subir.
Lmite bajo del WIP.
Lmite alto del WIP.
Segn la filosofa Lean, hay que aadir funcionalidades que aunque el cliente no las haya pedido,
estn de moda.
Verdadero
Falso