You are on page 1of 118

Agile Project Management

Fases

81

 Envision: visión del producto, alcance del

proyecto, comunidad del proyecto, forma de trabajo

 Especular: Plan de release, milestones e

iteraciones basado en features para materializar la
visión

 Explorar: entregar features probados en un

período corto, tratando constantemente de reducir el
riesgo y la incertidumbre del proyecto

 Adaptar: revisar los resultados, la situación actual,
el desempeño 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 visión del producto y del alcance del
proyecto
 Segundo: visionar quien tomará parte–

clientes, miembros del team e interesados
(stakeholders)
 Tercero: los miembros del team visionarán

cómo 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 asignación
de recursos para esos features
 Incorporar estrategias de mitigación de
riesgos
 Estimar costos del proyecto y generar otra
información 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 prácticas técnicas apropiadas y
estrategias de mitigación 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 más importante que
seguir un plan
 Después de la fase ‘envision’, el loop será:
especularexploraradaptar
 Cada iteración refina sucesivamente el
producto
 Los resultados son vistos desde las
siguientes perspectivas:





Del cliente
Técnica
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 iteración y el del proyecto global) es aprender para incorporar ese conocimiento en la próxima iteración o para pasarlo al próximo proyecto .

Prácticas .

 Las prácticas seleccionadas:    Generativas. sin aplicar el juicio. no prescriptivas Enfocadas en delivery y no en compliance .Consideraciones 84-86 Siempre se requiere el juicio: sobre-enfatizar la linearidad lleva a la parálisis y sobreenfatizar la evolución lleva al cambio sin fin y eventualmente sin sentido.  Los principios sin prácticas son inefectivos ylas prácticas sin principios tienden a implantarse mecánicamente.

Fase: Envision 87 .

es crítica para el éxito del proyecto ¿Por qué falta tantas veces? Respuesta:   Una visión clara es difícil: requiere trabajo duro y liderazgo . compelidora.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 visión del producto deben ser clarísimas  Sin una visión clara se arriesga experimentar sin fin.  Una visión clara.

Preguntas que resuelve  ¿Cuál 89 es la visión del producto del cliente?  ¿Cuál es el alcance del proyecto y su juego de constraints?  ¿quiénes son los participantes adecuados para la comunidad del proyecto?  ¿Cómo entregará el equipo el producto (enfoque)? .

91 Evolución del plan del producto Vision Alcance Feature s Tres Herramientas simples y poderosas  Vision Box – Forza a condensar la visión  Project Data Sheet – Forza a decantar detalles claves de alcance y constraints  Feature Cards – Obliga a condensar la información de cada feature en una ficha .

Por ejemplo. si la arquitectura evoluciona. la estructura del team pueda necesitar evolucionar.Siempre recordar 91 ¿Cuál es la documentación 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 prácticas van a evolucionar.  .

Las prácticas .

Las prácticas (4 categorías)  Visión del producto    Data sheet del proyecto Comunidad del proyecto     Caja de la visión 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 prácticas .

.Caja de Visión del Producto y Test del Elevador (Práctica) 93  Objetivo  Estimular a los miembros del team a que focalicen sus ideas desperdigadas del producto en una forma concisa. desarrollo y gerentes. visual y textual.  Estos dos mecanismos proveen un concepto común elevado del producto para mercadeo.

 Una buena visión del producto es constante.Desarrollo de la Discusión 93 No se puede predecir la innovación ni la creación de productos emergentes.  Los resultados emergentes a veces provienen de accidentes intencionales.  . por lo tanto hace falta un proceso especial. mientras que la vía para implementar esa visión necesita espacio para jugar. por lo tanto es necesario crear el ambiente para que ocurran estos accidentes.

Diseñando al caja del producto 93-94 Se trata de diseñar las partes frontal y trasera de la caja del producto  Esto implica       Nombre del producto Un gráfico Tres a cuatro bullets claves en el frente Descripción 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 distribución de las empresas medianas. . A diferencia de los otros productos. el Supli-Robot es un sistema robotizado de levantado y transporte de carga que provee re-ubicación dinámica de la carga dentro de la bodega y cargado de camiones con cajas de tamaños variados que reduce el costo de distribución y el tiempo de carga. que necesitan funcionalidades avanzadas de movimiento de cajas. nuestro producto es altamente automatizado y con precios agresivos.

Test del Elevador Formato 95 Para (cliente objetivo)  Que (exposición de la necesidad o de la oportunidad)  El (nombre del producto) es (categoría del producto)  Que (Beneficio clave. razón para comprarlo)  A diferencia de (Alternativa competitiva primaria)  Nuestro producto (exposición de la diferenciación primaria)  .

para mantener bajos los costos de exploración. volúmenes) Análisis competitivos Indicadores financieros críticos** 95 . es crítico disponer de un concepto nuclear. facilidad de uso. una visión. Después de varias horas de discusión:          Mission statement Dibujo de la caja Clientes objetivo y sus necesidades El test del elevador Medidas de la satisfacción del cliente Requerimientos clave operacionales y de tecnología Restricciones críticas al producto (Performance.Más sobre visión del producto   Para proyectos con alto grado de incertidumbre.

la organización de componentes y módulos puede influir la decisión de desarrollo distribuido y sobre la gerencia de los grupos distribuidos La arquitectura es guía. no camisa de fuerza.Práctica Arquitectura del Producto   Objetivo: Mostrar la plomería interna del proyecto – un diseño que facilita la exploración y guía el continuo desarrollo del producto. . La arquitectura junto con el tamaño total del proyecto contiene implicaciones importantes para el éxito del proyecto y del producto   98 P. Busca comunicar el contexto mayor al team. Guía el trabajo técnico y a la organización de la gente que desarrolla ese trabajo técnico. ej.

Feature Breakdown Structure  Gerencia de Ventas (Business Area)  Prospectación (Business Activity)       Crear pantalla log on de vendedores (Feature) Listar leads para los vendedores Desplegar detalles individuales por lead Administración de territorios Análisis de ventas Marketing     Generación de leads Seguimiento de leads Colocación de anuncios Servicio de Call Center 98 .

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 organización humana y la arquitectura técnica 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. módulos Hay otras arquitecturas útiles para los equipos técnicos.99-100     Las arquitecturas utilizan una combinación de elementos de: plataforma. interfaz. componente. sub-teams basados en componentes pueden funcionar mejor .

3) Todo feedback de empleado por interacción debe darse por clicks  Cada principio debe describirse en una o dos proposiciones y su número total para un proyecto.  Ejemplos: 1) Toda interacción siempre será  cerrada. en cualquier momento. 2) Toda interacción debe buscar un feedback.Principios guía 100-101 Esta es una segunda pieza de la guía arquitectónica  Estos principios asisten al team para que moldee el producto según las preferencias de los clientes. no debería exceder de 10 .

 Es la segunda más importante práctica de la fase de Envision . calendario y recursos.Práctica 101 Project Data Sheet – PDS  Objetivo: transmitir la esencia en términos de alcance. de cómo el proyecto materializará la visión.

0) .Project Data Sheet Product vrs Project vision 101-102 La visión del producto es una vista expandida de lo que el producto podría llegar a ser  La visión del proyecto limita el desarrollo del producto a los confines de lo definido en: alcance. y restricciones de costos. calendario.    Product vision  should haves – 234 features Project scope  will have – 126 features (Rel 1.

Secciones de una PDS 102 Clientes: lista de clientes clave  Project Manager  Product Manager  Project Objective Statement (POS)  Tradeoff Matrix (TOM)  Factor de exploración  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* x Recursos x *Defectos Una entrada/columna Conviene medir límite .

 Las filas muestran las dimensiones claves que crean el valor del producto  Las columnas despliegan la importancia relativa de cada dimensión .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.

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 .

 . pero más importante es ajustar los procesos y las prácticas al problema y ajustar las expectativas correspondientemente  Resulta de combinar la volatilidad de los requerimientos del producto con lo nuevo – inicierto.Factor de Exploración 105-106 Barómetro de la incertidumbre y del riesgo  Relacionado con el “problem domain” donde el team operará  10 indica un problem domain orientado a la exploración (alto riesgo) y 1 indica un ambiente de problemas estable  Importante identificar los factores del problem domain.de la plataforma tecnológica.

Factor de Exploración 107 Dimensión de Tecnología Dimensión de producto Bleeding Leading Bien Familiar Edge Edge conocida 10 8 7 7 Fluctuante 8 7 6 5 Rutina 7 6 4 3 Estable 7 5 5 1 Errática 10: problem domain que requiere mucha exploración 1: ambiente del problema muy estable .

.  Proyectos 8.Problem Domain 107 Es necesario establecer la incertidumbre global del espacio del problema. 10 requieren un enfoque fuerte APM       Iteraciones cortas Planeación 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 específicos y asegurar el éxito. 9.

la tecnología. la organización. La pregunta sobre los ‘quienes’ es la más prioritaria. la estrategia. sino la gente apropiada para el trabajo.Práctica Consiga la gente correcta 108 ‘El’ factor crítico de éxito  ‘Correcta’ quiere decir:      Capacidad técnica apropiada o experticia en el ‘domain’ El comportamiento disciplinado adecuado No significa la más talentosa y experimentada. la táctica. sobre las ‘qué’ – antes que la visión. .

Los participantes son los que pertenecen a la comunidad del proyecto:      Clientes – determinan e influyen los requerimientos Ejecutivos – proveen fondos y supervisión gerencial Miembros nucleares del team – trabajan para entregar el producto. los stakeholders proveen el conjunto de restricciones. los requerimientos de cumplimiento y los recursos . Stakeholders – Participantes internos que no son clientes directos Los clientes proveen los requerimientos. los miembros del team fabrican el producto.Práctica 111 Identificación de participantes   Objetivo: identificar a los participantes de modo que las expectativas sean entendidas y administradas.

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: guía al equipo para determinar qué resultados dar Ingeniero líder: guía los aspectos técnicos de las entregas Gerencia: una gama potencialmente amplia de individuos con alguna autoridad técnica 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 información. reportes y certificaciones .

Fase: Especular 127 .

Ideas preliminares 128 El control de cambios congela los requerimientos  El alcance mismo también evoluciona  De resistir el cambio a estimular el cambio  El control de cambios se refiere a la coordinación no a la negación  Flexibilidad indisciplinada  caos  Estabilidad indisciplinada rigidez  Balance entre flexibilidad y estructura mediante auto disciplina  .

 .Ideas preliminares 2 129 Los planes son guías. no camisas de fuerza  La realidad siempre se entromete  Los planes son vehículos para abrazar el cambio. no para bloquearlo  Los planes son:    Conjeturas acerca del futuro Guías para el futuro El desarrollo genera nueva información que a su vez crea la necesidad de re-planear  No es riesgo loco sino: “conjeturar algo basado en hechos e información 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 información de:        Especificaciones del producto Arquitectura de la plataforma Recursos Análisis de riesgo Niveles de defecto Restriccciones de negocios Calendario deseado .

 .129-130  Dos componentes cruciales en un enfoque de planeación y desarrollo iterativo   Ventanas pequeñas de iteración Features Para proyectos de SW: cada ventana de 2 a 6 semanas  Las ventanas cortas aceleran el desarrollo  La primera meta de la planeación y desarrollo basado en features es hacer el proceso visible y entendible.

recortemos los features 31 y 64”. en lugar de: “recortemos el tiempo de tests” .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: información del feature Detrás: información de la tarea técnica para estimar esfuerzo y administrar el trabajo “Estamos atrasados.

Ayudas que da esta fase 130-131 Determinar cómo el producto y sus features evolucionarán  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 línea base para analizar eventos que se dan durante el proyecto.  .

y no amonestarlos por no haber hecho un plan .131  Se necesita recompensar al team por su respuesta a los cambios.

milestones. plan de iteraciones .Categorías de prácticas  Estructura 131 de feature breakdown  Lista de features del producto  Feature cards  Tarjetas de requerimientos de performance  Plan de entregas  Entregas.

milestones e iteraciones Iteración 0 Análisis de riesgo Próximo plan de Iteración .132 Lista de Features Feature Breakdown Prácticas Tarjetas de Features Requerimientos Performance Plan de Iteraciones Plan de entregas.

milestones e iteraciones.Práctica 132 Lista de Features del Producto     Expansión de la desarrollada en la fase de envision Esta lista y las tarjetas que le acompañan son el insumo principal para la planeación de entregas. El software no es muy estricto para exigir todas las especificaciones desde un inicio. Para cada feature crea una tarjeta que contiene información básica descriptiva y de estimaciones. . por lo tanto le aplica un proceso evolutivo de especificaciones.

.Jerarquía de features 133  Producto  Area  de business subject Business activity  Feature  Pequeños productos podrían usar sólo 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 propósitos de planeación y de
entregas de los proyectos, el team necesita
incluir features de tecnología o componentes,
donde se muestran separados de los otros.

El peligro: construir muchos componentes
tecnológicos o de infraestructura antes de construir
algo con significado directo para el cliente
En cuanto más tiempo pasa por allí debajo, más
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 ingeniería discutirán aspectos
de calendario durante las asignación de
features a las interaciones de desarrollo.
 Una característica de los proyectos APM es la
volatilidad de los features en esta lista.
 Durante la planeación para cada iteración, la
lista de features a incluir puede cambiar
significativamente en relación al plan original

Práctica

Feature Cards
 Objetivo:

135

medio sencillo para juntar
información sobre los features, registrar
requerimientos de alto nivel y
desarrollar estimados de trabajo.
 El desarrollo basado en features
pretende ser desarrollo customer-facing

La discusión es crítica para entender la que a su vez es crítica para estimar Identifican features que los clientes quieren en el producto Para proyectos grandes.Feature Cards Discusión       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. se pueden usar ‘group cards’ por business activity para organizar y planear listas individuales de features. 15 o 20 La información 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 . de 10.requerimientos durante una iteración.

Feature Card Iteración planeada: 3 No.S): R (rutina) Dependencia de otros features: ninguna Tests de Aceptación: . de Feature: 25 Tipo de feature: cliente Nombre de feature: Establecer territorios de ventas 136 Descripción del feature: Crear territorios de ventas con base en regiones y áreas metropolitanas estándar Cantidad estimada de trabajo: 4.5 días Incertidumbre de los requerimientos(E.F.R.

. estables): un factor de exploración Dependencias de features: que podrían afectar la secuencia de implementación Tests de aceptación: criterios que el cliente utilizará para aceptar o rechazar el feature.Contenido de Feature Card        136 Identificador y nombre del feature Descripción: una o dos oraciones en términos del cliente Tipo de feature (C=customer. codificación. T=técnico) Trabajo estimado: lo que lleva producir el feature. Incertidumbre de los requerimientos (erráticos. rutinarios. e incluye tiempo para recoger requerimientos. pruebas y documentación. diseño. fluctuantes.

probar y documentar el feature. Features altamente inciertos podrían requerir investigación adicional antes de planearlos. podría requerirse una serie de prototipos de descubrimiento. Features de alto riesgo se calendarizaran en las iteraciones iniciales para que el team pueda determinar primero si el feature puede ser implementado. Si es difícil fijar los requerimientos.Capa debajo de los features      137 Para planear la próxima iteración hay que voltear las tarjetas y listar las actividades técnicas requeridas para: especificar. y segundo. si se puede. si llevará más tiempo y dinero de lo previsto. construir. Se pueden combinar las actividades técnicas de varios features en un solo paquete técnico de trabajo. . diseñar.

 Suelen ser de diferente color que las de features  Contienen: nombre. descripción.  . metas cuantitativas de performance  Contienen también los correspondientes ‘criterios de aceptación’ o ‘tests’ en esta área.Práctica Tarjeta de Requerimientos de Performance Objetivo: documentar las operaciones clave y los requerimientos de performance del producto.

M.L) M (moderada) Criterio de aceptación a.<2 seg en iteración 3 b.<1 seg en iteración 6 .Tarjeta de performance Iteración demostrada: 6 Performance ID: PC-12 Nombre del aspecto Inicio del Interaction Manager Descripción del performance El IM debe intervenir antes de transcurrido un segundo de detectada la interacción Dificultada para lograrla (H.

 Los ciclos APM son iterativos y guiados por features. Milestones e Iteraciones Representa el mapa de cómo el team pretende lograr la visión del producto dentro del alcance y las restricciones del proyecto -identificados en la Project Data Sheet. que es instanciada por features) es que mantiene la sincronía entre el cliente y el equipo de desarrollo.    Cambia el foco de la planeación y la ejecución de tareas a features de producto Otra ventaja de basar los planes en features (Y su arquitectura. .Práctica 140-141 Plan de Releases.

142  Las iteraciones producen features que han pasado los criterios de aceptación   La meta es disponer de un producto con features parciales y que pueda entregarse al final de cada iteración. Incremental delivery Milestones son puntos intermedios de uno a tres meses y pueden tener funciones gerenciales y técnicas  Su uso más importante: Puntos fuertes de sincronización e integración  .

dependencias y otras. prioridad •Todas las demás consideraciones de calendarización – disponibilidad de recursos. prioridad 1a. milestones e iteraciones para asignar features:   Valor del cliente Riesgo Alto riesgo Alto valor Bajo Valor Bajo riesgo 2a.Factores 143 Dos factores guían el plan de releases. Prioridad 3a.se subordinan a valor y riesgo .

(Contendrá algún diagrama de arquitectura en lugar de un feature implementable)  Ejemplo de un release plan  .  Por ejemplo.  Para cada uno de estos items debe crearse una feature card.Iteración 0 143 . un proyecto pudiera requerir alguna aequitectura de datos para desarrollar interfaces.144 Es una práctica que ayuda a ubicar el terreno medio entre anticipación y adaptación – El ‘0’ significa que no se entrega nada útil para el cliente en este período.

El plan resultante se puede ver así. costos y otra información de planeación del proyecto. staffing.Iteraciones 1-N  Se 144 necesita crear un plan que asigna features a iteraciones por la duración del proyecto para lograr un ‘feel’ del flujo del proyecto y determinar la fechas de compleción. .

2 Feature 3 Feature 5 Feature 1 Investigación Requerimientos Feature 3 Feature2 Feature 7 Iteración 4 Iteración 4 Tarjeta tema Feature 4 .PLANO DE FEATURE CARDS 146 Iteración 0 Arquitectura 1.1 Arquitectura 1.0 Iteración 1 Iteración 2 Iteración 3 Iteración 1 Tarjeta tema Iteración 2 Tarjeta tema Iteración 3 Tarjeta tema Arquitectura 1.

recursos y dependencias Sumarizar el plan en combinaciones de hoja a nivel de feature. parking lot Calcular el calendario inicial según disonibilidad de staff y el total estimado de trabajo Ajustar el plan cuando sea necesario . riesgos.Las Actividades para hacer el plan de iteración Incluyen 146         Determinar cómo los riesgos identificados influirán en la planeación Identificar la meta del calendario Establecer los períodos de milestone y de iteración Desarrollar un tema para cada iteración Asignar feature cards a cada iteración balancenado prioridades del cliente. plano de feature cards.

 La interdependencia entre features influye en la asignación.  . pero los más importantes son valor del cliente y riesgo.147 Mientras que con criterios de cliente se asignan features a las iteraciones.  Algunas veces se implementan primero los features de alto riesgo con el fin de reducir riesgos. aspectos de riesgo ténico pueden influir en estas decisiones.

149  Para cada iteración y milestone.        Esto es importante para que el team balancee entre amplitud y profundidad de los features Lo mejor para esto son tarjetas de iteración (ver ej en lámina siguiente) La ventaja de las tarjetas es que se pueden barajar durante las sesiones de planeación La información de las interdependencias de features debe estar en las feature cards. Un fc llamada “Re-trabajo y contingencia” se coloca en cada iteración. .148. el equipo debe desarrollar y escribir un tema guía. Se pueden acomodar también iteraciones vacías Los features asignados a los últimas iteraciones son los que se pueden botar si hiciera falta.

3 Tema: Captura de feedbacks para crear el rich log Comentario Las funciones avanzadas se verán en la iteración 7 Supuesto: Las simulaciones probarán un 80% de la funcionalidad .149 Tema de una iteración Iteracion No.

Gerencia de Ventas (GV) 150 Análisis de Ventas (18) Prospectación (10) Manejo de Territorio (8) 0 0 0 May 2004 Jun 2004 Jul 2004 Marketing (MM) (8) Pautar Anuncios (9) Servicio Call Center (28) 0 0 0 0 May 2004 Ago 2004 Sep 2004 Oct 2004 Generación Leads (22) Seguimiento Leads .

Planeación y Reportes a Nivel de Componentes o Actividad de Negocios .

 Una aplicación grande puede contener miles de features     El team de desarrollo necesita el detalle Clientes y gerentes pueden ser más efectivos a un nivel más grueso de ganularidad Para estos casos: FDD  Feature Driven Development . al menos para muchos clientes y gerentes.150 Para proyectos de mediano a grande. la planeación a nivel de feature es demasiado fina.

la jerarquía sería:  Business Subject Area (Ventas)  Business Activity (Análisis de ventas)  Feature: (Generar un reporte de ventas de producto por territorio) .150 Feature-Driven Development  Se basa en una jerarquía granular de features  En el caso del Manager Plus.

Este enfoque de “dos capas” para la planeacion puede ser muy efectivo. y se deja la calendarización a nivel de feature al equipo de ingeniería. pueden tener de 30 a 50 actividades y varios miles de features En estos casos se puede ver la calendarización por gerencias altas a nivel de componente o actividad. De Luca divide el dominio técnico en tres grupos de features :       User Interface Database Systems Interface .151 FDD  Aplicaciones grandes. como un CRM.

y de allí. d) un parqueo del proyecto . puede contribuir al entendimiento del producto.152 FDD    Aún con proyectos más pequeños. identificar nuevos features. b) una FBS. c) un plan de iteración con las feature cards. una jerarquía de actividad y features puede ayudar a un team a pensar en el producto Listar features y después organizarlos en actividades o comenzar con actividades genéricas de proyectos previos o de investigación de productos. En cualquier caso los artefactos finales de una actividad de planeación incluyen una combinación de: a) feature cards.

.  Asignar todos los features y luego comparar la fecha planeada (con todos los features) con la fecha meta.152 Tres tipos de planes de iteración  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.

los calendarios iniciales pueden contener demasiados “sis”. La decisión por uno de estos dependerá de:   Naturaleza del proyecto Expectativas de clientes y stakeholders Todo debe preverse en la fase de ‘Envision’ . Un plan de iteración por iteración. utilizando sólo la próxima interacción.152-153 Para proyectos con alto grado de exploración. Dependiendo del grado de incertidumbre se puede hacer.    Un plan completo con features asignados a cada iteración Un plan para dos iteraciones. y dejar todo el resto para después.

El team toma cada feature card y construye una lista de las actividades técnicas requeridas para implementar el feature. El equipo re-estima el trabajo con base en el examen más detallado y ajusta los features planeados para esa iteración Finalmente. y las anota en el reverso. el team regresa a hacer un plan detallado de la próxima (o primera) iteración.153 Plan de la próxima iteración     Una vez acordado el plan global de entregas para el proyecto completo. los miembros se apuntan para features o actividades basados en sus propias habilidades y/o deseos* .

en lugar de features cruzados . ej. Deployment Factible  Puesto que un deployment rápido conlleva muchos beneficios.154 1er. p. algo que el team puede hacer es determinar este FFD: First Feasible Deployment   Se puede hacer una instalación temprana a clientes clave que han pedido el producto Para el team puede traer a) Ingreso anticipado. se podría escoger terminar los features de una sola área. b) feedback valioso   Ojo: los costos de deployment podrían ser más que los beneficios Si se piensa hacer esto. hay que preverlo desde el principio.

cada iteración 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. mientras que el desarrollo incremental realiza el deployment de las piezas del producto En algunos tipos de desarrollo de SW.* Al identificar la iteración FFD los equipos de cliente y téncnico logran una idea de cuándo el producto puede ser rentablemente instalado Si el FFD se corre al final del proyecto.155 Deployment    El desarrollo iterativo crea piezas ‘deployable’ del producto. ej. Web. p. puede indicar un riesgo .

2. Cómo estimar lo desconocido Cómo estimar por features en lugar de actividades Cómo hacer una estimación progresiva .155 Estimando ¿Cómo se estima un proyecto ágil? Respuesta: con las mismas técnicas de siempre  Hay tres sutilezas detrás de la pregunta 1. 3.

tiempo y costo son vistos como restricciones.  Por lo tanto. no como estimados  Se aprende a vivir con la incertidumbre en lugar de demandar certidumbre de un mundo de cambios vertiginosos. .Primero 156  ¿Cómo se estima lo desconocido? No se puede – se adivina.

la planeación basada en features provee mejores estimados  . hacerlo por cada feature. ej. en lugar de estimar levantado de requerimientos para todo el proyecto. P.Segundo  156 Los proyectos ágiles se planean por features  La experiencia en puras tareas debe emplearse en estimar tareas para cada feature. en la mayoría de los casos. Un equipo que ha pasado varios días identificando features y asignándolos a iteraciones usualmente logra un mejor entendimiento del producto que los que se han basado en planeación de puras tareas  Por lo tanto.

ej. los miembros del team deben mejorar para estimar la próxima iteración.Tercero 156 Los buenos gerentes de proyecto siempre han tratado de emplear prácticas de estimación progresiva. completar la definición de requerimientos antes de estimar el resto del proyecto.  .  APM es un proceso fundamentalmente progresivo de estimación y de entrega que refleja la forma verdadera en que la información se revela en el tiempo. p.  Mientras avanzan las iteraciones. lo que mejorará también para el resto del proyecto.

incrementan la probabilidad del éxito del proyecto. 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 aprobación de su impacto en el proyecto.  .Evolución del Alcance ¡¿?! 157 Algunos cambios del alcance son de bajo costo y valiosos  Otros son extensos y costosos.

¿no acelera el desarrollo y reduce los costos al mismo tiempo?** .  Dupont estima que sólo el 25% de los features en su software se necesitan realmente.  45% de los features nunca fueron usados  Sólo 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.Alcance y features 158 No hay que grabar en placas doradas los requerimientos.

Alcance y features 158 La estrategia de construir unos features mínimos JUNTO CON la capacidad de adaptarse fácilmente y razonablemente al cambio puede ser muy rentable  El desarrollo ágil es sobre foco y balance: foco en la visión 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 planeación en algo que el cliente puede relacionar y priorizar fácilmente.

Alcance y features  El alcance del producto se basa en:     valor del cliente factibilidad técnica y costo Impacto en la adaptabilidad del producto necesidades críticas del calendario del cliente    158-159 No debe ser rehén de un conocimiento inicial incompleto Las iteraciones cortas combinadas con las revisiones por el cliente al final de cada iteración llevan al equipo completo –desarrolladores. clientesy gerentes. Podemos tomar un documento de requerimientos y estimar el tiempo que llevará desarrollar y probar el código.* .a enfrentar la realidad. o podemos construir un conjunto pequeño de features y medir cuanto tiempo llevó desarrollarlos.

159 Análisis y mitigación de riesgos El análisis y la mitigación de riesgos son parte integral de cada fase y proceso del APM  El diseño de un producto evoluciona de entender los requerimientos y las restricciones y de entender la ciencia y la ingeniería subyacentes.  Los riesgos dominantes en el software       Problemas inherentes al calendario Inflación de requerimientos Partida de empleados Derrumbe de las especificaciones Productividad pobre .

sino la pura imposibilidad de calendarizar lo desconocido.Riesgo    160 La mejor estragegia de mitigación de riesgo es la entrega incremental Para un producto altamente incierto. la falla en cumplir un calendario pueda no ser defecto. Las técnicas APM dirigidas al riesgo:      Involucración fuerte del team en planeación y estimación Feedback temprano sobre la velocidad de entrega Presión constante para balancear el número y profundidad de los features con las restricciones de calendario Interacciones cercanas entre los equipos de ingeniería y de clientes Detección/corrección temprana de errores para mantener un producto limpio y funcional .

Productividad pobre:     161 Gente equivocada en el equipo El team no trabaja bien en conjunto Baja moral Riesgo para productos nuevos     pobre investigación de mercado problemas técnicos insuficiente esfuerzo de mercadeo mal timing .Riesgo    APM posee una mitigación built-in contra la partida de empleados gracias al énfasis en la colaboración El derrumbe de las especificaciones ocurre cuando cuando los clientes o los gerentes de producto fallan en acordar las especificaciones.

el resto es relativamente fácil La planeación basada en features obliga a los equipos de ingeniería y de clientes a entender el producto de modos que la planeación basada en tareas raramente lo hace. 2.Sumario de la fase Tres actividades claves a completar antes de empezar a desarrollar features  1.    164 Articular una visión de producto Definir el alcance y restricciones del proyecto Crear un plan de entregas iterativo. . 3. 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.

EXPLORAR Cap 7 165 .

166 Un Complex Adaptive System (CAS) es una colección de agentes que exploran para lograr una meta (aptitud en el sentido biológico) mediante la interacción entre ellos según 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 según sea necesario.

el cual estimula un comportamiento:  emergente (innovador)  tomador de riesgos  Bajo esta luz.Liderazgo – Colaboración 166  El modelo CAS es una metáfora útil para un estilo de gerencia del tipo liderazgo-colaboración. las tareas claves gerenciales son:  Establecer una visión  Crear un ambiente de trabajo colaborador .

Gerencia  El 167 fin de la fase de exploración es entregar features probados y aceptados. pero en lugar de concentrarse en los detalles técnicos de cómo lograr esta meta. el gerente de proyecto ágil se concentra en crear un equipo auto-organizado. . autodisciplinado para que pueda lograr la meta última.

Desarrollar las capacidades de cada individuo 4.Contribución de la gerencia 167 Enfocar al team a que dé resultados 2. Proveer al team con los recursos requeridos y removerle obstáculos 5. 1. 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. . Hacer un team de un grupo de individuos 3.

Prácticas de la fase  Dar resultados según la visión y los objetivos   Workload management Prácticas técnicas   168 Cambio a bajo costo Comunidad del proyecto     Coaching y desarrollo del team Reuniones diarias de integración Toma de decisiones participativa Interacción diaria con el team del cliente .

Práctica Workload Management 169 Fin: lograr que los miembros del team manejen las actividades diarias requeridas para dar resultados al final de cada iteración  Los miembros del team deben manejar su propia carga en la mayor medida posible  Los gerentes de proyecto dan la dirección en lugar de controlar  .

Práctica Cambio a bajo costo 171 Meta: crear un producto adaptable  Mantener a un mínimo el costo del cambio y de la experimentación. lo que expande las posibilidades de diseño.  Cuatro prácticas      Diseño simple Integración frecuente Despiadados con las pruebas Refactura oportunista .

.  La deuda técnica puede surgir durante      el desarrollo inicial el mantenimiento ordinario las ampliaciones APM  dar valor del cliente hoy y mañana.Deuda Técnica 171 Cuando los equipos de desarrollo y soporte le dan apoyo sólo del diente al labio a excelencia técnica. cuando los gerentes de producto y de proyecto empujan al equipo más allá de lo rápido para caer en la prisa. La deuda técnica se refiere a mañana. se incurre en deuda técnica.

172 La deuda técnica resulta del apresuramiento Costo del Cambio CdC real Release del producto Deuda técnica CdC óptimo 1 4 5 6 años 7 8 .

sube la presión que lleva a otra implementación apresurada. y en cuanto más se extienden los atrasos. En cuanto peor se vuelve la deuda. continúa la espiral de muerte. .Deuda técnica     172 El incremento de la deuda técnica reduce directamente la responsividad a los clientes. En cuanto más grande es la deuda. los grupos de desarrollo se ven forzados a aumentar la trampa de la deuda. los atrasos son mayores. Sin una dedicación firme al manejo de la deuda técnica de largo plazo. por lo tanto. más caro es corregirla porque cuesta más justificarlo. lo que incrementa otra vez la deuda técnica.

Deuda técnica     172 No hay incentivo para disminuir la deuda técnica al principio del ciclo de vida del producto. mantener bajo el costo del cambio. porque los atrasos son todavía cortos. Reducir la deuda técnica. cuando el costo es bajo En cuanto más baja la deuda técnica. cuando es barato. El secreto para la reducción de la deuda técnica a largo plazo está en hacerlo temprano y seguido. tiene que ser una estrategia ténica y parte de la dedicación de una organización a la excelencia técnica. más barato es corregirla. cuesta menos justificar y este círculo virtuoso se refuerza a sí mismo. .

de modo que la capacidad de respuesta al cliente se mantenga lo más alta que se pueda durante la vida del producto. .Deuda técnica  Una 173 estrategia de deuda técnica no se dirige a proteger al producto de la obsolescencia. sino que a mantener bajo el costo del cambio.

 Hay dos enfoques fundamentales hacia el manejo del cambio que deben aparecer en las buenas estrategias de diseño:    Anticipación Adaptación Anticipación: predecir los cambios y planear  Adaptación: esperar que evolucionen los requerimientos o que los cambios se manifiesten.  .Diseño simple 173 Objetivo: mantener al aquipo afincado sobre lo conocido en lugar de anticipar lo desconocido.

. elegir los experimentos con los mejores resultados e incorporar los resultados en el producto. Diseño simple significa darle valor a la adaptación por sobre la anticipación La maleabilidad del producto depende del bajo costo de la iteración. debemos diseñar el sistema para que incorpore fácilmente ese cambio. En cuanto más bajo sea el costo del cambio.  Cuando los componentes no son maleables. Si hay posibilidades de que algo cambie. se prefiere la anticipación. más bajo es el costo de experimentación y más alta es la probabilidad de innovaciones significativas.Adaptación      173 También significa experimentar.

Integración frecuente  Busca 175 asegurar que los features encajan juntos en un todo integrado lo más antes y más frecuentemente posible. .

cuando todavía hay tiempo para corregirlas.     Integrar QA y pruebas de aceptación en cada iteración Disponer de un conjunto completo de pruebas automatizadas La meta final es sacar un producto instalable. de features limitados. . se reduce el costo del cambio.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. de cada iteración.

nuestros diseños deben mejor basarse en lo que conocemos hoy y en nuestra disponibilidad de emprender rediseños en el futuro. Refactoring implica actualizar los componentes internos (mejorar el diseño) sin cambiar la funcionalidad externa. . para poder mejorar el producto en el futuro.para lograr la doble meta:      179 proveer valor del cliente hoy proveer valor del cliente mañana Hay que incluir una disciplina de refactoring a nivel de producto en el proceso de desarrollo.Refactoring oportunista  El fin es mejorar el diseño del producto constantemente y continuamente –hacerlo más adaptable. Dado el ritmo de cambio.

siempre cambiará. Axioma antiguo: Hágalo bien desde la primera vez para mantener el costo del cambio bajo El nuevo axioma: no importa cuan bueno sea la primera vez. más rápido se degradarán la arquitectura o el diseño. por lo tanto mantenga bajo el costo del cambio.Refactoring oportunista      180 El refactoring mejora el diseño del producto pero no agrega nueva funcionalidad* –mejora la adaptabilidad. Disciplina de refactoring en el desarrollo . Agregar nueva funcionalidad usualmente pide rediseño En cuanto mayor sea el ritmo de cambio en los features de un producto.

 Dos factores son los más importantes    Pruebas: hay que integrarlas en el proceso de desarrollo y automatizarlas todo lo que se pueda. su situación actual es insostenible. Persistencia: hacer un poco de rafactoring de código cada vez que se contempla un cambio. siempre tratando de dejar el código un poco mejor que antes.Refactoring oportunista 181 Hay cada vez más disposición de los gerentes de producto a invertir en refactoring una vez que entienden la situación  Con clientes clamando por ampliaciones y con ciclos de de desarrollo que se alargan debido a la deuda técnica. .

 Significa planear algún nivel de refactoring para cada nuevo release de producto  Significa ir construyendo de modo lento pero seguro pruebas automáticas e ir integrando las pruebas dentro del proceso de desarrollo  .Persistencia 181 Significa pensar en rediseño durante cada iteración y asignar algún tiempo a implementar los rediseños.

CREANDO EQUIPOS ADAPTIVOS GRANDES .

y ellos.que interactúan dentro del a estructura de un team y reglas auto-disciplinadas de participación (cómo interactúan los unos con los otros) A los individuos se les da flexibilidad y un grado de autonomía dentro de esta estructura maleable. los agentes son los sub-teams. . ejercitan auto-disciplina para responsabilizarse por los resultados y para comportarse como miembros responsables y conscientes del team. a su vez.Componentes 238 Estructura organizacional basada en hubs  Extensiones de auto-organización  Auto-disciplina de equipo  Prácticas adicionales  Un team de proyecto consiste de individuos –agentes casi independientes. En el caso de los teams grandes que consisten de 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 integración y construcción Team Lead puede ser virtual .

 .Extensiones de autoorganización 241 Conseguir los líderes adecuados  Articular la descomposición del trabajo y las estrategias de integración  Estimular la interacción y el flujo de información entre teams  Enmarcar la toma de decisiones a nivel de proyecto El líder del proyecto se asegura que cada individuo comprenda la visión del producto y la parte de su sub-team dentro de esa visión En proyectos grandes. los subteams pueden también hacer el ejercicio de ‘envision’ para su porción del producto.

un sub-team de features necesita saber cómo interactará con el sub-team de arquitectura Los proyectos grandes son casi siempre de algún 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 distribución . cada sub-team necesita saber su rol respecto de los otros sub teams     por ejemplo. Además de conocer sus responsabilidades.