Agile Project Management

2,732 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,732
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
100
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Cada producto necesita de: un tema de markeing Una imagen visual y una descripción de features nítida con la que se quiere obtener la atención de los clientes para que investiguen más.
  • En cuanto más critíco sea el programa de entrega de resultados y en cuanto más volátil sea el proyecto, más importante es que el team tenga una buena visión del resultado final deseado. Sin esta visión, 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 exposición específica corta (25 palabras) que incluya información importante de alcance, calendario y recursos de la matriz de compensación (Tradeoff) TOM: una tabla que establece lasa prioridades relativas del alcane, recursos, calendario y defectos del proyecto – con uno y sólo de estos establecido como la más alta prioridad. Factor de exploración: una medida de 1 a 10 del factor de incertidumbre del proyecto Costo de los atrasos: los costos por el atraso del proyecto diarios, semanales o mensuales. Particularmente útil cuando el calendario es la más alta prioridad
  • Algunos llaman a las columnas: prioridad 1, 2 y 3 o Fija, flexible y libre
  • Dimensiones del producto : Errática, quiere decir que se entiende la visión del producto, pero los requerimientos del producto y del negocio son borrosos. los requerimientos podrían variar, no por una mala recopilación de ellos, sino por el conocimiento evolutivo del producto que se fabrica. Un caso errático podría llevar a cambios en los requerimientos desde 25 hasta 50% Requerimientos fluctuantes son un grado menos de incertidumbre Rutina: la recopilación inicial de requerimientos provee una línea base razonablemente estable para el trabajo posterior Estable: por ejemplo, cambios en el sistema de planillas provenientes de una nueva legislación, lo que es muy estable. Dimensiones de la tecnología Bleeding edge: tecnología 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 tecnología que se empleará para ciertos componentes, con el fin de disminuir el riesgo La combinación de producto sin la idea total de los requerimientos con una tecnología 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 técnicas, esta persona descubrirá cómo obtener la información 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 algún propósito. En cuanto más rápidamente podamos asociar esos clientes con los features que han requerido y obtener su feedback, es más probable que sean más 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 tendrán 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 maduración 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 están aprendiendo el proceso pudieran necesitar ser dirigidos por un gentil: “No saldremos de esta sesión de planeación mientras no tomemos todas las tareas”. Con equipos autodisciplinados y con experiencia, este asunto nunca sale –entienden la planeación 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 asignación diferente y posiblemente apareando a la persona sin experiencia con alguien más.
  • Algunos productos serán difíciles 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 instalación parcial le ayuda a uno a identificar los features que son importantes para los clientes. LA MAYORÍA 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 más rápido y barato permitir que los features evolucionen sobre la vida del proyecto (dentro de algunos límites, desde luego) que alucinar acerca de cuáles serían los requerimientos al comienzo y después construirlos sin la involucración contante de los clientes.
  • Los reality checks después de ciclos cortos impiden que la featuritis se salga de control Con una meta de tiempo cumpliéndose cada pocas semanas, la tendencia de aumentar los features disminuye.
  • * Se prepara el producto para agregar funcionalidad en el futuro
  • Agile Project Management

    1. 1. Agile Project Management
    2. 2. Fases 81 <ul><li>Envision : visión del producto, alcance del proyecto, comunidad del proyecto, forma de trabajo </li></ul><ul><li>Especular : Plan de release, milestones e iteraciones basado en features para materializar la visión </li></ul><ul><li>Explorar : entregar features probados en un período corto, tratando constantemente de reducir el riesgo y la incertidumbre del proyecto </li></ul><ul><li>Adaptar : revisar los resultados , la situación actual, el desempeño del equipo y adaptar cuando sea necesario . </li></ul><ul><li>Cerrar : concluir el proyecto, transmitir aprendizajes claves y celebrar </li></ul>
    3. 3. Envision 82 <ul><li>Primero : visionar qué es lo que se dará– una visión del producto y del alcance del proyecto </li></ul><ul><li>Segundo : visionar quien tomará parte– clientes, miembros del team e interesados (stakeholders) </li></ul><ul><li>Tercero : los miembros del team visionarán cómo se disponen a trabajar juntos </li></ul>
    4. 4. Especular 82-83 <ul><li>Recopilar los requerimientos iniciales amplios </li></ul><ul><li>Definir la carga de trabajo en la forma de una lista de features </li></ul><ul><li>Hacer un plan (release, milestones e iteraciones) que incluya fechas y asignación de recursos para esos features </li></ul><ul><li>Incorporar estrategias de mitigación de riesgos </li></ul><ul><li>Estimar costos del proyecto y generar otra información administrativa y financiera requerida </li></ul>
    5. 5. Explorar 83 <ul><li>Entrega de features del producto </li></ul><ul><li>Fija 3 áreas clave de actividad </li></ul><ul><ul><li>Entregar features planeados administrando la carga y usando prácticas técnicas apropiadas y estrategias de mitigación de riesgos </li></ul></ul><ul><ul><li>Crear una comunidad del proyecto colaborativa y auto-organizativa </li></ul></ul><ul><ul><li>Administrar las interacciones del equipo con: clientes, gerencia del producto y otros stakeholders. </li></ul></ul>
    6. 6. Adaptar 83 <ul><li>Responder al cambio es más importante que seguir un plan </li></ul><ul><li>Después de la fase ‘envision’, el loop será: especular  explorar  adaptar </li></ul><ul><li>Cada iteración refina sucesivamente el producto </li></ul><ul><li>Los resultados son vistos desde las siguientes perspectivas: </li></ul><ul><ul><li>Del cliente </li></ul></ul><ul><ul><li>Técnica </li></ul></ul><ul><ul><li>Gente </li></ul></ul><ul><ul><li>Performance de procesos </li></ul></ul><ul><ul><li>Status del proyecto </li></ul></ul>
    7. 7. Cerrar 84 <ul><li>Los proyectos deben tener un fin visible y percibible – hay que celebrarlo </li></ul><ul><li>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 </li></ul>
    8. 8. Prácticas
    9. 9. Consideraciones 84-86 <ul><li>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. </li></ul><ul><li>Los principios sin prácticas son inefectivos ylas prácticas sin principios tienden a implantarse mecánicamente, sin aplicar el juicio. </li></ul><ul><li>Las prácticas seleccionadas: </li></ul><ul><ul><li>Generativas, no prescriptivas </li></ul></ul><ul><ul><li>Enfocadas en delivery y no en compliance </li></ul></ul>
    10. 10. Fase: Envision 87
    11. 11. <ul><li>Todos los equipos que funcionan bien cuentan con un perfecto entendimiento de sus objetivos </li></ul><ul><li>Los detalles pueden ser borrosos, pero las objetivos de negocio y la visión del producto deben ser clarísimas </li></ul><ul><li>Sin una visión clara se arriesga experimentar sin fin. </li></ul><ul><li>Una visión clara, compelidora, es crítica para el éxito del proyecto ¿Por qué falta tantas veces? Respuesta: </li></ul><ul><ul><li>Una visión clara es difícil: requiere trabajo duro y liderazgo </li></ul></ul>89
    12. 12. Preguntas que resuelve 89 <ul><li>¿Cuál es la visión del producto del cliente? </li></ul><ul><li>¿Cuál es el alcance del proyecto y su juego de constraints? </li></ul><ul><li>¿quiénes son los participantes adecuados para la comunidad del proyecto? </li></ul><ul><li>¿Cómo entregará el equipo el producto (enfoque)? </li></ul>
    13. 13. Evolución del plan del producto <ul><li>Tres Herramientas simples y poderosas </li></ul><ul><li>Vision Box – Forza a condensar la visión </li></ul><ul><li>Project Data Sheet – Forza a decantar detalles claves de alcance y constraints </li></ul><ul><li>Feature Cards – Obliga a condensar la información de cada feature en una ficha </li></ul>Vision Alcance Features 91
    14. 14. Siempre recordar 91 <ul><li>¿Cuál es la documentación apenas suficiente? </li></ul><ul><li>El ‘como’ de la entrega los resultados está sujeto a ajustes y adaptaciones para mejorar el rendimiento conforme avanza el proyecto </li></ul><ul><li>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. </li></ul>
    15. 15. Las prácticas
    16. 16. Las pr ácticas (4 categorías) 92 <ul><li>Visión del producto </li></ul><ul><ul><li>Caja de la visión del producto y test del elevador </li></ul></ul><ul><ul><li>Arquitectura del producto y directrices </li></ul></ul><ul><li>Alcance del proyecto ( objetivos y constraints ) </li></ul><ul><ul><li>Data sheet del proyecto </li></ul></ul><ul><li>Comunidad del proyecto </li></ul><ul><ul><li>Conseguir la gente adecuada </li></ul></ul><ul><ul><li>Identificar a los participantes </li></ul></ul><ul><ul><li>Interfaces entre equipos cliente – desarrollo </li></ul></ul><ul><li>Enfoque </li></ul><ul><ul><li>Ajuste de procesos y prácticas </li></ul></ul>
    17. 17. Caja de Visi ón del Producto y Test del Elevador 93 (Práctica) <ul><li>Objetivo </li></ul><ul><ul><li>Estimular a los miembros del team a que focalicen sus ideas desperdigadas del producto en una forma concisa, visual y textual. </li></ul></ul><ul><ul><li>Estos dos mecanismos proveen un concepto común elevado del producto para mercadeo, desarrollo y gerentes. </li></ul></ul>
    18. 18. Desarrollo de la Discusión 93 <ul><li>No se puede predecir la innovación ni la creación de productos emergentes, por lo tanto hace falta un proceso especial. </li></ul><ul><li>Una buena visión del producto es constante, mientras que la vía para implementar esa visión necesita espacio para jugar. </li></ul><ul><li>Los resultados emergentes a veces provienen de accidentes intencionales, por lo tanto es necesario crear el ambiente para que ocurran estos accidentes. </li></ul>
    19. 19. Diseñando al caja del producto 93-94 <ul><li>Se trata de diseñar las partes frontal y trasera de la caja del producto </li></ul><ul><li>Esto implica </li></ul><ul><ul><li>Nombre del producto </li></ul></ul><ul><ul><li>Un gráfico </li></ul></ul><ul><ul><li>Tres a cuatro bullets claves en el frente </li></ul></ul><ul><ul><li>Descripción detallada de los features en la parte trasera </li></ul></ul><ul><li>Se presenta y discute cada propuesta de texto para la caja </li></ul>
    20. 20. Test del Elevador (> 2 minutos) 93 <ul><li>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. </li></ul>
    21. 21. Test del Elevador Formato 95 <ul><li>Para (cliente objetivo) </li></ul><ul><li>Que (exposición de la necesidad o de la oportunidad) </li></ul><ul><li>El (nombre del producto) es (categoría del producto) </li></ul><ul><li>Que (Beneficio clave, razón para comprarlo) </li></ul><ul><li>A diferencia de (Alternativa competitiva primaria) </li></ul><ul><li>Nuestro producto (exposición de la diferenciación primaria) </li></ul>
    22. 22. Más sobre visión del producto 95 <ul><li>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. </li></ul><ul><li>Después de varias horas de discusión: </li></ul><ul><ul><li>Mission statement </li></ul></ul><ul><ul><li>Dibujo de la caja </li></ul></ul><ul><ul><li>Clientes objetivo y sus necesidades </li></ul></ul><ul><ul><li>El test del elevador </li></ul></ul><ul><ul><li>Medidas de la satisfacción del cliente </li></ul></ul><ul><ul><li>Requerimientos clave operacionales y de tecnología </li></ul></ul><ul><ul><li>Restricciones críticas al producto (Performance, facilidad de uso, volúmenes) </li></ul></ul><ul><ul><li>Análisis competitivos </li></ul></ul><ul><ul><li>Indicadores financieros críticos** </li></ul></ul>
    23. 23. Práctica Arquitectura del Producto 98 <ul><li>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. </li></ul><ul><li>La arquitectura junto con el tamaño total del proyecto contiene implicaciones importantes para el éxito del proyecto y del producto </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>La arquitectura es guía, no camisa de fuerza. Busca comunicar el contexto mayor al team. </li></ul>
    24. 24. Feature Breakdown Structure 98 <ul><li>Gerencia de Ventas ( Business Area ) </li></ul><ul><ul><li>Prospectación ( Business Activity ) </li></ul></ul><ul><ul><ul><li>Crear pantalla log on de vendedores ( Feature ) </li></ul></ul></ul><ul><ul><ul><li>Listar leads para los vendedores </li></ul></ul></ul><ul><ul><ul><li>Desplegar detalles individuales por lead </li></ul></ul></ul><ul><ul><li>Administración de territorios </li></ul></ul><ul><ul><li>Análisis de ventas </li></ul></ul><ul><li>Marketing </li></ul><ul><ul><li>Generación de leads </li></ul></ul><ul><ul><li>Seguimiento de leads </li></ul></ul><ul><ul><li>Colocación de anuncios </li></ul></ul><ul><ul><li>Servicio de Call Center </li></ul></ul>
    25. 25. 99-100 <ul><li>Las arquitecturas utilizan una combinación de elementos de: plataforma, componente, interfaz, módulos </li></ul><ul><li>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 </li></ul><ul><li>La FBS provee el inventario de features desde el cual se desarrolla el plan de iteraciones </li></ul><ul><li>La organización humana y la arquitectura técnica coevolucionan durante la vida del proyecto </li></ul><ul><ul><li>Un core team multidisciplinario puede funcionar mejor al principio </li></ul></ul><ul><ul><li>Cuando ya han sido especificadas las interfaces mediante interacciones y debate, sub-teams basados en componentes pueden funcionar mejor </li></ul></ul>
    26. 26. Principios guía 100-101 <ul><li>Esta es una segunda pieza de la guía arquitectónica </li></ul><ul><li>Estos principios asisten al team para que moldee el producto según las preferencias de los clientes. </li></ul><ul><li>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 </li></ul><ul><li>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 </li></ul>
    27. 27. Práctica 101 Project Data Sheet – PDS <ul><li>Objetivo: transmitir la esencia en términos de alcance , calendario y recursos , de cómo el proyecto materializará la visión. </li></ul><ul><li>Es la segunda más importante práctica de la fase de Envision </li></ul>
    28. 28. Project Data Sheet 101-102 Product vrs Project vision <ul><li>La visión del producto es una vista expandida de lo que el producto podría llegar a ser </li></ul><ul><li>La visión del proyecto limita el desarrollo del producto a los confines de lo definido en: alcance, calendario, y restricciones de costos. </li></ul><ul><ul><li>Product vision  should haves – 234 features </li></ul></ul><ul><ul><li>Project scope  will have – 126 features (Rel 1.0) </li></ul></ul>
    29. 29. Secciones de una PDS 102 <ul><li>Clientes: lista de clientes clave </li></ul><ul><li>Project Manager </li></ul><ul><li>Product Manager </li></ul><ul><li>Project Objective Statement (POS) </li></ul><ul><li>Tradeoff Matrix (TOM) </li></ul><ul><li>Factor de exploración </li></ul><ul><li>Costo de los atrasos </li></ul><ul><li>Features (lista de los claves) </li></ul><ul><li>Beneficios al cliente </li></ul><ul><li>Arquitectura </li></ul><ul><li>Puntos/riesgos*** </li></ul>Ejemplo
    30. 30. Tradeoff Matrix - TOM 104 Una entrada/columna Conviene medir límite * Defectos x Recursos x Estabilidad* x Calendario x Alcance Acepta Flexible Fijo
    31. 31. 104 <ul><li>Es un acuerdo entre el team del proyecto, el cliente y el sponsor ejecutivo que se usa para manejar el cambio durante el proyecto. </li></ul><ul><li>Las filas muestran las dimensiones claves que crean el valor del producto </li></ul><ul><li>Las columnas despliegan la importancia relativa de cada dimensión </li></ul>
    32. 32. Tradeoff Matrix 105 <ul><li>No se puede responder a cambios si no se marca un espacio para manejarlos </li></ul><ul><li>Es importante calcular el costo de los atrasos </li></ul>
    33. 33. Factor de Exploración 105-106 <ul><li>Barómetro de la incertidumbre y del riesgo </li></ul><ul><li>Relacionado con el “problem domain” donde el team operará </li></ul><ul><li>10 indica un problem domain orientado a la exploración (alto riesgo) y 1 indica un ambiente de problemas estable </li></ul><ul><li>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 </li></ul><ul><li>Resulta de combinar la volatilidad de los requerimientos del producto con lo nuevo –inicierto- de la plataforma tecnológica. </li></ul>
    34. 34. Factor de Exploración 107 10: problem domain que requiere mucha exploración 1: ambiente del problema muy estable 1 5 5 7 Estable 3 4 6 7 Rutina 5 6 7 8 Fluctuante 7 7 8 10 Errática Bien conocida Familiar Leading Edge Bleeding Edge Dimensión de producto Dimensión de Tecnología
    35. 35. Problem Domain 107 <ul><li>Es necesario establecer la incertidumbre global del espacio del problema. </li></ul><ul><li>Proyectos 8, 9, 10 requieren un enfoque fuerte APM </li></ul><ul><ul><li>Iteraciones cortas </li></ul></ul><ul><ul><li>Planeación basada en features </li></ul></ul><ul><ul><li>Revisiones frecuentes con los clientes </li></ul></ul><ul><ul><li>Reconocimiento que los planes son especulativos </li></ul></ul><ul><li>El reconocimiento de diferentes dominios de problemas permite hacer ajustes a problemas específicos y asegurar el éxito. </li></ul>
    36. 36. Práctica Consiga la gente correcta 108 <ul><li>‘ El’ factor crítico de éxito </li></ul><ul><li>‘ Correcta’ quiere decir: </li></ul><ul><ul><li>Capacidad técnica apropiada o experticia en el ‘domain’ </li></ul></ul><ul><ul><li>El comportamiento disciplinado adecuado </li></ul></ul><ul><ul><li>No significa la más talentosa y experimentada, sino la gente apropiada para el trabajo. </li></ul></ul><ul><li>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 . </li></ul>
    37. 37. Práctica 111 Identificación de participantes <ul><li>Objetivo : identificar a los participantes de modo que las expectativas sean entendidas y administradas. </li></ul><ul><li>Los participantes son los que pertenecen a la comunidad del proyecto: </li></ul><ul><ul><li>Clientes – determinan e influyen los requerimientos </li></ul></ul><ul><ul><li>Ejecutivos – proveen fondos y supervisión gerencial </li></ul></ul><ul><ul><li>Miembros nucleares del team – trabajan para entregar el producto. </li></ul></ul><ul><ul><li>Stakeholders – Participantes internos que no son clientes directos </li></ul></ul><ul><li>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 </li></ul>
    38. 38. Lista de participantes 112 <ul><li>Patrocinador ejecutivo : decisiones claves sobre metas y restricciones </li></ul><ul><li>Gerente del proyecto : dirige el team a cargo de dar los resultados </li></ul><ul><li>Gerente de Producto : guía al equipo para determinar qué resultados dar </li></ul><ul><li>Ingeniero líder : guía los aspectos técnicos de las entregas </li></ul><ul><li>Gerencia : una gama potencialmente amplia de individuos con alguna autoridad técnica o de presupuesto sobre los resultados </li></ul><ul><li>Equipo del cliente : a cargo de fijar features y priorizarlos </li></ul><ul><li>Team del proyecto : los encargados de dar los resultados </li></ul><ul><li>Proveedores : proveen servicios o componentes del producto </li></ul><ul><li>Gobierno : Organismos regulatorios que requieren información, reportes y certificaciones </li></ul>
    39. 39. Fase : Especular 127
    40. 40. Ideas preliminares 128 <ul><li>El control de cambios congela los requerimientos </li></ul><ul><li>El alcance mismo también evoluciona </li></ul><ul><li>De resistir el cambio a estimular el cambio </li></ul><ul><li>El control de cambios se refiere a la coordinación no a la negación </li></ul><ul><li>Flexibilidad indisciplinada  caos </li></ul><ul><li>Estabilidad indisciplinada  rigidez </li></ul><ul><li>Balance entre flexibilidad y estructura mediante auto disciplina </li></ul>
    41. 41. Ideas preliminares 2 129 <ul><li>Los planes son guías, no camisas de fuerza </li></ul><ul><li>La realidad siempre se entromete </li></ul><ul><li>Los planes son vehículos para abrazar el cambio, no para bloquearlo </li></ul><ul><li>Los planes son: </li></ul><ul><ul><li>Conjeturas acerca del futuro </li></ul></ul><ul><ul><li>Guías para el futuro </li></ul></ul><ul><li>El desarrollo genera nueva información que a su vez crea la necesidad de re-planear </li></ul><ul><li>No es riesgo loco sino: “conjeturar algo basado en hechos e información incompleta”. </li></ul>
    42. 42. 129 <ul><li>El fruto de esta fase es el ‘Release Plan’ que contiene el mejor conocimiento inicial del team </li></ul><ul><ul><li>Este plan está basado en features entregados y no en actividades </li></ul></ul><ul><li>El plan de release usa información de: </li></ul><ul><ul><li>Especificaciones del producto </li></ul></ul><ul><ul><li>Arquitectura de la plataforma </li></ul></ul><ul><ul><li>Recursos </li></ul></ul><ul><ul><li>Análisis de riesgo </li></ul></ul><ul><ul><li>Niveles de defecto </li></ul></ul><ul><ul><li>Restriccciones de negocios </li></ul></ul><ul><ul><li>Calendario deseado </li></ul></ul>
    43. 43. 129-130 <ul><li>Dos componentes cruciales en un enfoque de planeación y desarrollo iterativo </li></ul><ul><ul><li>Ventanas pequeñas de iteración </li></ul></ul><ul><ul><li>Features </li></ul></ul><ul><li>Para proyectos de SW: cada ventana de 2 a 6 semanas </li></ul><ul><li>Las ventanas cortas aceleran el desarrollo </li></ul><ul><li>La primera meta de la planeación y desarrollo basado en features es hacer el proceso visible y entendible. </li></ul>
    44. 44. 130 <ul><li>Los features funcionan como interfaces entre los ingenieros de desarrollo y los usuarios finales – son un medio para entendimiento compartido. </li></ul><ul><li>Este espacio compartido toma la forma de una feature card </li></ul><ul><ul><li>El frente: información del feature </li></ul></ul><ul><ul><li>Detrás: información de la tarea técnica para estimar esfuerzo y administrar el trabajo </li></ul></ul><ul><ul><li>“ Estamos atrasados, recortemos los features 31 y 64”, en lugar de: “recortemos el tiempo de tests” </li></ul></ul>
    45. 45. Ayudas que da esta fase 130-131 <ul><li>Determinar c ómo el producto y sus features evolucionarán </li></ul><ul><li>Concentrarse en los features de alto valor desde el principio </li></ul><ul><li>No perder de vista los objetivos de negocios y las expectativos del cliente </li></ul><ul><li>Coordinar actividades y features interrelacionados entre ‘feature teams’ </li></ul><ul><li>Considerar alternativas de acciones adaptivas </li></ul><ul><li>Proveer una línea base para analizar eventos que se dan durante el proyecto. </li></ul>
    46. 46. 131 <ul><li>Se necesita recompensar al team por su respuesta a los cambios , y no amonestarlos por no haber hecho un plan </li></ul>
    47. 47. Categorías de prácticas 131 <ul><li>Estructura de feature breakdown </li></ul><ul><ul><li>Lista de features del producto </li></ul></ul><ul><ul><li>Feature cards </li></ul></ul><ul><ul><li>Tarjetas de requerimientos de performance </li></ul></ul><ul><li>Plan de entregas </li></ul><ul><ul><li>Entregas, milestones, plan de iteraciones </li></ul></ul>
    48. 48. Prácticas Plan de Iteraciones Feature Breakdown Lista de Features Tarjetas de Features Requerimientos Performance Iteración 0 Análisis de riesgo Próximo plan de Iteración Plan de entregas, milestones e iteraciones 132
    49. 49. Práctica 132 Lista de Features del Producto <ul><li>Expansión de la desarrollada en la fase de envision </li></ul><ul><li>Esta lista y las tarjetas que le acompañan son el insumo principal para la planeación de entregas, milestones e iteraciones. </li></ul><ul><li>Para cada feature crea una tarjeta que contiene información básica descriptiva y de estimaciones. </li></ul><ul><li>El software no es muy estricto para exigir todas las especificaciones desde un inicio, por lo tanto le aplica un proceso evolutivo de especificaciones . </li></ul>
    50. 50. Jerarquía de features 133 <ul><li>Producto </li></ul><ul><ul><li>Area de business subject </li></ul></ul><ul><ul><ul><li>Business activity </li></ul></ul></ul><ul><ul><ul><ul><li>Feature </li></ul></ul></ul></ul><ul><li>Pequeños productos podrían usar sólo el nivel de features. </li></ul>
    51. 51. ¿Qué es un feature? 134 <ul><li>Es un trozo del producto que entrega funcionalidad valiosa y utilizable a un cliente. </li></ul><ul><li>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. </li></ul><ul><ul><li>El peligro: construir muchos componentes tecnológicos o de infraestructura antes de construir algo con significado directo para el cliente </li></ul></ul><ul><ul><li>En cuanto más tiempo pasa por allí debajo, más se puede desviar el proyecto antes de recibir feedback del cliente. </li></ul></ul>
    52. 52. Features 134 <ul><li>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. </li></ul><ul><li>Una característica de los proyectos APM es la volatilidad de los features en esta lista. </li></ul><ul><li>Durante la planeación para cada iteración, la lista de features a incluir puede cambiar significativamente en relación al plan original </li></ul>
    53. 53. Pr áctica Feature Cards 135 <ul><li>Objetivo: medio sencillo para juntar información sobre los features, registrar requerimientos de alto nivel y desarrollar estimados de trabajo. </li></ul><ul><li>El desarrollo basado en features pretende ser desarrollo customer-facing </li></ul>
    54. 54. Feature Cards Discusión 135 <ul><li>Las fc identifican mas no definen los features </li></ul><ul><li>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 . </li></ul><ul><li>La discusión es crítica para entender la que a su vez es crítica para estimar </li></ul><ul><li>Identifican features que los clientes quieren en el producto </li></ul><ul><li>Para proyectos grandes, se pueden usar ‘group cards’ por business activity para organizar y planear listas individuales de features, de 10, 15 o 20 </li></ul><ul><li>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 </li></ul>
    55. 55. 136 Tests de Aceptación: Dependencia de otros features: ninguna Incertidumbre de los requerimientos(E,F,R,S): R (rutina) Cantidad estimada de trabajo: 4.5 días Crear territorios de ventas con base en regiones y áreas metropolitanas estándar Descripción del feature: Nombre de feature: Establecer territorios de ventas Tipo de feature: cliente No. de Feature: 25 Iteración planeada: 3 Feature Card
    56. 56. Contenido de Feature Card 136 <ul><li>Identificador y nombre del feature </li></ul><ul><li>Descripción: una o dos oraciones en términos del cliente </li></ul><ul><li>Tipo de feature (C=customer, T=técnico) </li></ul><ul><li>Trabajo estimado: lo que lleva producir el feature, e incluye tiempo para recoger requerimientos, diseño, codificación, pruebas y documentación. </li></ul><ul><li>Incertidumbre de los requerimientos (erráticos, fluctuantes, rutinarios, estables): un factor de exploración </li></ul><ul><li>Dependencias de features: que podrían afectar la secuencia de implementación </li></ul><ul><li>Tests de aceptación: criterios que el cliente utilizará para aceptar o rechazar el feature. </li></ul>
    57. 57. Capa debajo de los features 137 <ul><li>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. </li></ul><ul><li>Se pueden combinar las actividades técnicas de varios features en un solo paquete técnico de trabajo. </li></ul><ul><li>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. </li></ul><ul><li>Si es difícil fijar los requerimientos, podría requerirse una serie de prototipos de descubrimiento. </li></ul><ul><li>Features altamente inciertos podrían requerir investigación adicional antes de planearlos. </li></ul>
    58. 58. P ráctica Tarjeta de Requerimientos de Performance <ul><li>Objetivo: documentar las operaciones clave y los requerimientos de performance del producto. </li></ul><ul><li>Suelen ser de diferente color que las de features </li></ul><ul><li>Contienen: nombre, descripción, metas cuantitativas de performance </li></ul><ul><li>Contienen también los correspondientes ‘criterios de aceptación’ o ‘tests’ en esta área. </li></ul>
    59. 59. a- <2 seg en iteración 3 b- <1 seg en iteración 6 Criterio de aceptación M (moderada) Dificultada para lograrla (H,M,L) El IM debe intervenir antes de transcurrido un segundo de detectada la interacción Descripción del performance Inicio del Interaction Manager Nombre del aspecto PC-12 Performance ID: Iteración demostrada : 6 Tarjeta de performance
    60. 60. Práctica 140-141 Plan de Releases, Milestones e Iteraciones <ul><li>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. </li></ul><ul><li>Los ciclos APM son iterativos y guiados por features . </li></ul><ul><ul><li>Cambia el foco de la planeación y la ejecución de tareas a features de producto </li></ul></ul><ul><li>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. </li></ul>
    61. 61. 142 <ul><li>Las iteraciones producen features que han pasado los criterios de aceptación </li></ul><ul><ul><li>La meta es disponer de un producto con features parciales y que pueda entregarse al final de cada iteración. </li></ul></ul><ul><ul><li>Incremental delivery </li></ul></ul><ul><li>Milestones son puntos intermedios de uno a tres meses y pueden tener funciones gerenciales y técnicas </li></ul><ul><li>Su uso más importante: Puntos fuertes de sincronización e integración </li></ul>
    62. 62. Factores 143 <ul><li>Dos factores guían el plan de releases, milestones e iteraciones para asignar features: </li></ul><ul><ul><li>Valor del cliente </li></ul></ul><ul><ul><li>Riesgo </li></ul></ul><ul><li>Todas las demás consideraciones de calendarización –disponibilidad de recursos, dependencias y otras- se subordinan a valor y riesgo </li></ul>1a. Prioridad 2a. prioridad Alto valor 3a. prioridad Bajo Valor Bajo riesgo Alto riesgo
    63. 63. Iteración 0 143 - 144 <ul><li>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. </li></ul><ul><li>Por ejemplo, un proyecto pudiera requerir alguna aequitectura de datos para desarrollar interfaces. </li></ul><ul><li>Para cada uno de estos items debe crearse una feature card. (Contendrá algún diagrama de arquitectura en lugar de un feature implementable) </li></ul><ul><li>Ejemplo de un release plan </li></ul>
    64. 64. Iteraciones 1-N 144 <ul><li>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í. </li></ul>
    65. 65. Arquitectura 1.0 Iteraci ó n 1 Tarjeta tema Arquitectura 1.1 Arquitectura 1.2 Feature 3 Feature 2 Feature 1 Feature 7 Feature 5 Feature 3 Feature 4 Investigación Requerimientos Iteraci ó n 2 Tarjeta tema Iteraci ó n 3 Tarjeta tema Iteraci ó n 4 Tarjeta tema Iteración 0 Iteración 1 Iteración 2 Iteración 3 Iteración 4 PLANO DE FEATURE CARDS 146
    66. 66. Las Actividades para hacer el plan de iteración Incluyen 146 <ul><li>Determinar cómo los riesgos identificados influirán en la planeación </li></ul><ul><li>Identificar la meta del calendario </li></ul><ul><li>Establecer los períodos de milestone y de iteración </li></ul><ul><li>Desarrollar un tema para cada iteración </li></ul><ul><li>Asignar feature cards a cada iteración balancenado prioridades del cliente, riesgos, recursos y dependencias </li></ul><ul><li>Sumarizar el plan en combinaciones de hoja a nivel de feature, plano de feature cards, parking lot </li></ul><ul><li>Calcular el calendario inicial según disonibilidad de staff y el total estimado de trabajo </li></ul><ul><li>Ajustar el plan cuando sea necesario </li></ul>
    67. 67. 147 <ul><li>Mientras que con criterios de cliente se asignan features a las iteraciones, aspectos de riesgo ténico pueden influir en estas decisiones. </li></ul><ul><li>Algunas veces se implementan primero los features de alto riesgo con el fin de reducir riesgos. </li></ul><ul><li>La interdependencia entre features influye en la asignación, pero los más importantes son valor del cliente y riesgo . </li></ul>
    68. 68. 148- 149 <ul><li>Para cada iteración y milestone, el equipo debe desarrollar y escribir un tema guía. </li></ul><ul><ul><li>Esto es importante para que el team balancee entre amplitud y profundidad de los features </li></ul></ul><ul><ul><li>Lo mejor para esto son tarjetas de iteración (ver ej en lámina siguiente) </li></ul></ul><ul><li>La ventaja de las tarjetas es que se pueden barajar durante las sesiones de planeación </li></ul><ul><li>La información de las interdependencias de features debe estar en las feature cards. </li></ul><ul><li>Un fc llamada “Re-trabajo y contingencia” se coloca en cada iteración. </li></ul><ul><li>Se pueden acomodar también iteraciones vacías </li></ul><ul><li>Los features asignados a los últimas iteraciones son los que se pueden botar si hiciera falta. </li></ul>
    69. 69. 149 Tema de una iteración Las funciones avanzadas se verán en la iteración 7 Comentario Tema: Captura de feedbacks para crear el rich log Supuesto: Las simulaciones probarán un 80% de la funcionalidad Iteracion No. 3
    70. 70. Gerencia de Ventas (GV) Marketing (MM) 150 May 2004 0 Análisis de Ventas (18 ) Ago 2004 0 Seguimiento Leads (8 ) Sep 2004 0 Pautar Anuncios (9 ) Oct 2004 0 Servicio Call Center (28 ) May 2004 0 Generación Leads (22 ) Jun 2004 0 Prospecta- ción (10 ) Jul 2004 0 Manejo de Territorio (8 )
    71. 71. Planeación y Reportes a Nivel de Componentes o Actividad de Negocios
    72. 72. 150 <ul><li>Para proyectos de mediano a grande, la planeación a nivel de feature es demasiado fina, al menos para muchos clientes y gerentes. </li></ul><ul><li>Una aplicación grande puede contener miles de features </li></ul><ul><ul><li>El team de desarrollo necesita el detalle </li></ul></ul><ul><ul><li>Clientes y gerentes pueden ser más efectivos a un nivel más grueso de ganularidad </li></ul></ul><ul><li>Para estos casos: FDD  Feature Driven Development </li></ul>
    73. 73. 150 Feature-Driven Development <ul><li>Se basa en una jerarquía granular de features </li></ul><ul><li>En el caso del Manager Plus, la jerarquía sería: </li></ul><ul><ul><li>Business Subject Area (Ventas) </li></ul></ul><ul><ul><ul><li>Business Activity ( Análisis de ventas ) </li></ul></ul></ul><ul><ul><ul><ul><li>Feature : ( Generar un reporte de ventas de producto por territorio ) </li></ul></ul></ul></ul>
    74. 74. 151 FDD <ul><li>Aplicaciones grandes, como un CRM, pueden tener de 30 a 50 actividades y varios miles de features </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Este enfoque de “dos capas” para la planeacion puede ser muy efectivo. </li></ul><ul><li>De Luca divide el dominio técnico en tres grupos de features : </li></ul><ul><ul><li>User Interface </li></ul></ul><ul><ul><li>Database </li></ul></ul><ul><ul><li>Systems Interface </li></ul></ul>
    75. 75. 152 FDD <ul><li>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 </li></ul><ul><li>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. </li></ul><ul><li>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 </li></ul>
    76. 76. 152 Tres tipos de planes de iteración <ul><li>Hay varias formas de conducir el calendario inicial </li></ul><ul><ul><li>Asignar features a las iteraciones hasta la fecha meta y luego determinar si el alcance (features que se pueden implementar) parece razonable. </li></ul></ul><ul><ul><li>Asignar todos los features y luego comparar la fecha planeada (con todos los features) con la fecha meta. </li></ul></ul>
    77. 77. 152-153 <ul><li>Para proyectos con alto grado de exploración, los calendarios iniciales pueden contener demasiados “sis”. Dependiendo del grado de incertidumbre se puede hacer. </li></ul><ul><ul><li>Un plan completo con features asignados a cada iteración </li></ul></ul><ul><ul><li>Un plan para dos iteraciones, utilizando sólo la próxima interacción, y dejar todo el resto para después . </li></ul></ul><ul><ul><li>Un plan de iteración por iteración. </li></ul></ul><ul><li>La decisión por uno de estos dependerá de: </li></ul><ul><ul><ul><li>Naturaleza del proyecto </li></ul></ul></ul><ul><ul><ul><li>Expectativas de clientes y stakeholders </li></ul></ul></ul><ul><li>Todo debe preverse en la fase de ‘Envision’ </li></ul>
    78. 78. 153 Plan de la próxima iteración <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>El equipo re-estima el trabajo con base en el examen más detallado y ajusta los features planeados para esa iteración </li></ul><ul><li>Finalmente, los miembros se apuntan para features o actividades basados en sus propias habilidades y/o deseos* </li></ul>
    79. 79. 154 1er. Deployment Factible <ul><li>Puesto que un deployment rápido conlleva muchos beneficios, algo que el team puede hacer es determinar este FFD: First Feasible Deployment </li></ul><ul><ul><li>Se puede hacer una instalación temprana a clientes clave que han pedido el producto </li></ul></ul><ul><li>Para el team puede traer a) Ingreso anticipado, b) feedback valioso </li></ul><ul><ul><li>Ojo: los costos de deployment podrían ser más que los beneficios </li></ul></ul><ul><ul><li>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 </li></ul></ul>
    80. 80. 155 Deployment <ul><li>El desarrollo iterativo crea piezas ‘deployable’ del producto, mientras que el desarrollo incremental realiza el deployment de las piezas del producto </li></ul><ul><li>En algunos tipos de desarrollo de SW. p. ej. Web, cada iteración puede ser un ‘deployment’ incremental </li></ul><ul><li>El deployment anticipado de productos parcialmente completados logra: </li></ul><ul><ul><li>Mejora del ROI (por los ingresos) </li></ul></ul><ul><ul><li>Feedback temprano que puede mejorar el desarrollo en iteraciones subsiguientes.* </li></ul></ul><ul><li>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 </li></ul><ul><li>Si el FFD se corre al final del proyecto, puede indicar un riesgo </li></ul>
    81. 81. 155 Estimando <ul><li>¿Cómo se estima un proyecto ágil? </li></ul><ul><li>Respuesta: con las mismas técnicas de siempre </li></ul><ul><li>Hay tres sutilezas detrás de la pregunta </li></ul><ul><ul><li>Cómo estimar lo desconocido </li></ul></ul><ul><ul><li>Cómo estimar por features en lugar de actividades </li></ul></ul><ul><ul><li>Cómo hacer una estimación progresiva </li></ul></ul>
    82. 82. Primero 156 <ul><li>¿Cómo se estima lo desconocido? No se puede – se adivina. </li></ul><ul><ul><li>Por lo tanto, tiempo y costo son vistos como restricciones, no como estimados </li></ul></ul><ul><li>Se aprende a vivir con la incertidumbre en lugar de demandar certidumbre de un mundo de cambios vertiginosos. </li></ul>
    83. 83. Segundo 156 <ul><li>Los proyectos ágiles se planean por features </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>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 </li></ul><ul><li>Por lo tanto, en la mayoría de los casos, la planeación basada en features provee mejores estimados </li></ul>
    84. 84. Tercero 156 <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
    85. 85. Evolución del Alcance ¡¿?! 157 <ul><li>Algunos cambios del alcance son de bajo costo y valiosos </li></ul><ul><li>Otros son extensos y costosos, pero cruciales para proveer valor al cliente </li></ul><ul><li>Los cambios pueden ser perjudiciales si son arbitrarios o mal pensados </li></ul><ul><li>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. </li></ul>
    86. 86. Alcance y features 158 <ul><li>No hay que grabar en placas doradas los requerimientos. </li></ul><ul><li>Dupont estima que sólo el 25% de los features en su software se necesitan realmente. </li></ul><ul><li>45% de los features nunca fueron usados </li></ul><ul><li>Sólo 20% se usaron a menudo o siempre </li></ul><ul><li>Esto confirma que el deployment parcial mejora el ROI – puede evitar que uno construya features costosos y no utilizados </li></ul><ul><ul><li>Cortar los teams y los proyectos por la mitad, ¿no acelera el desarrollo y reduce los costos al mismo tiempo ?** </li></ul></ul>
    87. 87. Alcance y features 158 <ul><li>La estrategia de construir unos features mínimos JUNTO CON la capacidad de adaptarse fácilmente y razonablemente al cambio puede ser muy rentable </li></ul><ul><li>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 </li></ul><ul><li>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. </li></ul>
    88. 88. Alcance y features 158-159 <ul><li>El alcance del producto se basa en : </li></ul><ul><ul><li>valor del cliente </li></ul></ul><ul><ul><li>factibilidad t écnica y costo </li></ul></ul><ul><ul><li>Impacto en la adaptabilidad del producto </li></ul></ul><ul><ul><li>necesidades críticas del calendario del cliente </li></ul></ul><ul><ul><ul><li>No debe ser rehén de un conocimiento inicial incompleto </li></ul></ul></ul><ul><li>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. </li></ul><ul><li>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.* </li></ul>
    89. 89. 159 Análisis y mitigación de riesgos <ul><li>El análisis y la mitigación de riesgos son parte integral de cada fase y proceso del APM </li></ul><ul><li>El diseño de un producto evoluciona de entender los requerimientos y las restricciones y de entender la ciencia y la ingeniería subyacentes. </li></ul><ul><li>Los riesgos dominantes en el software </li></ul><ul><ul><li>Problemas inherentes al calendario </li></ul></ul><ul><ul><li>Inflación de requerimientos </li></ul></ul><ul><ul><li>Partida de empleados </li></ul></ul><ul><ul><li>Derrumbe de las especificaciones </li></ul></ul><ul><ul><li>Productividad pobre </li></ul></ul>
    90. 90. Riesgo 160 <ul><li>La mejor estragegia de mitigación de riesgo es la entrega incremental </li></ul><ul><li>Para un producto altamente incierto, la falla en cumplir un calendario pueda no ser defecto, sino la pura imposibilidad de calendarizar lo desconocido. </li></ul><ul><li>Las técnicas APM dirigidas al riesgo: </li></ul><ul><ul><li>Involucración fuerte del team en planeación y estimación </li></ul></ul><ul><ul><li>Feedback temprano sobre la velocidad de entrega </li></ul></ul><ul><ul><li>Presión constante para balancear el número y profundidad de los features con las restricciones de calendario </li></ul></ul><ul><ul><li>Interacciones cercanas entre los equipos de ingeniería y de clientes </li></ul></ul><ul><ul><li>Detección/corrección temprana de errores para mantener un producto limpio y funcional </li></ul></ul>
    91. 91. Riesgo 161 <ul><li>APM posee una mitigación built-in contra la partida de empleados gracias al énfasis en la colaboración </li></ul><ul><li>El derrumbe de las especificaciones ocurre cuando cuando los clientes o los gerentes de producto fallan en acordar las especificaciones. </li></ul><ul><li>Productividad pobre: </li></ul><ul><ul><li>Gente equivocada en el equipo </li></ul></ul><ul><ul><li>El team no trabaja bien en conjunto </li></ul></ul><ul><ul><li>Baja moral </li></ul></ul><ul><li>Riesgo para productos nuevos </li></ul><ul><ul><li>pobre investigación de mercado </li></ul></ul><ul><ul><li>problemas técnicos </li></ul></ul><ul><ul><li>insuficiente esfuerzo de mercadeo </li></ul></ul><ul><ul><li>mal timing </li></ul></ul>
    92. 92. Sumario de la fase 164 <ul><li>Tres actividades claves a completar antes de empezar a desarrollar features </li></ul><ul><ul><li>Articular una visión de producto </li></ul></ul><ul><ul><li>Definir el alcance y restricciones del proyecto </li></ul></ul><ul><ul><li>Crear un plan de entregas iterativo, basado en features </li></ul></ul><ul><li>Este último es el principal deliverable de la fase de especular </li></ul><ul><li>Cuando se logra la lista de features y el release plan, el resto es relativamente fácil </li></ul><ul><li>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. </li></ul>
    93. 93. EXPLORAR Cap 7 165
    94. 94. 166 <ul><li>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. </li></ul><ul><li>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. </li></ul>
    95. 95. Liderazgo – Colaboración 166 <ul><li>El modelo CAS es una metáfora útil para un estilo de gerencia del tipo liderazgo-colaboración, el cual estimula un comportamiento: </li></ul><ul><ul><li>emergente (innovador) </li></ul></ul><ul><ul><li>tomador de riesgos </li></ul></ul><ul><li>Bajo esta luz, las tareas claves gerenciales son: </li></ul><ul><ul><li>Establecer una visión </li></ul></ul><ul><ul><li>Crear un ambiente de trabajo colaborador </li></ul></ul>
    96. 96. Gerencia 167 <ul><li>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. </li></ul>
    97. 97. Contribución de la gerencia 167 <ul><li>Enfocar al team a que dé resultados </li></ul><ul><li>Hacer un team de un grupo de individuos </li></ul><ul><li>Desarrollar las capacidades de cada individuo </li></ul><ul><li>Proveer al team con los recursos requeridos y removerle obstáculos </li></ul><ul><li>Asesorar a los clientes </li></ul><ul><li>Orquestar el ritmo del team </li></ul><ul><li>Rol esencial: Crear un team de alto rendimiento a partir de un grupo de individuos. </li></ul>
    98. 98. Prácticas de la fase 168 <ul><li>Dar resultados según la visión y los objetivos </li></ul><ul><ul><li>Workload management </li></ul></ul><ul><li>Prácticas técnicas </li></ul><ul><ul><li>Cambio a bajo costo </li></ul></ul><ul><li>Comunidad del proyecto </li></ul><ul><ul><li>Coaching y desarrollo del team </li></ul></ul><ul><ul><li>Reuniones diarias de integración </li></ul></ul><ul><ul><li>Toma de decisiones participativa </li></ul></ul><ul><ul><li>Interacción diaria con el team del cliente </li></ul></ul>
    99. 99. Práctica 169 Workload Management <ul><li>Fin: lograr que los miembros del team manejen las actividades diarias requeridas para dar resultados al final de cada iteración </li></ul><ul><li>Los miembros del team deben manejar su propia carga en la mayor medida posible </li></ul><ul><li>Los gerentes de proyecto dan la dirección en lugar de controlar </li></ul>
    100. 100. Práctica 171 Cambio a bajo costo <ul><li>Meta: crear un producto adaptable </li></ul><ul><li>Mantener a un mínimo el costo del cambio y de la experimentación, lo que expande las posibilidades de diseño. </li></ul><ul><li>Cuatro prácticas </li></ul><ul><ul><li>Diseño simple </li></ul></ul><ul><ul><li>Integración frecuente </li></ul></ul><ul><ul><li>Despiadados con las pruebas </li></ul></ul><ul><ul><li>Refactura oportunista </li></ul></ul>
    101. 101. Deuda Técnica 171 <ul><li>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. </li></ul><ul><li>La deuda técnica puede surgir durante </li></ul><ul><ul><li>el desarrollo inicial </li></ul></ul><ul><ul><li>el mantenimiento ordinario </li></ul></ul><ul><ul><li>las ampliaciones </li></ul></ul><ul><li>APM  dar valor del cliente hoy y mañana. La deuda técnica se refiere a mañana. </li></ul>
    102. 102. Costo del Cambio 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
    103. 103. Deuda técnica 172 <ul><li>El incremento de la deuda técnica reduce directamente la responsividad a los clientes. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
    104. 104. Deuda técnica 172 <ul><li>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. </li></ul><ul><li>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 </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
    105. 105. Deuda técnica 173 <ul><li>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. </li></ul>
    106. 106. Dise ño simple 173 <ul><li>Objetivo: mantener al aquipo afincado sobre lo conocido en lugar de anticipar lo desconocido. </li></ul><ul><li>Hay dos enfoques fundamentales hacia el manejo del cambio que deben aparecer en las buenas estrategias de diseño: </li></ul><ul><ul><li>Anticipación </li></ul></ul><ul><ul><li>Adaptación </li></ul></ul><ul><li>Anticipación: predecir los cambios y planear </li></ul><ul><li>Adaptación: esperar que evolucionen los requerimientos o que los cambios se manifiesten. </li></ul>
    107. 107. Adaptación 173 <ul><li>También significa experimentar, elegir los experimentos con los mejores resultados e incorporar los resultados en el producto. </li></ul><ul><li>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. </li></ul><ul><li>Si hay posibilidades de que algo cambie, debemos diseñar el sistema para que incorpore fácilmente ese cambio. </li></ul><ul><li>Diseño simple significa darle valor a la adaptación por sobre la anticipación </li></ul><ul><li>La maleabilidad del producto depende del bajo costo de la iteración. </li></ul><ul><ul><li>Cuando los componentes no son maleables, se prefiere la anticipación. </li></ul></ul>
    108. 108. Integración frecuente 175 <ul><li>Busca asegurar que los features encajan juntos en un todo integrado lo más antes y más frecuentemente posible. </li></ul>
    109. 109. Despiadados con las pruebas 178 <ul><li>El fin es que la calidad del producto se mantenga alta a lo largo del proceso de desarrollo. </li></ul><ul><li>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. </li></ul><ul><ul><li>Integrar QA y pruebas de aceptación en cada iteración </li></ul></ul><ul><ul><li>Disponer de un conjunto completo de pruebas automatizadas </li></ul></ul><ul><li>La meta final es sacar un producto instalable , de features limitados, de cada iteración. </li></ul>
    110. 110. Refactoring oportunista 179 <ul><li>El fin es mejorar el diseño del producto constantemente y continuamente –hacerlo más adaptable- para lograr la doble meta: </li></ul><ul><ul><li>proveer valor del cliente hoy </li></ul></ul><ul><ul><li>proveer valor del cliente mañana </li></ul></ul><ul><li>Hay que incluir una disciplina de refactoring a nivel de producto en el proceso de desarrollo. </li></ul><ul><li>Refactoring implica actualizar los componentes internos (mejorar el diseño) sin cambiar la funcionalidad externa, para poder mejorar el producto en el futuro. </li></ul><ul><li>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. </li></ul>
    111. 111. Refactoring oportunista 180 <ul><li>El refactoring mejora el diseño del producto pero no agrega nueva funcionalidad * –mejora la adaptabilidad. </li></ul><ul><li>Agregar nueva funcionalidad usualmente pide rediseño </li></ul><ul><li>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. </li></ul><ul><li>Axioma antiguo: Hágalo bien desde la primera vez para mantener el costo del cambio bajo </li></ul><ul><li>El nuevo axioma: no importa cuan bueno sea la primera vez, siempre cambiará, por lo tanto mantenga bajo el costo del cambio. </li></ul>Disciplina de refactoring en el desarrollo
    112. 112. Refactoring oportunista 181 <ul><li>Hay cada vez más disposición de los gerentes de producto a invertir en refactoring una vez que entienden la situación </li></ul><ul><li>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. </li></ul><ul><li>Dos factores son los más importantes </li></ul><ul><ul><li>Pruebas : hay que integrarlas en el proceso de desarrollo y automatizarlas todo lo que se pueda. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
    113. 113. Persistencia 181 <ul><li>Significa pensar en rediseño durante cada iteración y asignar algún tiempo a implementar los rediseños. </li></ul><ul><li>Significa planear algún nivel de refactoring para cada nuevo release de producto </li></ul><ul><li>Significa ir construyendo de modo lento pero seguro pruebas automáticas e ir integrando las pruebas dentro del proceso de desarrollo </li></ul>
    114. 114. CREANDO EQUIPOS ADAPTIVOS GRANDES
    115. 115. Componentes 238 <ul><li>Estructura organizacional basada en hubs </li></ul><ul><li>Extensiones de auto-organiza ción </li></ul><ul><li>Auto-disciplina de equipo </li></ul><ul><li>Pr ácticas adicionales </li></ul><ul><li>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) </li></ul><ul><li>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. </li></ul><ul><li>En el caso de los teams grandes que consisten de sub-teams, los agentes son los sub-teams. </li></ul>
    116. 116. puede ser virtual Miembros fijos y part-time Project Management Team Project Manager Team del cliente Product Manager Team de Arquitectura Team Lead Teams de Features A-N Team Lead Team de integración y construcción Team Lead
    117. 117. Extensiones de auto-organización 241 <ul><li>Conseguir los líderes adecuados </li></ul><ul><li>Articular la descomposición del trabajo y las estrategias de integración </li></ul><ul><li>Estimular la interacción y el flujo de información entre teams </li></ul><ul><li>Enmarcar la toma de decisiones a nivel de proyecto </li></ul><ul><li>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 </li></ul><ul><li>En proyectos grandes, los subteams pueden también hacer el ejercicio de ‘envision’ para su porción del producto. </li></ul>
    118. 118. <ul><li>Además de conocer sus responsabilidades, cada sub-team necesita saber su rol respecto de los otros sub teams </li></ul><ul><ul><li>por ejemplo, un sub-team de features necesita saber cómo interactará con el sub-team de arquitectura </li></ul></ul><ul><li>Los proyectos grandes son casi siempre de algún modo proyectos distribuidos </li></ul><ul><li>Hay que enfrentar aspectos de distancia, cultura y experticia </li></ul><ul><li>Definir los roles y responsabilidades de los subteams es un paso inicial para tratar con los aspectos de distribución </li></ul>

    ×