Agile Project Management

Fases 81Envision: visin del producto, alcance del proyecto, comunidad del proyecto, forma de trabajoEspecular: Plan de release, milestones e iteraciones basado en features para materializar la visinExplorar: entregar features probados en un perodo corto, tratando constantemente de reducir el riesgo y la incertidumbre del proyectoAdaptar: 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 82Primero: visionar qu es lo que se dar una visin del producto y del alcance del proyectoSegundo: 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-83Recopilar los requerimientos iniciales ampliosDefinir la carga de trabajo en la forma de una lista de featuresHacer un plan (release, milestones e iteraciones) que incluya fechas y asignacin de recursos para esos featuresIncorporar estrategias de mitigacin de riesgosEstimar costos del proyecto y generar otra informacin administrativa y financiera requerida

Explorar 83Entrega de features del productoFija 3 reas clave de actividadEntregar features planeados administrando la carga y usando prcticas tcnicas apropiadas y estrategias de mitigacin de riesgosCrear una comunidad del proyecto colaborativa y auto-organizativaAdministrar las interacciones del equipo con: clientes, gerencia del producto y otros stakeholders.

Adaptar 83Responder al cambio es ms importante que seguir un planDespus de la fase envision, el loop ser: especularexploraradaptarCada iteracin refina sucesivamente el productoLos resultados son vistos desde las siguientes perspectivas:Del clienteTcnicaGentePerformance de procesosStatus del proyecto

Cerrar 84Los proyectos deben tener un fin visible y percibible hay que celebrarloEl 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-86Siempre se requiere el juicio: sobre-enfatizar la linearidad lleva a la parlisis y sobre-enfatizar 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 prescriptivasEnfocadas en delivery y no en compliance

Fase: Envision 87

Todos los equipos que funcionan bien cuentan con un perfecto entendimiento de sus objetivosLos detalles pueden ser borrosos, pero las objetivos de negocio y la visin del producto deben ser clarsimasSin 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 liderazgo89

Preguntas que resuelve 89Cul 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)?

Evolucin del plan del productoTres Herramientas simples y poderosasVision Box Forza a condensar la visinProject Data Sheet Forza a decantar detalles claves de alcance y constraintsFeature Cards Obliga a condensar la informacin de cada feature en una fichaVisionAlcanceFeatures91

Siempre recordar 91Cul 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 proyectoLa 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) 92Visin del productoCaja de la visin del producto y test del elevadorArquitectura del producto y directricesAlcance del proyecto (objetivos y constraints)Data sheet del proyectoComunidad del proyectoConseguir la gente adecuadaIdentificar a los participantesInterfaces entre equipos cliente desarrolloEnfoqueAjuste de procesos y prcticas

Caja de Visin del Producto y Test del Elevador 93 (Prctica)ObjetivoEstimular 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 93No 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-94Se trata de disear las partes frontal y trasera de la caja del productoEsto implicaNombre del productoUn grficoTres a cuatro bullets claves en el frenteDescripcin detallada de los features en la parte traseraSe presenta y discute cada propuesta de texto para la caja

Test del Elevador (> 2 minutos) 93Para 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 ElevadorFormato 95Para (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 95Para 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 statementDibujo de la cajaClientes objetivo y sus necesidadesEl test del elevadorMedidas de la satisfaccin del clienteRequerimientos clave operacionales y de tecnologaRestricciones crticas al producto (Performance, facilidad de uso, volmenes)Anlisis competitivosIndicadores financieros crticos**

PrcticaArquitectura del Producto 98Objetivo: 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 productoP. ej. la organizacin de componentes y mdulos puede influir la decisin de desarrollo distribuido y sobre la gerencia de los grupos distribuidosLa arquitectura es gua, no camisa de fuerza. Busca comunicar el contexto mayor al team.

Feature Breakdown Structure 98Gerencia de Ventas (Business Area)Prospectacin (Business Activity)Crear pantalla log on de vendedores (Feature)Listar leads para los vendedoresDesplegar detalles individuales por leadAdministracin de territoriosAnlisis de ventasMarketingGeneracin de leadsSeguimiento de leadsColocacin de anunciosServicio de Call Center

99-100Las arquitecturas utilizan una combinacin de elementos de: plataforma, componente, interfaz, mdulosHay 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 EspecularLa FBS provee el inventario de features desde el cual se desarrolla el plan de iteracionesLa organizacin humana y la arquitectura tcnica coevolucionan durante la vida del proyectoUn core team multidisciplinario puede funcionar mejor al principioCuando ya han sido especificadas las interfaces mediante interacciones y debate, sub-teams basados en componentes pueden funcionar mejor

Principios gua 100-101Esta es una segunda pieza de la gua arquitectnicaEstos 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 clicksCada principio debe describirse en una o dos proposiciones y su nmero total para un proyecto, en cualquier momento, no debera exceder de 10

Prctica 101Project Data Sheet PDSObjetivo: 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 101-102Product vrs Project visionLa visin del producto es una vista expandida de lo que el producto podra llegar a serLa 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 featuresProject scope will have 126 features (Rel 1.0)

Secciones de una PDS 102Clientes: lista de clientes claveProject ManagerProduct ManagerProject Objective Statement (POS)Tradeoff Matrix (TOM)Factor de exploracinCosto de los atrasosFeatures (lista de los claves)Beneficios al clienteArquitecturaPuntos/riesgos***Ejemplo

Tradeoff Matrix - TOM 104Una entrada/columnaConviene medir lmite*Defectos

FijoFlexibleAceptaAlcancexCalendarioxEstabilidad*xRecursosx

104Es 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 productoLas columnas despliegan la importancia relativa de cada dimensin

Tradeoff Matrix 105No se puede responder a cambios si no se marca un espacio para manejarlosEs importante calcular el costo de los atrasos

Factor de Exploracin 105-106Barmetro de la incertidumbre y del riesgoRelacionado con el problem domain donde el team operar10 indica un problem domain orientado a la exploracin (alto riesgo) y 1 indica un ambiente de problemas estableImportante identificar los factores del problem domain, pero ms importante es ajustar los procesos y las prcticas al problema y ajustar las expectativas correspondientementeResulta de combinar la volatilidad de los requerimientos del producto con lo nuevo inicierto- de la plataforma tecnolgica.

Factor de Exploracin 10710: problem domain que requiere mucha exploracin 1: ambiente del problema muy estable

Dimensin de TecnologaDimensin de productoBleeding EdgeLeading EdgeFamiliarBien conocidaErrtica10877Fluctuante8765Rutina7643Estable7551

Problem Domain 107Es necesario establecer la incertidumbre global del espacio del problema.Proyectos 8, 9, 10 requieren un enfoque fuerte APMIteraciones cortasPlaneacin basada en featuresRevisiones frecuentes con los clientesReconocimiento que los planes son especulativosEl reconocimiento de diferentes dominios de problemas permite hacer ajustes a problemas especficos y asegurar el xito.

Prctica Consiga la gente correcta 108El factor crtico de xitoCorrecta quiere decir:Capacidad tcnica apropiada o experticia en el domainEl comportamiento disciplinado adecuadoNo 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 111Identificacin de participantesObjetivo: 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 requerimientosEjecutivos proveen fondos y supervisin gerencialMiembros nucleares del team trabajan para entregar el producto.Stakeholders Participantes internos que no son clientes directosLos 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 112Patrocinador ejecutivo: decisiones claves sobre metas y restriccionesGerente del proyecto: dirige el team a cargo de dar los resultadosGerente de Producto: gua al equipo para determinar qu resultados darIngeniero lder: gua los aspectos tcnicos de las entregasGerencia: una gama potencialmente amplia de individuos con alguna autoridad tcnica o de presupuesto sobre los resultadosEquipo del cliente: a cargo de fijar features y priorizarlosTeam del proyecto: los encargados de dar los resultadosProveedores: proveen servicios o componentes del productoGobierno: Organismos regulatorios que requieren informacin, reportes y certificaciones

Fase: Especular 127

Ideas preliminares 128El control de cambios congela los requerimientosEl alcance mismo tambin evolucionaDe resistir el cambio a estimular el cambioEl control de cambios se refiere a la coordinacin no a la negacinFlexibilidad indisciplinada caosEstabilidad indisciplinada rigidezBalance entre flexibilidad y estructura mediante auto disciplina

Ideas preliminares 2 129Los planes son guas, no camisas de fuerzaLa realidad siempre se entrometeLos planes son vehculos para abrazar el cambio, no para bloquearloLos planes son:Conjeturas acerca del futuroGuas para el futuroEl desarrollo genera nueva informacin que a su vez crea la necesidad de re-planearNo es riesgo loco sino: conjeturar algo basado en hechos e informacin incompleta.

129El fruto de esta fase es el Release Plan que contiene el mejor conocimiento inicial del teamEste plan est basado en features entregados y no en actividadesEl plan de release usa informacin de:Especificaciones del productoArquitectura de la plataformaRecursosAnlisis de riesgoNiveles de defectoRestriccciones de negociosCalendario deseado

129-130Dos componentes cruciales en un enfoque de planeacin y desarrollo iterativoVentanas pequeas de iteracinFeaturesPara proyectos de SW: cada ventana de 2 a 6 semanasLas ventanas cortas aceleran el desarrolloLa primera meta de la planeacin y desarrollo basado en features es hacer el proceso visible y entendible.

130Los 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 cardEl frente: informacin del featureDetrs: informacin de la tarea tcnica para estimar esfuerzo y administrar el trabajoEstamos atrasados, recortemos los features 31 y 64, en lugar de: recortemos el tiempo de tests

Ayudas que da esta fase 130-131Determinar cmo el producto y sus features evolucionarnConcentrarse en los features de alto valor desde el principioNo perder de vista los objetivos de negocios y las expectativos del clienteCoordinar actividades y features interrelacionados entre feature teamsConsiderar alternativas de acciones adaptivasProveer una lnea base para analizar eventos que se dan durante el proyecto.

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

Categoras de prcticas 131Estructura de feature breakdownLista de features del productoFeature cardsTarjetas de requerimientos de performancePlan de entregasEntregas, milestones, plan de iteraciones

PrcticasPlan deIteracionesFeatureBreakdownLista deFeaturesTarjetas deFeaturesRequerimientosPerformanceIteracin 0Anlisis deriesgoPrximo plande IteracinPlan de entregas,milestones e iteraciones132

Prctica 132Lista de Features del ProductoExpansin de la desarrollada en la fase de envisionEsta 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 133ProductoArea de business subjectBusiness activityFeature

Pequeos productos podran usar slo el nivel de features.

Qu es un feature? 134Es 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 clienteEn cuanto ms tiempo pasa por all debajo, ms se puede desviar el proyecto antes de recibir feedback del cliente.

Features 134De 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

PrcticaFeature Cards 135Objetivo: 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 CardsDiscusin 135Las fc identifican mas no definen los featuresLas 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 estimarIdentifican features que los clientes quieren en el productoPara proyectos grandes, se pueden usar group cards por business activity para organizar y planear listas individuales de features, de 10, 15 o 20La 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

136

Feature CardIteracin planeada: 3No. de Feature: 25Tipo de feature: clienteNombre de feature: Establecer territorios de ventasDescripcin del feature: Crear territorios de ventas con base en regiones y reas metropolitanas estndar

Cantidad estimada de trabajo: 4.5 dasIncertidumbre de los requerimientos(E,F,R,S): R (rutina)Dependencia de otros features: ningunaTests de Aceptacin:

Contenido de Feature Card 136Identificador y nombre del featureDescripcin: una o dos oraciones en trminos del clienteTipo 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 exploracinDependencias de features: que podran afectar la secuencia de implementacinTests de aceptacin: criterios que el cliente utilizar para aceptar o rechazar el feature.

Capa debajo de los features 137Para 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.

PrcticaTarjeta de Requerimientos de PerformanceObjetivo: documentar las operaciones clave y los requerimientos de performance del producto.Suelen ser de diferente color que las de featuresContienen: nombre, descripcin, metas cuantitativas de performanceContienen tambin los correspondientes criterios de aceptacin o tests en esta rea.

Tarjeta de performanceIteracin demostrada: 6Performance ID:PC-12Nombre del aspectoInicio del Interaction ManagerDescripcin del performanceEl IM debe intervenir antes de transcurrido un segundo de detectada la interaccin

Dificultada para lograrla (H,M,L)M (moderada)Criterio de aceptacina-

Prctica 140-141Plan de Releases, Milestones e IteracionesRepresenta 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 productoOtra 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.

142Las iteraciones producen features que han pasado los criterios de aceptacinLa meta es disponer de un producto con features parciales y que pueda entregarse al final de cada iteracin.Incremental deliveryMilestones son puntos intermedios de uno a tres meses y pueden tener funciones gerenciales y tcnicasSu uso ms importante: Puntos fuertes de sincronizacin e integracin

Factores 143Dos factores guan el plan de releases, milestones e iteraciones para asignar features:Valor del clienteRiesgoTodas las dems consideraciones de calendarizacin disponibilidad de recursos, dependencias y otras- se subordinan a valor y riesgo

Alto riesgoBajo riesgoAlto valor2a. prioridad1a. PrioridadBajo Valor3a. prioridad

Iteracin 0 143 - 144Es 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 144Se 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.

Arquitectura1.0Iteracin 1Tarjeta temaArquitectura1.1Arquitectura1.2Feature 3Feature2Feature 1Feature 7Feature 5Feature 3Feature 4InvestigacinRequerimientosIteracin 2Tarjeta temaIteracin 3Tarjeta temaIteracin 4Tarjeta temaIteracin 0Iteracin 1Iteracin 2Iteracin 3Iteracin 4PLANO DE FEATURE CARDS 146

Las Actividades para hacer el plan de iteracin Incluyen 146Determinar cmo los riesgos identificados influirn en la planeacinIdentificar la meta del calendarioEstablecer los perodos de milestone y de iteracinDesarrollar un tema para cada iteracinAsignar feature cards a cada iteracin balancenado prioridades del cliente, riesgos, recursos y dependenciasSumarizar el plan en combinaciones de hoja a nivel de feature, plano de feature cards, parking lotCalcular 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 featuresLo 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 planeacinLa 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 vacasLos features asignados a los ltimas iteraciones son los que se pueden botar si hiciera falta.

149Tema de una iteracin

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

ComentarioLas funciones avanzadas se vern en la iteracin 7

Supuesto:Las simulaciones probarn un 80% de la funcionalidad

Gerencia de Ventas (GV)Marketing (MM)150

Anlisis deVentas(18)0May 2004

SeguimientoLeads(8)0Ago 2004

PautarAnuncios(9)0Sep 2004

Servicio Call Center(28)0Oct 2004

GeneracinLeads(22)0May 2004

Prospecta-cin(10)0Jun 2004

Manejo deTerritorio(8)0Jul 2004

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 featuresEl team de desarrollo necesita el detalleClientes y gerentes pueden ser ms efectivos a un nivel ms grueso de ganularidadPara estos casos: FDD Feature Driven Development

150Feature-Driven DevelopmentSe basa en una jerarqua granular de featuresEn 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)

151FDDAplicaciones grandes, como un CRM, pueden tener de 30 a 50 actividades y varios miles de featuresEn 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 InterfaceDatabaseSystems Interface

152FDDAn con proyectos ms pequeos, una jerarqua de actividad y features puede ayudar a un team a pensar en el productoListar 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

152Tres tipos de planes de iteracinHay varias formas de conducir el calendario inicialAsignar 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 iteracinUn 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 proyectoExpectativas de clientes y stakeholdersTodo debe preverse en la fase de Envision

153Plan de la prxima iteracinUna 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 iteracinFinalmente, los miembros se apuntan para features o actividades basados en sus propias habilidades y/o deseos*

1541er. Deployment FactiblePuesto que un deployment rpido conlleva muchos beneficios, algo que el team puede hacer es determinar este FFD: First Feasible DeploymentSe puede hacer una instalacin temprana a clientes clave que han pedido el productoPara el team puede traer a) Ingreso anticipado, b) feedback valiosoOjo: los costos de deployment podran ser ms que los beneficiosSi 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

155DeploymentEl desarrollo iterativo crea piezas deployable del producto, mientras que el desarrollo incremental realiza el deployment de las piezas del productoEn algunos tipos de desarrollo de SW. p. ej. Web, cada iteracin puede ser un deployment incrementalEl 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 instaladoSi el FFD se corre al final del proyecto, puede indicar un riesgo

155EstimandoCmo se estima un proyecto gil?Respuesta: con las mismas tcnicas de siempreHay tres sutilezas detrs de la preguntaCmo estimar lo desconocidoCmo estimar por features en lugar de actividadesCmo hacer una estimacin progresiva

Primero 156Cmo se estima lo desconocido? No se puede se adivina.Por lo tanto, tiempo y costo son vistos como restricciones, no como estimadosSe aprende a vivir con la incertidumbre en lugar de demandar certidumbre de un mundo de cambios vertiginosos.

Segundo 156Los proyectos giles se planean por featuresLa 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 tareasPor lo tanto, en la mayora de los casos, la planeacin basada en features provee mejores estimados

Tercero 156Los 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 ?!157Algunos cambios del alcance son de bajo costo y valiososOtros son extensos y costosos, pero cruciales para proveer valor al clienteLos cambios pueden ser perjudiciales si son arbitrarios o mal pensadosEn 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 158No 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 usadosSlo 20% se usaron a menudo o siempreEsto confirma que el deployment parcial mejora el ROI puede evitar que uno construya features costosos y no utilizadosCortar los teams y los proyectos por la mitad, no acelera el desarrollo y reduce los costos al mismo tiempo?**

Alcance y features 158La estrategia de construir unos features mnimos JUNTO CON la capacidad de adaptarse fcilmente y razonablemente al cambio puede ser muy rentableEl 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 productoEl 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 158-159El alcance del producto se basa en:valor del clientefactibilidad tcnica y costoImpacto en la adaptabilidad del productonecesidades crticas del calendario del clienteNo debe ser rehn de un conocimiento inicial incompletoLas 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.*

159Anlisis y mitigacin de riesgosEl anlisis y la mitigacin de riesgos son parte integral de cada fase y proceso del APMEl 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 softwareProblemas inherentes al calendarioInflacin de requerimientosPartida de empleadosDerrumbe de las especificacionesProductividad pobre

Riesgo 160La mejor estragegia de mitigacin de riesgo es la entrega incrementalPara 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 estimacinFeedback temprano sobre la velocidad de entregaPresin constante para balancear el nmero y profundidad de los features con las restricciones de calendarioInteracciones cercanas entre los equipos de ingeniera y de clientesDeteccin/correccin temprana de errores para mantener un producto limpio y funcional

Riesgo 161APM posee una mitigacin built-in contra la partida de empleados gracias al nfasis en la colaboracinEl derrumbe de las especificaciones ocurre cuando cuando los clientes o los gerentes de producto fallan en acordar las especificaciones.Productividad pobre:Gente equivocada en el equipoEl team no trabaja bien en conjuntoBaja moralRiesgo para productos nuevospobre investigacin de mercadoproblemas tcnicosinsuficiente esfuerzo de mercadeomal timing

Sumario de la fase 164Tres actividades claves a completar antes de empezar a desarrollar featuresArticular una visin de productoDefinir el alcance y restricciones del proyectoCrear un plan de entregas iterativo, basado en featuresEste ltimo es el principal deliverable de la fase de especularCuando se logra la lista de features y el release plan, el resto es relativamente fcilLa 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

166Un 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 166El modelo CAS es una metfora til para un estilo de gerencia del tipo liderazgo-colaboracin, el cual estimula un comportamiento:emergente (innovador)tomador de riesgosBajo esta luz, las tareas claves gerenciales son:Establecer una visinCrear un ambiente de trabajo colaborador

Gerencia 167El 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, auto-disciplinado para que pueda lograr la meta ltima.

Contribucin de la gerencia 167Enfocar al team a que d resultadosHacer un team de un grupo de individuosDesarrollar las capacidades de cada individuoProveer al team con los recursos requeridos y removerle obstculosAsesorar a los clientesOrquestar el ritmo del teamRol esencial: Crear un team de alto rendimiento a partir de un grupo de individuos.

Prcticas de la fase 168Dar resultados segn la visin y los objetivosWorkload managementPrcticas tcnicasCambio a bajo costoComunidad del proyectoCoaching y desarrollo del teamReuniones diarias de integracinToma de decisiones participativaInteraccin diaria con el team del cliente

Prctica 169Workload ManagementFin: lograr que los miembros del team manejen las actividades diarias requeridas para dar resultados al final de cada iteracinLos miembros del team deben manejar su propia carga en la mayor medida posibleLos gerentes de proyecto dan la direccin en lugar de controlar

Prctica 171Cambio a bajo costoMeta: crear un producto adaptableMantener a un mnimo el costo del cambio y de la experimentacin, lo que expande las posibilidades de diseo.Cuatro prcticasDiseo simpleIntegracin frecuenteDespiadados con las pruebasRefactura oportunista

Deuda Tcnica 171Cuando 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 duranteel desarrollo inicialel mantenimiento ordinariolas ampliacionesAPM dar valor del cliente hoy y maana. La deuda tcnica se refiere a maana.

Costo del Cambio 1 4 5 6 7 8aosRelease del productoCdC ptimoDeuda tcnicaCdC realLa deuda tcnica resulta del apresuramiento172

Deuda tcnica 172El 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 172No 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 bajoEn 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 173Una 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 173Objetivo: 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:AnticipacinAdaptacinAnticipacin: predecir los cambios y planearAdaptacin: esperar que evolucionen los requerimientos o que los cambios se manifiesten.

Adaptacin 173Tambin 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 anticipacinLa maleabilidad del producto depende del bajo costo de la iteracin.Cuando los componentes no son maleables, se prefiere la anticipacin.

Integracin frecuente 175Busca asegurar que los features encajan juntos en un todo integrado lo ms antes y ms frecuentemente posible.

Despiadados con las pruebas 178El 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 iteracinDisponer de un conjunto completo de pruebas automatizadasLa meta final es sacar un producto instalable, de features limitados, de cada iteracin.

Refactoring oportunista 179El fin es mejorar el diseo del producto constantemente y continuamente hacerlo ms adaptable- para lograr la doble meta:proveer valor del cliente hoyproveer valor del cliente maanaHay 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 180El refactoring mejora el diseo del producto pero no agrega nueva funcionalidad* mejora la adaptabilidad.Agregar nueva funcionalidad usualmente pide rediseoEn 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 bajoEl 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 181Hay cada vez ms disposicin de los gerentes de producto a invertir en refactoring una vez que entienden la situacinCon 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 importantesPruebas: 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 181Significa 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 productoSignifica ir construyendo de modo lento pero seguro pruebas automticas e ir integrando las pruebas dentro del proceso de desarrollo

CREANDO EQUIPOS ADAPTIVOS GRANDES

Componentes 238Estructura organizacional basada en hubsExtensiones de auto-organizacinAuto-disciplina de equipoPrcticas adicionalesUn 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.

puede ser virtualMiembros fijos y part-time

Extensiones de auto-organizacin 241Conseguir los lderes adecuadosArticular la descomposicin del trabajo y las estrategias de integracinEstimular la interaccin y el flujo de informacin entre teamsEnmarcar la toma de decisiones a nivel de proyectoEl lder del proyecto se asegura que cada individuo comprenda la visin del producto y la parte de su sub-team dentro de esa visinEn 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 teamspor ejemplo, un sub-team de features necesita saber cmo interactar con el sub-team de arquitecturaLos proyectos grandes son casi siempre de algn modo proyectos distribuidosHay que enfrentar aspectos de distancia, cultura y experticiaDefinir los roles y responsabilidades de los subteams es un paso inicial para tratar con los aspectos de distribucin

Cada producto necesita de:un tema de markeingUna imagen visual y una descripcin de features ntida con la que se quiere obtener la atencin de los clientes para que investiguen ms.En cuanto ms critco sea el programa de entrega de resultados y en cuanto ms voltil sea el proyecto, ms importante es que el team tenga una buena visin del resultado final deseado. Sin esta visin, los proyectos de desarrollo iterativo corren el riesgo de volverse proyectos oscilantes, porque cada uno acaba viendo las minucias en lugar de ver el cuadro completo.POS: Una exposicin especfica corta (25 palabras) que incluya informacin importante de alcance, calendario y recursos de la matriz de compensacin (Tradeoff)TOM: una tabla que establece lasa prioridades relativas del alcane, recursos, calendario y defectos del proyecto con uno y slo de estos establecido como la ms alta prioridad.Factor de exploracin: una medida de 1 a 10 del factor de incertidumbre del proyectoCosto de los atrasos: los costos por el atraso del proyecto diarios, semanales o mensuales. Particularmente til cuando el calendario es la ms alta prioridad

Algunos llaman a las columnas: prioridad 1, 2 y 3 oFija, flexible y libre

Dimensiones del producto: Errtica, quiere decir que se entiende la visin del producto, pero los requerimientos del producto y del negocio son borrosos. los requerimientos podran variar, no por una mala recopilacin de ellos, sino por el conocimiento evolutivo del producto que se fabrica.Un caso errtico podra llevar a cambios en los requerimientos desde 25 hasta 50%Requerimientos fluctuantes son un grado menos de incertidumbreRutina: la recopilacin inicial de requerimientos provee una lnea base razonablemente estable para el trabajo posteriorEstable: por ejemplo, cambios en el sistema de planillas provenientes de una nueva legislacin, lo que es muy estable.

Dimensiones de la tecnologaBleeding edge: tecnologa tan nueva que muy poca gente tiene experiencia con ella. Se tiene que aprender probando.Leading edge: relativamente nueva, pero siempre hay que recurrir a ciertos focos de experticia.Puede elegirse algunas veces el tipo de tecnologa que se emplear para ciertos componentes, con el fin de disminuir el riesgo

La combinacin de producto sin la idea total de los requerimientos con una tecnologa muy nueva, da el caso de mayor incertidumbre y riesgo.- A veces no se puede encontrar al exacto experto que uno desea, pero si se encuentra a una persona con la actitud correcta de auto-disciplina y suficientes habilidades tcnicas, esta persona descubrir cmo obtener la informacin correcta.Los planes deben adaptarse porque se cambia el entendimiento de los requerimientos: los estimados de carga de trabajo cambian debido a factores ignorados, gente llega o se va del proyecto.

Cualquier prodcuto contiene un conjunto de features que los clientes usan para algn propsito. En cuanto ms rpidamente podamos asociar esos clientes con los features que han requerido y obtener su feedback, es ms probable que sean ms exitosos los esfuerzos de desarrollo del producto. (141)En algunos proyectos, los miembros del equipo se apuntan para implementar features completos; en otros, se apuntan para actividades dentro de los feaures (y alguno se apunta para asegurar que el feature completo ha sido terminado)

Las palabras claves son: apuntarse para y asignar (p.ej. por el Project Manager)

Tomar la responsabilidad por terminar el trabajo refuerza el compromiso da cada individuo hacia el proyecto, y, por lo tanto, contribuye a construir un team que se auto-organiza.

Algunos teams no tendrn la experiencia o la autodisciplina para desarrollar este apuntarse hasta agotar los features, pero la habilidad del project manager y del team para hacer que esto funcione es un buen indicador de su maduracin hacia un equipo adaptivo efectivo.

Qu pasa si alguien no se apunta para una tarea particular? Qu pasa cuando alguien con la habilidad equivocada se apunta para un feature que no puede sacar? Algunos teams que estn aprendiendo el proceso pudieran necesitar ser dirigidos por un gentil: No saldremos de esta sesin de planeacin mientras no tomemos todas las tareas.

Con equipos autodisciplinados y con experiencia, este asunto nunca sale entienden la planeacin a nivel de tareas y las expectativas y saben que todas las tareas deben ser cubiertas.

En el caso del falto de habilidad que quiera tomar un feature, el projecto manager lo induce a una asignacin diferente y posiblemente apareando a la persona sin experiencia con alguien ms.Algunos productos sern difciles de instalar parcialmente, por ejemplo si un competidor ya tiene un producto en el mercado, con cierta capacidad, puede no ser recomendable instalar el producto mientras no tenga una capacidad comparable.

Por otro lado, esperar por un producto con todos sus features puede ser un error. La instalacin parcial le ayuda a uno a identificar los features que son importantes para los clientes. LA MAYORA DE PRODUCTOS TIENEN DEMASIADOS FEATURES QUE LOS CLIENTES RARAMENTE USAN. El deployment parcial, cuando la competencia ya ha instalado productos completos, puede permitirnos conocer algo acerca del cliente que ni nosotros ni la competencia sabemos actualmente.Es ms rpido y barato permitir que los features evolucionen sobre la vida del proyecto (dentro de algunos lmites, desde luego) que alucinar acerca de cules seran los requerimientos al comienzo y despus construirlos sin la involucracin contante de los clientes.

Los reality checks despus de ciclos cortos impiden que la featuritis se salga de control

Con una meta de tiempo cumplindose cada pocas semanas, la tendencia de aumentar los features disminuye.

* Se prepara el producto para agregar funcionalidad en el futuro