Agile Project Management

1
Agile Project Management
2
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

3
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

4
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

5
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.

6
Adaptar 83

• Responder al cambio es más importante que seguir
  un plan
• Después de la fase envision, el loop será
  especular?explorar?adaptar
• Cada iteración refina sucesivamente el producto
• Los resultados son vistos desde las siguientes
  perspectivas
• Del cliente
• Técnica
• Gente
• Performance de procesos
• Status del proyecto

7
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

8
Prácticas
9
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

10
Fase Envision 87
11
89

• Todos los equipos que funcionan bien cuentan con
  un perfecto entendimiento de sus objetivos
• Los detalles pueden ser borrosos, pero las
  objetivos de negocio y la visión del producto
  deben ser clarísimas
• Sin una visión clara se arriesga experimentar sin
  fin.
• Una visión clara, 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

12
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)?

13
Evolución del plan del producto
91
Vision
Alcance
Features

• Tres Herramientas simples y poderosas
• Vision Box Forza a condensar la visión
• Project Data Sheet Forza a decantar detalles
  claves de alcance y constraints
• Feature Cards Obliga a condensar la información
  de cada feature en una ficha

14
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.

15
Las prácticas
16
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

17
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.

18
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.

19
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

20
Test del Elevador (gt 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.

21
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)

22
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

23
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.

24
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

25
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

26
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

27
Práctica 101Project Data Sheet PDS

• Objetivo 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

28
Project Data Sheet 101-102Product 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)

29
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
30
Tradeoff Matrix - TOM 104
Conviene medir límite
Una entrada/columna
Defectos
31
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

32
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

33
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.

34
Factor de Exploración 107
10 problem domain que requiere mucha
exploración 1 ambiente del problema muy estable
35
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.

36
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.

37
Práctica 111Identificació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

38
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

39
Fase Especular 127
40
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

41
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.

42
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

43
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.

44
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

45
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.

46
131

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

47
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

48
132
Lista de Features
Feature Breakdown
Tarjetas de Features
Prácticas
Requerimientos Performance
Plan de Iteraciones
Iteración 0
Análisis de riesgo
Plan de entregas, milestones e iteraciones
Próximo plan de Iteración
49
Práctica 132Lista 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.

50
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.

51
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.

52
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

53
PrácticaFeature 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

54
Feature CardsDiscusió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

55
136
56
Contenido de Feature Card 136

• Identificador y nombre del feature
• Descripción una o dos oraciones en términos del
  cliente
• Tipo de feature (Ccustomer, Tté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.

57
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.

58
PrácticaTarjeta 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.

59
(No Transcript)
60
Práctica 140-141Plan 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.

61
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

62
Factores 143

• Dos factores guían el plan de releases,
  milestones e iteraciones para asignar features
• Valor del cliente
• Riesgo

• Todas las demás consideraciones de
  calendarización disponibilidad de recursos,
  dependencias y otras- se subordinan a valor y
  riesgo

63
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

64
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í.

65
PLANO DE FEATURE CARDS 146
Iteración 0
Iteración 1
Iteración 2
Iteración 3
Iteración 4
Iteración 1 Tarjeta tema
Iteración 2 Tarjeta tema
Iteración 3 Tarjeta tema
Iteración 4 Tarjeta tema
Feature 4
Arquitectura 1.0
Arquitectura 1.1
Arquitectura 1.2
Feature 5
Feature 3
Feature 1
Investigación Requerimientos
Feature 3
Feature2
Feature 7
66
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

67
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.

68
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.

69
149Tema de una iteración
70
Gerencia de Ventas (GV)
150
Marketing (MM)
71
Planeación y Reportes a Nivel de Componentes o
Actividad de Negocios
72
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

73
150Feature-Driven Development

• Se basa en una jerarquía granular de features
• En 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)

74
151FDD

• 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

75
152FDD

• 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

76
152Tres tipos de planes de iteración

• Hay varias formas de conducir el calendario
  inicial
• Asignar features a las iteraciones hasta la fecha
  meta y luego determinar si el alcance (features
  que se pueden implementar) parece razonable.
• Asignar todos los features y luego comparar la
  fecha planeada (con todos los features) con la
  fecha meta.

77
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

78
153Plan 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

79
1541er. 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

80
155Deployment

• 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

81
155Estimando

• Cómo se estima un proyecto ágil?
• Respuesta con las mismas técnicas de siempre
• Hay tres sutilezas detrás de la pregunta
• Cómo estimar lo desconocido
• Cómo estimar por features en lugar de actividades
• Cómo hacer una estimación progresiva

82
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 estimados
• Se aprende a vivir con la incertidumbre en lugar
  de demandar certidumbre de un mundo de cambios
  vertiginosos.

83
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

84
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.

85
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.

86
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?

87
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.

88
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.

89
159Aná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

90
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

91
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

92
Sumario de la fase 164

• Tres actividades claves a completar antes de
  empezar a desarrollar features
• Articular una visión de producto
• Definir el alcance y restricciones del proyecto
• Crear un plan de entregas iterativo, basado en
  features
• Este último es el principal deliverable de la
  fase de especular
• Cuando se logra la lista de features y el release
  plan, el resto es relativamente 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.

93
EXPLORAR Cap 7 165
94
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.

95
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

96
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.

97
Contribución de la gerencia 167

• Enfocar al team a que dé resultados
• Hacer un team de un grupo de individuos
• Desarrollar las capacidades de cada individuo
• Proveer al team con los recursos requeridos y
  removerle obstáculos
• Asesorar a los clientes
• Orquestar el ritmo del team
• Rol esencial Crear un team de alto rendimiento a
  partir de un grupo de individuos.

98
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

99
Práctica 169Workload 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

100
Práctica 171Cambio 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

101
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.

102
172
La deuda técnica resulta del apresuramiento
CdC real
Costo del Cambio
Release del producto
Deuda técnica
CdC óptimo
1 4 5 6 7 8 años
103
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.

104
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.

105
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.

106
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.

107
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.

108
Integración frecuente 175

• Busca asegurar que los features encajan juntos en
  un todo integrado lo más antes y más
  frecuentemente posible.

109
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.

110
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.

111
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
112
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.

113
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

114
CREANDO EQUIPOS ADAPTIVOS GRANDES
115
Componentes 238

• Estructura organizacional basada en hubs
• Extensiones de auto-organización
• Auto-disciplina de equipo
• Prácticas adicionales
• Un team de proyecto consiste de individuos
  agentes casi independientes- 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.

116
Miembros fijos y part-time
puede ser virtual
117
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ón
• En proyectos grandes, los subteams pueden también
  hacer el ejercicio de envision para su porción
  del producto.

118

• 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