Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Principios: Planificación de Proyectos

Principios: Planificación de Proyectos

Se expone consideraciones para conformar un buen proceso de planificación, como presentar un buen plan y la características de un plan "agile".

Oscar Centeno

October 23, 2014
Tweet

More Decks by Oscar Centeno

Other Decks in Technology

Transcript

  1. El cono de la incertidumbre • ¿Cuándo van a terminar?

    El proyecto se espera que tarde 20 meses. 1981, Barry Boehm
  2. ¿Qué es planificar? • La búsqueda de la solución óptima

    a una pregunta: ¿Qué debemos construir? Construyamos X, Y y Z para liberar en Agosto Enero Junio Agosto Construyamos sólo X y Z para liberar en Julio Construyamos sólo X , Z y B para liberar en Setiembre
  3. Un buen proceso de planificación • Reduce el riesgo •

    Reduce la incertidumbre • Permite tomar buenas decisiones • Crea confianza • Comparte expectativas
  4. Reduce riesgos • Un buen proceso de planificación: – Expone

    el riesgo “integrarse con un sistema legado mainframe desconocido” – ¿Lo atacamos al estudiar acerca del mainframe? – ¿Estimamos el riesgo como incertidumbre?
  5. Reduce incertidumbre • El mayor riesgo: Construir el producto equivocado.

    Plan Inicial Nuevas Ideas ¿Aceptamos nuevas ideas y cambiamos el plan? ¿Rechazamos nuevas ideas para mantener el plan?
  6. Tomar de decisiones • El plan estima y brinda opciones

    para decidir: – ¿Liberamos en agosto o esperamos a setiembre? – ¿Podemos acelerar el proceso comprando X herramienta?
  7. Un Buen Plan • Es confiable para la toma de

    decisiones. Fecha estimada: Plan detallado para 2 primeros meses: Suposiciones principales: Plan para comunicar avance De 7 a 9 meses. Características más prioritarias o riesgosas. Entregables cada 2 semanas. Demostraciones de producto terminado. Una sola voz del negocio Un equipo capacitado en X y Y dominio. Las interfaces con el mainframe son XML. Comunicados cada 2 semanas. Monitoreo de avance de metas principales Proyecciones con base en entregas bisemanales. El plan se irá detallando en cada avance.
  8. Un Plan Agile • Es fácil de cambiar…. Eliminar Feature

    Reducir Features Cambiar personal Buscar alternativas a una solución Cambiar la fecha proyectada. … durante todo el proyecto. Cambiar tecnología.
  9. #2 Responda a estos mitos • Mito: Los equipos Ágiles

    no se comprometen a fechas o “features”.
  10. Estadísticas • 66% de proyectos sobrepasan su presupuesto significativamente (Lederer

    and Prasad 1992). • 64% de features en productos son raramente o nunca usadas (Johnson 2002) • El proyecto promedio sobrepasa su presupuesto en un 100% (Standish 2001)
  11. 1. Planificación por actividades • Se enfocan en completar actividades

    y no en la entrega de features. • No hay valor para el cliente en terminar actividades. • Si hay que reducir tiempo, se recorta actividades (calidad).
  12. 3. No se desarrolla Features por Prioridad Completar actividades al

    100% no es suficiente. El orden es importante.
  13. 4. Se ignora la incertidumbre “El análisis inicial de requerimientos

    culmina en una especificación perfecta.” “Los usuarios no cambiarán de opinión.” “No tendrán nuevas necesidades.” “No habrá problemas en la tecnología.” “Podemos asignar estimaciones precisas a un trabajo impreciso”
  14. En enfoque Agile Un solo equipo Iteraciones cortas Entregar algo

    cada iteración Enfoque en prioridades del negocio Inspeccionar y adaptar