Principios: Planificación de Proyectos de Software Oscar Centeno oscar.centeno@gmail.com Octubre 2014

Lección de Hoy Un Buen Proceso Un Buen Plan Un Plan Agile

El cono de la incertidumbre • ¿Cuándo van a terminar? El proyecto se espera que tarde 20 meses. 1981, Barry Boehm

¿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

Un buen proceso de planificación • Reduce el riesgo • Reduce la incertidumbre • Permite tomar buenas decisiones • Crea confianza • Comparte expectativas

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?

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?

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?

Crea confianza • La clave son las Entregas constantes

Comparte expectativas Plan tradicional Fecha Plan Agile Fecha Expectativas Suposiciones Alternativas Metas

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.

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.

Lección de Hoy Un Buen Proceso Un Buen Plan Un Plan Agile

#1 Responda a estos mitos • Mito: Los equipos Ágiles no planifican.

#2 Responda a estos mitos • Mito: Los equipos Ágiles no se comprometen a fechas o “features”.

¿Por qué fracasa la planificación?

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)

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

Ejemplo de cronograma por actividades

¿Permite analizar y tomar decisiones?

2. Asignaciones Multitarea • > Tareas simultáneas < Productividad

¡Es como asignar 100% a una autopista!

3. No se desarrolla Features por Prioridad Completar actividades al 100% no es suficiente. El orden es importante.

Ejemplo de cronograma no por prioridades ¿Qué eliminamos al final si hay que recortar algo?

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”

Solución a la incertidumbre Iterar Construya Muestre Agregue tareas que faltaron Corrija estimaciones

En enfoque Agile Un solo equipo Iteraciones cortas Entregar algo cada iteración Enfoque en prioridades del negocio Inspeccionar y adaptar

Ejemplo de Cronograma

Bibliografía Agile Planning and Estimating, Mike Cohn, 2005.

Principios: Planificación de Proyectos de Software Oscar Centeno oscar.centeno@gmail.com