Agile Project Management
118
Agile Project Management
description
Transcript of Agile Project Management
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á: especularexploraradaptar
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 84
Los 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
Consideraciones 84-86
Siempre se requiere el juicio: sobre-enfatizar la linearidad lleva a la parálisis y sobre-enfatizar 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, sin aplicar el juicio.
Las prácticas seleccionadas: Generativas, no prescriptivas Enfocadas en delivery y no en compliance
Fase: Envision 87
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, compelidora, 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
89
Preguntas que resuelve 89
¿Cuál 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)?
Evolución del plan del producto
Tres Herramientas simples y poderosasVision Box – Forza a condensar la visiónProject Data Sheet – Forza a decantar
detalles claves de alcance y constraintsFeature Cards – Obliga a condensar la
información de cada feature en una ficha
Vision Alcance Features
91
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. Por ejemplo, si la arquitectura evoluciona, la estructura del team pueda necesitar evolucionar.
Las prácticas
Las prácticas (4 categorías) 92
Visión del producto Caja de la visión del producto y test del elevador Arquitectura del producto y directrices
Alcance del proyecto (objetivos y constraints) Data sheet del proyecto
Comunidad del proyecto 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 93 (Práctica)
Objetivo Estimular a los miembros del team a que
focalicen sus ideas desperdigadas del producto en una forma concisa, visual y textual.
Estos dos mecanismos proveen un concepto común elevado del producto para mercadeo, desarrollo y gerentes.
Desarrollo de la Discusión 93
No se puede predecir la innovación ni la creación de productos emergentes, por lo tanto hace falta un proceso especial.
Una buena visión del producto es constante, mientras que la vía para implementar esa visión 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.
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, que necesitan funcionalidades avanzadas de movimiento de cajas, 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. A diferencia de los otros productos, nuestro producto es altamente automatizado y con precios agresivos.
Test del ElevadorFormato 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)
Más sobre visión del producto 95
Para proyectos con alto grado de incertidumbre, es crítico disponer de un concepto nuclear, una visión, para mantener bajos los costos de exploració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, facilidad
de uso, volúmenes) Análisis competitivos Indicadores financieros críticos**
PrácticaArquitectura del Producto 98
Objetivo: Mostrar la plomería interna del proyecto –un diseño que facilita la exploración y guía el continuo desarrollo del producto. Guía el trabajo técnico y a la organización de la gente que desarrolla ese trabajo técnico.
La arquitectura junto con el tamaño total del proyecto contiene implicaciones importantes para el éxito del proyecto y del producto P. ej. 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. Busca comunicar el contexto mayor al team.
Feature Breakdown Structure 98
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
99-100
Las arquitecturas utilizan una combinación de elementos de: plataforma, componente, interfaz, módulos
Hay otras arquitecturas útiles para los equipos técnicos, 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, sub-teams basados en componentes pueden funcionar mejor
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.
Ejemplos: 1) Toda interacción siempre será cerrada, 2) Toda interacción debe buscar un feedback, 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, en cualquier momento, no debería exceder de 10
Práctica 101
Project Data Sheet – PDSObjetivo: transmitir la esencia en
términos de alcance, calendario y recursos, de cómo el proyecto materializará la visión.
Es la segunda más importante práctica de la fase de Envision
Project Data Sheet 101-102
Product vrs Project vision 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, calendario, y restricciones de costos. Product vision should haves – 234 features Project scope will have – 126 features (Rel 1.0)
Secciones de una PDS 102
Clientes: lista de clientes clave Project Manager Product Manager Project Objective Statement (POS) Tradeoff Matrix (TOM) Factor de exploración Costo de los atrasos Features (lista de los claves) Beneficios al cliente Arquitectura Puntos/riesgos***
Ejemplo
Tradeoff Matrix - TOM 104
Fijo Flexible Acepta
Alcance x
Calendario x
Estabilidad* x
Recursos x
Una entrada/columna Conviene medir límite*Defectos
104
Es un acuerdo entre el team del proyecto, el cliente y el sponsor ejecutivo que se usa para manejar el cambio durante el proyecto.
Las filas muestran las dimensiones claves que crean el valor del producto
Las columnas despliegan la importancia relativa de cada dimensión
Tradeoff Matrix 105
No se puede responder a cambios si no se marca un espacio para manejarlos
Es importante calcular el costo de los atrasos
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, 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- de la plataforma tecnológica.
Factor de Exploración 107
Dimensión de Tecnología
Dimensión de producto
Bleeding Edge
Leading Edge
FamiliarBien
conocida
Errática 10 8 7 7
Fluctuante 8 7 6 5
Rutina 7 6 4 3
Estable 7 5 5 1
10: problem domain que requiere mucha exploración
1: ambiente del problema muy estable
Problem Domain 107
Es necesario establecer la incertidumbre global del espacio del problema.
Proyectos 8, 9, 10 requieren un enfoque fuerte APM Iteraciones cortas 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.
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,
sino la gente apropiada para el trabajo.
La pregunta sobre los ‘quienes’ es la más prioritaria, sobre las ‘qué’ – antes que la visión, la estrategia, la táctica, la organización, la tecnología.
Práctica 111
Identificación de participantes Objetivo: identificar a los participantes de modo que
las expectativas sean entendidas y administradas. Los participantes son los que pertenecen a la
comunidad del proyecto: Clientes – determinan e influyen los requerimientos Ejecutivos – proveen fondos y supervisión gerencial Miembros nucleares del team – trabajan para entregar el
producto. Stakeholders – Participantes internos que no son clientes
directos Los clientes proveen los requerimientos; los
miembros del team fabrican el producto; los stakeholders proveen el conjunto de restricciones, los requerimientos de cumplimiento y los recursos
Lista de participantes 112
Patrocinador ejecutivo: decisiones claves sobre metas y restricciones
Gerente del proyecto: dirige el team a cargo de dar los resultados
Gerente de Producto: 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.
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, recortemos los features 31 y
64”, en lugar de: “recortemos el tiempo de tests”
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.
131
Se necesita recompensar al team por su respuesta a los cambios, y no amonestarlos por no haber hecho un plan
Categorías de prácticas 131
Estructura de feature breakdown Lista de features del producto Feature cards Tarjetas de requerimientos de performance
Plan de entregas Entregas, milestones, plan de iteraciones
Prácticas
Plan deIteraciones
FeatureBreakdown
Lista deFeatures
Tarjetas deFeatures
RequerimientosPerformance
Iteración 0
Análisis deriesgo
Próximo plande Iteración
Plan de entregas,milestones e iteraciones
132
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, milestones e iteraciones.
Para cada feature crea una tarjeta que contiene información básica 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.
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 135
Objetivo: 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
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- requerimientos durante una iteración.
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, se pueden usar ‘group cards’ por business activity para organizar y planear listas individuales de features, de 10, 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
Feature Card Iteración planeada: 3
No. de Feature: 25 Tipo de feature: cliente
Nombre de feature: Establecer territorios de ventas
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,S): R (rutina)
Dependencia de otros features: ninguna
Tests de Aceptación:
136
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, T=técnico) Trabajo estimado: lo que lleva producir el feature, e
incluye tiempo para recoger requerimientos, diseño, codificación, pruebas y documentación.
Incertidumbre de los requerimientos (erráticos, fluctuantes, rutinarios, 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.
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, diseñar, construir, probar y documentar el feature.
Se pueden combinar las actividades técnicas de varios features en un solo paquete técnico 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á más tiempo y dinero de lo previsto.
Si es difícil fijar los requerimientos, podría requerirse una serie de prototipos de descubrimiento.
Features altamente inciertos podrían requerir investigación adicional antes de planearlos.
Práctica
Tarjeta de Requerimientos de Performance
Objetivo: documentar las operaciones clave y los requerimientos de performance del producto.
Suelen ser de diferente color que las de features
Contienen: nombre, descripción, metas cuantitativas de performance
Contienen también los correspondientes ‘criterios de aceptación’ o ‘tests’ en esta área.
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,M,L) M (moderada)
Criterio de aceptación a- <2 seg en iteración 3
b- <1 seg en iteración 6
Práctica 140-141
Plan de Releases, 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.
Los ciclos APM son iterativos y guiados por features. 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, que es instanciada por features) es que mantiene la sincronía entre el cliente y el equipo de desarrollo.
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
Factores 143
Dos factores guían el plan de releases, milestones e iteraciones para asignar features: Valor del cliente Riesgo
Alto riesgo Bajo riesgo
Alto valor 2a. prioridad 1a. Prioridad
Bajo Valor 3a. prioridad
•Todas las demás consideraciones de calendarización –disponibilidad de recursos, dependencias y otras- se subordinan a valor y riesgo
Iteración 0 143 - 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.
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á algún diagrama de arquitectura en lugar de un feature implementable)
Ejemplo de un release plan
Iteraciones 1-N 144
Se 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, staffing, costos y otra información de planeación del proyecto. El plan resultante se puede ver así.
Arquitectura1.0
Iteración 1Tarjeta tema
Arquitectura1.1
Arquitectura1.2
Feature 3
Feature2
Feature 1
Feature 7
Feature 5
Feature 3
Feature 4
InvestigaciónRequerimientos
Iteración 2Tarjeta tema
Iteración 3Tarjeta tema
Iteración 4Tarjeta tema
Iteración 0 Iteración 1 Iteración 2 Iteración 3 Iteración 4
PLANO DE FEATURE CARDS 146
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, riesgos, recursos y dependencias Sumarizar el plan en combinaciones de hoja a nivel de
feature, plano de feature cards, parking lot Calcular el calendario inicial según 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 ténico 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 asignación, pero los más importantes son valor del cliente y riesgo.
148- 149
Para cada iteración y milestone, el equipo debe desarrollar y escribir un tema guía. 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. Se pueden acomodar también iteraciones vacías Los features asignados a los últimas iteraciones son
los que se pueden botar si hiciera falta.
149
Tema de una iteración
Iteracion No. 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
Análisis de
Ventas
(18)
0
May 2004
Gerencia de Ventas (GV)
Seguimiento
Leads
(8)
0
Ago 2004
Pautar
Anuncios
(9)
0
Sep 2004
Servicio Call Center
(28)
0
Oct 2004
Marketing (MM)
Generación
Leads
(22)
0
May 2004
Prospecta-
ción
(10)
0
Jun 2004
Manejo de
Territorio
(8)
0
Jul 2004
150
Planeación y Reportes a Nivel de Componentes o Actividad de Negocios
150
Para proyectos de mediano a grande, la planeación a nivel de feature es demasiado fina, al menos para muchos clientes y gerentes.
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
150
Feature-Driven DevelopmentSe basa en una jerarquía granular de
featuresEn el caso del Manager Plus, 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)
151
FDD Aplicaciones grandes, como un CRM, pueden
tener de 30 a 50 actividades y varios miles de features En estos casos se puede ver la calendarización
por gerencias altas a nivel de componente o actividad, y se deja la calendarización a nivel de feature al equipo de ingeniería.
Este enfoque de “dos capas” para la planeacion puede ser muy efectivo.
De Luca divide el dominio técnico en tres grupos de features : User Interface Database Systems Interface
152
FDD Aún con proyectos más pequeños, 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, y de allí, identificar nuevos features, puede contribuir al entendimiento del producto.
En cualquier caso los artefactos finales de una actividad de planeación incluyen una combinación de: a) feature cards, b) una FBS, c) un plan de iteración con las feature cards, d) un parqueo del proyecto
152
Tres tipos de planes de iteraciónHay varias formas de conducir el
calendario inicial Asignar features a las iteraciones hasta la
fecha meta y luego determinar si el alcance (features que se pueden implementar) parece razonable.
Asignar todos los features y luego comparar la fecha planeada (con todos los features) con la fecha meta.
152-153
Para proyectos con alto grado de exploración, los calendarios iniciales pueden contener demasiados “sis”. Dependiendo del grado de incertidumbre se puede hacer. Un plan completo con features asignados a cada
iteración Un plan para dos iteraciones, utilizando sólo la
próxima interacción, y dejar todo el resto para después.
Un plan de iteración por iteración.
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’
153
Plan de la próxima iteración Una vez acordado el plan global de entregas para el
proyecto completo, el team regresa a hacer un plan detallado de la próxima (o primera) iteración.
El team toma cada feature card y construye una lista de las actividades técnicas requeridas para implementar el feature, y las anota en el reverso.
El equipo re-estima el trabajo con base en el examen más detallado y ajusta los features planeados para esa iteración
Finalmente, los miembros se apuntan para features o actividades basados en sus propias habilidades y/o deseos*
154
1er. Deployment Factible Puesto que un deployment rápido conlleva muchos
beneficios, 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, 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,
p. ej. se podría escoger terminar los features de una sola área, en lugar de features cruzados
155
Deployment El desarrollo iterativo crea piezas ‘deployable’ del
producto, mientras que el desarrollo incremental realiza el deployment de las piezas del producto
En algunos tipos de desarrollo de SW. p. ej. Web, cada 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.* 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, puede indicar un riesgo
155
Estimando
¿Cómo se estima un proyecto ágil?
Respuesta: con las mismas técnicas de siempre
Hay tres sutilezas detrás de la pregunta1. Cómo estimar lo desconocido
2. Cómo estimar por features en lugar de actividades
3. Cómo hacer una estimación progresiva
Primero 156
¿Cómo 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 156
Los proyectos ágiles se planean por features La experiencia en puras tareas debe emplearse
en estimar tareas para cada feature. P. ej. en lugar de estimar levantado de requerimientos para todo el proyecto, hacerlo por cada feature.
Un equipo que ha pasado varios 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, en la mayoría de los casos, la planeación basada en features provee mejores estimados
Tercero 156
Los buenos gerentes de proyecto siempre han tratado de emplear prácticas de estimación progresiva, p. ej. 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.
Mientras avanzan las iteraciones, los miembros del team deben mejorar para estimar la próxima iteración, lo que mejorará también para el resto del proyecto.
Evolución del Alcance ¡¿?!157
Algunos cambios del alcance son de bajo costo y valiosos
Otros son extensos y costosos, pero cruciales para proveer valor al cliente
Los cambios pueden ser perjudiciales si son arbitrarios o mal pensados
En general, los cambios de alcance que resuelven requerimientos evolutivos y que son tomados con el entendimiento y la aprobación de su impacto en el proyecto, incrementan la probabilidad del éxito del proyecto.
Alcance y features 158
No hay que grabar en placas doradas los requerimientos.
Dupont estima que 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,
¿no acelera el desarrollo y reduce los costos al mismo tiempo?**
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 158-159
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
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- a enfrentar la realidad.
Podemos tomar un documento de requerimientos y estimar el tiempo que llevará desarrollar y probar el código, 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
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, sino la pura imposibilidad de calendarizar lo desconocido.
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
Riesgo 161
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.
Productividad pobre: 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
Sumario de la fase 164
Tres actividades claves a completar antes de empezar a desarrollar features
1. Articular una visión de producto2. Definir el alcance y restricciones del proyecto3. Crear un plan de entregas iterativo, basado en features
Este último es el principal deliverable de la fase de especular
Cuando se logra la lista de features y el release plan, el resto es relativamente 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.
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.
Liderazgo – Colaboración 166
El modelo CAS es una metáfora útil para un estilo de gerencia del tipo liderazgo-colaboración, el cual estimula un comportamiento: emergente (innovador) tomador de riesgos
Bajo esta luz, las tareas claves gerenciales son: Establecer una visión Crear un ambiente de trabajo colaborador
Gerencia 167
El 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, auto-disciplinado para que pueda lograr la meta última.
Contribución de la gerencia 167
1. Enfocar al team a que dé resultados2. Hacer un team de un grupo de individuos3. Desarrollar las capacidades de cada
individuo4. Proveer al team con los recursos
requeridos y removerle obstáculos5. Asesorar a los clientes6. Orquestar el ritmo del teamRol esencial: Crear un team de alto rendimiento
a partir de un grupo de individuos.
Prácticas de la fase 168
Dar resultados según la visión y los objetivos Workload management
Prácticas técnicas 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 169
Workload Management 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 171
Cambio a bajo costo 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
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, se incurre en deuda técnica.
La deuda técnica puede surgir durante el desarrollo inicial el mantenimiento ordinario las ampliaciones
APM dar valor del cliente hoy y mañana. La deuda técnica se refiere a mañana.
Cost
o de
l Cam
bio
1 4 5 6 7 8
años
Release del producto
CdC óptimo
Deuda técnica
CdC real
La deuda técnica resulta del apresuramiento
172
Deuda técnica 172
El incremento de la deuda técnica reduce directamente la responsividad a los clientes.
Sin una dedicación firme al manejo de la deuda técnica 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 más se extienden los atrasos, sube la presión que lleva a otra implementación apresurada, lo que incrementa otra vez la deuda técnica.
En cuanto más grande es la deuda, más caro es corregirla porque cuesta más justificarlo, por lo tanto, continúa la espiral de muerte.
Deuda técnica 172
No hay incentivo para disminuir la deuda técnica al principio del ciclo de vida del producto, cuando es barato, porque los atrasos son todavía cortos.
El secreto para la reducción de la deuda técnica a largo plazo está en hacerlo temprano y seguido, cuando el costo es bajo
En cuanto más baja la deuda técnica, más barato es corregirla, cuesta menos justificar y este círculo virtuoso se refuerza a sí mismo.
Reducir la deuda técnica, mantener bajo el costo del cambio, tiene que ser una estrategia ténica y parte de la dedicación de una organización a la excelencia técnica.
Deuda técnica 173
Una estrategia de deuda técnica 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 más alta que se pueda durante la vida del producto.
Diseño simple 173
Objetivo: mantener al aquipo afincado sobre lo conocido en lugar de anticipar lo desconocido.
Hay dos enfoques fundamentales hacia el manejo del cambio que deben aparecer en las buenas estrategias de 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.
Adaptación 173
También significa experimentar, elegir los experimentos con los mejores resultados e incorporar los resultados en el producto.
En cuanto más bajo sea el costo del cambio, más bajo es el costo de experimentación y más alta es la probabilidad de innovaciones significativas.
Si hay posibilidades de que algo cambie, debemos diseñar el sistema para que incorpore fácilmente ese cambio.
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. Cuando los componentes no son maleables, se prefiere la
anticipación.
Integración frecuente 175
Busca asegurar que los features encajan juntos en un todo integrado lo más antes y más frecuentemente posible.
Despiadados con las pruebas 178
El fin es que la calidad del producto se mantenga alta a lo largo del proceso de desarrollo.
Contribuye a la meta de crear productos adaptables porque al encontrar faltas pronto, cuando todavía hay tiempo para corregirlas, se reduce el costo del cambio. 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, de cada iteración.
Refactoring oportunista 179
El fin es mejorar el diseño del producto constantemente y continuamente –hacerlo más adaptable- para lograr la doble meta: 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 implica actualizar los componentes internos (mejorar el diseño) sin cambiar la funcionalidad externa, para poder mejorar el producto en el futuro.
Dado el ritmo de cambio, nuestros diseños deben mejor basarse en lo que conocemos hoy y en nuestra disponibilidad de emprender rediseños en el futuro.
Refactoring oportunista 180
El refactoring mejora el diseño del producto pero no agrega nueva funcionalidad* –mejora la adaptabilidad.
Agregar nueva funcionalidad usualmente pide rediseño
En cuanto mayor sea el ritmo de cambio en los features de un producto, más rápido se degradarán la arquitectura o el diseño.
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, siempre cambiará, por lo tanto mantenga bajo el costo del cambio.
Disciplina de refactoring en el desarrollo
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, su situación actual es insostenible.
Dos factores son los más importantes Pruebas: hay que integrarlas en el proceso de
desarrollo y automatizarlas todo lo que se pueda. 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.
Persistencia 181
Significa pensar en rediseño durante cada iteración y asignar algún tiempo a implementar los rediseños.
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
CREANDO EQUIPOS ADAPTIVOS GRANDES
Componentes 238
Estructura organizacional basada en hubs Extensiones de auto-organización Auto-disciplina de equipo Prácticas adicionalesUn team de proyecto consiste de individuos –agentes casi
independientes- 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, y ellos, a su vez, ejercitan auto-disciplina para responsabilizarse por los resultados y para comportarse como miembros responsables y conscientes del team.
En el caso de los teams grandes que consisten de sub-teams, los agentes son los sub-teams.
Project Management Team
Project Manager
Team del cliente
Product Manager
Team de Arquitectura
Team Lead
Teams de Features A-N
TeamLead
Team de integración y construcción
TeamLead
puede ser virtual
Miembros fijos y part-time
Extensiones de auto-organizació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ónEn proyectos grandes, los subteams pueden también
hacer el ejercicio de ‘envision’ para su porción del producto.
Además de conocer sus responsabilidades, cada sub-team necesita saber su rol respecto de los otros sub teams por ejemplo, un sub-team de features necesita saber 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
