Este libro lo puedes adquirir en:

http://www.javiergarzas.com/recursos-descargas/supervivencia-planificacion-agil
A todos aquellos que en algún momento conseguimos planificar

con éxito un proyecto software usando prácticas ágiles

y que sobrevivimos para contar cómo… e inspirar este libro

De la edición: 233gradosdeTI

MARCAS COMERCIALES: las marcas de los productos citados en el contenido de

este libro (sean o no marcas registradas) pertenecen a sus respectivos propietarios.
wwww.javiergarzas.com y 233gradosdeTI no están asociadas a ningún producto o
fabricante mencionado en la obra, los datos y los ejemplos utilizados son ficticios
salvo que se indique lo contrario.

Se ha puesto el máximo empeño en ofrecer al lector una información completa y

precisa.

Sin embargo, 233gradosdeTI no asume ninguna responsabilidad derivada de su uso, ni

tampoco por cualquier violación de patentes ni otros derechos de terceras partes que
pudieran ocurrir. Esta publicación tiene como objeto proporcionar unos conocimientos
precisos y acreditados sobre el tema tratado. Su venta no supone para el editor ninguna
forma de asistencia legal, administrativa ni de ningún otro tipo. En caso de precisarse
asesoría legal u otra forma de ayuda experta, deben buscarse los servicios de un
profesional competente.

Reservados todos los derechos de publicación en cualquier idioma. Según lo dispuesto

en el Código Penal vigente ninguna parte de este libro puede ser reproducida, grabada
en sistema de almacenamiento o transmitida en forma alguna ni por cualquier
procedimiento, ya sea electrónico, mecánico, reprográfico, magnético o cualquier otro,
sin autorización previa y por escrito de 233gradosdeTI: su contenido está protegido por
la Ley vigente que establece penas de prisión y/o multas a quienes intencionadamente
reprodujeren o plagiaren, en todo o en parte, una obra literaria, artística o científica.

Fotolia (www.fotolia.com) o a quién esta se los haya otorgado,tiene los derechos de

autor de la foto publicada como portada de la obra.

ISBN: 978-84-616-5733-9

Versión: 1.0
 Sobre el autor

JAVIER GARZÁS PARRA

javier.garzas@urjc.es
twitter: @jgarzas
web: www.javiergarzas.com

Cursó estudios postdoctorales y fue investigador invitado en la Universidad Carnegie

Mellon (Pittsburgh, EE.UU). Doctor (Ph.D.) (cum laude por unanimidad) e Ingeniero en
Informática (premio extraordinario).

Actualmente trabaja como consultor y CIO en la empresa KybeleConsulting S.L.

(empresa spin off del grupo de investigación de la Universidad Rey Juan Carlos)y es
profesor en la Universidad Rey Juan Carlos.

Edita el blog www.javiergarzas.com.

Cuenta con certificaciones de Auditor Jefe de TICs (Calificado por AENOR) para ISO
15504 SPICE – ISO 12207, Auditor ISO 20000 por ITSMF, especialización en
Enterprise Application Integration (premiado por Pricewaterhousecopers), CISA
(Certified Information Systems Auditor), CGEIT (Certified in the Governance of
Enterprise IT) y CRISC (Certified in Risk and Information Systems Control) por la
ISACA, CSQE (Software Quality Engineer Certification) por la ASQ (American
Society for Quality), Introduction CMMI-Dev y Acquisition Supplement for CMMI v1.2
(CMMI-ACQ) e ITIL V3 Foundation.

Ha trabajado para más de 70 organizaciones como INFORMÁTICA DE LA

COMUNIDAD DE MADRID (ICM), RENFE, DIRECCIÓN GENERAL DE TRÁFICO
(DGT), MINISTERIO DE ADMINISTRACIONES PÚBLICAS (MAP), SISTEMAS
TÉCNICOS DE LOTERÍAS (STL), AENOR, etc.

Comenzó su carrera profesional como consultor senior y responsable del centro de

competencias en ingeniería del software de ALTRAN, desde donde participa en
proyectos para TELEFÓNICA MÓVILES CORPORACIÓN, INDRA tráfico aéreo o en
la automatización de la simulación de la rotativa de EL MUNDO. Más tarde fue
responsable de calidad software y de proyectos de mCENTRIC. Posteriormente,
DIRECTOR EJECUTIVO Y DE INFORMÁTICA de la empresa de desarrollo de ERPs
para la gestión universitaria con mayor número de clientes en España.

Experto en gestión y dirección de departamentos y fábricas software (realizando

implantaciones de fábricas y mejoras en España, Colombia, Chile y Venezuela), con
una amplia experiencia en ingeniería del software, calidad y mejora de procesos
(participación en la mejora, evaluación o auditoría de procesos CMMI o ISO 15504 en
más de 40 empresas).

Ha participado en numerosos proyectos de I+D nacionales e internacionales,

ponencias, editado varios libros (destacando el primer libro en castellano sobre
fábricas software) y publicado más de 100 trabajos de investigación. Evaluador de la
ANEP (Agencia Nacional de Evaluación y Prospectiva) y experto certificado por
AENOR y EQA para la valoración de proyectos I+D.
 Prefacio
"No serán las especies más fuertes las que sobrevivirán, ni las más inteligentes, sino
aquellas que mejor se adaptan al cambio."

-- Charles Darwin

Sobrevivir, anteponerse a duras adversidades usando lo imprescindible, manteniendo

las condiciones físicas y psíquicas.

En ocasiones, la complejidad de planificar y gestionar un proyecto software se asemeja

a una situación de supervivencia, nos hace enfrentarnos a una situación tremendamente
adversa.

Frente a una situación de supervivencia, conocer lo imprescindible, técnicas probadas,

concretas y prácticas que nos ayuden… esa será la clave de nuestro éxito.

Y eso es lo que encontrarás en este libro, una ayuda para sobrevivir, para seguir
adelante, para hacerte con la planificación de un proyecto utilizando lo imprescindible
y utilizando la agilidad.

Aunque hay multitud de libros sobre planificación de proyectos, en este libro

encontrarás sintetizadas las técnicas ágiles más prácticas y necesarias para prepararte
rápidamente y sobrevivir. Por ello este libro nació con el propósito de no superar las
100 páginas en su versión ebook (150 en papel).

El objetivo de este libro es ayudarte a estar preparado lo más rápido posible. Los
negocios se mueven hoy a tal velocidad que la necesidad de planificar un proyecto
software en ocasiones llega casi sin avisar, dejándonos el tiempo justo para
prepararnos, y para ello necesitarás tener localizadas técnicas prácticas y probadas,
aquellas que son fruto de la experiencia, aquello que realmente puede salvarte.

Y por si fuera poco, junto a la velocidad cada vez mayor de los negocios de base
tecnológica, cuando ya muchas empresas empezaban a conocer la planificación
software de proyectos tradicionales, en los últimos años irrumpe, fuertemente en las
empresas, una manera diferente y más eficiente de gestionar proyectos: la agilidad.

Seguramente habrás oído palabras como Scrum, ciclos de vida iterativos, puntos
historia, historias de usuario, etc., ¿Pero cómo encaja todo para planificar mi proyecto?
¿Cómo ordenar todo? ¿Cómo todo ello me puede ayudar? ¿Qué es realmente práctico y
qué no? La respuesta, es uno de los objetivos de este libro.

Por último, antes de empezar, recuerda que lo más importante frente a una situación de
adversidad son dos cosas: tu actitud frente a los problemas y tu preparación previa.
Este libro será tu herramienta imprescindible para la segunda. El resto depende de ti.

CONTENIDO
La presente obra ofrece una visión amplia sobre diferentes factores que se deben tener
en consideración para la planificación, estimación y seguimiento de un proyecto usando
técnicas y métodos ágiles.

Y este libro persigue cubrir los siguientes puntos:

Cuál es el proceso de planificación ágil y el “roadmap”.

Qué papel juega la parte cliente, o el usuario, también llamado “product owner”,
en la gestión de un proyecto ágil.
Cuánto tiempo debe durar una iteración.
Cómo planificar las iteraciones.
Cómo estimar un proyecto ágil.
Las claves del seguimiento.

La selección de los temas incluidos en esta obra se ha basado sobre todo en la

experiencia práctica del autor, después de haber trabajado en multitud de proyectos
ágiles, y a la que se añade el rigor científico, proporcionando una panorámica actual y
completa sobre problemáticas y soluciones asociadas a la planificación ágil.

La obra consta de 9 capítulos y dos anexos:

El primer capítulo introduce el proceso de planificación en un proyecto ágil.

En el capítulo 2 analizamos qué es un roadmap y su papel en la planificación.
En el capítulo 3 veremos una figura clave y fundamental en un proyecto ágil: el
“product owner”; y analizaremos también qué son las historias de usuario.
En el capítulo 4aprenderemos a estimar un proyecto con distintos métodos
relacionados con la agilidad.
En el capítulo 5 veremos cómo planificar las releases.
En el capítulo 6 veremos el plan de cada iteración, con ejemplos de cómo dividir
historias de usuario en tareas.
En el capítulo 7 veremos qué medios usar para poder seguir el avance y la
 evolución de nuestro proyecto.
En el capítulo 8 veremos cómo poder subcontratar nuestro proyecto, que tipos de
contratos hay para ello y qué riesgos suponen cada uno.
En el capítulo 9 haremos un resumen de conceptos que no podemos olvidar ni
confundir.
Por último, en los Anexos I y II, puedes encontrar un resumen de Scrum y de FDD,
dos metodologías que se mencionan a lo largo del texto, y en los que puedes
apoyarte si tienes dudas.

ORIENTACIÓN A LOS LECTORES

Nuestro propósito al presentar este libro ha sido dirigirnos a una audiencia amplia que
comprende:

Desarrolladores, líderes de proyecto, jefes de proyecto, consultores, o auditores.

Participantes en seminarios o cursos monográficos sobre agilidad.
Directivos que tengan entre sus responsabilidades el desarrollo y mantenimiento
de sistemas así como la subcontratación de este tipo de proyectos.
Usuarios avanzados, que tengan interés en adquirir unos conocimientos sobre las
técnicas y metodologías más probadas para planificar proyectos.
Analistas o consultores que, aun teniendo conocimientos de la materia, quieran
abordarla de forma más sistemática.

SOBRE LA TERMINOLOGÍA
Desde siempre, la falta de una terminología unificada ha sido un problema en ingeniería
del software. El mundo de la gestión de proyectos y el de la agilidad no son ajenos a
este problema. Es por ello que esta breve sección pretende aclarar algunas posibles
dudas que pudieran generar la terminología usada en este libro.

Iteración y sprint. Los ciclos de vida ágiles se basan, principalmente, en

iteraciones de cortos periodos de tiempo (semanas). Sprint es el nombre que se le
da al concepto iteración en aquellos entornos que usan la metodología Scrum.
Otras metodologías ágiles usan de manera general el concepto iteración. En
muchos entornos se utiliza sprint como sinónimo de iteración, pero no lo son, ya
que el sprint es siempre ágil y la iteración puede o no serlo.
Metodología. Es bastante común usar el término metodología a la hora de referirse
a las metodologías ágiles. Y, por facilidad de lectura y familiaridad con el mundo
real y profesional, durante el texto también se usará principalmente la palabra
metodología. Pero siendo rigurosos las metodologías ágiles son más bien meta-
metodologías o catálogos de buenas prácticas que deben ajustarse dentro de unas
guías a la realidad de cada proyecto.

Requisito, especificación de requisitos e historia de usuario. Un requisito es algo

que el usuario necesita que se incorpore a un sistema software para resolver un
problema o lograr un objetivo. No hay que confundir “requisito” con la
especificación de requisitos, que es su descripción, para lo cual hay varias
maneras de hacerlo, desde numerosas plantillas, a casos de uso llegando hasta lo
más usado en el mundo ágil: las historias de usuario.
OTRAS OBRAS RELACIONADAS

Gestión ágil de proyectos software.

Garzás Parra, Javier / De Salamanca, Juan Enríquez / Irrazábal,

Emanuel

Si no está familiarizado con la agilidad, le recomendamos leer

primero este libro, ya que ofrece una visión general e introductoria de
qué es la agilidad.

Esta obra ofrece una visión amplia sobre diferentes factores que se deben tener en
consideración decidir la implantación de métodos ágiles. Y persigue los siguientes
objetivos:

Presentar de forma clara los conceptos fundamentales relacionados con la

agilidad.
Dar a conocer las principales metodologías y técnicas.

Esta obra podrás encontrarla en:

http://www.kybeleconsulting.com/libros/

AGRADECIMIENTOS
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 debería incidir el libro. Con sus inquietudes han ayudado a
clarificarnos qué debíamos dejar claro y qué debíamos enfatizar en esta obra.

Por otro lado, me resultaría imposible citar a todas las personas que con sus
sugerencias y comentarios han contribuido a que sea posible la realización de este libro
(destacando a los lectores del blog www.javiergarzas.com , y sus comentarios de
incalculable valor para motivar este libro).

Aún así, queríamos destacar la labor de revisión, las sugerencias y los comentarios
realizados por:

Ana María del Carmen García Oterino y David García, quienes han ayudado en la
siempre complicada tarea de la maquetación, corrección de textos y figuras.

A Mariano Minoli y Veronica Bollati, que desinteresadamente han contribuido a

que este libro sea lo que es con sus valiosas revisiones de los borradores previos.

Javier Garzás Parra

Móstoles, julio de 2013

Capítulo
1

1. Hoja de ruta del superviviente a una planificación software usando

técnicas ágiles

En el año 304 a.C., los habitantes de la isla griega de Rodas, para celebrar su
victoria sobre Demetrio, y después de haber logrado repeler el fuerte asedio al que
éste sometió a su ciudad, decidieron construir una colosal estatua del dios Helios,
estatua que eternamente recordase su victoria.

Para la construcción de tal obra, conocida hasta nuestros días como el coloso de
Rodas, eligieron a Cares de Lindos, al que los rodios pidieron una propuesta con el
coste de construir una estatua de 50 pies (15 metros) de altura.

Dado que el precio pedido por Cares para construir la estatua de 50 pies era
suficientemente asequible para la ciudad de Rodas, estos le pidieron una segunda
oferta, esta vez para un coloso del doble de altura.

Cares estimó entonces que una estatua del doble de altura costaría el doble de
precio. Y los rodios, rápidamente, aceptaron la propuesta de Cares.

No fue hasta el comienzo de la construcción cuando Cares cayó en el error de su

estimación: doblar la altura le conllevó ocho veces más materiales, y aquella mala
estimación, aquella mala planificación, en aquel “contrato cerrado llave en mano”,
le llevó a la bancarrota… y al suicidio.

Los problemas en la planificación han acompañado a la humanidad desde hace muchos

años. Antes, principalmente, en la construcción de grandes obras arquitectónicas y,
actualmente, en las grandes “obras” de hoy en día… las tecnológicas.

Y a esto se une la cantidad de estudios que ya han señalado como los problemas de
planificación y estimación son los problemas más frecuentes, y con mayor impacto, en
proyectos de desarrollo software (McConnell, 2007).
Como primera medida para enfrentarnos a una planificación ágil, debemos tener claro
las “herramientas” que hay disponibles para ayudarnos con ello, el orden a la hora de
hacer uso de ellas y que, dependiendo de la magnitud del software a crear, de su
tamaño, del tiempo de proyecto, etc., debemos hacer uso de diferentes niveles de
abstracción a la hora de planificar. Veamos todo ello a continuación.
EL ROADMAP Y LOS NIVELES DE ABSTRACCIÓN A LA HORA
DE PLANIFICAR
Si el proyecto es grande, lo más normal es que utilicemos hasta incluso tres niveles de
planificación, que típicamente en proyectos ágiles son los siguientes: planificación del
“roadmap”1, planificación de la creación de una “release”1 y la planificación de cada
iteración.

Los tres anteriores tienen, cada uno de ellos, diferente nivel de abstracción. El
roadmap, que veremos con detalle en el capítulo 2, tiene un objetivo más estratégico; el
plan de creación de una release o la planificación de las diferentes iteraciones
necesarias para ello, que trataremos en el en el capítulo 5, un objetivo táctico y,
finalmente, el plan de la iteración es más operativo, y lo veremos en el capítulo 6.

Lógicamente, no siempre haremos uso de un roadmap, y como se comentaba

previamente, la necesidad de usarlo vendrá dada por el tamaño del proyecto. En
proyectos pequeños bastará con hacer una planificación de la iteración, en proyectos
medianos, además de la anterior, añadiremos el plan de release y ya en proyectos
grandes aplicaremos un roadmap.

La Figura 1 muestra la relación entre estos tres niveles de planificación.

Figura 1. Los tres niveles de planificación en un proyecto ágil

Por otro lado, aunque en sí la mayoría de técnicas y buenas prácticas de planificación y

estimación aplicables a proyectos ágiles son en esencia similares a las de un proyecto
tradicional, incluso más antiguas a la aparición del concepto agilidad, su modo de
aplicación difiere, por la propia naturaleza de un proyecto ágil, y por el ciclo de vida
iterativo en que se basa. Pero, en cualquier caso, y como en un proyecto tradicional, la
mayoría de las decisiones de planificación, la estimación y el ajuste del ciclo de vida,
de las iteraciones, etc., vendrá dado, y condicionado, por los requisitos…

LOS REQUISITOS Y EL “PRODUCT OWNER”

Es por ello, que en un proyecto ágil el cómo se gestionan los requisitos, las llamadas
historias de usuario, y quién es responsable de su elaboración, validación y
priorización, el conocido como “product owner” o representante de los usuarios,
juegan un papel crítico en la planificación de un proyecto ágil. Y todo ello lo vamos a
ver detenidamente en el en el capítulo 3.

El papel que juega el product owner es tal que de esta figura depende gran parte la
planificación del proyecto, el plan de iteraciones, su duración, etc... Y, por supuesto…
mucha parte del éxito del proyecto depende de él.

Entre otros, el product owner es el responsable de los requisitos, normalmente escritos

en las llamadas “historias de usuario”, las cuales, una vez disponibles, son estimadas…

LA ESTIMACIÓN
En un proyecto ágil no es raro comenzar una iteración con requisitos poco
especificados y, sin embargo, necesitamos una estimación para cada requisito…y para
el proyecto.

Habiendo recogido las necesidades podremos estimar, si bien cómo hacer la

estimación va a diferir para cada uno de los niveles de abstracción que vimos
anteriormente, los de la Figura 1. En la Tabla 1 podemos ver el horizonte temporal que
nos ofrece cada planificación, cómo especificamos requisitos en cada una de ellas, el
nivel de abstracción y cómo se estima.

Horizonte Cómo especificamos Nivel de Método de

temporal requisitos abstracción estimación

Semestres o
Roadmap Temas Estratégico T-Shirt
incluso años

Epopeyas e historias de Puntos historia u

Release Meses Táctico
usuario horas
Iteración Semanas Tareas Operativo Horas o días
ideales

Tabla 1. Comparativa de los tres tipos de planificaciones ágiles

Quizás la parte más delicada es la estimación de las historias de usuario, ya que gran
parte del éxito del proyecto dependerá de ello, todo ello lo veremos en el capítulo 4,
destacando como para dicha estimación su suele hacer uso de los puntos historia.

Teniendo claros los requisitos, las historias de usuario, su priorización y su estimación

podremos hacer el plan de las iteraciones…

PLANIFICANDO LAS ITERACIONES

El corazón de un proyecto ágil es el ciclo de vida iterativo e incremental con
iteraciones cortas, de apenas unas semanas. Pero más allá de esto son múltiples las
decisiones que tendremos que tomar y responder a cuestiones como ¿qué temporalidad
exacta deberían tener las iteraciones? ¿Un par de semanas? ¿Un mes? ¿Deberían todas
tener la misma temporalidad? El capítulo 5 profundiza en todos estos interrogantes.

Y una vez resueltos lo anteriores, planificaremos una por una cada iteración, justo antes
de que cada una de ellas comience…

EL PLAN DE UNA ITERACIÓN

La iteración es ese periodo de tiempo, de apenas unas semanas, que se repite,
reiterativamente, en un proyecto ágil, y que cada vez que concluye lo debe hacer
dejando listo un producto software “entregable” o “potencialmente entregable” (si es
que en nuestro “roadmap” definimos que no se hará un paso a producción al final de
todas y cada una de las iteraciones).

Durante la iteración, el equipo de proyecto realizará tareas, comprueba tiempos, etc.,

en el capítulo 6 hablaremos de ello, que previamente debemos planificar y estimar. Y
en ocasiones hará desviaciones, por lo que tenemos que llevar un seguimiento…

EL SEGUIMIENTO
Todo proyecto, y los ágiles no iban a ser menos, requiere de un seguimiento, desde que
comienza hasta su fin. Un seguimiento correcto nos ayudará a detectar desviaciones y a
tomar las decisiones correctas. Y nos anticipará con tiempo si cumpliremos nuestro
objetivo de entregar un producto de cierta funcionalidad en la fecha establecida, el
capítulo 7 trata sobre ello.
Capítulo
2

2. El Roadmap de un proyecto ágil

“En la preparación para la batalla siempre he encontrado que los planes son
inútiles, pero la planificación es indispensable”.

--Dwight D.Eisenhower

“No dejes que los árboles te impidan ver el bosque”

-- Refrán español

Usaremos un roadmap (cuya traducción sería hoja de ruta) si gestionamos un producto

grande, un producto que va a evolucionar durante muchos años y si los prototipos
software que se irán desarrollando no pasarán muy frecuentemente a producción.

Una release es una versión más del software, con la particularidad de que es una
versión que va pasar a producción, es decir, va a ser usada por los usuarios reales del
producto software. Toda versión que desarrollamos no necesariamente es una release,
porque no toda versión, ni todo prototipo operativo, se libera o pasa a producción.

La Figura 2 muestra varias releases en el tiempo, y varias iteraciones. Nótese como las
releases no siempre tienen la misma temporalidad y como, normalmente, las iteraciones
si la tienen. Al final de cada iteración de desarrollo se obtiene un prototipo con
funcionalidad, y solo algunos de estos prototipos se convierten en release.

Figura 2. Releases e iteraciones en el tiempo

En el roadmap reflejaríamos el conjunto de releases (pasos a producción) que
prevemos que se van a realizar de nuestro producto. Estas previsiones pueden tener un
alcance de semestres o años (Pichler, 2012).

El roadmap ocupa un nivel estratégico y su objetivo es coordinar a las diferentes áreas

de la empresa: ventas, marketing, desarrollo, etc.
El roadmap es un plan de alto nivel que describe cómo el producto va a ir
evolucionando en el futuro.

Normalmente, como mínimo, un

roadmap ágil (o no ágil) contiene
versiones de producto, fechas previstas Utiliza un roadmap si
de lanzamiento y funcionalidad a alto
nivel. Por ejemplo: - Quieres tener una visión a largo alcance de
las versiones, estratégica, y de la
funcionalidad que se va a ir pasando a
v 2.5, prevista para el último
producción (se va a poner a disposición de
trimestre de 2012, implementará la los usuarios reales).
firma electrónica.
- Si tu negocio / tipo de software /
organización no posibilita pasos a
v 3.0, prevista para el segundo producción frecuentes.
trimestre de 2013, implementará la
integración con SAP.

Un roadmap tiene varios beneficios, pero principalmente permite comunicar, mostrar y

reflexionar sobre el futuro del producto.

2.1. Los temas

Para definir los objetivos de las release, usamos los denominados “temas”.

Por ejemplo, decir que en la release 3 afrontaremos “la afiliación de usuarios a nuestro
portal” es un tema.

Así que los temas se usan para recoger necesidades a nivel de roadmap.

En la Tabla 2 se pueden ver ejemplos de temas en un roadmap.

Los usuarios podrán hacer compras online

Los usuarios podrán descargar videos
 Los jugadores podrán jugar una partida básica

Tabla 2. Ejemplos de temas en un roadmap

Un tema no deja de ser una frase que marca el objetivo de la release.

¿Qué razones pueden llevarnos a decidir qué los pasos a producción no deban ser
al final de cada iteración?

Algunos ejemplos:

- Mi software depende o se integra con el software

de un tercero, y antes de pasar a producción es necesaria
una fase de integración.

- Razones estratégicas o comerciales, en ocasiones no

interesa que los competidores vean las nuevas funcionalidades.

- Entornos en los que sólo puedo hacer un paso a producción,

p.e., sistemas empotrados, embebidos, firmware, el software
del ABS de un choche, etc.

- Software crítico, sanitario, militar, etc., que requiere

de muchas y exhaustivas pruebas, para las
que incluso se puede destinar un tiempo mayor
al de una iteración de desarrollo
2.2.¿Cuánto tiempo debe transcurrir entre releases?

Dos factores suelen determinar el tiempo que transcurre entre una release y otra:

Razones de negocio.
Limitaciones organizativas y técnicas.

Aunque normalmente el roadmap planifica releases a meses, hay empresas que

optimizan su ciclo de trabajo para hacer pasos a producción incluso diarios. Hay casos
de estudio populares, como por ejemplo los de Flickr o Quora. Según comentan en
Quora, en un día normal, realizan 46 pasos a producción, necesitando de media tan solo
de seis a siete minutos para pasar un cambio a producción (Quora, 2013).

Otras organizaciones necesitan semanas para Si tu organización tarda semanas

hacer un paso a producción de un pequeño en pasar a producción un cambio
cambio el software, y cuando esto sucede puede en solo una línea de código…
deberse a que el proceso es demasiado puede que se esté haciendo
burocrático, o poco automatizado, o que negocio, demasiado lenta y burocrática,
sistemas y desarrollo están poco compenetrados. perdiendo oportunidad de negocio

El problema viene cuando la organización pierde por ello competitividad, ya que

alarga mucho el tiempo en validar versiones del producto con el usuario real, y con
ello en adaptar futuras versiones a las necesidades reales del usuario.

La disciplina que trata con el objetivo de hacer mínimo el tiempo desde que se decide
pasar a producción hasta que el software está listo es el “continuous delivery”.

2.3.“Continuous delivery” y “DevOps”

La entrega continua o “continuous delivery” es el proceso de poder liberar software

rápidamente (con la seguridad de que no va a producir problemas en producción), lo
cual se basa en tener gran parte del proceso automatizado, disponer de buenas pruebas,
y de que los departamentos de desarrollo, sistemas y negocio trabajen como uno.

Las ideas de continuous delivery aparecen con fuerza en 2010, cuando apareció el libro
Continuous Delivery, de Jez Humbley y David Farley(Humble & Farley, 2010), que
trata las técnicas para poder crear un flujo continuo de versiones software listas para
pasar al entorno de producción de manera segura, sin defectos ni sustos.
La entrega continua, el continuous delivery, es la evolución natural de la “integración
continua”, que se basa en integrar el software (compilarlo y probarlo) automáticamente
lo más frecuentemente posible, y así poder detectar fallos cuanto antes.

El proceso de integración continua se basa en obtener los fuentes desde el gestor de

versiones (Subversion, Git, Plastic u otros) compilarlo y lanzar las pruebas. Todo este
proceso suele automatizarse con herramientas de integración continua como Jenkinso
similares que, a su vez, se basan en que la secuencia de compilación, despliegue, etc.,
esté “escrita” y se lance con motores como Maven, Ant, Msbuild, Mkfile u otros
similares.

La entrega continua no implica necesariamente que tengas que hacer muchos pasos a
producción. “continuous delivery” no es “continuous deployment”. El continuous
delivery pretende que podamos pasar a producción cuando queramos, rápidamente, que
cuando decidamos pasar a producción sea en poco tiempo.

El momento y frecuencia en pasar a producción lo decide el negocio, pero cuando se

decide pasar… la puesta en producción debe ser lo más rápida posible.

La entrega continua consiste en olvidar que el software se construye como una

actividad separada de explotación, producción, operaciones, o similares, y que el
software esté siempre listo para el lanzamiento.

En relación a esto, en los últimos años aparece el término DevOps (development +

operations, es decir, desarrollo + operaciones) para reflejar la máxima colaboración e
integración entre desarrollo software y operaciones (producción, explotación, sistemas,
etc., según la terminología). El objetivo de DevOps, romper la típica separación entre
estas dos áreas.

Por ejemplo, un caso de estudio de DevOps es lo que en su momento logró Flickr: tal
integración entre desarrollo y operaciones que hacían… ¡diez pasos a producción por
día!

Aunque la idea es antigua, el término “DevOps” como tal se popularizó en 2009,

debido a los “DevOpsDays” de Bélgica, que luego se han repetido en varios países.

DevOps y la “entrega continua” son la extensión de la agilidad y el Lean al área de

Operaciones.

Con todo, y como citaba Mary Poppendieck (Poppendieck & Poppendieck, 2006):
“How long would it take your organization to deploy a change that involves just one
single line of code?” Pregúntate si ese tiempo es razonable y si te está haciendo ser
cada vez menos competitivo.
2.3.Estimación con T-SHIRT

Algunos equipos utilizan la unidad de estimación llamada T-shirt (la traducción al

castellano sería camiseta), cuyos valores van, asemejando tallas de camisetas, desde
“pequeña”, “mediana”, “grande” o “súper grande”, o S, M, L, XL y XXL.

Esta unidad suele usarse en estimaciones muy tempranas y para medir grandes
requerimientos, con poco nivel de detalle, por ello suele usarse para estimar el tamaño
de los “temas” que definen una release. Como podemos ver el ejemplo de la Tabla 3 , a
los diferentes temas del proyecto se les asigna un tamaño que se mide en T-Shirt.

Su principal objetivo es que rápidamente se realice una estimación, que puede dar una
idea a clientes, usuarios, del esfuerzo que requerirá cierta funcionalidad. Pero tiene el
problema de ser un método con alta probabilidad de error.

Temas T-SHIRT

Los usuarios podrán hacer compras online XXL

Los usuarios podrán descargar videos XL

Los jugadores podrán jugar una partida básica L

Tabla 3. Ejemplos T-SHIRT

Capítulo
3

3. "Product owner” y las historias de usuario

“El rol del product owner es una función nueva y disruptiva para la mayoría de las
organizaciones, y por ello no es fácil de cubrir con otros roles y estructuras
existentes.”

-- Roman Pichler

El “product owner”2(o propietario del producto) es aquella persona con una visión muy
clara del producto que se quiere desarrollar, que es capaz de transmitir esa visión al
equipo de desarrollo y, además, está altamente disponible para transmitirla.

El product owner también es el responsable de la comunicación entre equipo y

usuarios, y de gestionar qué trabajo se tiene que desarrollar, en qué orden y qué valor
se va entregando.

Normalmente, y según lo anterior, el product owner suele ser uno de los futuros
usuarios del sistema, o a veces, alguien de marketing o cualquier persona que entienda
lo que quieren los usuarios, el mercado del producto, la competencia, y el futuro del
sistema en desarrollo.

La figura del product owner es clave en un proyecto ágil, en su planificación y

seguimiento. Es una figura que cuando no realiza correctamente su función 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 erróneas alrededor de este

rol.

En unas ocasiones sus tareas se minimizan, en otras suelen pasarse por alto muchas de
sus importantes responsabilidades, etc.

El product owner es responsable de la mayor parte de

la planificación de un proyecto ágil.

No es un ente pasivo que se limita a decir qué hay

que hacer. Debe ser consciente de ello y estar
preparado… si queremos terminar con éxito un proyecto ágil.

Quizás el papel más importante del product owner en la gestión de un proyecto ágil es
gestionar qué historias de usuario se desarrollarán, en qué orden y cuáles no.

La mayoría 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 número (ver capítulos de velocidad (4.7) y de historias de usuario
(3.5)) a las que el equipo es capaz de desarrollar en una iteración. La función del
product owner aquí es vital, ya que conociendo la velocidad del equipo (que veremos
en el punto 4.7, ) debe ser quien decida que historias de usuario entran en el product
backlog, cuáles no, y además la prioridad de las historias del product backlog.

Habitualmente, en un proyecto ágil, para la gestión y priorización de lo que se espera

que haga el product owner se usa el “product backlog” (en terminología Scrum), que es
un repositorio priorizado de funcionalidades (normalmente en formato de historia de
usuario) a ser implementadas por el equipo de desarrollo, que veremos con más detalle
en el Capítulo 3.5.

3.1.Los tipos de Product Owner

No hay dos empresas software que utilicen igual el rol del product owner. Existen
múltiples maneras de implantar la figura del product owner. Esto varía enormemente en
función de si el equipo está desarrollando un software comercial, software para uso
interno, software empotrado, el equipo es interno o externo, o algún otro tipo de
producto.

La clave es que la persona que ejerce el rol del product owner tiene que tener una
visión clara de lo que se va a construir y las prioridades.

Pero, aun así, hay dos tendencias principales en lo que refiere a tipos de product
owners: aquellos en los que el usuario o el cliente toma el rol de product owner o
aquellos en los que una persona que representa al cliente es la que toma el rol de
product owner.
3.1.1.Cuando el cliente es el product owner

En esta situación, el cliente o el usuario final, toma el rol de product owner; dirige y
controla el desarrollo del software directamente. Esto acelera la toma de decisiones y
aumenta la posibilidad de crear un producto que responde a sus necesidades.

El problema, muchas veces, viene de que el cliente debe estar altamente disponible,
cualificado para esta tarea y con ganas de que se desarrolle un producto de éxito.
Cliente y equipo deben desarrollar una relación estrecha y de confianza.

Pero muchas veces, en esta situación, sobre todo cuando el proveedor es externo, no es
tan fácil, ya que suelen aparecer diferentes intereses. En proyectos tipo “llave en
mano” o cerrados, muchas veces el proveedor de desarrollo quiere terminar cuanto
antes y el cliente obtener la máxima funcionalidad.

3.1.2.Cuando un representante del cliente toma el rol

Esta es una de las estrategias más comunes, que sea un representante del cliente el que
tome el rol de product owner. Así trabajan normalmente las empresas que desarrollan
software a medida o “llave en mano”, y con proveedores externos (y métodos ágiles,
claro).

Uno de los problemas de los product owners es la dedicación que requiere este rol, ya
que en los proyectos ágiles la figura del product owner debe estar altamente disponible
para el equipo, y esto no es siempre posible. Para ello, si el cliente no tiene mucha
disponibilidad, muchas veces asigna una persona totalmente dedicada a representarle.

Otras veces también ocurre que el software es para varios clientes, y un único product
owner suele actuar como representante de los mismos, escuchando ideas y necesidades
de varios clientes y usuarios, y decidiendo cuándo estas debieran implementarse.

En esta situación, en la que un product owner representa al cliente, son gerentes,

comerciales, o analistas de negocio los que suelen tomar este rol. Lo que no quita que
muchas veces, junto con el product owner, los clientes y usuarios participen en
reuniones puntuales con el equipo de desarrollo, como, por ejemplo, aquellas para
revisar las entregas.
El reto en esta estrategia es lograr tener un product owner con conocimiento funcional y
la confianza y apoyo de clientes, usuarios o directivos, así como la capacidad de poder
tomar decisiones.

Por problemas como los anteriores, este tipo de implementación del product owner es
criticada en ciertos foros más puristas, pero el mundo real es el mundo real, y esta
segunda tipología se observa cada vez más.

3.1.3.El product owner y el product manager

Muchas empresas eligen a la figura del “product manager” como “product owner”.
Aunque existe cierto debate sobre si son lo mismo, si son compatibles, etc., en nuestra
experiencia, esto es frecuente, válido, y suele funcionar, siempre y cuando se tenga en
cuenta que el product manager suele hacer más cosas que el product owner, como
definir estrategias de mercado, marketing, estrategias de precios, análisis de
competitividad, etc.

Si se da el caso de equiparar el rol del product manager con el rol del product owner,
hay que tener en cuenta que en esta situación dicho product manager debe realizar sus
funciones de manager, además de las funciones de product owner, es decir, lleva a cabo
más actividades que un product owner convencional. Por ello, estas tareas
“adicionales” que realiza en este caso esta figura, frente a un product owner
convencional, no deben ser un obstáculo para sus responsabilidades como product
owner con el equipo de desarrollo ágil, donde debe definir funcionalidades del sistema
futuro, priorizar, validar, etc.

3.2.Responsabilidades de un product owner

A modo de conclusión, hemos sintetizado en 7 puntos las responsabilidades más

destacadas de un product owner y que se puede ver en la Tabla 4. Responsabilidades
del product owner

1. Escribir buenas historias de usuario.

2. Decidir qué construir… ¡y qué no!
3. Fijar criterios de aceptación para cada historia de usuario. Validar entregas.
4. Definir “productos mínimos viables”.
5. Priorizar historias de usuario, y para ello tener claro el valor de las mismas y el
valor que necesita el producto en cada momento (que diferirá a lo largo de la vida del
producto).
6. Estar accesible, y disponible, para explicar al equipo técnico dudas funcionales.
7. Definir el plan de releases (o la visión estratégica).

Tabla 4. Responsabilidades del product owner

3.3.Historias de usuario

La historia de usuario es la manera más común de tomar requisitos en un proyecto ágil.

Normalmente las historias de usuario siguen el siguiente formato:

“Como [rol o tipo de usuario], [quiero | podré | seré capaz | necesitaré |…] con el
beneficio de…”

Muchas veces las historias de usuario suelen escribirse en “post-it” o tarjetas, aunque
son mucho más que eso. Una historia no es sólo una descripción de una funcionalidad
en un post-it, una historia de usuario además está formada por otras dos partes no
físicas (Jeffries, 2001):

La conversación que conllevan, ya que son una herramienta para interactuar.

El cómo se confirma su implementación, las pruebas y verificación de la misma.

Las historias de usuario muestran la funcionalidad que será desarrollada, pero no cómo
se desarrollará. Por ello, cosas como que “el software se escribirá en C++” no es una
buena historia de usuario.

Además de las historias de usuario, podemos hacer uso de Sin buenos requisitos,
las epopeyas. Una epopeya es una historia de usuario más sin buenas historias de
grande, de mayor funcionalidad que sigue el mismo formato usuario, la planificación
que una historia de usuario pero su alcance es mayor. Las de tu proyecto tendrá
epopeyas recogen objetivos de alto nivel, objetivos de más riesgo, y será
carácter más estratégico. menos exacta.
Normalmente las epopeyas se dividirán en historias de usuario, que son más
manejables y más pequeñas, ya que realizar una epopeya nos podría llevar más de una
iteración o sprint (Tabla 5).
 Tareas para implementar
Epopeya Historia de Usuario
una historia de usuario

Diseño de la historia
Implementación
Como usuario, quiero
Como usuario, quiero Pruebas
seleccionar el artículo a
comprar artículos. Aceptación
comprar
Demo
Refactorización

Como usuario, quiero

…
seleccionar las unidades

Como usuario, quiero

...
seleccionar la forma de pago

Como usuario, quiero

…
seleccionar la forma de envío

Tabla 5. Epopeyas, historias de usuario y tareas

Otra manera de comprender la división anterior es ordenándolas por incertidumbre, de

mayor a menor (Tabla 6).
Requisitos Grado de incertidumbre

Tema ++++

Epopeya +++

Historia de usuario ++

Tareas +

Tabla 6. Requisitos por orden de incertidumbre

3.3.1.Creando buenas historias de usuario

Como habrás podido apreciar en la sección anterior, las historias de usuario son un
elemento fundamental en un proyecto ágil y, obviamente, van a ser claves para su
planificación y estimación. Y es por ello que esta sección recoge algunas claves y
buenas prácticas a la hora de crear historias de usuario.

Una historia de usuario recoge una funcionalidad mínima. Por ejemplo, según la
metodología ágil “extreme programming”(Beck & Andres, 2004), una historia de
usuario es “la unidad más pequeña posible de valor para el negocio”.

Las historias están pensadas para conversar, por ello son concisas y mínimas, para
recordarnos sólo lo que hay que añadir al software. No son especificaciones de
requisitos software. Si el texto no cabe en la tarjeta en la que se escribe la historia de
usuario es porque hay que dividirla en varias, o porque tiene información no relevante.
En este sentido, las historias deberían completarse en una iteración, no necesitar más
de una para ello.

Existe cierto debate sobre si una historia de usuario puede o debe tener un enlace,
trazabilidad, a otros documentos de soporte donde se amplía información sobre cómo
implementarla: por ejemplo una norma de seguridad, políticas internas, las reglas
corporativas en interfaces de usuario, etc. A pesar del debate, este es un recurso muy
utilizado por muchos equipos para mantener información de respaldo sin agrandar las
historias de usuario.

Para lograr esta trazabilidad, suelen añadirse a la historia identificadores de otros

documentos de soporte. Esto puede hacerse a mano o utilizar herramientas.

Las historias de usuario (ejemplo en la Figura 3) deberían ser escritas por el usuario o
por el product owner (ver epígrafe 3), ya que es el usuario realmente quien sabe lo que
necesita.

Figura 3. Ejemplo de historia de usuario

Por último, cada historia de usuario debería tener una prueba de aceptación, que
debería realizarse durante la iteración (evitando hacer una fase final, separada, sólo
para pruebas).

3.3.2.El valor de una historia de usuario

Claramente, uno de los principales objetivos de un product owner es que se entregue el

mayor valor al cliente o usuarios. Y esto en ocasiones es un gran reto.

El concepto “valor” de una historia de usuario no tiene una única definición, sino que
depende del producto, del momento etc.

El product owner debe definir el valor de cada

historia de usuario.

El valor que cada historia aportará al usuario

final depende de cada producto, organización
e incluso cambia según avanza la vida del
proyecto – producto software

Un buen product owner debe manejar eficientemente cómo aportar el mayor valor
posible. Y para ello debe manejar el orden de las historias que deben ser
implementadas, ordenando su implementación de mayor a menor valor.

Como se muestra en la Figura 4, normalmente, al comienzo del proyecto, por

desconocimiento de lo que realmente el usuario necesita, los product owners pueden
pedir al equipo técnico que implemente historias de usuario que pueden no aportar
mucho valor, pero que son necesarias para explorar lo que los usuarios realmente
quieren.

Posteriormente, con las cosas más claras, vendrá la fase en la que el producto
irá aportando cada vez más valor a los usuarios. Finalmente, habiendo cumplido las
mayores necesidades, el producto entrará en mantenimiento, o en la incorporación de
pequeñas funcionalidades o ajustes (Kniberg, 2012).

Figura 4. El valor que el product owner quiere entregar al cliente

Por otro lado, la principal responsabilidad del product owner es que se construyan las
cosas correctas, será responsabilidad del equipo técnico construirlas correctamente.

Para saber qué valor tiene una historia de usuario, la manera más simple es poner un
número a cada historia de usuario. A número mayor, mayor será el valor también. Hay
técnicas que ayudan a ello. Como las que veremos a continuación.
3.4.Técnicas para priorizar y dar valor a las historias de usuario

Normalmente, la priorización de requisitos, historias de usuario, etc., viene dada por el

valor que estas aportan al cliente o al negocio. A mayor valor, mayor prioridad.
Aunque dicho así, el concepto “valor aportado” queda bastante ambiguo y se puede dar
a cientos de interpretaciones. Es por ello deseable acotar y formalizar cómo se hace la
priorización y en base a qué factores.

Como es lógico, no existe un criterio universal para dar valor, priorizar historias de
usuario o requisitos, depende de cada negocio. Si bien es importante que cada equipo
fije los criterios por los cuales hará la priorización. En cualquier caso, es bastante
frecuente observar tres parámetros principales a la hora de determinar el valor de cada
requisito (Cohn, 2005):

- Rentabilidad de incorporar el requisito.

- Coste de incorporar el requisito.

- Cantidad de riesgos que minimizará la incorporación del requisito.

En muchas ocasiones, los anteriores suelen combinarse con algunas técnicas para
determinar la necesidad de incorporar al producto un nuevo requisito. Las dos técnicas
más populares en este sentido son el modelo Kano y la técnica MoSCoW.

3.4.1.Modelo Kano

El modelo Kano, de los 80, se utiliza para clasificar y priorizar requisitos en función
de lo que satisfarán al usuario. En el caso de los proyectos ágiles, el modelo Kano
suele usarse para priorizar la lista de funcionalidades o de historias de usuario.

Según el modelo Kano, hay cuatro tipos de atributos del producto:

- Requisitos obligatorios (básicos). Necesidades básicas. Atributos que esperan los

clientes y conducen a la insatisfacción extrema si están ausentes o mal satisfechos. Por
ejemplo, “que pases a un bar, pidas una caña, o una coca cola, y te la pongan. Que
pidas una caña y te la pongan no hace mejor al bar, pero que la pidas y no te la
pongan te enfadaría”.

- Necesidades (esperado,lineal). Atributos que bien realizados conducen al

incremento lineal de la satisfacción del cliente. Fuente de satisfacción, y necesarios de
priorizar a la hora de implementarlos. Por ejemplo, “que te pongan la caña, o coca
cola, rápido, con una sonrisa y una tapa”.

- No esperados (inesperado, excitante). Atributos atractivos, generalmente

inesperados por los clientes y que puede resultar en una gran satisfacción si están
disponibles. No suelen ser una prioridad. Son innovación. Por ejemplo, que “el bar
tenga wi-fi”, etc. Pregúntate si no se estará quedando tu producto sólo en cumplir
necesidades y aspectos básicos y estará tu competencia trabajando en requisitos
inesperados.

- Indiferentes. El cliente no está interesado en ellos.

El uso del modelo Kano se basa en clasificar los requisitos según los anteriores tipos y
así priorizarlos, en función de la etapa en que se encuentre tu producto.

3.4.2.Técnica MoSCoW

La priorización o análisis MoSCoW es otra técnica usada para comprender la

importancia que tiene para los usuarios la implementación de un requisito o
funcionalidad.

La técnica MoSCoW recibe su nombre de las cuatro categorías en que puede

clasificarse un requisito. Estas cuatro categorías son, en inglés: M, Must (obligatorio),
S, de Should (debería), C, de Could (podría), y W, de won’t (no necesario). Las letras
“o” en el nombre se añaden simplemente para mejorar la pronunciación y que además
el nombre de la técnica coincida con “Moscú” en inglés.

MoSCoW fue creada por Dai Clegg de Oracle UK, en el 94, y ha sido muy
popularizada por el grupo Dynamic Systems Development Method (DSDM).

Concretamente, los cuatro tipos en que se clasifican los requisitos son los siguientes:
 M - Must (Debe incluirse). Requisitos de prioridad alta, que deben ser
satisfechos para que el desarrollo pueda considerarse un éxito o incluso lanzar el
producto.
S - Should (Debería incluirse). La funcionalidad no es crítica, pero si importante
y deseable.
C - Could (Podrá incluirse).Requisitos deseables pero no estrictamente
necesarios.
W - Won’t (No incluir). Requisitos de los que se tiene claro no implementar,
aunque en un futuro podrían reconsiderarse.

3.5.El product backlog y los mapas de historias

La colección de historias a incorporar en un producto de software se conoce como

product backlog o pila de producto. El product backlog contiene historias priorizadas,
normalmente, las que están en un lugar más alto son las que tienen mayor prioridad.
Esto lo podemos ver en la Figura 5.

El término product backlog es originario de la metodología Scrum, aunque su uso se ha

a generalizado a otras metodologías ágiles o solo iterativas.

Hay que tener en cuenta que el nombre de “pila” de producto puede inducir a error, ya
que las pilas de producto no siguen una estructura típica del concepto pila en
informática, es decir, LIFO o Last In First Out, (último en salir primero en entrar).

Figura 5. Product Backlog

Un mapa de historias de usuario es una manera complementaria de priorizar y
complementar un product backlog (Patton, 2008).

Hay muchas maneras de organizar un mapa de historias de usuario, aunque

generalmente, se suele hacer como se muestra en la Figura 6.

Figura 6. Mapa de historias de usuario

En el nivel superior se colocan las epopeyas. Debajo de cada una de ellas las historias
de usuario en que estas se descomponen. Las epopeyas se colocan de izquierda a
derecha en función del orden de uso del sistema, o de cómo explican mejor qué debe
hacer el sistema.

A su vez, las historias de usuario en que se descompone cada epopeya se ordenan de

arriba abajo en función de su prioridad.

Finalmente, se pueden agrupar historias de usuario en releases usando líneas

horizontales.

Hay muchas maneras de hacer un mapa de historias de usuario, e incluso algunos usan
terminología diferente (en ocasiones en vez de usar la palabra epopeya se usa la
palabra actividad, si bien en esencia la idea es la misma).
Para concluir, las ventajas de un mapa de historias frente a un product backlog son que:

Deja más clara la cadena de valor.

Muestra la relación entre historias de usuario grandes y pequeñas.
Aporta un contexto.

3.5.1.Relación entre el Roadmap y el Product Backlog

Si se aplica correctamente, el roadmap y el product backlog se complementan muy

bien. Aunque antes de crear un roadmap ágil, debes saber si puedes predecir cómo
evolucionará en el futuro el producto, con cierto grado de certeza. Y vas a necesitar
roadmap si gestionas un producto grande.

El roadmap ágil contiene la planificación estratégica del producto y el producto

backlog el trabajo más táctico. El roadmap debería capturar las principales
funcionalidades de cada release, mientras que el product backlog se centra en la
creación de la siguiente release(Pichler, 2012).

El roadmap contextualiza el product backlog. Por ejemplo, se usa para decidir si una
nueva característica se debe añadir, o si debe ser incluida en una versión futura. En
consecuencia, el uso del roadmap, hace que el product backlog se vuelva más conciso y
que contenga menos elementos, siendo más transparente, y más fácil de manejar.

Contar con una persona a cargo del roadmap ágil y el product backlog une objetivos
estratégicos y tácticos del producto, y establece una clara autoridad y responsabilidad
sobre los mismos.

Normalmente los roadmaps se crean para productos medianos o grandes, aquellos en

los que puedo hacer una previsión de su situación en meses, en 6 o 12 meses por
ejemplo. Y cuando normalmente ya hay algunas primeras versiones del producto.

Mientras que un product backlog (el típico que se usa en Scrum) es bueno para saber lo
que debe estar terminado para lanzar una release concreta, un roadmap permite mirar
más hacia el futuro y captar la estrategia de producto, lo que probablemente se
implementará en el tiempo. Permite proyectar en el tiempo donde quieres que esté tu
producto en el futuro.
Como resumen de las diferencias entre la hoja de ruta del producto (roadmap) y el
product backlog:

- Roadmap ágil: contiene varias releases, su objetivo es planificar el producto, su

horizonte suele ser años, se actualiza cada varios meses, etc.

- Product backlog: contiene historias de usuario, su objetivo es el desarrollo de una

release, su horizonte suele ser meses, se actualiza cada iteración, etc.
Capítulo
4

4. Estimando un proyecto ágil

“Hacer predicciones es muy difícil… sobre todo si se trata acerca del futuro”

-- Neils Bohr

¿Cuánto tiempo tardarías en ver la serie de televisión “The Big Bang Theory3”?
¿Difícil pregunta?

Si yo tuviese que responder a la anterior cuestión, intentaría concretar primero los

“requisitos” de la tarea solicitada. Concretamente, qué capítulos o qué temporadas
debería ver. Dependiendo de lo claro que tengas los requisitos, la estimación será más
o menos exacta.

En el mundo de los proyectos software, las estimaciones arrancan de la misma manera:

teniendo claros los requisitos. Si no hay requisitos… difícilmente se podrá estimar.
Con la particularidad de que en un proyecto ágil, en el que el producto se va
construyendo “poco a poco”, los requisitos existen, pero menos especificados que en
un proyecto tradicional (abordaremos esta problemática en el punto 4.1).

Una vez resuelto el anterior punto, para estimar cuánto tiempo me llevaría ver la serie,
sabiendo ya el requisito solicitado, sabiendo los capítulos que me piden ver, intentaría
averiguar el “tamaño” de la tarea que tenemos que realizar. Y para ello necesitaré una
unidad de tamaño.

Supongamos que un cliente me dice que lo que necesita, el “requisito”, es que vea los
capítulos 1, 5 y 9 de “The Big Bang Theory”. Ahora puedo empezar a calcular el
tamaño, midiéndolo en alguna unidad. En este caso la unidad de tamaño puede ser el
“número de capítulos”, en el ejemplo, el tamaño de mi tarea es de 3 capítulos.

En software, seguiremos un proceso similar, teniendo claros los requisitos mediremos

el tamaño del trabajo a realizar. Claro que en software utilizaremos otras medidas de
tamaño y, concretamente, en proyectos ágiles es usual utilizar la unidad denominada
“punto historia”, que mide la complejidad, tamaño de cada requisito o historia de
usuario.

Seguidamente, parece lógico poder calcular el tiempo que nos llevará la tarea. El
tiempo de duración de cada capítulo es de 25 minutos. Por lo que ahora puedo aplicar
una función de cálculo sencilla, y multiplicar 3 capítulos * 25 minutos, con el resultado
de 75 minutos.

Y, de nuevo, en el mundo de los proyectos software, el proceso será similar: desde el

tamaño obtendremos el tiempo estimado. Si bien, lógicamente, en el mundo del
software no será tan fácil como en el de las series, ya que no todos los “capítulos”,
requisitos, tienen la misma duración.

En este punto, ¿podría ya decirle al cliente que la tarea encomendada de ver 3 capítulos
de la serie me llevaría 75 min.? El ávido lector, seguramente, ya se habrá percatado de
lo poco probable que es cumplir con dicho tiempo estimado.

Salvo excepciones, que las hay, muy pocos seríamos capaces de estar 75 minutos
seguidos, sin parar, viendo una serie. La vida real difiere de las estimaciones.
Seguramente iremos al baño, pararemos para descansar, ir a comer algo, nos llamarán
por teléfono, etc. Y es por ello que nuestros 75 minutos de “tiempo ideal” tendremos
que transformarlos en “tiempo real”, que normalmente será superior.

De nuevo, y por último, en software sucede algo similar. El tiempo ideal varía por
muchas razones, que van desde el equipo de desarrollo, su experiencia, productividad,
preparación, etc., hasta el calendario, las festividades, etc.

4.1.La definición de los requisitos afecta a la estimación

Una regla básica en estimación software es que según avanza el proyecto la estimación
contiene menor error, por ello, sería conveniente reestimar periódicamente, según
avanza el proyecto, para reajustar la estimación.

El porqué de este comportamiento lo explica de manera bastante ilustrativa el llamado

cono de incertidumbre (Little, 2006; McConnell, 2006), que refleja (ver Figura 7)
cómo las estimaciones son cada vez más precisas, según progresa un proyecto.
 Figura 7. Cono de incertidumbre

En el cono de incertidumbre, el eje horizontal representa el paso del tiempo, desde la

concepción inicial del proyecto, a la especificación de requisitos, diseño, etc. Y el eje
vertical contiene el grado del error de las estimaciones en varios momentos en el
proyecto.

Al principio del proyecto, cuando sólo se tienen requisitos poco especificados,

debemos asumir, y ser conscientes, de que el error con el que se trabaja es mayor que
cuando se estima teniendo requisitos detallados, o teniendo ya un diseño o, aplicando
todo ello a un proyecto ágil, cuando se llevan ya varias iteraciones.

Sin requisitos, sin historias

En un proyecto que tiene un ciclo iterativo e
incremental (ver capítulo 5), tendremos un mini cono de de usuario, o con requisitos
incertidumbre en cada iteración (Construx Software muy vagos... el error de la
Builders, 2013), pudiéndose plantear dos situaciones. estimación será muy alto

La primera, en la que los requisitos, que como vimos en la sección 3.3 se basan en
historias de usuario, se detallan en cada iteración, y la segunda, en la que primero se
detalla una gran cantidad de requisitos y luego se itera. Las empresas deben priorizar
entre la flexibilidad de la primera opción o preferir la mayor previsibilidad de la
segunda, para algunos…menos “ágil”. Veamos ambas opciones con mayor detalle.

4.1.1.Definir las historias de usuario sólo al comienzo de cada iteración

Debido a lo ambiguo de los requisitos, nos moveríamos, en cada iteración, al principio,
en la parte de mayor error del cono de incertidumbre tal y como se puede ver en la
Figura 8.

Figura 8. Cono de incertidumbre en proyectos sin fase previa de requisitos

Esto, claramente, penaliza la previsibilidad a largo alcance, nos movemos en cada

iteración en un cono de incertidumbre con alto error, aumentando el posible error en
costes, calendario, y la funcionalidad.

Pero crea proyectos más flexibles, proyectos que no invierten tiempo en especificar
detalladamente grandes cantidades de requisitos, quizás porque no se conocen, no se
sabe su viabilidad, si el cliente los requerirá, etc.

Metodologías como Scrum proponen ciclos de vida más cercanos a este tipo de
planificación.

4.1.2.Detallar primero todos los requisitos y luego iterar

Otros proyectos definen la mayoría de los requisitos al principio, y una vez definido el
total, o la mayoría de los requisitos, las iteraciones cubren las fases de diseño,
construcción, y pruebas (Figura 9).
 Figura 9. Cono de incertidumbre en proyectos con fase previa de requisitos

En otras palabras, el proyecto se mueve secuencialmente, en cascada, en la definición

de requisitos, y luego cambia a un enfoque iterativo a partir de ahí.

Esta segunda opción soporta mayor previsibilidad a largo alcance, de costo y

temporalidad, así como una cantidad moderada de flexibilidad de requisitos.

Metodologías como FDD (ver ANEXO II. FDD) utilizan este enfoque. En ocasiones,
los equipos que usan Scrum añaden el mencionado sprint cero (ver punto 5.4) para
relajar la agilidad y utilizar esta estrategia.

4.2.Los puntos historia

Históricamente, la unidad clásica de estimación del “tamaño” de un requisito ha sido el

Punto Función. Pero, en los últimos años, los puntos historia se han convertido en una
unidad de tamaño muy usada, principalmente en proyectos ágiles.

Cualquier medida del tamaño, bien sean puntos historia, puntos función, puntos casos
de uso, o cualquier otra, parte de los requisitos para calcular el tamaño del software.
Estos requisitos pueden venir dados en diferentes formatos, más o menos detallados o
especificados. Formatos que pueden ir desde un documento, a un pliego de
descripciones técnicas, casos de uso o, como suele ser habitual en proyectos ágiles,
historias de usuario.

La Tabla 7 recoge una síntesis de métodos de estimación, la unidad de tamaño que usan
y en qué están basados estos métodos.

Método de estimación Unidad típica de tamaño Características

Juicio Experto Cualquiera Experiencia individual

Punto Función Lite Punto Función Paramétrico

Punto Caso de Uso Punto Caso de Uso Paramétrico

Planning Poker Punto Historia Experiencia colectiva

Analogía Cualquiera Experiencia documentada

Tabla 7. Métodos de estimación, unidad y base

También podríamos ordenar los métodos como el T-SHIRT que ya vimos (punto 2.4) o
los que veremos a continuación en función de la precisión que presentan como se ve en
la Tabla 8.

Método de estimación Precisión que busca…

Estimación en horas +++

Estimación en puntos historia ++

Estimación según tallas T-Shirt +

Tabla 8. Técnicas de estimación ordenadas por precisión

Los puntos historia son una unidad usada, normalmente, para medir el tamaño de una
historia de usuario. El número de puntos historia asociados a una historia de usuario
representa el tamaño global de la historia.

Más concretamente un punto historia es una fusión de la cantidad de esfuerzo que

supone desarrollar la historia de usuario, la complejidad de su desarrollo y el riesgo
inherente(Cohn, 2005).
A diferencia del punto función, no existe una fórmula para calcular los puntos historia
de una historia de usuario. 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 tamaño que una historia a la que se le asigna un único punto.

Y normalmente hay dos formas de hacer esta asignación:

Seleccionar una historia de las más pequeñas y asignarle 1 punto historia. Esta
historia de usuario con 1 punto historia hará de unidad, y al resto se le asignarán
puntos historia en función de su complejidad respecto a ésta.

Seleccionar una historia de tamaño medio y asignarle un número en la mitad del

rango de puntos historia a utilizar. Normalmente, se usan rangos de puntos historia
entre 1-10. Según esto, buscaríamos una historia de tamaño medio y le
asignaríamos cinco puntos historia. Cada historia adicional se calcula
comparándola con la primera historia.

En cualquier caso, recomendamos el primer método por ser más fácil de aplicar.

4.3.La escala de puntos historia

Varios estudios han demostrado que es mejor estimar usando rangos o escalas de
posibles valores que se pueden asignar(Miranda, 2001) a la estimación, es decir,
fijando un tope máximo de puntos historia.

Según lo anterior, normalmente iremos agrupando historias en puntos historia, como

muestra la Tabla 9.

1 punto historia Historia D, Historia B

2 punto historia Historia C, Historia L

3 punto historia Historia E, Historia G, Historia I, Historia J

5 punto historia Historia F, Historia H

8 punto historia Historia A

Tabla 9. Ejemplo de asignación de Puntos Historia a historias de usuario

Normalmente, hay dos escalas de puntos historia que suelen tener buenos resultados:

1, 2, 3, 5, 8, etc.
1, 2, 4, 8, etc.

La primera escala es la secuencia de Fibonacci, útil porque la separación entre los

números de la secuencia se hace más grande a medida que los números aumentan. En la
segunda, cada número es dos veces el número que le precede. Estas secuencias no
lineales funcionan bien porque reflejan mayor incertidumbre asociada a estimaciones
de grandes unidades de trabajo.

Además, normalmente, deberíamos limitar los valores de la escala, por ejemplo, a 10

valores.

4.4.La Técnica de estimación “Planning Poker”

El Planning Poker (Cohn, 2005; Haugen, 2006) es una técnica que se utiliza para
asignar los puntos historia a las historias de usuario (ver Tabla 9). Esta técnica recibe
el nombre de Planning Poker ya que cada una de las personas implicadas en el proceso
de estimación toma un mazo de cartas que suelen estar numeradas con alguna de las
secuencias que vimos antes.

Normalmente se siguen los siguientes pasos:

1. Se presentan las historias de usuario a estimar, haciendo una descripción de las

mismas y se procede a discutir aquellos detalles más relevantes o que no hayan
quedado claros. Suele darse un tiempo máximo de discusión para mejorar la
productividad.

2. Tras este período de discusión, cada una de las personas implicadas en el proceso
de estimación toma su mazo de cartas y escoge la carta que representa su estimación (el
número de puntos historia).
3. 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 dispersión entre las estimaciones (unos
dicen 2, otros 20) se vuelve al discutir la historia de usuario y se vuelve a realizar el
proceso de estimación.

4. Por último, si no existe una gran dispersión, se llega por consenso a un acuerdo en la
estimación de la historia de usuario.

Generalmente, la dispersión en las estimaciones es síntoma de que la información que

maneja parte de los involucrados en el proceso de estimación no es completa o exacta.
La segunda ronda de discusión permite aclarar aquellos puntos poco claros, diferencias
de criterio y desvelar información que pueda no ser obvia sobre la historia para que en
la siguiente ronda de estimación, la dispersión de las estimaciones sea mucho menor y
se pueda llegar fácilmente a un consenso.

4.5.¿Puntos historia o estimación en horas?

En el mundo de la estimación y planificación ágil, este es uno de los grandes debates,

si usar puntos historia u horas directamente a la hora de planificar (debate que también
es de aplicación a cualquier otra medida del tamaño, como los puntos función o los
puntos caso de uso). Y al respecto, podemos encontrar opiniones de todo tipo, aunque
lo normal es usar “puntos historia” para estimar historias de usuario y horas para
estimar tareas (recordemos que las historias de usuario se dividen en tareas).

Los puntos historia son útiles a la hora de hacer estimaciones a largo plazo, pero no
funcionan muy bien a corto plazo.

Como vimos, los puntos historia se usan para asignar "tamaño relativo". Se utilizan
series cerradas, por ejemplo la de Fibonacci (1, 2, 3, 5, 8, etc.), porque el objetivo es
agrupar cosas de tamaño similar en lugar de lograr una estimación muy precisa.

Cuando se estima en horas buscamos responder a la pregunta "¿Cuánto tiempo puede

llevarnos?". Cuando se estiman en puntos historia buscamos tamaños relativos o la
complejidad "¿Cómo es de grande en relación otras?" En la Tabla 10 podemos ver un
ejemplo.

Historias de Usuario Tareas

 “Puntos historia”> “Horas o días ideales”

Como usuario, …
Programar [10 horas]
[8 puntos historia]

Escribir Test [5 horas]

Actualizar documentos [2 horas]

Suma = 17 horas

Tabla 10. Ejemplo de relación entre puntos historia y horas

La Tabla 11 muestra una comparativa entre la estimación con puntos historia y la

estimación en horas.

Puntos Historia Horas ideales

Ideal para estimar a medio – largo plazo Ideal a corto plazo

Se suele aplicar en el sprint

Se suele aplicar en el product backlog
backlog

Mide tamaño / complejidad relativa Mide tiempo de duración

Busca relativizar el tamaño complejidad de una cosa

Busca exactitud
frente a otra

Tabla 11. Comparativa sobre el uso de puntos historia y horas

Como comentábamos, lo más usual y utilizado es hacer uso de los puntos historia para
estimar historias de usuario. Pero siempre queda abierta la opción de estimar historias
de usuario directamente en horas. Autores como Kent Beck(Beck & Andres,
2004)recomiendan que una vez que el equipo se ha familiarizado con los puntos
historia le será fácil hacer saber a cuánto tiempo equivale cada punto historia, y en ese
momento “es preferible trabajar con tiempo real para hacer la comunicación más clara,
directa y transparente”.
Las principales razones de usar puntos historia frente a horas son:

El punto historia es una unidad de mayor error, pero más rápida, lo que posibilita
al product owner priorizar el product backlog.

Los puntos historia son independientes del equipo de desarrollo, es decir, para el
mismo número de puntos historia, dos equipos pueden implementarlos en diferente
tiempo. Esto es útil cuando no se sabe quién implementará las historias, o en
procesos de subcontratación o licitación de un proyecto ágil.

4.6.¿A cuántas horas equivale un punto historia?

Aunque, como vimos antes, las historias de usuario se suelen estimar en puntos historia,
en la mayoría de equipos siempre suele surgir la siguiente cuestión: "entonces, un punto
historia equivale 9 horas ¿no?" (cámbiese el 9 por lo que corresponda).

Normalmente no hay una relación lineal entre puntos historia – horas (digo relación
lineal, no que no exista relación). Es decir, podemos tener dos historias de usuario con
los mismos puntos historia pero que su tiempo de realización sea diferente.

Por ejemplo, imaginemos que en nuestro equipo, las historias de 5 puntos historia están
en un rango de entre 15 y 30 horas. Por otro lado, el rango de horas en que se mueven
las historias de 1 punto historia va a ser diferente al de las historias de 8 puntos
historia.

Esto significa que la distribución de las estimaciones pequeñas será más exacta que las
grandes. Estimar el tamaño de una historia que requiere modificar un texto en una Web
debe ser mucho más fácil que calcular el esfuerzo de una historia que requiere cambiar
varias tablas de la BBDD.

En su blog (Treadway, 2011)hizo un pequeño estudio con los datos de su equipo,

recopilando datos de 6 iteraciones y obteniendo el siguiente gráfico de horas
estimadas/puntos función.
 Figura 10. Distribución de horas estimadas/puntos historia

De dicho gráfico se obtienen las conclusiones que ya se comentaron en los párrafos

anteriores: no hay una relación o correspondencia exacta entre la estimación en puntos
historia de las historias de usuario y su equivalencia a horas, sino que dicha
correspondencia se encuentra en un rango de valores.

Por ejemplo, si nos fijamos en la gráfica de la estimación de 1 Punto Historia de la

Figura 10, nos damos cuenta de que dicho punto historia equivale a un rango de entre 1
y 19 horas aproximadamente, no hay un valor de hora exacto.

Por otra parte, también se observa en la gráfica que la estimación de la historia de

usuario más pequeña (con un valor de puntos historia menor) es más precisa que la de
un valor de más puntos historia, ya que el rango de equivalencia en horas es menor.

Como ya se ha comentado, es más sencillo estimar con precisión una historia de

usuario pequeña que una grande, la Figura 10 muestra como a un 1 punto historia le
corresponde un valor en un horas que se mueve entre 1 y 19, frente al rango en que se
mueven los 8 puntos historia, a los que les corresponden un valor en horas que se
mueve entre 11 y 57 horas.

4.7.Refinando la estimación con la Velocidad del equipo

Para entender cómo estimar y planificar un proyecto con puntos historia es útil y
necesario conocer el concepto de velocidad, una medida del ratio de avance del
proyecto(Cohn, 2005).
La velocidad se calcula sumando el número de La velocidad media del equipo,
puntos historia de cada historia de usuario terminada obtenida de datos históricos,
durante una iteración del proyecto (o sprint en es un dato de incalculable
terminología de la metodología Scrum). Ejemplos:
valor a la hora de planificar

Si el equipo completó tres historias en la iteración, cada una de cinco puntos

historia, entonces su velocidad en esta iteración fue quince.

Si el equipo completó dos historias de cinco puntos su velocidad fue diez.

Si sumamos los puntos historia de todas las historias de usuario a desarrollar

tendremos una estimación del tamaño total del proyecto. Y si conocemos la velocidad
del equipo, por datos históricos, podremos dividir el tamaño entre la velocidad para
llegar a una estimación del número de iteraciones necesarias. En la Tabla 12 podemos
ver un ejemplo.

Velocidad

Iteración o Sprint (puntos historia

completados)

1 45

2 21

3 35

4 44

5 29

Tabla 12. Ejemplo de cálculo de la velocidad media de un equipo

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 iteración 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
iteración es de dos semanas, nuestra estimación de la duración es de veinte semanas.
Podemos contar hacia adelante veinte semanas en el calendario y hacer el plan de
proyecto(Cohn, 2005).

En cualquier caso, no olvides que cuando hablamos de velocidad hacemos referencia a

una media. Si necesitas hacer estudios más profundos sobre la velocidad de un equipo,
o comparar más fielmente a dos equipos según su velocidad, etc., deberías acompañar
la velocidad media de otros valores, por ejemplo, la desviación típica. La Tabla 13
muestra un ejemplo de dos equipos con la misma velocidad media pero en los que la
desviación muestra que uno de ellos, el A, es mucho más regular que el otro.

Equipo A Equipo B

10, 11, 9, 10 10,14,9,7

Media: 10 Media: 10

Desviación:0.7 Desviación:2.5

Tabla 13.Ejemplo de dos equipos con la misma velocidad media pero distinta
desviación
Capítulo
5

5. Planificando las iteraciones

"No seas de una única forma, adáptate y construye la tuya propia, y déjala crecer, sé
como el agua. Si pones agua en una taza se convierte en la taza. Si pones agua en
una botella se convierte en la botella. Sé agua amigo mío".

--Bruce lee

Cuando creamos un “plan de release” nuestro objetivo era planificar y prever qué iba a
suceder durante las diferentes iteraciones que se irían sucediendo hasta concluir con
una release. Si los roadmap se hacían a semestres o años (planificando varias
releases), normalmente el plan de una release se crea para unos pocos meses o
semanas.

Cada uno de estos planes de release estará formado por el número de iteraciones que
consideremos adecuado. Aún así el plan de release no tiene que describir el detalle de
cómo se va a trabajar dentro de cada una de las iteraciones que abarcan dicha release,
eso lo dejaremos para el plan de la iteración.

A la hora de planificar las releases haremos uso, para recoger necesidades y requisitos,
de las historias de usuario. Las historias de usuario, que ya vimos con detalle, recogen
de una manera particular aquello que el negocio o el usuario desea que se implemente.

La Figura 11 muestra un ejemplo de planificación de la release. Obtenidas varias

historias de usuario (requisitos) que debieran implementarse en la misma, las
funcionalidades que debe tener el producto, estas se dividen en varias iteraciones.
 Figura 11. Planificación de la reléase con 2 iteraciones

Para seleccionar qué historias de usuario, y en qué orden se van a implementar,

será necesario estimar el valor que aporta cada una al usuario (ver epígrafe 3.3.2) y el
tamaño/complejidad de las historias de usuario de la release (ver epígrafe 3.3), algo
necesario para poder decidir qué historias se desarrollarán en cada iteración.

Un punto a destacar del plan de la release es identificar las condiciones de

satisfacción de cada prototipo y de la release, es decir, bajo qué condiciones la release
estará lo suficientemente terminada como para pasar a producción.

Y este punto involucra a los usuarios, clientes, o figura que los representa, el product
owner.

No olvides determinar las condiciones de satisfacción o validación de prototipos y

releases

Otro aspecto que no debe pasarse por alto es que durante el tiempo que transcurre hasta
que se obtiene la release iremos iterando, es decir, el ciclo de vida de trabajo
será iterativo, más concretamente, iterativo e incremental, ya que este ciclo de vida es
el corazón de un proyecto ágil.

5.1.Ciclo de vida ágil: iterativo, incremental y de iteraciones cortas

Frente a realizar cada fase del proyecto una única vez, una fase tras otra sin, en teoría,
vuelta atrás, o en cascada, una alternativa es el “ciclo de vida incremental” en el que el
software se va creando poco a poco, por partes. En vez de una única fase monolítica de
requisitos, otra única de diseño y una final de codificación, el software final se
construye después de varias fases de requisitos, diseño y codificación, cada una
creando parte del software final. Se van desarrollando partes del software, para
después integrarlas a medida que se completan. A este ciclo de vida se le conoce como
iterativo incremental.

Pero no sólo el ciclo de vida incremental es el que propone una manera alternativa al
desarrollo en cascada. Hay muchas otras propuestas (como el ciclo de vida en espiral),
donde una de las más destacadas es el “ciclo de vida iterativo”. El desarrollo iterativo
se centra en mejorar y revisar reiterativamente el producto ya creado. En cada ciclo se
revisa y mejora el trabajo. Por ejemplo, cuando se desarrolla rápidamente un producto,
muchas veces no se hace con todos los detalles ni la máxima calidad, pero se hace con
la idea de que el usuario vea cuanto antes un prototipo, para que en sucesivas
iteraciones dicho producto se vaya mejorando y afianzando.

De la unión de los dos anteriores, iterativo + incremental, nace el “ciclo de vida

iterativo e incremental”, que es una de las buenas prácticas de ingeniería del software
más antiguas (su primer uso en el software se data en los 50 con la construcción del
avión cohete X-15) y es característico de los proyectos ágiles.

En este tipo de ciclo de vida, al final de cada iteración se consigue una versión
operativa del software, que añade nuevas funcionalidades y mejoras sobre la versión
anterior.

El ciclo de vida de un proyecto ágil es iterativo e incremental, con iteraciones

cortas, normalmente, de no más de un mes

Al ir desarrollando prototipos, se obtiene un “feedback” continuo por parte del usuario

sobre un producto operativo.

Es importarte recordar que el ciclo de vida iterativo e incremental está compuesto por
dos “partes”, por lo que no hay que olvidar “la parte iterativa”, ya que en la práctica,
muchas veces nos encontramos con que los equipos olvidan la parte iterativa, olvidan
que cada prototipo debe mejorar en calidad al anterior, y se centran solo en añadir
funcionalidad. El problema de esto es que pasadas unas cuantas iteraciones, el
producto se hace difícilmente mantenible, por su baja calidad, y por ello es muy difícil
añadir nuevas funcionalidades, alargándose las iteraciones, los ciclos, y muriendo la
esencia de todo esto.
5.2.Cuánto tiempo debe durar una iteración

Un punto clave a la hora de planificar un proyecto iterativo es decidir la duración de

las iteraciones (o de los sprint en terminología Scrum). En la Figura 12, se puede ver
un ejemplo con iteraciones de 3 semanas de duración.

Figura 12. Ejemplo de planificación de un proyecto iterativo con iteraciones de 3

semanas.

Para seleccionar la duración de una iteración, podemos encontrar recomendaciones de

todo tipo. Por ejemplo, metodologías como XP (Beck & Andres, 2004) recomiendan
iteraciones de un par de semanas, mientras que lo habitual en Scrum es que sean de un
mes de duración. Y lo normal que nos solemos encontrar en proyectos son iteraciones
que están entre una semana y un mes.

¿Qué debería determinar la duración más recomendable para una iteración? 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 iteración (demos de prototipos), por
lo que a mayor frecuencia requerida para mostrar demos y avance, menor debiera
ser la duración de la iteración.

En línea con el anterior, debiéramos pensar con qué frecuencia hay que medir, o
mostrar, el progreso del proyecto. En teoría sólo al final de una iteración podemos
medir con precisión la cantidad de trabajo que realmente ha sido completado.

La frecuencia con la que se pueden re-ajustar objetivos del proyecto. No

debiéramos hacer cambios de objetivo, funcionalidad, o alcance, una vez que ha
 comenzado una iteración. Los ajustes y cambios deben esperar hasta el momento
en que una iteración termina. Por ello, si se requiere mayor ratio de cambio de
alcance, menor debiera ser la duración de la iteración. 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 iteración.

Ten cuidado, que en este punto la terminología puede ser confusa…

Una iteración, es un periodo de tiempo, no confundir con el ciclo de vida iterativo.

El ciclo de vida incremental, contiene las fases del cascada estándar, pero cada
iteración trabaja sobre un sub conjunto de funcionalidad. Desarrollar por partes el
software, después integrarlas a medida que se completan.

En el ciclo de vida iterativo, en cada ciclo, iteración, se revisa y mejora el

producto. Un ejemplo de desarrollo iterativo es aquel basado en refactorizaciones,
en el que cada ciclo mejora más la calidad del producto.

Es importante señalar que este ciclo no implica añadir funcionalidades, pero si

revisión y la mejora.

Ciclo de vida ágil, Iterativo e incremental,

Incremental = añadir
iterativo = re-trabajo
iteraciones = cortas, semanas.
iteraciones no son (o a priori no tienen porqué) lineales y son flexibles

Con todo, por ejemplo, si tenemos cuatro meses de proyecto, y nuestras iteraciones son
de un mes de duración, tendremos tres momentos (al final de la iteración 1, 2 y 3) para
tomar “feedback”, medir progreso y re-ajustar prioridades.

Otra consideración 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 iteración, esa idea solo puede introducirse en la próxima versión, que comenzará
en dos semanas. Dos semanas que quedan de la iteración en que aparece el nuevo
requisito, más 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 consideración. No olvides que a menor tiempo de iteración mayor nivel y
sofisticación debe tener el equipo de desarrollo, por lo que la madurez,
compenetración, experiencia, cualidades técnicas, etc., juegan un papel importante.

5.3.Deberían las iteraciones durar el mismo tiempo?

A iteraciones más cortas, harás

En nuestra experiencia, hemos visto equipos trabajar
más entregas, con mayor
muy bien con iteraciones, o sprint, de duración
variable, es decir, que justo antes de comenzar el frecuencia, y menor será la
mismo, en su planificación, se decidía la duración desviación respecto a lo que el
que tendría la iteración. usuario espera.

Pero conviene decir que han sido más los equipos que trabajan bien con iteraciones de
la misma duración. Es más, en equipos poco experimentados, variar la temporalidad de
la iteración suele conducir a problemas.

Es recomendable que todas las

Comentaban (Kniberg & Skarin, 2010) que una
iteraciones duren lo mismo, esto
vez establecida la duración idónea para los
sprint… “mantenedla durante un buen periodo de sincroniza a la organización,
tiempo, porque manteniendo la misma duración se permite hacer cálculos de
logra un “latido corporativo” al que todo el velocidad más exactos y detectar
mundo se acostumbra”. problemas en el proyecto

Las principales ventajas de tener sprint todos ellos de tiempo fijo viene de que:

Sincroniza calendarios, todo el mundo sabe cuando comienza y cuando acaba un

sprint. Se evitan discusiones sobre las fechas de entrega, ya que con el tiempo
toda la organización se acostumbra a que “aquí cada dos semanas se entrega”.

Facilita el cálculo de la velocidad del equipo, una métrica muy importante a la

hora de planificar un proyecto ágil (que veremos con más detalle en la
sección 4.7). La velocidad es el trabajo completado al final del sprint, e interesa
ir disponiendo de la media histórica de la velocidad del equipo. Si los sprint son
cada uno de una temporalidad diferente el trabajo entregado se verá afectado por
 ello, será mayor o menor, y será difícil tener una media, y detectar caídas de
velocidad, desviaciones de la media, por problemas.

No obstante, que los sprints regularmente sean de la misma temporalidad no significa

que eternamente tengan que tener la misma temporalidad.

La duración pueden variar de un proyecto a otro, o tras una retrospectiva, el equipo

puede detectar que le conviene otra temporalidad, y comenzar así una serie amplia de
sprints todos ellos con la misma temporalidad pero diferente temporalidad a los de la
serie anterior.

En cualquier caso, el cambio de temporalidad no es algo frecuente.

5.4.El “Sprint cero”

En algunos equipos es frecuente el uso del llamado sprint o iteración cero, cuyo
objetivo son los preparativos previos a comenzar el desarrollo. Así, normalmente,
durante el sprint cero se realizan las tareas como las siguientes:

Se dejan listos los entornos de desarrollo.

Se trabaja en el product backlog, principalmente en dejar listas las historias de
usuario, priorizadas y estimadas.
Se hace una previsión del reparto de historias de usuario por iteración.
Se hace un estudio de la arquitectura.

Autores como (Ambler, 2008), comentan que el sprint cero es aquel en que se organiza
el trabajo, se estudian requisitos iniciales, conceptualizaciones arquitectónicas
iniciales, se dejan listos los puestos de trabajo, la planificación inicial, y todo lo que se
necesita para iniciar el proyecto. Aunque para Ken Schawber(Schawber, 2008),
coautor de Scrum, el sprint cero no deja de ser una errónea forma de llamar a la
planificación previa al primer sprint.

5.5.El “Sprint de release”

En las metodologías ágiles, y en Scrum especialmente, cada iteración, cada sprint,

debiera concluir con un incremento funcional sobre el producto, que además sea
potencialmente entregable. Aunque, no todo lo “potencialmente entregable” es
realmente “entregable”.

El sprint de release es aquel que implementa aquellas tareas necesarias para poner el
sistema en producción. Aquel que muchos proyectos requieren al final de un ciclo de
release, es decir, después de un número de iteraciones o sprint previos a un paso a
producción. Un último sprint dedicado a preparar el paso a producción.

En este sprint se realizan tareas como el despliegue, generación de “scripts” de

recuperación del sistema en caso de problemas al pasar a producción, tareas
relacionadas con las bases de datos en producción, documentación, pruebas de carga,
integraciones, etc.

Sobre el sprint de release hay comentarios a favor y en contra, hay quien dice que es
necesario, y quien dice que debería evitarse, ya que el equipo debería dejar lo
suficientemente listas las cosas al final de un sprint regular como para que los pasos a
producción no requieran de ese tiempo dedicado exclusivamente al paso a producción.

En proyectos que implementan el “continuous delivery” este sprint carece de sentido,

ya que el paso a producción es prácticamente inmediato.

5.6.¿Y mis Diagramas Gantt? ¿volveré a utilizarlos?

En planificaciones software tradicionales, muchas veces hay reuniones de proyecto en

las que los participantes muestran decenas de diagramas Gantt (como podemos ver en
la Figura 13), con decenas de barras azules horizontales, flechas de dependencias,
porcentajes de avance dentro de las barras, porcentajes de uso de recursos, columnas
de fechas de inicio, fin, real, etc.

Figura 13. Ejemplo de diagrama Gantt

En muchas ocasiones cuando en una reunión salen estos diagramas, diagramas que,
algunos, por su tamaño, son impresos en varios folios, se corre el riesgo de que la
única preocupación del equipo sea cuadrar barras, flechas y recursos, en un espacio
temporal…

Pienso que, en parte, la razón de su gran uso en el mundo del desarrollo software viene
de la formación que casi todos los ingenieros en informática o carreras técnicas han
recibido en gestión de proyectos, aún hoy en un alto porcentaje, basada en aprender
Gantt, Perts, rutas críticas, etc. Es decir, planificación tradicional, aquella heredada de
la gestión y construcción de productos físicos cómo barcos, casas o coches.

Si tienes que usar Gantt, intenta evitar malas prácticas que suelen asociarse a los
mismos

Y esa “visión Gantt” de que fabricar software debe hacerse como se construyen cosas
físicas está tremendamente arraigada en la cultura de ciertas organizaciones,
incrementada aún más en los últimos años por el uso de macro marcos de gestión de
proyectos (no específicos para software) como PMP.

Por supuesto, no siempre es un error aplicar y estudiar este tipo de gestión de

proyectos, pero hay proyectos en los que la planificación Gantt es una buena manera de
gestionar… pero en otros no lo es.

En una planificación ágil el Gantt se sustituye por los planes de release, los ciclos de
vida iterativos y los seguimientos con técnicas como los “burndown chart” (que
veremos en el capítulo 7).

No es incompatible usar un Gantt, que acompañe a la planificación de la release aunque

en un ciclo de vida ágil, la predicción dentro de cada iteración es menor, y ello
dificulta el uso de estos diagramas.

En cualquier caso, te dejamos un recopilatorio de errores típicos al planificar un

proyecto software con Gantt, con el ánimo de que seas consciente de ellos y los evites.

5.6.1.Malas prácticas relacionadas con el uso de Gantts planificando software

El uso de diagramas Gantt no tiene porque conllevar necesariamente problemas en la

planificación y seguimiento de proyectos, aunque, en la práctica, he podido observar
numerosas malas prácticas relacionadas con el uso de diagramas de Gantt. He aquí dos
de las más frecuentes.

Barras Gantt que muestran porcentajes de avance del proyecto… asignados sin
ningún criterio.

En innumerables ocasiones he visto como los jefes de proyecto actualizan las barras
porcentuales de avance de un Gantt según el tiempo transcurrido (que no el trabajo
terminado) o sólo preguntando a la gente “cómo va el proyecto”. Y, por razones como
estas, muchos de los diagramas Gantt están al 90% de avance durante el 90% de la vida
del proyecto.

En una planificación ágil, la medida de avance es escalonada, no porcentual, y la única

medida de avance es el número de trabajo completado al finalizar una iteración.
Veremos cómo se hace este seguimiento en el capítulo 7 .

Planificar un Gantt de proyecto en función del tiempo disponible y no en función

del tamaño del software a desarrollar.

O “estimar” de adelante hacia atrás. Es decir, fijada una fecha de finalización del
proyecto, normalmente impuesta por motivos comerciales, construir un Gantt cuyas
barras y recursos encajen de cualquier forma entre la fecha actual y la de fin.

Un recurso muy usado en estos casos es tener que abusar de las tareas que,
supuestamente, se pueden hacer en paralelo. En una planificación ágil, se asume que
hay incertidumbre al comienzo del proyecto y se está abierto a ajustar la planificación.
Capítulo
6

6. El Plan de una iteración

“Sólo cuando conoces cada detalle de la condición del terreno puedes maniobrar y
guerrear.”

-- Sun Tzu

El objetivo del plan de una iteración es describir y estimar las tareas que se van a
abordar en las semanas que dura una iteración.

Las historias de usuario, los requisitos, se dividen en tareas. Las tareas ya son algo muy
concreto a realizar durante una iteración, con el objetivo de completar una o varias
historias de usuario.

A la hora de descomponer historias de usuario en tareas, se intenta que el tamaño de las

tareas sea de entre medio día hasta un máximo de 3 o 4 días de trabajo de un solo
miembro del equipo. En cualquier caso, nunca deben exceder al tiempo de una
iteración.

La Tabla 14 muestra varios ejemplos de tareas típicas en las que se podría haber
dividido una historia de usuario.

Ejemplo de tarea Descripción

Diseño de la Realizamos especialmente esta tarea para generar discusión sobre

historia de usuario cómo se va a implementar la historia de usuario.

Esta tarea puede incluir la definición de las interfaces y los

Implementación de
métodos necesarios para cubrir la necesidad expresada en la
una historia
historia. Pueden existir múltiples tareas de este tipo.
Pruebas unitarias Esta tarea debiera ser obligatoria para cada historia.
asociadas a la
historia (TDD)

Pruebas de
Tarea definida para desarrollar las pruebas de aceptación
aceptación
automáticas que facilitarán la validación de la historia por parte
asociadas a la
del cliente y/o usuario.
historia

Para cada historia, se deben tener en cuenta requisitos de

Requisitos no
seguridad, rendimiento, escalabilidad, etc. Estos atributos de
funcionales
calidad pueden dar lugar a nuevas tareas.

Revisiones de El código siempre debe haber sido revisado, convirtiéndose la

código revisión en otra tarea.

Refactorización Esta tarea se debe incluir para cada historia con el fin de evitar una
del código complejidad excesiva del código.

En el caso de que se demore en exceso la implementación de una

Emular interfaces
interfaz, éstas se deben emular con el fin de comenzar a trabajar.

Pruebas
Pruebas ad-hoc para una historia.
exploratorias

Corrección de Dependiendo de la historia, se debe reservar tiempo para la

errores resolución de errores o incidencias.

Verificación de Dependiendo de la historia, se debe reservar tiempo para verificar

errores la corrección de los errores.

Demostración interna al equipo de la historia. Esta pequeña

Demo demostración se suele realizar una vez finalizada la historia en la
reunión diaria.

Actualizar la wiki Con el diseño y los resultados de la historia.

o el repositorio de
documentos

Documentación de Generación de los manuales de usuario, instalación, etc., también

usuario puede estar ubicada en alguna tarea.
 Tabla 14. Ejemplos de tareas

6.1.Tiempo Ideal y tiempo Real

Como ya se comentó, normalmente estimamos historias de usuario en puntos historia y

tareas en horas, lo que no quita que ciertos equipos, normalmente experimentados, usen
las horas para estimar también historias de usuario.

Tiempo ideal: “¿Cuánto dura un

Los “días u horas ideales” serían los días que
partido de futbol? Idealmente 90
“idealmente” tardaría una tarea en completarse.
Le llamamos tiempo ideal porque considera que min. Pero, con faltas,
no hay interrupciones, dispones de todo lo interrupciones, tiempo añadido…
necesario para terminar tu trabajo, etc. no sabría decirte el tiempo real”

Para las primeras estimaciones e iteraciones tendremos que hacer una aproximación al
tiempo real, pero para las siguientes sería aconsejable ir tomando datos de qué ha ido
sucediendo en iteraciones previas.

Así, sería interesante registrar las horas de trabajo que cada miembro del equipo
realmente ha dedicado a la iteración. Una sencilla tabla que tenga en filas a las
personas y una columna de tiempo real dedicado nos puede ayudar a hacer previsiones
más exactas en el futuro. En la Tabla 15 se puede ver el tiempo real de trabajo.

Ideal Real

1 hora de reuniones

1 hora de email

Una jornada de 8 horas de trabajo 1 hora de teléfono

Realmente cada día quedan

5 horas para el proyecto

Tabla 15. Tiempo ideal frente a tiempo real
Capítulo
7

7. El seguimiento del proyecto

“Aceptar nuestra vulnerabilidad en lugar de tratar de ocultarla es la mejor manera
de adaptarse a la realidad.”

-- David Viscott

Los “BurnDown” son una representación del trabajo que queda por hacer y a su vez,
permiten comparar el progreso del proyecto o dela iteración, con la planificación
inicial.

Normalmente el trabajo pendiente de realizar, en puntos historia o en número de

historias de usuario, se muestra en el eje vertical, y el tiempo, en los días, semanas o
iteraciones, compone el eje horizontal.

El gráfico BurnDown proporciona información muy útil para predecir las desviaciones
y ver el avance. La Figura 14 representa un ejemplo de esa gestión. La línea verde
representa el caso más optimista de trabajo que se puede entregar en el tiempo, la línea
roja representa la pesimista. Ambos rangos deben ser conocidos por el product owner
en función de la velocidad del equipo (ver epígrafe 4.7).

Figura 14. Gestión de expectativas del proyecto

Conocer lo anterior es de vital importancia para ir gestionando en el tiempo las
expectativas que “stakeholders” y usuarios tienen del producto que se les va a ir
entregando.

Por ejemplo, imaginemos que se espera cierta funcionalidad del producto en una fecha
dada, como se representa en la Figura 15. Según todo lo anterior, el product owner
debe exponer a los usuarios el caso más optimista y el más desfavorable, para que
tengan en consideración que puede haber mayor o menor funcionalidad entregada, o que
valoren ampliar el tiempo de proyecto.

Figura 15. Gestión de expectativas en una fecha dada

Capítulo
8

8. La subcontratación del proyecto

"Customer collaboration over contract negotiation"

-- Manifiesto Ágil

A la hora de subcontratar un proyecto ágil podemos encontrar diferentes tipos de

contratos. Autores como(Cockburn, 2006), (Beamount, 2008) o (Sutherland,
2008)recopilan las diferentes variantes, si bien estas se pueden agrupar en tres: pago
por tiempo o por iteración, pago por punto historia y contrato fijo. Sólo las dos
primeras podemos considerarlas “ágiles”. Si bien estos tres grupos se mezclan muchas
veces a la hora de elaborar un contrato para subcontratar un proyecto ágil.

8.1. Pago por tiempo o por iteración

La manera más natural de formalizar un contrato para un proyecto ágil es la de pago por
tiempo de trabajo (o por número de sprint o iteraciones), también conocido como “por
servicio” o “por bolsa de horas”. En su forma más básica, el proyecto duraría hasta que
la versión final del producto software esté terminada. Y los pagos se harían
normalmente por el tiempo que ha durado el proyecto, por iteración o por número de
sprint. Si el tiempo estimado de proyecto es muy largo también se puede facturar al
finalizar cada sprint.

El problema de esta modalidad es que la mayoría del riesgo lo tiene el cliente que
subcontrata. El miedo de muchos clientes es que el proveedor podría relajarse, dando
lugar a más iteraciones de las necesarias y mayores costes.

Para ello, en este tipo de contratos se suelen introducir cláusulas que reducen el riesgo
del cliente. Lo normal es cerrar de antemano un tiempo máximo de proyecto, dando la
opción al cliente de cancelar el proyecto o renegociar una continuación. O de manera
similar, introducir hitos de chequeo cada cierto tiempo. Por ejemplo, en un proyecto se
podría determinar que cada cuatro meses el cliente podrá decidir si continúa o cancela
el proyecto.

8.2. Pago por punto historia

Este es uno de los esquemas más recomendados. En algunos sectores del desarrollo
software, como por ejemplo la banca, se ha introducido con fuerza un modelo en el que
el proveedor factura por la cantidad de funcionalidad desarrollada. Y para cuantificar
la funcionalidad entregada se mide con diferentes técnicas, como por ejemplo, la
técnica de puntos función para medir el tamaño de la funcionalidad. Cabe destacar que
el cliente paga por puntos función entregados, no por los que se estimaron, por lo que
suele ser un esquema bastante eficiente para ambas partes. Asimismo se puede replicar
este modelo cambiando puntos función por puntos de historia de usuario o similar.

El cliente estima los puntos historia, los revisa con el proveedor y se factura en función
de puntos historia entregados.

8.3. El contrato cerrado

El contrato cerrado, también conocido como “llave en mano”, consiste, básicamente, en

que el cliente redacta, siempre antes de comenzar el proyecto, un documento llamado
“pliego de condiciones” que, principalmente, contiene los requisitos que debe
implementar el software, o el sistema de información.

Redactado el “pliego de condiciones”, con sus requisitos, este se expone a las

empresas candidatas a llevarse el proyecto, las cuales, tomando como base esos
requisitos, dicen al cliente por cuánto dinero están dispuestas a hacer el proyecto y en
cuánto tiempo.

Por último, el cliente selecciona una empresa de desarrollo, normalmente basándose en

la que menor precio oferta y menor tiempo dice y, normalmente, añade al contrato las
llamadas penalizaciones: si la empresa se retrasa en tiempo se le paga menos, y a más
retraso menos se le paga.
8.3.1.El contrato cerrado y los proyectos ágiles

El cliente, redacta unos requisitos en un momento, tan temprano, que muchas veces
escribe sólo ideas poco concretas e incompletas de lo que se supone necesita que haga
el software, y que normalmente, cuando avanza el proyecto, difieren de lo que
realmente necesitaba, lo cual acaba sabiendo cuando recibe la primera entrega.

Esto sucede porque muchas veces hasta que no se ve un primer prototipo no se sabe
bien lo que se necesita, o sucede porque se toman mal los requisitos, o sencillamente
porque las necesidades cambian con el tiempo y lo que se creía necesario hoy mañana
puede no serlo.

El proveedor, en base a esos requisitos (como dijimos, la mayoría de las veces poco
concretos, o que difieren de lo que realmente se necesitará) hace una estimación del
tiempo de desarrollo.

Bajo estas premisas, el objetivo del proveedor, será terminar en plazo… como sea,
para evitar la penalización típica que llevan estos contratos por retrasos. Al proveedor
le preocupa entregar sólo lo que dicen los requisitos del pliego y no entregar un
software que cumpla las necesidades de los usuarios (que no siempre es lo mismo).

Si a lo largo del proyecto alguien piensa (el cliente, por ejemplo) que han cambiado, o
eran erróneos, etc., da igual. Esos requisitos están firmados y hay penalización por
incumplimiento. No hay cambio de requisitos.

El software se entregará en fechas a toda costa (suele haber penalización por retraso).
Lo cual suele ser en detrimento de dejar tiempo para calidad software, metodologías,
prototipos con usuarios, etc.

Normalmente, este tipo de contrato persiste por el temor del cliente a caer en manos del
proveedor, y este pudiera alargar y alargar, meses y meses, el desarrollo software (y
con ello el presupuesto).
Capítulo
9

9. Consejos finales para el superviviente

Conociendo y aplicando todo lo anterior, es más que seguro que podrás sobrevivir a la
planificación de un proyecto ágil. Además, la práctica con cada uno de los anteriores
consejos y técnicas te llevará con el tiempo a una supervivencia cada vez más cómoda.

No obstante, permíteme sólo unas páginas finales para trasmitirte algunos últimos
consejos que todo buen superviviente a un proyecto software acaba teniendo claro con
el tiempo…

9.1. Consejo 1: no estimes sólo el desarrollo software

Recuerda que, en un proyecto no sólo hay desarrollo software, también hay

proveedores de hardware, diseñadores gráficos, entornos de producción, etc.

Y no olvides otras tareas comunes, como vacaciones, reuniones, informes, etc.

9.2. Consejo 2: encuentra tu propio método de estimación

Recuerda que, aún utilizando el mismo método para calcular los puntos historia, dos
empresas - equipos pueden obtener estimaciones diferentes… ¿por qué? Porque una,
por ejemplo, puede desarrollar en una tecnología, y la otra empresa en otra, una puede
tener personal más cualificado, otra utilizar una arquitectura diferente, etc.

Por ello, no olvides que el punto historia hay que ajustarlo a la realidad de la empresa
y a los requerimientos tecnológicos concretos de cada proyecto.
9.3. Consejo 3: Estima usando rangos

Recuerda que, los métodos tienen siempre un error y nunca son exactos. Es decir, que
ningún método de estimación nos dirá cosas del tipo “el proyecto terminará el día
miércoles 12 de noviembre a las 12:33”. Eso es imposible en proyectos medianos o
grandes.

Por ello, cuando trabajamos con métodos de estimación el resultado debe ser rangos
del tipo “el proyecto terminará la primera quincena de noviembre”, “la última semana
de noviembre”, etc.

El rango temporal depende de la exactitud de nuestro método, del momento en el que

estimo (la exactitud no es la misma el primer día de proyecto que el penúltimo mes) y
de la magnitud del proyecto (proyectos mayores implican rangos mayores, p.e. semanas
vs. quincenas).

9.4. Consejo 4: Siempre acompáñate de la estimación por analogía

Recuerda que, la experiencia y el conocimiento es tesoro más valioso que irás

adquiriendo con el tiempo. Así que… guárdalo.

La analogía se basa en que guardes decisiones de otros proyectos, cómo estimaste,

cuánto estimaste, cómo definiste las iteraciones, que guardes cómo te fue al final de
proyecto, y que utilices ese conocimiento para futuras planificaciones.
ANEXO I.Scrum

Scrum es una metodología ágil para la gestión de proyectos; por lo que queda fuera de
su ámbito el tratamiento explicito de, por ejemplo, el testing, el control de versiones, el
diseño, arquitectura, etc. Su principal objetivo es obtener resultados (normalmente
prototipos) pronto y adaptarse a los cambios (normalmente, los cambios en los
requisitos). Por otro lado, es un “framework”, por lo que es necesaria su adaptación en
cada organización, o incluso a cada equipo (Sutherland & Schwaber, 2011).

De manera sintetizada, los pilares de Scrum son, principalmente, dos: el ciclo de vida
iterativo e incremental (en iteraciones cortas) y diversas reuniones a lo largo del
proyecto.

Ciclo de vida iterativo e incremental. Los Sprints

Una de las bases de las metodologías ágiles es el ciclo de vida iterativo e incremental.
El ciclo de vida iterativo e incremental es aquel en que se va liberando el producto por
partes, periódicamente, iterativamente, poco a poco, y además cada entrega es un
incremento de funcionalidad respecto a la anterior. Esto difiere del ciclo de vida en
cascada, en el que las fases del ciclo de vida (requisitos, análisis, diseño, etc.) se
realizan (en teoría) una única vez, y el inicio de una fase no comienza hasta que termina
la fase que le precede.

En Scrum a cada iteración se le llama sprint. Un sprint es un periodo de corta duración

(entre 2 y 4 semanas, el equipo decide) que debe finalizar con un prototipo operativo.
Lo que se va a implementar en el sprint, la funcionalidad del prototipo, proviene del
Product Backlog, que contiene requisitos funcionales o historias de usuario

En Scrum, la figura del product owner, que vendría a ser el usuario o el cliente, es el
responsable de gestionar el product backlog y de crear las historias de usuario.

Una vez seleccionadas las historias de usuario que se van a desarrollar en el sprint, el
equipo técnico las descompone en tareas, las cuales forman el Sprint Backlog, que será
inamovible durante el sprint.

Las Reuniones
El segundo pilar más importante de Scrum son las reuniones. Su importancia reside en
que las reuniones son la base para lograr transparencia y comunicación, y posibilitan
algo característico en un equipo ágil: que sea auto-gestionado y multifuncional. Las
reuniones se realizan a lo largo de todo el proyecto, según las siguientes tipologías:

- Reunión de Planificación del sprint (Sprint Planning Meeting). Al principio de

cada sprint, para decidir que se va a realizar en ese sprint.

- Reunión diaria (Daily Scrum). Máximo 15 minutos, en la que se trata qué se hizo
ayer, que se va a hacer hoy y que problemas se han encontrado.

- Reunión de Revisión del sprint (Sprint Review Meeting). Al final de cada sprint, y
se trata qué se ha completado y qué no. También se muestra el trabajo al Product
Owner.

- Retrospectiva del sprint (Sprint Retrospective). También al final del sprint, y sirve
para que los implicados den sus impresiones sobre el sprint, y se utiliza para la mejora
del proceso.

Consideraciones importantes y cosas que deberías tener muy claras

- Cada proyecto, empresa, producto, línea de negocio, etc., requiere una

adaptación de Scrum a su caso. Scrum es un marco de trabajo, o meta-metodología,
por lo que tiene que adaptarse.

- Scrum, aunque nace en el mundo del desarrollo software, es una metodología lo

suficientemente genérica como para poder aplicarse a la gestión de otro tipo de
proyectos. De ahí que se esté extendiendo su uso a otros ámbitos.

- Normalmente Scrum no se utiliza sola, ya que no cubre todo lo que se necesita

para abordar un proyecto software. En software es muy típico acompañar Scrum con
la metodología XP, que aporta cuestiones más cercanas a la programación, y con
Kanban, que ayuda mucho en la gestión de las tareas en las que se descomponen las
historias de usuario.

- Scrum no es la única metodología ágil que existe. No es la solución a todos los

males. Hay empresas en las que, por su negocio, no encaja bien Scrum. Y en lograr, si
aplica, su implantación está la clave del éxito y lo que supone un verdadero esfuerzo.
ANEXO II. FDD

Aunque aquí hablamos de la “metodología FDD”, siendo rigurosos, al igual que sucede
en Scrum, FDD es, concretamente, un “framework” o una meta-metodología, es decir,
que necesita ser adaptado al caso concreto.

El padre de la metodología es Jeff De Luca. El libro que mejor describe la metodología

es el “A Practical Guide to Feature-Driven Development” (Palmer & Felsing, 2002) y
la web de referencia es la del creador(De Luca, 2012).

Los procesos de la metodología ágil FDD

FDD es una metodología dirigida por modelos, y de iteraciones cortas.

FDD define 5 procesos:

Proceso 1 – Desarrollar el modelo global (Developover all model).

Proceso 2 – Construir una lista de características (Build feature list).
Proceso 3 – Planificar (Plan by feature).
Proceso 4 – Diseñar (Design by feature).
Proceso 5 – Construir (Build by feature).

Los 3 primeros pueden considerarse la “iteración o sprint cero”, aunque en FDD no le

llaman así, y los consideran “procesos iniciales”.

En la práctica los equipos de desarrollo necesitan un tiempo previo para arrancar,

montar entornos, planificar, e incluso hacer un estudio previo de la arquitectura. Esto
normalmente se suele hacer en lo que comúnmente se llama iteración cero (o sprint
cero para quienes siguen Scrum). Pero, por ejemplo, en Scrum no se dice mucho de esta
iteración cero, sin embargo FDD la detalla mucho más.

Los dos primeros procesos son secuenciales y definen el modelo global. Los tres
finales se iteran para cada “feature” (que vienen a ser los requisitos).

Proceso 1: Desarrollar el modelo global (Developover all model)

Una de las cosas más polémicas de los proyectos ágiles es cómo y cuándo se crea el
diseño y la arquitectura. En el mundo ágil, hay incluso quienes, erróneamente, asocian
la palabra diseño con el ciclo de vida en cascada, tan denostado por el agilísimo
extremo.

En la metodología ágil FDD si se recomienda, y deja claro, que hay que tener un diseño
previo. No un diseño documentado y detallado al máximo, pero si un borrador de la
arquitectura. Y que además éste se construya de manera iterativa. El diseño es más en
anchura que en profundidad. La profundidad (los detalles) van saliendo iterativamente
a lo largo del proyecto. El diseño es un artefacto vivo.

A diferencia de otras metodologías como Scrum, la metodología ágil FDD contempla

una fase de diseño y el rol del “Chief Architect”, o diseñador experimentado. También
recomienda el uso de UML (el lenguaje unificado) en colores, la metodología de
modelado de Coad(Coad et al., 1999).

Proceso 2: Construir una lista de características (Build feature list)

En la metodología ágil FDD a los requisitos se les llama “features”. FDD define una
feature como una pequeña función orientada al cliente. Por pequeño se entiende que
suele durar de 1 a 3 días de desarrollo.

FDD organiza sus “features” en una jerarquía de tres niveles. Proyectos o equipos más
grandes agradecen esta jerarquía. Jerarquizar los requisitos ayuda a manejar un mayor
número de requisitos.

“Lead developers” (desarrolladores líder) o “chief programmer” (programadores Jefe)

organizan la lista de “features” con los conocimientos adquiridos durante el modelado
(FDD utiliza los términos “lead developers” y “chief programmer”).

Proceso 3: Planificar (Plan by feature)

Tercer y último proceso de los que conformarían la “iteración cero”. Su objetivo, crear
una planificación inicial y asignar responsabilidades.

La metodología ágil FDD también se aleja de conceptos muy arraigados en el mundo

ágil, como el de la propiedad colectiva del código. En lugar de que “todo el código sea
de todo el mundo”, en FDD se asignan como responsables de partes del código a
desarrolladores concretos. Esta asignación de responsables tiene lugar durante el
proceso de planificación. Y ojo, que en FDD hablamos de responsabilidad del código
no de exclusividad. Esto es otra muestra más de cómo FDD está pensada para
proyectos grandes.

Proceso 4: Diseñar (Design by feature)

En esta parte se realiza un diseño para cada feature. El programador responsable (chief
programmer) elige un grupo de features a desarrollar durante las próximas dos
semanas.

En la metodología ágil FDD se realizan diagramas de secuencia para cada feature, y se

refina el diseño o modelo global.

Proceso 5: Construir (Build by feature)

Después de una inspección diseño exitosa, los propietarios de cada clase, o partes del
código, desarrollan el software.

La metodología ágil FDD contempla el uso de las pruebas unitarias e inspecciones de

código, tras las cuales la feature se sube a la línea principal de desarrollo.

Para acabar, la metodología ágil FDD podríamos considerarla orientada a equipos más
grandes, con más personas que aquellos a los que normalmente se aplican otras
metodologías ágiles como Scrum. La metodología ágil FDD contempla la figura del
jefe de proyecto y una fase de arquitectura.

Scrum y XP suelen usarse, y recomendarse, para equipos pequeños y auto-organizados

y en estas metodologías no queda tan claro la fase de diseño.
Referencias

Ambler, S. (2008). Acceleration: An agile productivity measure. Fecha de

consulta: 17 mayo 2012. Disponible en:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/metri
lang=en

Beamount, S. (2008). Agile & contracts. scrum gathering stockholm. Disponible

en: http://www.scrumalliance.org/resources/442

Beck, K., & Andres, C. (2004). Extreme programming explained: Embrace

change Addison-Wesley Professional.

Coad, P., De Luca, J., & Lefebvre, E. (1999). Java modeling in color with UML:
Enterprise components and process

Cockburn, A. (2006). Agile contracts. Fecha de consulta: 17 mayo 2012.

Disponible en: http://alistair.cockburn.us/Agile+contracts/v/multi

Cohn, M. (2005). Agile estimating and planning. Upper Saddle River, NJ, USA.
Prentice Hall PTR.

Construx Software Builders. (2013). 2013. Disponible en:

http://www.construx.com/Page.aspx?cid=1653

De Luca, J. (2012). Jeff de Luca's website. 2013. Disponible en:

http://www.nebulon.com/

Haugen, N. C. (2006). An empirical study of using planning poker for user story
estimation. Artículo presentado en Agile Conference, 2006, pp. 9.

Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases
through build, test, and deployment automation Addison-Wesley.

Jeffries, R. (2001). Essential XP: Card, conversation, confirmation. Fecha de

consulta: 17 mayo 2012. Disponible en:
http://xprogramming.com/articles/expcardconversationconfirmation/

Kniberg, H. (2012). Agile product ownership in a nutshell. 2013. Disponible en:

http://www.youtube.com/watch?v=502ILHjX9EE

Kniberg, H., & Skarin, M. (2010). Kanban and scrum - making the most of both
Lulu Enterprises Inc.

Little, T. (2006). Schedule estimation and uncertainty surrounding the cone of

uncertainty. IEEE Software, 23(3), 48-54.

McConnell, S. (2007). Classic mistakes update. 2013. Disponible en:

http://www.construx.com/10x_Software_Development/Classic_Mistakes_Updated/

McConnell, S. (2006). Software estimation: Demystifying the black art.

Redmond, WA, USA. Microsoft Press.

Miranda, E. (2001). Improving subjective estimates using paired comparisons.

IEEE Software, 18(1), 87-91.

Palmer, S., & Felsing, J. (2002). A practical guide to feature driven development.
A Practical Guide to Feature Driven Development,

Patton, J. (2008). User story mapping. 2013. Disponible en:

http://www.agileproductdesign.com/presentations/user_story_mapping/index.html

Pichler, R. (2012). Working with an agile product roadmap. 2013. Disponible en:
http://www.romanpichler.com/blog/product-planning/agile-product-roadmap/

Poppendieck, M., & Poppendieck, T. (2006). Implementing lean software

development: From concept to cash Addison-Wesley Professional.

Quora. (2013). Continuous deployment at quora. 2013. Disponible en:

http://engineering.quora.com/Continuous-Deployment-at-Quora

Schawber, K. (2008). Sprint zero. 2013. Disponible en:

http://tech.groups.yahoo.com/group/scrumdevelopment/message/32488

Sutherland, J. (2008). Money for nothing and your change for free. agile 2008
presentation. Fecha de consulta: 17 mayo 2012. Disponible en:
http://jeffsutherland.com/Agile2008MoneyforNothing.pdf

Sutherland, J., & Schwaber, K. (2011). The scrum papers: Nut, bolts, and origins
of an agile framework. Fecha de consulta: 17 mayo 2012. Disponible en:
http://jeffsutherland.com/ScrumPapers.pdf

Treadway, M. (2011). throw new NerdOverflowException();. 2013. Disponible

en: http://the-tread-way.blogspot.com.es/2011/04/how-many-hours-are-in-story-
point.html
1. Durante el texto se hará uso de las palabras “roadmap” y “release” en inglés, por
ser de uso más común que los equivalentes en castellano.

2. En el texto utilizaremos las palabras en inglés, product owner, por ser de mayor
uso en castellano.

3. Para este ejercicio, puedes pensar en la serie “The Big Bang Theory” o cualquier
otra. Aunque si no conocías esta serie aprovecho para recomendártela.
 Table of Contents
1. Hoja de ruta del superviviente a una planificación software usando técnicas ágiles
2. El Roadmap de un proyecto ágil
2.1. Los temas
2.2.¿Cuánto tiempo debe transcurrir entre releases?
2.3.“Continuous delivery” y “DevOps”
2.3.Estimación con T-SHIRT
3. "Product owner” y las historias de usuario
3.1.Los tipos de Product Owner
3.1.1.Cuando el cliente es el product owner
3.1.2.Cuando un representante del cliente toma el rol
3.1.3.El product owner y el product manager
3.2.Responsabilidades de un product owner
3.3.Historias de usuario
3.3.1.Creando buenas historias de usuario
3.3.2.El valor de una historia de usuario
3.4.Técnicas para priorizar y dar valor a las historias de usuario
3.4.1.Modelo Kano
3.4.2.Técnica MoSCoW
3.5.El product backlog y los mapas de historias
3.5.1.Relación entre el Roadmap y el Product Backlog
4. Estimando un proyecto ágil
4.1.La definición de los requisitos afecta a la estimación
4.1.1.Definir las historias de usuario sólo al comienzo de cada iteración
4.1.2.Detallar primero todos los requisitos y luego iterar
4.2.Los puntos historia
4.3.La escala de puntos historia
4.4.La Técnica de estimación “Planning Poker”
4.5.¿Puntos historia o estimación en horas?
4.6.¿A cuántas horas equivale un punto historia?
4.7.Refinando la estimación con la Velocidad del equipo
5. Planificando las iteraciones
5.1.Ciclo de vida ágil: iterativo, incremental y de iteraciones cortas
5.2.Cuánto tiempo debe durar una iteración
5.3.Deberían las iteraciones durar el mismo tiempo?
5.4.El “Sprint cero”
5.5.El “Sprint de release”
5.6.¿Y mis Diagramas Gantt? ¿volveré a utilizarlos?
5.6.1.Malas prácticas relacionadas con el uso de Gantts planificando
 software
6. El Plan de una iteración
6.1.Tiempo Ideal y tiempo Real
7. El seguimiento del proyecto
8. La subcontratación del proyecto
8.1. Pago por tiempo o por iteración
8.2. Pago por punto historia
8.3. El contrato cerrado
8.3.1.El contrato cerrado y los proyectos ágiles
9. Consejos finales para el superviviente
9.1. Consejo 1: no estimes sólo el desarrollo software
9.2. Consejo 2: encuentra tu propio método de estimación
9.3. Consejo 3: Estima usando rangos
9.4. Consejo 4: Siempre acompáñate de la estimación por analogía
ANEXO I.Scrum
ANEXO II. FDD
Referencias