ACIS Procesos Individuales y de Equipo Por Bernardo Díaz Arias berdiaz@yahoo.com

Procesos Individuales y de Equipo Introducción Personal Software Process Team Software Process

1. Introducción PSP/TSP: Como moverse de la teoría a la práctica (What To How)? El mejoramiento requiere cambio y provomer de forma consistente en actores humanos no es un problema trivial. La metodología se implementa desde dos dimensiones: Parte de la coordinación de un proyecto hacia los miembros Parte de cada miembro hacia el proyecto

1. Introducción En las universidades no se enseña normalmente a como ser productivo Cada persona trabaja según sus convicciones y experiencia en un instante Normalmente cada individuo no acepta ser cuestionado ni se autocuestiona

1. Introducción Huevo vs. Gallina: “Los individuos solo creen en una metodología hasta que no la usan y ven los resultados pero no se deciden a usarla hasta que no creen en ella…” Un equipo es tan productivo como sus miembros… Es responsabilidad del PM motivar, guiar y facilitar el trabajo de los miembros del equipo Cada miembro del equipo debe “empoderarse” de los resultados del mismo mediante proactividad

1. Introducción PSP/TSP => Rapidez + Calidad PSP/TSP => Control cuantitativo PSP/TSP => Cada tipo de actividad debe tener una revisión PSP/TSP => El tiempo de diseño debe ser al menos igual al de desarrollo PSP/TSP => El producto debe entregarse con un 70% de defectos corregidos PSP/TSP => Son la alternativa más ágil para iniciar las buenas prácticas hacia CMMI No dependen/afectan el uso de otras metodologías o herramientas.

2. PSP Le enseña a cada individuo a: Controlar (estadísticamente) la calidad de sus proyectos (todo es un proyecto!!!) Hacer compromisos realistas (medibles!!!) y que va a cumplir Mejorar sus habilidades de estimación y planeación Reducir los defectos en sus productos Usar las conclusiones de cada proyecto en el siguiente

2. PSP Se concentra en minimizar tiempo y maximizar calidad => ($) [Deming y Juran (80s)] “La mejor manera de incrementar la productividad y calidad de cualquier industria era garantizar el entrenamiento y productividad de las personas” PSP se considera un subproducto de CMM [Humphrey *** y Paulk(80s)] Tiene 2 enfoques de implementación: Reactiva y Proactiva. Cada individuo debe medir y controlar su propia productividad

2. PSP - Principios Para garantizar mejoramiento continuo los individuos deben especializarse en trabajar basados en procesos bien definidos y mesurables Para producir productos de calidad los individuos deben sentirse responsables de ella “Siempre será más eficiente prevenir defectos que encontrarlos y solucionarlos..” “La manera correcta siempre es la más rápida y barata de hacer las cosas…” Es realista, reconoce actividades de tipo directas e indirectas. La productividad debe administrarse individualmente

2. PSP - Estructura

2. PSP - Estructura

2. PSP – Métricas Esfuerzo: Total Horas Invertidas Progreso: Variación entre tiempo estimado vs. esfuerzo Calidad: defectos/KLOC Productividad: KLOC/hora Estabilidad: Cantidad de modificaciones al producto

2. PSP – Indicadores Objetivo Final [Yield]: En pruebas de aceptación lograr 0.3 defectos/KLOC “Haber corregido el 70% de los defectos antes de la entrega al cliente…” Madurez promedio: Después de 4 proyectos. “Se realizan estimados confiables a partír de info histórica de 3 últimos proyectos…”

2. PSP – Métricas Yield [70%] = 65 defectos (100% = 92 aprox.) “Se logra la madurez si en las pruebas de aceptación se encuentran Max 27 defectos.”

2. PSP – Ejemplos de Plantillas Reporte de Actividades (diario) Plan Detallado (Cronograma) Diseño Detallado (Inventario de clases a desarrollar, Modelos UML clases, secuencias) Reporte de Pruebas Individuales (antes de entregarlo al PM) Resumen de Resultados (métricas y análisis de toda la iteración)

2. PSP Por que fallan los proyectos? Compromisos no realistas Entre más grande el proyecto más control se requiere: Pocos desarrolladores trabajan sobre un plan Sin un plan detallado no se conoce el progreso Si el desarrollador no conoce su avance, la gerencia del proyecto no puede garantizar los compromisos ni controlar el proyecto!!!

2. PSP Por que fallan los proyectos? La calidad del software es más compleja para proyectos más grandes o técnicamente complejos: Si las partes tienen problemas, el sistema tiene problemas Si cada desarrollador no administra la calidad de sus productos, el equipo no administra la calidad Si la calidad no es explícitamente administrada, siempre será pobre Los grupos deben volverse equipos: Reglas establecidas desde el primer día Liderazgo -> Motivación y compromiso a través del ejemplo Coaching -> Unión

2. PSP Peopleware? Teoría X Y Etapas de todo equipo: Forming, Storming, Norming, Performing Metodologías de solución de conflictos: Scoring Model Norming “Face it!!!”

2. PSP

2. PSP PSP0: You establish a measured performance baseline. PSP1: You make size, resource, and schedule plans. PSP2: You practice defect and yield management.

2. PSP

3. Team Software Process Indica como establecer equipos de trabajo autónomos y productivos Cada miembro debe tener habilidad en PSP Define roles y actividades para cada miembro del equipo Recomendado para equipos desde 3 – 20 ingenieros Enseña a los PM como acompañar y motivar a sus equipos para lograr máxima productividad y cohesión. La unidad de control es la semana (EVA)

3. Team Software Process A diferencia de PSP es enfático en que el proyecto se cumpla con los costos establecidos. Introduce el concepto de revisiones entre compañeros y revisiones formales al finalizar una etapa (iteración, fase) Dada su complejidad los proyectos actuales son desarrollados por equipos, entre más miembros mayor falta de control. Se deben integrar múltiples roles con visiones diferentes. Se promueve la conciencia de la gerencia y administración a todos los niveles del equipo.

3. Team Software Process Estructura: Incepción Elaboración Construcción Transición

3. Team Software Process Cada fase debe visualizarse entre 2 – 4 meses Cada Launch está predefinido a 4-5 días (incepción) Cada Relaunch está predefinido a 2-3 días El equipo del proyecto es el directamente responsable de la planeación del proyecto (launch) y la fase (relaunch) La gerencia del proyecto revisa cada plan En cada Launch/relaunch se deben producir planes alternos

3. Team Software Process Características de los Equipos Efectivos: El objetivo del equipo es claro, visible y realista Los recursos son adecuados para el trabajo Compromiso y motivación de los individuos Disciplina de los individuos (PSP) Los miembros del equipo se apoyan mutuamente

3. Team Software Process Construcción del Equipo:

3. Team Software Process Roles TSP: Team Leader Planning Manager Customer Interface Manager (GUI, Requirements) Implementation Manager Test Manager Quality Manager Process Manager (Experto en metodologías) Support Manager (Admin Config.) Otros Roles…

3. Team Software Process Workflow del Proceso:

3. Team Software Process Launching:

3. Team Software Process Launching:

3. Team Software Process Launching: Objetivo: “Planes Individuales”

3. Team Software Process Teamworking: “Manteniendo la productividad adquirida” Liderazgo Activo: Asegurarse que cada individuo pueda cumplir los compromisos Comunicación constante de parte de la gerencia Compromiso y motivación de los individuos. Reporte oportuno de incidentes. Disciplina de los individuos (PSP) Los miembros del equipo se apoyan mutuamente Actualizar y balancear las cargas de trabajo Competitividad: Calidad vs. Cantidad

3. Team Software Process TSP Quality Management: Defect Injection Rates Estimates / phase (Historical) Defect Removal Rates Estimates / phase (Historical) Phase Yield: %defects / phase (entry – closeup)

3. Team Software Process TSP Inspections: PSP (Personal Reviews: Manual + Automated) Peer Reviews (Cross Checks) Formal Inspections (por iteración – Experto/ disciplina)

3. Team Software Process TSP Inspections: “Los 7 pecados capitales...” Los participantes no entienden el objetivo de la revisión Los revisores critican el recurso no el producto Las revisiones no se planean Mezclar reuniones de revisión con reuniones de solución Los revisores no están contextualizados Participación de roles no requeridos (manager) El revisor se concentra en la forma no en el contenido

Finalmente… Muchas gracias por su tiempo !!!