1 www.rallydev.

com 2013 Rally Software Development

5 Niveles de Planicacin gil:
Desde la Visin Corporativa del
Producto hasta el Stand-up del Equipo
White Paper
Este documento evala las prcticas giles aplicadas en proyectos
multiequipos y proyectos con una duracin de mas de un ao. Esto
se hace a travs de la inspeccin de los requerimientos impuestos al
escalar proyectos y como se aplican los principios giles bsicos a
estos requerimientos. En la introduccin se presentn los principios
giles ms importantes, as como tambin los principios Lean
sobre los cuales los mtodos giles son basados. Uno de estos
principios Lean, denominado Muri o sobrecarga de personas, es
tratado a travs de la extensin del proceso de planifcacin gil. La
extensin de la tcnica de planifcacin gil ms usada (planifcacin
de iteraciones) es descrita en detalle, tanto la motivacin para la
extensin asi como las prcticas de colaboracin por de cada uno
de los niveles de planifcacin. El ltimo captulo evala el impacto
de la complejidad del producto sobre el proceso de planifcacin y
presentamos una solucin para crear un fujo regular a lo largo del
ciclo de planifcacin/entrega.
2 www.rallydev.com 2013 Rally Software Development
ndice de Contenido
5 NIVELES DE PLANIFICACIN GIL: DESDE LA VISIN CORPORATIVA DEL PRODUCTO
HASTA EL STAND-UP DEL EQUIPO ..........................................................................................1
NDICE DE CONTENIDO .............................................................................................................2
INTRODUCCIN .........................................................................................................................3
POR QU ENFOCAR LA PLANIFICACIN DE LAS ACTIVIDADES? ............................................................ 3
GIL Y LEAN ..................................................................................................................................................... 3
VOCABULARIO DEL GIL ................................................................................................................................ 3
LOS ELEMENTOS FUNDAMENTALES DEL LEAN MURI, MURA Y MUDA ................................................. 4
PLANIFICANDO PROYECTOS GILES DE GRAN ESCALA .....................................................5
VISIN DEL PRODUCTO - NIVEL 1 ................................................................................................................. 6
ROADMAP DEL PRODUCTO NIVEL 2 .......................................................................................................... 7
PLANIFICACIN DEL RELEASE NIVEL 3 ..................................................................................................... 8
PLANIFICACIN DE LA ITERACIN NIVEL 4 ............................................................................................. 10
PLANO DIARIO NIVEL 5 .............................................................................................................................. 11
CONCLUSIN ...........................................................................................................................12
REGULARIDAD EN EL PROCESO DE PLANIFICACIN .........................................................13
CONCLUSIN ...........................................................................................................................14
REFERENCIAS ..........................................................................................................................15
3 www.rallydev.com 2013 Rally Software Development
Introduccin
Por qu el enfoque en la Planifcacin de Actividades?
La experiencia obtenida durante una implementacin de gran envergadura de conceptos
giles en proyectos de desarrollo de software nos ensea que los actuales y populares
mtodos giles de desarrollo de software (como Scrum) no pueden ser escalados para
los niveles de programa, producto y organizacin al menos que sean modifcados. Los
fundamentos para los cambios en estos mtodos son encontrados en los principios Lean,
o: el futuro de los mtodos giles se encuentra en sus orgenes. Este documento describe
una estructura de planifcacin que ha sido usada con xito en proyectos giles de gran
envergadura
1
y examina el impacto de la introduccin de esta estructura de planifcacin en
tres principios fundamentales Lean: Muri, Mura y Muda.
gil y Lean
Los orgenes del Scrum son encontrados en los escritos de Takeuchi y Nonaka
ii
y fueron
desenvueltos como metodologa por Schwaber, Beedle y Sutherland
iii,iv
. En 2003, los
principios de desarrollo gil de software fueron vinculados a los principios Lean, cuyo
concepto fue explorado ms a fondo por Sutherland, Viktorov y Blount
vi
. Este raciocinio ha
sido ampliamente desenvuelto en un proceso que agrega prcticas a la estructura Scrum
para cubrir las complejidades que surgen cuando esta estructura es aplicada a programas
de desarrollo de software involucrando diversos equipos y/o mltiples proyectos
2
. Este
documento se basa en estas publicaciones y en la experiencia del autor en las diversas
implementaciones de prcticas giles en proyectos y programas de gran envergadura.
Vocabulario del Agil
Este documento hace uso intenso del lxico Agil. Algunos de los trminos ms usados son:
Mtodos giles El grupo de mtodos livianos de desarrollo de software que fueron
creados con base al Manifesto Agil
3
. Ejemplos: Extreme Programming (XP), Scrum y
Feature Driven Development.
Product Owner La persona responsable por el xito del producto y, por lo tanto,
califcado para priorizar las funcionalidades requeridas por el producto.
Equipo de Entrega El grupo de personas responsable por la entrega de los elementos
que en conjunto componen el producto. Son responsables de entregar la calidad
adecuada y pueden, por lo tanto, determinar y estimar las tareas involucradas para la
entrega de las funcionalidades requeridas por los productos.
Muri, Mura, Muda o Load, Flow, Waste Tres principios primordiales Lean que describen
la necesidad de planifcar la (carga) de trabajo correctamente, crear un ritmo (fujo de
4 www.rallydev.com 2013 Rally Software Development
trabajo) regular en el equipo y evitar la entrega de productos que no tienen ningn valor
(desperdicio) para el cliente.
Backlog del Producto Una lista de funcionalidades, cada una con una nivel de prioirida,
que componen el producto de acuerdo con los objetivos del Product Owner.
Iteracin Un perodo de una a seis semanas en el cual el equipo de entrega produce
funcionalidades operacionales (aceptadas) de los productos. Tambin conocido como
Sprint en la metodologa Scrum.
Funcionalidad Un componente del producto que el Product Owner y el cliente
reconocen y valoran. La entrega de una funcionalidad se hace por medio de tareas, que
son las actividades ms tcnicas reconocidas y valoradas por el equipo de entrega. La
estimacin del trabajo involucrado en la entrega de las funcionalidades y tareas es hecha
por el equipo de entrega, lo que representa una diferencia importante con relacin al
desarrollo basado en planes, en el cual las tareas de estimacin son responsabilidad de
un gerente del proyecto.
Los Elementos Fundamentales del Lean Muri, Mura y Muda
Los tres principios Lean utilizados para defnir mtodos giles de desarrollo de software
tienen sus orgenes en los conceptos Muri, Mura y Muda:
Muri Sobrecarga de personas o equipos
Mura Irregularidad en la carga de trabajo
Muda Desperdicio o actividades que no agregan valor
Existe una relacin entre los tres principios: Mura crea Muri lo cual crea establece la
incapacidad para reducir Muda
4
. O sea: el desperdicio puede ser reducido solucionando los
problemas de desequilibrio de carga y de sobrecarga del personal
vII
:
Todos los mtodos giles reducen rigurosamente los mtodos
ya existentes de desarrollo de software a estructuras que son
ms bien descritas como apenas sufcientes. Cuando estas
estructuras apenas sufcientes son combinadas con disciplina
y prcticas rigurosas de inspeccin y adaptacin, se crean
metodologas robustas que propician la entrega ms rpida de
software operativo.
Los mtodos giles ya existentes se enfocan en proyectos
pequeos (un solo equipo, duracin de pocos meses), y el impacto de los proyectos
grandes (multiequipos, plurianuales) en prcticas giles no son contemplados con los
1
Los proyectos denominados grandes normalmente duran bien ms que un ao, y tienen 50 o ms personas involucradas para
entregar la funcionalidad exigida.
2
Sutherland, Tabaka & Smits Program Management with Scrum Curso de dos das para ScrumMasters 2006
3
http://www.agilemanifesto.org/
4
Womack: http://www.leanuk.org/articles/mura_muri_muda.pdf
Muri
Mura
Muda
5 www.rallydev.com 2013 Rally Software Development
mtodos giles. Este documento analiza los requisitos para el proceso de planifcacin gil y
su vnculo con la sobrecarga de individuos y equipos (muri).
Planifcando Proyectos Agiles de Gran Escala
En mtodos giles, la asignacin de la carga de trabajo de un equipo es hecha a travs
de la planifcacin de las iteraciones. Debido a la brevedad de la iteracin (normalmente
dura de una a seis semanas) el plan tiene poca importancia y la planifcacin tiene mucha
importancia. En caso de proyectos pequeos, puede ser sufciente planifcar una sola
iteracin a la vez. La experiencia obtenida en la planifcacin de iteraciones cuando se aplica
a proyectos que requieres un nmero alto de iteraciones y/o que utilizan un sin nmero de
equipos, es que la visin a largo plazo de estas iteraciones se puede perder, lo cual es una
desventaja. En otras palabras: se pierde la visin del todo. Una solucin es agregar niveles
de planifcacin para incluir la visin del todo. En las metodologas basadas en planes y
en cascada, este problema se supera a travs de una considerable fase inicial de diseo,
teniendo por objetivo prever con precisin cuanto trabajo es necesario en cada una de
sus tareas. Esto conlleva a una gran inversin inicial en el proyecto, a tal punto que no se
puede tener certeza que la funcionalidad proyectada es, de hecho, la funcionalidad deseada
por el Product Owner. Un abordaje con niveles diferentes de planifcacin debe evitar la
reintroduccin de una nueva considerable fase de diseno.
Las actividades de planifcacin para proyectos de desarrollo de gran escala deben basarse
en cinco niveles:
Visin del Producto
Roadmap del Producto
Planifcacin del Release
Planifcacin del Sprint
Compromiso Diario
La certeza de la realizar las actividades defnidas en cada uno de los cinco niveles aumenta
y, por lo tanto, la cantidad de los detalles abordados (dinero invertido), el nmero de
personas involucradas y la frecuencia pueden aumentar sin que se corra el riesgo de gastar
dinero en funcionalidades que van a hacer creadas, o ser creadas de una forma diferente.
Cada uno de los cinco niveles se enfoca en los principios fundamentales de la planifcacin:
prioridades, estimados y compromisos.
6 www.rallydev.com 2013 Rally Software Development
Visin del Producto - Nivel 1
La fgura ms amplia que una persona puede dibujar del futuro es la visin de un Product
Owner. En esta visin, l explica la forma como una organizacin o un producto deben
verse. l indica que partes del sistema requieren ser alteradas (prioridad) y que esfuerzo se
requiere para alcanzar sta meta (estimados y compromisos).
Visin del Producto Cmo obternerla
Un ejercicio para poder tener una visin del producto deseado es la elaboracin de
un elevator statement
vIII
(un resumen muy muy corto de los objetivos) o un vision box
(especie visin embalada o empaquetada) del producto. El objetivo de este ejercicio es
crear un descripcin de las funcionalidades deseadas en el producto, de los clientes
objetivos y las principales diferenciales con relacin a otros productos o productos de la
competencia. Geoffrey Moore usa el siguiente formato en su elevator statement: Para
que (cliente objetivo) que requiere(descripcin del requerimiento) el (nombre del producto)
es un (categora del producto) que (principal benefcio del producto, motivo atrayente
para comprar). A diferencia de (alternativa primaria de la competencia), nuestro producto
(descripcin de la diferenciacin primaria). La visin del producto describe un estado
deseado que se proyecta 12 meses o ms hacia el futuro. Las dems actividades de
planifcacin (diseo) irn a detallar la visin, pero pueden desviarse de ella, ya que el futuro
nos traer una perspectiva diferente acerca del mercado, del producto y de los esfuerzos
requeridos para hacer la visin realidad.
anualmente por el product owner
dos vezes por ao por el product owner
trimestralmente por el product owner y los equipos
diariamente por los individuos
dos vezes por semana por los equipos
plan
diario
plan de la
iteracin
plan del release
roadmap
del producto
visin del producto
7 www.rallydev.com 2013 Rally Software Development
Roadmap del Producto Nivel 2
La era de los proyectos de gran envergadura que entregaban resultados a lo largo de
los aos desapareci. Los clientes exigen cambios con mayor frecuencia y los plazos de
entrega time-to-market se miden en semanas o meses. La mayor frecuencia y plazos ms
cortos fuerzan al Product Owner a pensar en etapas, en un camino en direccin al producto
fnal. De la misma manera como se planifca un viaje y se comparte con los otros viajantes,
un roadmap de producto es creado y transmitido a las personas que contribuyen con su
entrega. Las metas para hacerlo demandan que el Product Owner:
Transmita informaciones sobre el todo
Determine e informe para cuando los releases son requeridos
Determine que funcionalidad es sufciente para cada release
Se concentre en el valor que le produce al negocio cada uno de los releases
El equipo de entrega, a su vez, deber:
Ver el todo
Conocer las etapas necesarias para obetner la visin
Conocer las prioridades del negocio
Aportar conocimiento tcnico para el roadmap
Suministrar estimaciones para las funcionalidades proyectadas
Roadmap del Producto Cmo logralo
La creacin del roadmap es en gran parte motivada/conducida por el Product Owner (o
por el equipo del Product Owner). Esta fase del programa no tiene mucho impacto de las
restricciones tecnolgicas. En una reunin, o serie de reuniones, el roadmap ser diseado
por el Product Owner. Este proceso puede ser tan simple como una representacin grfca
de los releases, o ms formal, a travs de un documento que defne fechas, contenidos y
objetivos de los releases previstos.
Backlogs del Producto
Para prepararnos para la prxima fase de la planifcacin (planifcacin del release), se debe
crear una lista de las funcionalidades deseadas - el backlog del producto. En su forma
ms simple, este backlog es una planilla de requisitos del producto descrita brevemente
de forma que un equipo de entrega pueda suministrar estimados para la realizacin de
cada funcionalidad. Lo ms importante es que la lista tiene que contener prioiridades. El
xito de un proyecto gil depende de la entrega rpida de las funcionalidades con mayor
prioridad. Como el xito de un proyecto es medido en trminos de negocios, la priorizacin
8 www.rallydev.com 2013 Rally Software Development
de la lista de funcionalidades es responsabilidad de la empresa, o sea, del Product Owner.
La interaccin con los equipos de entrega es obligatoria. Sin una discusin acerca de las
funcionalidades, el equipo de entrega tendr difcultades para producir estimados con una
imprecisin aceptable. Las caractersticas de un backlog de producto son:
Un nico backlog de producto para todos los equipos (ver el todo)
Funcionalidades de tamao grande a muy grande (que requieran hasta 20 das
hombre(persona) para entregar una funcionalidad)
Funcionalidad con prioridades defnida de acuerdo a las prioridades del negocio
(descubiertas a travs de estudio de mercado)
Funcionalidades tecnolgicas (a veces denominadas features no funcionales, tareas
requeridas para que el producto funcione en el modo deseado, por ejemplo, la
implementacin de un determinado DBMS para garantizar determinado desempeo del
sistema) son limitadas a las que tienen un impacto directo sobre el xito del producto en
el mercado.
Planifcacin del Release Nivel 3
En pequeos proyectos (equipo nico que entrega producto en incrementos y en pocas
iteraciones) el backlog del producto por s mismo puede proporcionar una visin general
del proyecto. El tamao, la duracin y las entregas son fcilmente reconocidas. No hay
necesidad de sincronizar o agrupar entregas y/o equipos. Esto cambia cuando se aplican
conceptos giles a programas en los cuales habr dependencias entre equipos y entre
proyectos. Algunos de los equipos podrn estar operando de acuerdo a diferentes principios
giles o operando en estilo cascada (waterfall). El primer momento para iniciar la agrupacin
de las actividades y asignarlas a los equipos ocurre durante la planifcacin del release.
Un release es lo que el propio nombre implica: un conjunto de funcionalidad que se entrega
en incrementos al cliente (interno). Algunas caractersticas de un release son:
Releases son defnidos por fecha, tema y conjunto de funcionalidad. Las fechas del
release pueden ser asociadas a eventos, como conferencias o cambios en el sistema
jurdico.
El alcance y no la fecha o la calidad es la variable clave, lo que destaca la necesidad de
usar un backlog de producto con prioridades como base para un evento de planifcacin.
Cuando una fecha del release es inalterable, un aumento en el presupuesto es
improbable y normalmente to tine un efecto positivo en un release, el alcance es la nica
variable que puede ser decisiva para la fecha de lanzamiento.
Todos los equipos que trabajan en diferentes iteraciones necesitan operar al mismo ritmo.
Cuando todos los equipos trabajan al mismo ritmo, el descubrimiento y la gestin de las
dependencias ocurren automticamente durante las actividades de planifcacin.
9 www.rallydev.com 2013 Rally Software Development
Hay fechas de release fjas entre todos los equipos del programa: un intervalo normal
sera de dos a cuatro meses.
Caractersticas del Release vs. Iteracin
Un release es defnido al nivel del sistema o del programa, normalmente de acuerdo a la
terminologa del Product Owner. El tema, su fecha de lanzamiento y sus funcionalidades
con prioridades en conjunto forman un release; todos estos conceptos son defnidos por el
Product Owner. Cuando los releases son vistos desde la perspectiva del roadmap, la alta
visibilidad y confanza se manifestan en el corto plazo (release actual y prximo release).
Esto se expresa a travs de ms detalles en las descripciones de las funcionalidades y de
un tamao ms pequeo de las funcionalidades. Un release puede extenderse de seis a
nueve meses, aunque dos a cuatro meses son ms comunes. El propsito de un release
es proporcionar tanto al cliente como al equipo una visualizacin del todo y hacer que
el Product Owner y el equipo de entrega realizaren una primera tentativa de subdividir
los requisitos de alto nivel en funcionalidades del producto, guindolos detallar las
funcionalidades que con mayour probabilidad a ser creadas.
Por otro lado, la iteracin est defnida al nivel de la funcionalidad. El equipo de entrega y
el Product Owner defnieron en forma conjunta el nmero de iteraciones de un release. La
prioridad de las features determina cuales de ellas sern entregadas en cada iteracin; el
nmero de funcionalidades que sern entregadas en la iteracin es defnida por la velocidad
del equipo y por las estimaciones del equipo acerca de las funcionalidades. Las actividades
de planifcacin de la iteracin normalmente determinan una nica iteracin a la vez, o
a veces dos. Planifcar solamente para la prxima iteracin signifca que las actividades
tienen una alta probabilidad de ser emprendidas. Esto garantiza la inversin de tiempo
por el equipo de entrega en la subdivisin de las funcionalidades en tareas. Las tareas
son tcnicas por naturaleza; el Product Owner no ir necesariamente a reconocerlas. La
duracin de las iteraciones vara de una a seis semanas, siendo dos semanas el perodo
ms frecuente. El propsito de la iteracin es hacer que cada equipo se comprometa a
entregar las funcionalidades estimadas que fueron estimadas con mucha precisin.
Planicacin del Release Cmo lograrlo
Teniendo una visin del producto y un roadmap disponibles que son actualizados y
analizados con mucha reguralidad por el Product Owner y por el equipo, todos entienden
el enfoque o tema de los prximos releases y las fechas de release deseadas. Adems, las
funcionalidades del producto ya habrn sido coleccionadas en su backlog, con su prioridad
y estimado. A travs de estas labores, el Product Owner y los equipos de entrega obtienen
un entendimiento de lo que necesita ser entregado, cuando, y por qu, en el orden pactado.
Si el equipo estim las funcionalidades en storypoints o tamaos de T-shirts
x
, deber pactar
su capacidad (velocidad esperada) tomando como base nmeros histricos - o por simple
10 www.rallydev.com 2013 Rally Software Development
suposicin. La disponibilidad normal de los miembros de equipo es del 60 a 70%, pero
pueden ocurrir nmeros bajos de hasta 25%, o altos, hasta 90%.
Una sesin de planifcacin de release normalmente demora un da entero, y a veces dos
das, si el programa es muy grande (se requiere cientos de miembros de equipo). Todos
los miembros de equipo participan de la sesin: el Product Owner, todo el equipo de
entrega y todos los dems involucrados. La sesin es altamente cooperativa e interactiva;
las herramientas ms comnmente utilizadas son notas adhesivas, fip-charts y cuadros
blancos. Un ejemplo de agenda
xi
podra ser:
Introducciones, metas, actualizaciones de la agenda,
Visin del producto, explicacin del producto por el Product Owner utilzando metforas
Timeboxes para los releases e iteraciones
Impacto de los releases e iteraciones concludos
Clculo de capacidad por el equipo de entrega
Acuerdo sobre entregables (cuando una funcionalidad se da por concluda)
Trasladar funcionalidades a un release durante las sesiones de planifcacin por los
diferentes equipos. Esto puede signifcar literalmente traladar las notas adhesivas
donde estn escritas las funcionalidades y los releases estn representados en hojas
separadas del fip-chart. Todos los miembros del equipo participan de este ejercicio.
Transferencia de las funcionalidades del release para iteraciones dentro del release por
los diferentes equipos
Determinacin de dependencias a travs de la evaluacin de los resultados individuales
de la planifcacin, trasladando funcionalidades para las iteraciones o releases necesarios
a fn de resolver las dependencias
Clculo fnal de la carga de trabajo por iteracin y comparacin con la capacidad
disponible
Anlisis de los riesgos y problemas descubiertos
Compromiso con el plan del release por todos los participantes
Retrospectiva de la sesin
Planifcacin de la Iteracin Nivel 4
Durante la planifcacin del release, la entrega de funcionalidades fue defnidad tomando
en consideracin las dependencias entre las funcionalidades y entre los equipos. Debido
a la falta de detalles (no se invierte en actividades de diseo hasta que la probabilidad
de crear la funcionalidad sea casi segura) los estimados son a grandes razgos y tienen
una incertidumbre aceptable. En caso de iteraciones dentro del release, se hace una
sesin de planifcacin. Antes de la sesin o durante la misma, se aaden detalles a las
11 www.rallydev.com 2013 Rally Software Development
funcionalidades a travs de su subdivisn en tareas. La adicin de detalles aumenta la
precisin de los estimados. La capacidad real de los diferentes equipos es conocida con
ms certeza que durante la sesin de planifcacin del release. La combinacin de estos
factores aumentada la certeza de que el equipo podr ser capaz de comprometerse a
realmente entregar varias funcionalidades durante la iteracin, con un alto grado de certeza
de cumplir con el compromiso.
Planicacin de la Iteracin: Cmo logralo
La estructura de la sesin de planifcacin de la iteracin se asemeja a la sesin de
planifcacin del release. Aunque los equipos trabajen individualmente para producir su
plan de iteracin, la sincronizacin entre los equipos proporcionar un mecanismo efcaz
para detectar y solucionar dependencias. La programacin de la reunin de planifcacin
trae grandes semejanzas con la de una reunin de planifcacin de release, con la distincin
bsica del horizonte de la planifcacin: solamente una nica iteracin es observada en
todas las actividades. El ncleo de las actividades es ejecutado equipo a equipo:
Los equipos individuales determinan su capacidad real o la cantidad de trabajo que
puede ser hecho dentro de la iteracin.
Los equipos individuales descomponen en tareas tantas funcionalidades cuntas parecer
compatible con la prxima iteracin - esto puede ser hecho como preparacin.
Cada tarea es estimada con una duracin normal de medio da a dos das.
La defnicin
5
de listo debe ser llevada en cuenta al descomponerse y estimarse
funcionalidades: una funcionalidad no ser considerada concluida hasta que haya sido
completamente testada y aceptada por el Product Owner.
Los resultados de los equipos individuales son inspeccionados en una sesin conjunta para
determinar dependencias (o su desaparicin) que no fueron vistas durante la sesin de
planifcacin del release.
Plano Diario Nivel 5
Muchos equipos giles adoptaron el hbito de mantener una reunin diaria: la reunin stand-
up de Scrum. En una sesin de 15 minutos, los miembros del equipo actualizan sus status
(lo que hice ayer), se comprometen con el trabajo de hoy (lo que har hoy) y relatan
impedimentos (estoy siendo impedido por ). Esta reunin diaria normalmente no es vista
como una sesin de planifcacin, pero seguramente lo es. Las personas miran hacia el da
que est por venir, aprendieron con los das anteriores en la iteracin y dicen unas a las otras
lo que planean hacer. Los problemas son planteados, posiblemente resueltos y la posibilidad
de xito en la entrega de las funcionalidades deseadas dentro de la iteracin puede ser
determinada despus de la reunin.
5
Una defnicin de las entregas de una funcionalidad (cuando una feature est lista) lista los artefactos que necesitan ser entregues
con el cdigo real. Puede incluir tests, resultados de tests, varios tipos de documentacin etc. Algunos de estos artefactos
sern defnidos al nivel de proyecto (como documentos exigidos para examinar equipos), otros dependen del equipo (como
documentacin de usuario en caso de equipos que trabajan con funcionalidades relativas a la interfaz de usuario).
12 www.rallydev.com 2013 Rally Software Development
Reunin Stand-up: Cmo logralo
Tal como otras actividades de planifcacin, los planes diarios necesitan ser sincronizados
entre los equipos. Esto ocurre en una reunin stand-up para coordinacin (reunin Scrum
of Scrums en la metodologa Scrum). Los representantes de cada equipo reportan el status,
los planes e impedimentos unos para los otros en un formato idntico. Las tres preguntas
contestadas son las mismas que de la reunin stand-up individual (lo que el equipo
concluy ayer, qu va a hacer el equipo hoy y lo que est impidiendo el equipo). Lo que
se hace visible es:
Cmo todos los equipos estn progresando?
Cules son los impedimentos entre los equipos?
Quin esta tomando providencias para eliminarlos?
El principio de una reunin stand-up de coordinacin puede ser repetido para comportar
un gran nmero de equipos: representantes de los equipos de los equipos reportan
sobre el progreso de los equipos de los equipos. Estas reuniones normalmente coordinan
esfuerzos de equipos que no tienen ningn inters en comn. Por ejemplo, todos los
equipos de entrega de TI tienen una reunin stand-up de coordinacin (diaria), as como
los equipos de entrenamiento, equipos fnancieros, de pre-produccin, etc. En una
programacin semanal o (al fnal del ciclo del release) diaria, los representantes de los
equipos se encuentran para reportar sobre progresos, planes e impedimentos.
Conclusin
Esta seccin abord la carga de los equipos de entrega a travs de la planifcacin de las
actividades de entrega con el nivel adecuado de detalle en los momentos adecuados. A
travs de las actividades de planifcacin organizadas en etapas, es posible obtener un
equilibrio entre las visiones y los compromisos de largo plazo y las inversiones iniciales
en las actividades de design y planifcacin. A travs de la propiedad del release y de la
planifcacin de la iteracin por los equipos de entrega, los riesgos de sobrecargar equipos e
individuos son mucho ms bajos.
13 www.rallydev.com 2013 Rally Software Development
Regularidad en el Proceso de Planifcacin
La irregularidad en la carga de trabajo puede ser resuelta tenindose siempre una cantidad
de trabajo lista para los equipos e individuos. Esto permite a los equipos e individuos asumir
el trabajo cuando haya capacidad disponible.
En el documento de autora de Takeuchi y NonakaiI, The New New Product Development
Game, los autores enfatizan que un mecanismo de inicio y parada impone retrasos en el
proceso de entrega. A travs de una superposicin de actividades entre los equipos, o a
travs del inicio anticipado del prximo equipo (mientras el equipo anterior todava est
trabajando en sus tareas), o una ejecucin paralela de la mayora de los equipos (separando
sus dependencias durante el progreso), la duracin total del desarrollo del producto es
abreviada.
Cuando un equipo no est familiarizado con el dominio del problema presentado por el
Product Owner, va a exigir tiempo para preparar estimaciones a travs de la descomposicin
de las funcionalidades en tareas. Esto genera atrasos entre las iteraciones: la primera
iteracin entrega las funcionalidades solicitadas con xito y solo entonces el equipo
determina el impacto de la entrega en el backlog del producto y empieza a estudiar
y descomponer el prximo grupo de funcionalidades. Este trabajo puede ser hecho
anticipadamente: los miembros del equipo (algunos o todos) pueden planear el trabajo que
tiene ms probabilidad de ser emprendido en la prxima iteracin. De una forma simple
(cuando los miembros estn familiarizados con las funcionalidades) esto exigir algunas
horas de trabajo para estudiar el backlog del producto e interrogar el Product Owner.
Cuando la familiaridad disminuye, estas actividades crecen para varias personas-da. La
estructura ms extrema observada ocurre cuando dos miembros del equipo gastan la
iteracin entera estudiando las funcionalidades para la prxima. Durante el perodo de
planifcacin de la iteracin, ellos suministran orientacin al equipo y despus de la sesin
de planifcacin vuelven a ser parte del equipo de entrega, asumiendo funciones de entrega
reales. Dos otros miembros del equipo asumen entonces la tarea de preparacin. Los
efectos de este abordaje son:
Las iteraciones se sobreponen y son continuadas sin intervalos
Algunas funcionalidades del backlog del producto son previamente divididas en fases
El tope del backlog del producto siempre est listo para ser incluido en una iteracin
Este abordaje reserva tiempo para abordar problemas que son causados por falta de
conocimiento de las funcionalidades por el equipo de entrega. Un ejemplo de actividades
que pueden ser ejecutadas durante esta fase de pre-preparacin es la creacin de
prototipos de la funcionalidad de la aplicacin que pueden ser testados por un grupo de
usuarios para estudiar sus experiencias. El resultado es la concordancia entre el Product
Owner y el equipo de desarrollo de que los tems del backlog estn listos - el equipo est
seguro de que puede estimar y descomponer las funcionalidades.
14 www.rallydev.com 2013 Rally Software Development
Los equipos de desarrollo necesitan separar tiempo para crear prototipos para el Product
Owner por lo menos una iteracin antes de la implementacin. En otras palabras, las
ventajas de un proceso de planifcacin regular tiene su precio, pero el efecto puede ser
signifcativo. En el caso descrito anteriormente (dos miembros del equipo estn ocupados
con la preparacin de la sesin de planifcacin), ya que el atraso entre el fnal de una
iteracin y el inicio de la prxima puede consumir el tiempo de una iteracin, o en otras
palabras la preparacin duplica el rendimiento.
Conclusin
Es posible adherirse al principio apenas sufciente de los mtodos giles y expandir el
nmero de proyectos en los que los mtodos pueden ser aplicados desde proyectos de un
solo equipo, y de corto plazo, hasta proyectos multiequipos y de largo plazo. Los niveles
adicionales de planifcacin no son engaosos y no requieren de mucho tiempo, y enfocan
al grupo adecuado de personas en el producto fnal, con un nivel adecuado de detalle,
evitando as desperdiciar grandes cantidades de tiempo y dinero antes del inicio de la
entrega real de las funcionalidades. El signifcado del trmino aceptablemente errneo es
de suma importancia, cuando cualquier miembro de los equipos desea apegarse a detalles
de especifcacin y/o planifcacin del trabajo. De ser as la implementacin gil est en
camino de vuelta para los mtodos de cascada.
15 www.rallydev.com 2013 Rally Software Development
Referencias
[i] Liker, The Toyota Way, McGraw Hill, 2005, pp. 114-115
[ii] Takeuchi & Nonaka, The New New Product Development Game, Harvard Business
Review, Jan/Feb 1986
[iii] Schwaber & Beedle, Agile Software Development with SCRUM, Prentice Hall, 2001
[iv] Schwaber, Agile Project Management with Scrum, Microsoft Press, 2004
[v] Poppendieck & Poppendieck, Lean Software Development, Addison-Wesley, 2003
[vi] Sutherland, Viktorov & Blount, Adaptive Engineering of Large Software Projects with
Distributed / Outsourced
Teams, in International Conference on Complex Systems, Boston, MA, USA, 2006.
[vii] Liker, The Toyota Way, McGraw Hill, 2005, pp. 114-115
[viii] Moore & McKenna, Crossing the Chasm, Capstone Publishing, 1999
[ix] Highsmith, Agile Project Management, Addison-Wesley, 2004
[x] Cohn, Agile Estimating and Planning, Prentice Hall, 2006 [xi] Tabaka, Collaboration
Explained, Addison Wesley, 2006
[xi] Tabaka, Collaboration Explained, Addison Wesley, 2006