ACIS

1. ACIS Process Productivity Por Bernardo Díaz Arias berdiaz@yahoo.com

2. PROCESS PRODUCTIVITY • Introducción • Personal Software Process • Team Software Process • Técnicas de Estimación

3. 1. Introducción Problema: “Un aspecto que origina fracaso en proyectos de software es la falta de habilidades de planeación, organización y productividad de los desarrolladores así como la habilidad de la gerencia para generarlos” “La productividad y cumplimiento de un equipo depende de la productividad de las partes” Solución Propuesta: “Frente a este problema surgío PSP como una propuesta para mejorar la productividad y planeación de los ingenieros. TSP es un set de buenas prácticas especializadas en promover la productividad y empoderamiento de un equipo para lograr los objetivos del proyecto”

4. Fortalezas: Efectivos para administrar el performance de cada individuo y su equipo. Orientación netamente práctica 1. Introducción Debilidades: • No se enfoca en disciplinas técnicas importantes dentro de todo proceso de desarrollo como análisis del negocio, ingeniería de requerimientos, administración del ambiente, configuración, etc. • Las plantillas de referencia son redundantes y en general poco ágiles.

5. Oportunidades: La generación de estadísticas y métricas individuales (PSP) sirven para estimar directamente las del proyecto (TSP) y posteriormente las de la compañía (CMM). Se complementa muy bien con un set de procesos como RUP. 1. Introducción Amenazas: • La versión más reciente de PSP (Agosto del 2005) trata los mismos conceptos de la original pero es más formal y rigurosa por lo que se puede desvirtuar la practicidad y sencillez del enfoque inicial. • TSP NO es un framework de gerencia de proyectos sino de administración y liderazgo de equipos, por lo mismo no remplaza a PMI, lo complementa.

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

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

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

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

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

11. 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 es responsable de medir y controlar su propia productividad

12. 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..”

13. 2. PSP - Principios • “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

14. 2. PSP - Estructura

15. 2. PSP - Estructura

16. 2. PSP Unidades de Producción: Usadas según la fase del proyecto y tipo de software: Functional • GUI-forms • Function Points • Use Cases/Use Case Points Technical • Components • Classes/Methods • LOCs

17. 2. PSP Lines Of Code (LOC): Normalized Production Units • One line of code is one logical statement. Declarations are counted as lines of code. • Only Source lines that are delivered as part of the product are included – test drivers and other support software is excluded. • Source lines are created by the project staff – code generated by applications generators is excluded. • Comments are not counted as lines of code. • Productivity by language / Software Platform Must Be Considered.

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

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

20. 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…”

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

22. 2. PSP • Formal Model (2005)

23. 2. PSP • PSP0: Establish a measured performance baseline. • PSP1: Make size, resource, and schedule plans. • PSP2: Control product quality through defect and yield management. • PSP3: Continuous Improvment

24. 2. PSP

25. 3. Team Software Process 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 como se donde estoy?, que me falta? • Si el desarrollador no conoce su avance, la gerencia del proyecto no puede garantizar los compromisos ni controlar el proyecto!!! • Cuál es el pecado capital en un equipo de desarrollo?

26. 3. Team Software Process 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

27. 3. Team Software Process • 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!!!”

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

29. 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 necesidad 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.

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

31. 3. Team Software Process RUP vs. TSP: • Plan de Fase = Launch / Relaunch • Previous Planning of the next phase or planning at the beginning?

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

33. 3. Team Software Process Construcción del Equipo:

34. 3. Team Software Process Equipos Efectivos, Team-Building: • El objetivo del equipo es claro, visible y realista • Los recursos son adecuados para el trabajo (experiencia+conocimiento) • Cada actividad del proyecto tienen un único responsable. • Cada individuo debe tener claros y aceptar sus objetivos, roles y responsabilidades • Para comprometerse a cualquier actividad el individuo debe dimensionar el tamaño y evaluar el impacto de la tarea. • Cada individuo es responsable de comunicar oportunamente los inconvenientes que se le presenten. • El éxito del proyecto es responsabilidad de todo el equipo • Compromiso y motivación de los individuos • Disciplina de los individuos (PSP) • Los miembros del equipo se apoyan mutuamente (performing?)

35. 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…

36. 3. Team Software Process Workflow del Proceso:

37. 3. Team Software Process Launching:

38. 3. Team Software Process Launching:

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

40. 3. Team Software Process Team-Working: “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. • Gestionar la disciplina de los individuos (PSP) • Actualizar y balancear las cargas de trabajo • Promover la Competitividad: Calidad vs. Cantidad

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

42. 3. Team Software Process TSP Inspections: • PSP (Personal Reviews: Automated + Manual) • Peer Reviews (Cross Checks) • Formal Inspections (per iteración – By an Expert/ discipline)

43. 3. Team Software Process TSP Inspections: “Los 4 pecados capitales...” • El revisor debe poder realizar el objeto de revisión al menos con las mismas características. • Las revisiones no se planean. Los participantes no entienden el objetivo de la revisión. Los revisores no están contextualizados. • No enfocar las revisiones. Los revisores critican el recurso no el producto. Mezclar reuniones de revisión con reuniones de solución. El revisor se concentra en la forma no en el contenido • Participación de roles no requeridos (manager)

44. 4. Técnicas de Estimación • Para lograr metas realistas un individuo debe tener un estimado del esfuerzo, tamaño e impacto de la tarea que va a realizar. • El incumplimiento deteriora las relaciones entre los miembros del equipo y mina la motivación.

45. 4. Técnicas de Estimación • Puntos de Casos de Uso (UCP) • Análisis de Puntos de Función (FPA) • Registro Histórico de Tiempos Planeados vs. Tiempos Reales

46. 4. Técnicas de Estimación • Puntos de Casos de Uso (UCP)

47. 4. Técnicas de Estimación • Análisis de Puntos de Función (FPA)

48. 4. Técnicas de Estimación • Registro Histórico de Tiempos Planeados vs. Tiempos Reales

49. Finalmente… Muchas gracias por su tiempo !!!