Agile Project Management

Fases

81

Envision: visin del producto, alcance del

proyecto, comunidad del proyecto, forma de trabajo

Especular: Plan de release, milestones e

iteraciones basado en features para materializar la

visin

Explorar: entregar features probados en un

perodo corto, tratando constantemente de reducir el

riesgo y la incertidumbre del proyecto

Adaptar: revisar los resultados, la situacin actual,

el desempeo del equipo y adaptar cuando sea
necesario.

Cerrar: concluir el proyecto, transmitir aprendizajes

claves y celebrar

Envision

82

Primero: visionar qu es lo que se dar

una visin del producto y del alcance del

proyecto
Segundo: visionar quien tomar parte

clientes, miembros del team e interesados

(stakeholders)
Tercero: los miembros del team visionarn

cmo se disponen a trabajar juntos

Especular

82-83

Recopilar los requerimientos iniciales amplios

Definir la carga de trabajo en la forma de
una lista de features
Hacer un plan (release, milestones e
iteraciones) que incluya fechas y asignacin
de recursos para esos features
Incorporar estrategias de mitigacin de
riesgos
Estimar costos del proyecto y generar otra
informacin administrativa y financiera
requerida

Explorar

83

Entrega de features del producto

Fija 3 reas clave de actividad

Entregar features planeados administrando la

carga y usando prcticas tcnicas apropiadas y
estrategias de mitigacin de riesgos
Crear una comunidad del proyecto colaborativa y
auto-organizativa
Administrar las interacciones del equipo con:
clientes, gerencia del producto y otros
stakeholders.

Adaptar

83

Responder al cambio es ms importante que

seguir un plan
Despus de la fase envision, el loop ser:
especularexploraradaptar
Cada iteracin refina sucesivamente el
producto
Los resultados son vistos desde las
siguientes perspectivas:

Del cliente
Tcnica
Gente
Performance de procesos
Status del proyecto

Cerrar
Los

84

proyectos deben tener un fin

visible y percibible hay que celebrarlo
El objetivo clave de la fase de cierre
(mini cierre de cada iteracin y el del
proyecto global) es aprender para
incorporar ese conocimiento en la
prxima iteracin o para pasarlo al
prximo proyecto

Prcticas

Consideraciones

84-86

Siempre se requiere el juicio: sobre-enfatizar

la linearidad lleva a la parlisis y sobreenfatizar la evolucin lleva al cambio sin fin y
eventualmente sin sentido.
Los principios sin prcticas son inefectivos
ylas prcticas sin principios tienden a
implantarse mecnicamente, sin aplicar el
juicio.
Las prcticas seleccionadas:

Generativas, no prescriptivas
Enfocadas en delivery y no en compliance

Fase: Envision

87

89

Todos los equipos que funcionan bien

cuentan con un perfecto entendimiento de
sus objetivos
Los detalles pueden ser borrosos, pero las
objetivos de negocio y la visin del producto
deben ser clarsimas
Sin una visin clara se arriesga experimentar
sin fin.
Una visin clara, compelidora, es crtica para
el xito del proyecto Por qu falta tantas
veces? Respuesta:

Una visin clara es difcil: requiere trabajo duro y

liderazgo

Preguntas que resuelve

Cul

89

es la visin del producto del

cliente?
Cul es el alcance del proyecto y su
juego de constraints?
quines son los participantes
adecuados para la comunidad del
proyecto?
Cmo entregar el equipo el producto
(enfoque)?

91

Evolucin del plan del producto

Vision

Alcance

Feature
s

Tres Herramientas simples y poderosas

Vision Box Forza a condensar la visin
Project Data Sheet Forza a decantar
detalles claves de alcance y constraints
Feature Cards Obliga a condensar la
informacin de cada feature en una ficha

Siempre recordar

91

Cul es la documentacin apenas

suficiente?
El como de la entrega los resultados est
sujeto a ajustes y adaptaciones para mejorar
el rendimiento conforme avanza el proyecto
La comunidad del proyecto y sus procesos y
prcticas van a evolucionar. Por ejemplo, si la
arquitectura evoluciona, la estructura del team
pueda necesitar evolucionar.

Las prcticas

Las prcticas (4 categoras)

Visin del producto

Data sheet del proyecto

Comunidad del proyecto

Caja de la visin del producto y test del elevador

Arquitectura del producto y directrices

Alcance del proyecto (objetivos y constraints)

92

Conseguir la gente adecuada

Identificar a los participantes
Interfaces entre equipos cliente desarrollo

Enfoque

Ajuste de procesos y prcticas

Caja de Visin del Producto y

Test del Elevador (Prctica)
93

Objetivo
Estimular

a los miembros del team a que

focalicen sus ideas desperdigadas del
producto en una forma concisa, visual y
textual.
Estos dos mecanismos proveen un
concepto comn elevado del producto para
mercadeo, desarrollo y gerentes.

Desarrollo de la Discusin

93

No se puede predecir la innovacin ni la

creacin de productos emergentes, por lo
tanto hace falta un proceso especial.
Una buena visin del producto es constante,
mientras que la va para implementar esa
visin necesita espacio para jugar.
Los resultados emergentes a veces provienen
de accidentes intencionales, por lo tanto es
necesario crear el ambiente para que ocurran
estos accidentes.

Diseando al caja del

producto
93-94

Se trata de disear las partes frontal y trasera

de la caja del producto
Esto implica

Nombre del producto

Un grfico
Tres a cuatro bullets claves en el frente
Descripcin detallada de los features en la parte
trasera

Se presenta y discute cada propuesta de

texto para la caja

Test del Elevador

(> 2 minutos)
93

Para las bodegas de distribucin de las

empresas medianas, que necesitan
funcionalidades avanzadas de movimiento de
cajas, el Supli-Robot es un sistema
robotizado de levantado y transporte de
carga que provee re-ubicacin dinmica de la
carga dentro de la bodega y cargado de
camiones con cajas de tamaos variados que
reduce el costo de distribucin y el tiempo de
carga. A diferencia de los otros productos,
nuestro producto es altamente automatizado
y con precios agresivos.

Test del Elevador

Formato
95

Para (cliente objetivo)

Que (exposicin de la necesidad o de la
oportunidad)
El (nombre del producto) es (categora del
producto)
Que (Beneficio clave, razn para comprarlo)
A diferencia de (Alternativa competitiva
primaria)
Nuestro producto (exposicin de la
diferenciacin primaria)

Ms sobre visin del producto

Para proyectos con alto grado de incertidumbre, es

crtico disponer de un concepto nuclear, una visin,
para mantener bajos los costos de exploracin.
Despus de varias horas de discusin:

Mission statement
Dibujo de la caja
Clientes objetivo y sus necesidades
El test del elevador
Medidas de la satisfaccin del cliente
Requerimientos clave operacionales y de tecnologa
Restricciones crticas al producto (Performance, facilidad
de uso, volmenes)
Anlisis competitivos
Indicadores financieros crticos**

95

Prctica
Arquitectura del Producto

Objetivo: Mostrar la plomera interna del proyecto

un diseo que facilita la exploracin y gua el
continuo desarrollo del producto. Gua el trabajo
tcnico y a la organizacin de la gente que desarrolla
ese trabajo tcnico.
La arquitectura junto con el tamao total del proyecto
contiene implicaciones importantes para el xito del
proyecto y del producto

98

P. ej. la organizacin de componentes y mdulos puede

influir la decisin de desarrollo distribuido y sobre la
gerencia de los grupos distribuidos

La arquitectura es gua, no camisa de fuerza. Busca

comunicar el contexto mayor al team.

Feature Breakdown Structure

Gerencia de Ventas (Business Area)

Prospectacin (Business Activity)

Crear pantalla log on de vendedores (Feature)

Listar leads para los vendedores
Desplegar detalles individuales por lead

Administracin de territorios
Anlisis de ventas

Marketing

Generacin de leads
Seguimiento de leads
Colocacin de anuncios
Servicio de Call Center

98

99-100

Las arquitecturas utilizan una combinacin de

elementos de: plataforma, componente, interfaz,
mdulos
Hay otras arquitecturas tiles para los equipos
tcnicos, pero la FBS sirve para comunicarse entre el
cliente y el equipo de desarrollo y funciona como
puente entre las fases de Envision y Especular
La FBS provee el inventario de features desde el cual
se desarrolla el plan de iteraciones
La organizacin humana y la arquitectura tcnica
coevolucionan durante la vida del proyecto

Un core team multidisciplinario puede funcionar mejor al

principio
Cuando ya han sido especificadas las interfaces mediante
interacciones y debate, sub-teams basados en
componentes pueden funcionar mejor

Principios gua

100-101

Esta es una segunda pieza de la gua

arquitectnica
Estos principios asisten al team para que
moldee el producto segn las preferencias de
los clientes.
Ejemplos: 1) Toda interaccin siempre ser

cerrada, 2) Toda interaccin debe buscar un

feedback, 3) Todo feedback de empleado por
interaccin debe darse por clicks

Cada principio debe describirse en una o dos

proposiciones y su nmero total para un
proyecto, en cualquier momento, no debera
exceder de 10

Prctica

101

Project Data Sheet PDS

Objetivo:

transmitir la esencia en
trminos de alcance, calendario y
recursos, de cmo el proyecto
materializar la visin.
Es la segunda ms importante prctica
de la fase de Envision

Project Data Sheet

Product vrs Project vision
101-102

La visin del producto es una vista expandida

de lo que el producto podra llegar a ser
La visin del proyecto limita el desarrollo del
producto a los confines de lo definido en:
alcance, calendario, y restricciones de
costos.

Product vision should haves 234 features

Project scope will have 126 features (Rel 1.0)

Secciones de una PDS

102

Clientes: lista de clientes clave

Project Manager
Product Manager
Project Objective Statement (POS)
Tradeoff Matrix (TOM)
Factor de exploracin
Costo de los atrasos
Features (lista de los claves)
Beneficios al cliente
Arquitectura
Ejemplo
Puntos/riesgos***

Tradeoff Matrix - TOM

Fijo
Alcance
Calendario

104

Flexible

Acepta

x
x

Estabilidad*

Recursos

*Defectos

Una entrada/columna

Conviene medir
lmite

104

Es

un acuerdo entre el team del

proyecto, el cliente y el sponsor
ejecutivo que se usa para manejar el
cambio durante el proyecto.
Las filas muestran las dimensiones
claves que crean el valor del producto
Las columnas despliegan la
importancia relativa de cada dimensin

Tradeoff Matrix
No

105

se puede responder a cambios si no

se marca un espacio para manejarlos
Es importante calcular el costo de los
atrasos

Factor de Exploracin

105-106

Barmetro de la incertidumbre y del riesgo

Relacionado con el problem domain donde el
team operar
10 indica un problem domain orientado a la
exploracin (alto riesgo) y 1 indica un ambiente de
problemas estable
Importante identificar los factores del problem
domain, pero ms importante es ajustar los
procesos y las prcticas al problema y ajustar las
expectativas correspondientemente
Resulta de combinar la volatilidad de los
requerimientos del producto con lo nuevo
inicierto- de la plataforma tecnolgica.

Factor de Exploracin

107

Dimensin de Tecnologa
Dimensin
de producto

Bleeding Leading
Bien
Familiar
Edge
Edge
conocida

10

Fluctuante

Rutina

Estable

Errtica

10: problem domain que requiere mucha exploracin

1: ambiente del problema muy estable

Problem Domain

107

Es necesario establecer la incertidumbre

global del espacio del problema.
Proyectos 8, 9, 10 requieren un enfoque
fuerte APM

Iteraciones cortas
Planeacin basada en features
Revisiones frecuentes con los clientes
Reconocimiento que los planes son especulativos

El reconocimiento de diferentes dominios de

problemas permite hacer ajustes a problemas
especficos y asegurar el xito.

Prctica

Consiga la gente correcta

108

El factor crtico de xito

Correcta quiere decir:

Capacidad tcnica apropiada o experticia en el

domain
El comportamiento disciplinado adecuado
No significa la ms talentosa y experimentada,
sino la gente apropiada para el trabajo.

La pregunta sobre los quienes es la ms

prioritaria, sobre las qu antes que la
visin, la estrategia, la tctica, la
organizacin, la tecnologa.

Prctica

111

Identificacin de participantes

Objetivo: identificar a los participantes de modo que

las expectativas sean entendidas y administradas.
Los participantes son los que pertenecen a la
comunidad del proyecto:

Clientes determinan e influyen los requerimientos

Ejecutivos proveen fondos y supervisin gerencial
Miembros nucleares del team trabajan para entregar el
producto.
Stakeholders Participantes internos que no son clientes
directos

Los clientes proveen los requerimientos; los

miembros del team fabrican el producto; los
stakeholders proveen el conjunto de restricciones, los
requerimientos de cumplimiento y los recursos

Lista de participantes

112

Patrocinador ejecutivo: decisiones claves sobre metas y

restricciones
Gerente del proyecto: dirige el team a cargo de dar los
resultados
Gerente de Producto: gua al equipo para determinar qu
resultados dar
Ingeniero lder: gua los aspectos tcnicos de las entregas
Gerencia: una gama potencialmente amplia de individuos con
alguna autoridad tcnica o de presupuesto sobre los resultados
Equipo del cliente: a cargo de fijar features y priorizarlos
Team del proyecto: los encargados de dar los resultados
Proveedores: proveen servicios o componentes del producto
Gobierno: Organismos regulatorios que requieren informacin,
reportes y certificaciones

Fase:

Especular

127

Ideas preliminares

128

El control de cambios congela los

requerimientos
El alcance mismo tambin evoluciona
De resistir el cambio a estimular el cambio
El control de cambios se refiere a la
coordinacin no a la negacin
Flexibilidad indisciplinada caos
Estabilidad indisciplinada rigidez
Balance entre flexibilidad y estructura
mediante auto disciplina

Ideas preliminares 2

129

Los planes son guas, no camisas de fuerza

La realidad siempre se entromete
Los planes son vehculos para abrazar el
cambio, no para bloquearlo
Los planes son:

Conjeturas acerca del futuro

Guas para el futuro

El desarrollo genera nueva informacin que a

su vez crea la necesidad de re-planear
No es riesgo loco sino: conjeturar algo
basado en hechos e informacin incompleta.

129

El fruto de esta fase es el Release Plan que

contiene el mejor conocimiento inicial del team

Este plan est basado en features entregados y no en

actividades

El plan de release usa informacin de:

Especificaciones del producto

Arquitectura de la plataforma
Recursos
Anlisis de riesgo
Niveles de defecto
Restriccciones de negocios
Calendario deseado

129-130

Dos componentes cruciales en un enfoque de

planeacin y desarrollo iterativo

Ventanas pequeas de iteracin

Features

Para proyectos de SW: cada ventana de 2 a 6

semanas
Las ventanas cortas aceleran el desarrollo
La primera meta de la planeacin y desarrollo
basado en features es hacer el proceso visible y
entendible.

130

Los features funcionan como interfaces entre

los ingenieros de desarrollo y los usuarios
finales son un medio para entendimiento
compartido.
Este espacio compartido toma la forma de
una feature card

El frente: informacin del feature

Detrs: informacin de la tarea tcnica para
estimar esfuerzo y administrar el trabajo
Estamos atrasados, recortemos los features 31 y
64, en lugar de: recortemos el tiempo de tests

Ayudas que da esta fase

130-131

Determinar cmo el producto y sus features

evolucionarn
Concentrarse en los features de alto valor
desde el principio
No perder de vista los objetivos de negocios y
las expectativos del cliente
Coordinar actividades y features
interrelacionados entre feature teams
Considerar alternativas de acciones adaptivas
Proveer una lnea base para analizar eventos
que se dan durante el proyecto.

131

Se

necesita recompensar al team por

su respuesta a los cambios, y no
amonestarlos por no haber hecho un
plan

Categoras de prcticas
Estructura

131

de feature breakdown

Lista

de features del producto

Feature cards
Tarjetas de requerimientos de performance
Plan

de entregas

Entregas,

milestones, plan de iteraciones

132

Lista de
Features
Feature
Breakdown

Prcticas

Tarjetas de
Features
Requerimientos
Performance

Plan de
Iteraciones

Plan de entregas,
milestones e iteraciones

Iteracin 0
Anlisis de
riesgo
Prximo plan
de Iteracin

Prctica 132

Lista de Features del Producto

Expansin de la desarrollada en la fase de envision

Esta lista y las tarjetas que le acompaan son el
insumo principal para la planeacin de entregas,
milestones e iteraciones.
Para cada feature crea una tarjeta que contiene
informacin bsica descriptiva y de estimaciones.
El software no es muy estricto para exigir todas las
especificaciones desde un inicio, por lo tanto le aplica
un proceso evolutivo de especificaciones.

Jerarqua de features

133

Producto
Area

de business subject

Business activity

Feature

Pequeos

productos podran usar slo

el nivel de features.

Qu es un feature?

134

Es un trozo del producto que entrega

funcionalidad valiosa y utilizable a un cliente.
Para los propsitos de planeacin y de
entregas de los proyectos, el team necesita
incluir features de tecnologa o componentes,
donde se muestran separados de los otros.

El peligro: construir muchos componentes

tecnolgicos o de infraestructura antes de construir
algo con significado directo para el cliente
En cuanto ms tiempo pasa por all debajo, ms
se puede desviar el proyecto antes de recibir
feedback del cliente.

Features

134

De la lista de features potenciales, el team del

producto y el de ingeniera discutirn aspectos
de calendario durante las asignacin de
features a las interaciones de desarrollo.
Una caracterstica de los proyectos APM es la
volatilidad de los features en esta lista.
Durante la planeacin para cada iteracin, la
lista de features a incluir puede cambiar
significativamente en relacin al plan original

Prctica

Feature Cards
Objetivo:

135

medio sencillo para juntar

informacin sobre los features, registrar
requerimientos de alto nivel y
desarrollar estimados de trabajo.
El desarrollo basado en features
pretende ser desarrollo customer-facing

Feature Cards

Discusin

135

Las fc identifican mas no definen los features

Las fc son acuerdos entre los clientes y los miembros
del team para discutir -y documentar en el grado
necesario- requerimientos durante una iteracin.
La discusin es crtica para entender la que a su
vez es crtica para estimar
Identifican features que los clientes quieren en el
producto
Para proyectos grandes, se pueden usar group
cards por business activity para organizar y planear
listas individuales de features, de 10, 15 o 20
La informacin en las fc se vuelve el producto del
esfuerzo colaborativo del team y el punto focal para
entendimiento mutuo del producto al nivel de detalle

Feature Card

Iteracin planeada: 3

No. de Feature: 25

Tipo de feature: cliente

Nombre de feature: Establecer territorios de ventas

136

Descripcin del feature:

Crear territorios de ventas con base en regiones y reas metropolitanas
estndar

Cantidad estimada de trabajo: 4.5 das

Incertidumbre de los requerimientos(E,F,R,S): R (rutina)
Dependencia de otros features: ninguna
Tests de Aceptacin:

Contenido de Feature Card

136

Identificador y nombre del feature

Descripcin: una o dos oraciones en trminos del
cliente
Tipo de feature (C=customer, T=tcnico)
Trabajo estimado: lo que lleva producir el feature, e
incluye tiempo para recoger requerimientos, diseo,
codificacin, pruebas y documentacin.
Incertidumbre de los requerimientos (errticos,
fluctuantes, rutinarios, estables): un factor de
exploracin
Dependencias de features: que podran afectar la
secuencia de implementacin
Tests de aceptacin: criterios que el cliente utilizar
para aceptar o rechazar el feature.

Capa debajo de los features

137

Para planear la prxima iteracin hay que voltear las

tarjetas y listar las actividades tcnicas requeridas para:
especificar, disear, construir, probar y documentar el
feature.
Se pueden combinar las actividades tcnicas de varios
features en un solo paquete tcnico de trabajo.
Features de alto riesgo se calendarizaran en las
iteraciones iniciales para que el team pueda determinar
primero si el feature puede ser implementado, y segundo,
si se puede, si llevar ms tiempo y dinero de lo previsto.
Si es difcil fijar los requerimientos, podra requerirse una
serie de prototipos de descubrimiento.
Features altamente inciertos podran requerir
investigacin adicional antes de planearlos.

Prctica

Tarjeta de Requerimientos de
Performance
Objetivo: documentar las operaciones clave y
los requerimientos de performance del
producto.
Suelen ser de diferente color que las de
features
Contienen: nombre, descripcin, metas
cuantitativas de performance
Contienen tambin los correspondientes
criterios de aceptacin o tests en esta rea.

Tarjeta de performance

Iteracin demostrada: 6

Performance ID:

PC-12

Nombre del aspecto

Inicio del Interaction Manager

Descripcin del performance

El IM debe intervenir antes de

transcurrido un segundo de
detectada la interaccin

Dificultada para lograrla (H,M,L)

M (moderada)

Criterio de aceptacin

a- <2 seg en iteracin 3

b- <1 seg en iteracin 6

Prctica 140-141

Plan de Releases, Milestones e Iteraciones

Representa el mapa de cmo el team
pretende lograr la visin del producto dentro
del alcance y las restricciones del proyecto
-identificados en la Project Data Sheet.
Los ciclos APM son iterativos y guiados por
features.

Cambia el foco de la planeacin y la ejecucin de

tareas a features de producto

Otra ventaja de basar los planes en features

(Y su arquitectura, que es instanciada por
features) es que mantiene la sincrona entre
el cliente y el equipo de desarrollo.

142

Las iteraciones producen features que han

pasado los criterios de aceptacin

La meta es disponer de un producto con features

parciales y que pueda entregarse al final de cada
iteracin.
Incremental delivery

Milestones son puntos intermedios de uno a

tres meses y pueden tener funciones
gerenciales y tcnicas
Su uso ms importante: Puntos fuertes de
sincronizacin e integracin

Factores

143

Dos factores guan el plan de releases,

milestones e iteraciones para asignar
features:

Valor del cliente

Riesgo

Alto riesgo
Alto valor
Bajo Valor

Bajo riesgo

2a. prioridad 1a. Prioridad

3a. prioridad

Todas las dems consideraciones de calendarizacin

disponibilidad de recursos, dependencias y otras- se
subordinan a valor y riesgo

Iteracin 0

143 - 144

Es una prctica que ayuda a ubicar el terreno

medio entre anticipacin y adaptacin El 0
significa que no se entrega nada til para el
cliente en este perodo.
Por ejemplo, un proyecto pudiera requerir alguna
aequitectura de datos para desarrollar interfaces.
Para cada uno de estos items debe crearse una
feature card. (Contendr algn diagrama de
arquitectura en lugar de un feature
implementable)
Ejemplo de un release plan

Iteraciones 1-N
Se

144

necesita crear un plan que asigna

features a iteraciones por la duracin
del proyecto para lograr un feel del
flujo del proyecto y determinar la fechas
de complecin, staffing, costos y otra
informacin de planeacin del proyecto.
El plan resultante se puede ver as.

PLANO DE FEATURE CARDS 146

Iteracin 0

Arquitectura
1.0

Iteracin 1

Iteracin 2

Iteracin 3

Iteracin 1
Tarjeta tema

Iteracin 2
Tarjeta tema

Iteracin 3
Tarjeta tema

Arquitectura
1.1

Arquitectura
1.2

Feature 3

Feature 5

Feature 1

Investigacin
Requerimientos

Feature 3
Feature2

Feature 7

Iteracin 4
Iteracin 4
Tarjeta tema
Feature 4

Las Actividades para hacer el

plan de iteracin Incluyen
146

Determinar cmo los riesgos identificados influirn en la

planeacin
Identificar la meta del calendario
Establecer los perodos de milestone y de iteracin
Desarrollar un tema para cada iteracin
Asignar feature cards a cada iteracin balancenado
prioridades del cliente, riesgos, recursos y dependencias
Sumarizar el plan en combinaciones de hoja a nivel de
feature, plano de feature cards, parking lot
Calcular el calendario inicial segn disonibilidad de staff y
el total estimado de trabajo
Ajustar el plan cuando sea necesario

147

Mientras que con criterios de cliente se

asignan features a las iteraciones, aspectos
de riesgo tnico pueden influir en estas
decisiones.
Algunas veces se implementan primero los
features de alto riesgo con el fin de reducir
riesgos.
La interdependencia entre features influye en
la asignacin, pero los ms importantes son
valor del cliente y riesgo.

148- 149

Para cada iteracin y milestone, el equipo debe

desarrollar y escribir un tema gua.

Esto es importante para que el team balancee entre amplitud

y profundidad de los features
Lo mejor para esto son tarjetas de iteracin (ver ej en lmina
siguiente)

La ventaja de las tarjetas es que se pueden barajar

durante las sesiones de planeacin
La informacin de las interdependencias de features
debe estar en las feature cards.
Un fc llamada Re-trabajo y contingencia se coloca
en cada iteracin.
Se pueden acomodar tambin iteraciones vacas
Los features asignados a los ltimas iteraciones son
los que se pueden botar si hiciera falta.

149

Tema de una iteracin

Iteracion No. 3
Tema: Captura de feedbacks para crear el rich log

Comentario
Las funciones avanzadas se vern en la iteracin 7

Supuesto:
Las simulaciones probarn un 80% de la funcionalidad

Gerencia de Ventas (GV)

150

Anlisis de
Ventas
(18)

Prospectacin
(10)

Manejo de
Territorio
(8)

May 2004

Jun 2004

Jul 2004

Marketing (MM)

(8)

Pautar
Anuncios
(9)

Servicio
Call Center
(28)

May 2004

Ago 2004

Sep 2004

Oct 2004

Generacin
Leads
(22)

Seguimiento
Leads

Planeacin y Reportes a Nivel

de Componentes o Actividad
de Negocios

150

Para proyectos de mediano a grande, la

planeacin a nivel de feature es demasiado
fina, al menos para muchos clientes y
gerentes.
Una aplicacin grande puede contener miles
de features

El team de desarrollo necesita el detalle

Clientes y gerentes pueden ser ms efectivos a un
nivel ms grueso de ganularidad

Para estos casos: FDD Feature Driven

Development

150

Feature-Driven Development
Se

basa en una jerarqua granular de

features
En el caso del Manager Plus, la
jerarqua sera:
Business

Subject Area (Ventas)

Business Activity (Anlisis de ventas)
Feature: (Generar un reporte de
ventas de producto por territorio)

151

FDD

Aplicaciones grandes, como un CRM, pueden

tener de 30 a 50 actividades y varios miles de
features
En estos casos se puede ver la calendarizacin
por gerencias altas a nivel de componente o
actividad, y se deja la calendarizacin a nivel de
feature al equipo de ingeniera.
Este enfoque de dos capas para la planeacion
puede ser muy efectivo.
De Luca divide el dominio tcnico en tres grupos
de features :

User Interface
Database
Systems Interface

152

FDD

An con proyectos ms pequeos, una jerarqua de

actividad y features puede ayudar a un team a
pensar en el producto
Listar features y despus organizarlos en actividades
o comenzar con actividades genricas de proyectos
previos o de investigacin de productos, y de all,
identificar nuevos features, puede contribuir al
entendimiento del producto.
En cualquier caso los artefactos finales de una
actividad de planeacin incluyen una combinacin
de: a) feature cards, b) una FBS, c) un plan de
iteracin con las feature cards, d) un parqueo del
proyecto

152

Tres tipos de planes de iteracin

Hay

varias formas de conducir el

calendario inicial
Asignar

features a las iteraciones hasta la

fecha meta y luego determinar si el
alcance (features que se pueden
implementar) parece razonable.
Asignar todos los features y luego
comparar la fecha planeada (con todos los
features) con la fecha meta.

152-153

Para proyectos con alto grado de exploracin,

los calendarios iniciales pueden contener
demasiados sis. Dependiendo del grado de
incertidumbre se puede hacer.

Un plan completo con features asignados a cada

iteracin
Un plan para dos iteraciones, utilizando slo la
prxima interaccin, y dejar todo el resto para
despus.
Un plan de iteracin por iteracin.

La decisin por uno de estos depender de:

Naturaleza del proyecto

Expectativas de clientes y stakeholders

Todo debe preverse en la fase de Envision

153

Plan de la prxima iteracin

Una vez acordado el plan global de entregas para el

proyecto completo, el team regresa a hacer un plan
detallado de la prxima (o primera) iteracin.
El team toma cada feature card y construye una lista
de las actividades tcnicas requeridas para
implementar el feature, y las anota en el reverso.
El equipo re-estima el trabajo con base en el examen
ms detallado y ajusta los features planeados para
esa iteracin
Finalmente, los miembros se apuntan para features o
actividades basados en sus propias habilidades y/o
deseos*

154

1er.
Deployment
Factible
Puesto que un deployment rpido conlleva muchos
beneficios, algo que el team puede hacer es
determinar este FFD: First Feasible Deployment

Se puede hacer una instalacin temprana a clientes clave

que han pedido el producto

Para el team puede traer a) Ingreso anticipado, b)

feedback valioso

Ojo: los costos de deployment podran ser ms que los

beneficios
Si se piensa hacer esto, hay que preverlo desde el principio,
p. ej. se podra escoger terminar los features de una sola
rea, en lugar de features cruzados

155

Deployment

El desarrollo iterativo crea piezas deployable del

producto, mientras que el desarrollo incremental
realiza el deployment de las piezas del producto
En algunos tipos de desarrollo de SW. p. ej. Web,
cada iteracin puede ser un deployment incremental
El deployment anticipado de productos parcialmente
completados logra:

Mejora del ROI (por los ingresos)

Feedback temprano que puede mejorar el desarrollo en
iteraciones subsiguientes.*

Al identificar la iteracin FFD los equipos de cliente y

tncnico logran una idea de cundo el producto
puede ser rentablemente instalado
Si el FFD se corre al final del proyecto, puede indicar
un riesgo

155

Estimando
Cmo se estima un proyecto gil?
Respuesta: con las mismas tcnicas de
siempre
Hay tres sutilezas detrs de la pregunta
1.
2.

3.

Cmo estimar lo desconocido

Cmo estimar por features en lugar de
actividades
Cmo hacer una estimacin progresiva

Primero

156

Cmo

se estima lo desconocido? No
se puede se adivina.
Por

lo tanto, tiempo y costo son vistos

como restricciones, no como estimados

Se

aprende a vivir con la incertidumbre

en lugar de demandar certidumbre de
un mundo de cambios vertiginosos.

Segundo

156

Los proyectos giles se planean por features

La experiencia en puras tareas debe emplearse

en estimar tareas para cada feature. P. ej. en lugar
de estimar levantado de requerimientos para todo
el proyecto, hacerlo por cada feature.

Un equipo que ha pasado varios das

identificando features y asignndolos a
iteraciones usualmente logra un mejor
entendimiento del producto que los que se
han basado en planeacin de puras tareas
Por lo tanto, en la mayora de los casos, la
planeacin basada en features provee
mejores estimados

Tercero

156

Los buenos gerentes de proyecto siempre

han tratado de emplear prcticas de
estimacin progresiva, p. ej. completar la
definicin de requerimientos antes de estimar
el resto del proyecto.
APM es un proceso fundamentalmente
progresivo de estimacin y de entrega que
refleja la forma verdadera en que la
informacin se revela en el tiempo.
Mientras avanzan las iteraciones, los
miembros del team deben mejorar para
estimar la prxima iteracin, lo que mejorar
tambin para el resto del proyecto.

Evolucin del Alcance ?!

157

Algunos cambios del alcance son de bajo

costo y valiosos
Otros son extensos y costosos, pero
cruciales para proveer valor al cliente
Los cambios pueden ser perjudiciales si son
arbitrarios o mal pensados
En general, los cambios de alcance que
resuelven requerimientos evolutivos y que
son tomados con el entendimiento y la
aprobacin de su impacto en el proyecto,
incrementan la probabilidad del xito del
proyecto.

Alcance y features

158

No hay que grabar en placas doradas los

requerimientos.
Dupont estima que slo el 25% de los
features en su software se necesitan
realmente.
45% de los features nunca fueron usados
Slo 20% se usaron a menudo o siempre
Esto confirma que el deployment parcial
mejora el ROI puede evitar que uno
construya features costosos y no utilizados

Cortar los teams y los proyectos por la mitad,

no acelera el desarrollo y reduce los costos al
mismo tiempo?**

Alcance y features

158

La estrategia de construir unos features

mnimos JUNTO CON la capacidad de
adaptarse fcilmente y razonablemente al
cambio puede ser muy rentable
El desarrollo gil es sobre foco y balance:
foco en la visin clave y metas del proyecto; y
forzar decisiones trade off que logran balance
para el producto
El desarrollo gil planea por feature, por lo
que concentra su proceso de planeacin en
algo que el cliente puede relacionar y
priorizar fcilmente.

Alcance y features

El alcance del producto se basa en:

valor del cliente

factibilidad tcnica y costo
Impacto en la adaptabilidad del producto
necesidades crticas del calendario del cliente

158-159

No debe ser rehn de un conocimiento inicial incompleto

Las iteraciones cortas combinadas con las revisiones

por el cliente al final de cada iteracin llevan al
equipo completo desarrolladores, clientesy
gerentes- a enfrentar la realidad.
Podemos tomar un documento de requerimientos y
estimar el tiempo que llevar desarrollar y probar el
cdigo, o podemos construir un conjunto pequeo de
features y medir cuanto tiempo llev desarrollarlos.*

159

Anlisis y mitigacin de riesgos

El anlisis y la mitigacin de riesgos son parte
integral de cada fase y proceso del APM
El diseo de un producto evoluciona de
entender los requerimientos y las
restricciones y de entender la ciencia y la
ingeniera subyacentes.
Los riesgos dominantes en el software

Problemas inherentes al calendario

Inflacin de requerimientos
Partida de empleados
Derrumbe de las especificaciones
Productividad pobre

Riesgo

160

La mejor estragegia de mitigacin de riesgo es la

entrega incremental
Para un producto altamente incierto, la falla en
cumplir un calendario pueda no ser defecto, sino la
pura imposibilidad de calendarizar lo desconocido.
Las tcnicas APM dirigidas al riesgo:

Involucracin fuerte del team en planeacin y estimacin

Feedback temprano sobre la velocidad de entrega
Presin constante para balancear el nmero y profundidad
de los features con las restricciones de calendario
Interacciones cercanas entre los equipos de ingeniera y de
clientes
Deteccin/correccin temprana de errores para mantener un
producto limpio y funcional

Riesgo

APM posee una mitigacin built-in contra la partida

de empleados gracias al nfasis en la colaboracin
El derrumbe de las especificaciones ocurre cuando
cuando los clientes o los gerentes de producto fallan
en acordar las especificaciones.
Productividad pobre:

161

Gente equivocada en el equipo

El team no trabaja bien en conjunto
Baja moral

Riesgo para productos nuevos

pobre investigacin de mercado

problemas tcnicos
insuficiente esfuerzo de mercadeo
mal timing

Sumario de la fase

Tres actividades claves a completar antes de

empezar a desarrollar features

1.
2.
3.

164

Articular una visin de producto

Definir el alcance y restricciones del proyecto
Crear un plan de entregas iterativo, basado en features

Este ltimo es el principal deliverable de la fase de

especular
Cuando se logra la lista de features y el release
plan, el resto es relativamente fcil
La planeacin basada en features obliga a los
equipos de ingeniera y de clientes a entender el
producto de modos que la planeacin basada en
tareas raramente lo hace.

EXPLORAR

Cap 7 165

166

Un Complex Adaptive System (CAS) es una

coleccin de agentes que exploran para
lograr una meta (aptitud en el sentido
biolgico) mediante la interaccin entre ellos
segn un conjunto de reglas.
Un CAS experimenta con alternativas,
selecciona y ejecuta las viables, compara los
resultados contra las metas (objetivos del
sistema) y se adapta segn sea necesario.

Liderazgo Colaboracin

166

El

modelo CAS es una metfora til

para un estilo de gerencia del tipo
liderazgo-colaboracin, el cual estimula
un comportamiento:
emergente

(innovador)
tomador de riesgos
Bajo

esta luz, las tareas claves

gerenciales son:
Establecer

una visin
Crear un ambiente de trabajo colaborador

Gerencia
El

167

fin de la fase de exploracin es

entregar features probados y
aceptados, pero en lugar de
concentrarse en los detalles tcnicos
de cmo lograr esta meta, el gerente de
proyecto gil se concentra en crear un
equipo auto-organizado, autodisciplinado para que pueda lograr la
meta ltima.

Contribucin de la gerencia

167

Enfocar al team a que d resultados

2. Hacer un team de un grupo de individuos
3. Desarrollar las capacidades de cada
individuo
4. Proveer al team con los recursos
requeridos y removerle obstculos
5. Asesorar a los clientes
6. Orquestar el ritmo del team
Rol esencial: Crear un team de alto rendimiento
a partir de un grupo de individuos.
1.

Prcticas de la fase

Dar resultados segn la visin y los objetivos

Workload management

Prcticas tcnicas

168

Cambio a bajo costo

Comunidad del proyecto

Coaching y desarrollo del team

Reuniones diarias de integracin
Toma de decisiones participativa
Interaccin diaria con el team del cliente

Prctica
Workload Management
169

Fin: lograr que los miembros del team

manejen las actividades diarias requeridas
para dar resultados al final de cada iteracin
Los miembros del team deben manejar su
propia carga en la mayor medida posible
Los gerentes de proyecto dan la direccin en
lugar de controlar

Prctica
Cambio a bajo costo
171

Meta: crear un producto adaptable

Mantener a un mnimo el costo del cambio y
de la experimentacin, lo que expande las
posibilidades de diseo.
Cuatro prcticas

Diseo simple
Integracin frecuente
Despiadados con las pruebas
Refactura oportunista

Deuda Tcnica

171

Cuando los equipos de desarrollo y soporte le

dan apoyo slo del diente al labio a
excelencia tcnica; cuando los gerentes de
producto y de proyecto empujan al equipo
ms all de lo rpido para caer en la prisa, se
incurre en deuda tcnica.
La deuda tcnica puede surgir durante

el desarrollo inicial
el mantenimiento ordinario
las ampliaciones

APM dar valor del cliente hoy y maana.

La deuda tcnica se refiere a maana.

172

La deuda tcnica
resulta del
apresuramiento

Costo del Cambio

CdC real

Release del
producto

Deuda tcnica
CdC ptimo
1

6
aos

Deuda tcnica

172

El incremento de la deuda tcnica reduce

directamente la responsividad a los clientes.
Sin una dedicacin firme al manejo de la deuda
tcnica de largo plazo, los grupos de desarrollo se
ven forzados a aumentar la trampa de la deuda.
En cuanto peor se vuelve la deuda, los atrasos son
mayores, y en cuanto ms se extienden los atrasos,
sube la presin que lleva a otra implementacin
apresurada, lo que incrementa otra vez la deuda
tcnica.
En cuanto ms grande es la deuda, ms caro es
corregirla porque cuesta ms justificarlo, por lo tanto,
contina la espiral de muerte.

Deuda tcnica

172

No hay incentivo para disminuir la deuda tcnica al

principio del ciclo de vida del producto, cuando es
barato, porque los atrasos son todava cortos.
El secreto para la reduccin de la deuda tcnica a
largo plazo est en hacerlo temprano y seguido,
cuando el costo es bajo
En cuanto ms baja la deuda tcnica, ms barato es
corregirla, cuesta menos justificar y este crculo
virtuoso se refuerza a s mismo.
Reducir la deuda tcnica, mantener bajo el costo del
cambio, tiene que ser una estrategia tnica y parte
de la dedicacin de una organizacin a la excelencia
tcnica.

Deuda tcnica
Una

173

estrategia de deuda tcnica no se

dirige a proteger al producto de la
obsolescencia, sino que a mantener
bajo el costo del cambio, de modo que
la capacidad de respuesta al cliente se
mantenga lo ms alta que se pueda
durante la vida del producto.

Diseo simple

173

Objetivo: mantener al aquipo afincado sobre

lo conocido en lugar de anticipar lo
desconocido.
Hay dos enfoques fundamentales hacia el
manejo del cambio que deben aparecer en
las buenas estrategias de diseo:

Anticipacin
Adaptacin

Anticipacin: predecir los cambios y planear

Adaptacin: esperar que evolucionen los
requerimientos o que los cambios se
manifiesten.

Adaptacin

173

Tambin significa experimentar, elegir los experimentos

con los mejores resultados e incorporar los resultados
en el producto.
En cuanto ms bajo sea el costo del cambio, ms bajo
es el costo de experimentacin y ms alta es la
probabilidad de innovaciones significativas.
Si hay posibilidades de que algo cambie, debemos
disear el sistema para que incorpore fcilmente ese
cambio.
Diseo simple significa darle valor a la adaptacin por
sobre la anticipacin
La maleabilidad del producto depende del bajo costo
de la iteracin.

Cuando los componentes no son maleables, se prefiere la

anticipacin.

Integracin frecuente
Busca

175

asegurar que los features

encajan juntos en un todo integrado lo
ms antes y ms frecuentemente
posible.

Despiadados con las pruebas

178

El fin es que la calidad del producto se

mantenga alta a lo largo del proceso de
desarrollo.
Contribuye a la meta de crear productos
adaptables porque al encontrar faltas pronto,
cuando todava hay tiempo para corregirlas,
se reduce el costo del cambio.

Integrar QA y pruebas de aceptacin en cada

iteracin
Disponer de un conjunto completo de pruebas
automatizadas

La meta final es sacar un producto instalable,

de features limitados, de cada iteracin.

Refactoring oportunista

El fin es mejorar el diseo del producto

constantemente y continuamente hacerlo ms
adaptable- para lograr la doble meta:

179

proveer valor del cliente hoy

proveer valor del cliente maana

Hay que incluir una disciplina de refactoring a nivel

de producto en el proceso de desarrollo.
Refactoring implica actualizar los componentes
internos (mejorar el diseo) sin cambiar la
funcionalidad externa, para poder mejorar el
producto en el futuro.
Dado el ritmo de cambio, nuestros diseos deben
mejor basarse en lo que conocemos hoy y en
nuestra disponibilidad de emprender rediseos en el
futuro.

Refactoring oportunista

180

El refactoring mejora el diseo del producto pero no

agrega nueva funcionalidad* mejora la
adaptabilidad.
Agregar nueva funcionalidad usualmente pide
rediseo
En cuanto mayor sea el ritmo de cambio en los
features de un producto, ms rpido se degradarn
la arquitectura o el diseo.
Axioma antiguo: Hgalo bien desde la primera vez
para mantener el costo del cambio bajo
El nuevo axioma: no importa cuan bueno sea la
primera vez, siempre cambiar, por lo tanto
mantenga bajo el costo del cambio.

Disciplina de refactoring en el desarrollo

Refactoring oportunista

181

Hay cada vez ms disposicin de los

gerentes de producto a invertir en refactoring
una vez que entienden la situacin
Con clientes clamando por ampliaciones y
con ciclos de de desarrollo que se alargan
debido a la deuda tcnica, su situacin actual
es insostenible.
Dos factores son los ms importantes

Pruebas: hay que integrarlas en el proceso de

desarrollo y automatizarlas todo lo que se pueda.
Persistencia: hacer un poco de rafactoring de
cdigo cada vez que se contempla un cambio,
siempre tratando de dejar el cdigo un poco mejor
que antes.

Persistencia

181

Significa pensar en rediseo durante cada

iteracin y asignar algn tiempo a
implementar los rediseos.
Significa planear algn nivel de refactoring
para cada nuevo release de producto
Significa ir construyendo de modo lento pero
seguro pruebas automticas e ir integrando
las pruebas dentro del proceso de desarrollo

CREANDO EQUIPOS
ADAPTIVOS GRANDES

Componentes

238

Estructura organizacional basada en hubs

Extensiones de auto-organizacin
Auto-disciplina de equipo
Prcticas adicionales

Un team de proyecto consiste de individuos agentes casi

independientes- que interactan dentro del a estructura de un
team y reglas auto-disciplinadas de participacin (cmo
interactan los unos con los otros)
A los individuos se les da flexibilidad y un grado de autonoma
dentro de esta estructura maleable, y ellos, a su vez, ejercitan
auto-disciplina para responsabilizarse por los resultados y para
comportarse como miembros responsables y conscientes del
team.
En el caso de los teams grandes que consisten de sub-teams, los
agentes son los sub-teams.

Project
Management Team
Project
Manager

Team del cliente

Product
Manager

Teams de Features
A-N
Team
Lead

Miembros fijos y
part-time
Team de
Arquitectura
Team
Lead

Team de integracin
y construccin
Team
Lead
puede ser virtual

Extensiones de autoorganizacin
241

Conseguir los lderes adecuados

Articular la descomposicin del trabajo y las
estrategias de integracin
Estimular la interaccin y el flujo de informacin entre
teams
Enmarcar la toma de decisiones a nivel de proyecto
El lder del proyecto se asegura que cada individuo
comprenda la visin del producto y la parte de su
sub-team dentro de esa visin
En proyectos grandes, los subteams pueden tambin
hacer el ejercicio de envision para su porcin del
producto.

Adems de conocer sus responsabilidades, cada

sub-team necesita saber su rol respecto de los otros
sub teams

por ejemplo, un sub-team de features necesita saber cmo

interactar con el sub-team de arquitectura

Los proyectos grandes son casi siempre de algn

modo proyectos distribuidos
Hay que enfrentar aspectos de distancia, cultura y
experticia
Definir los roles y responsabilidades de los subteams
es un paso inicial para tratar con los aspectos de
distribucin