ACIS
Process Productivity
Por Bernardo Díaz Arias
[email protected]
PROCESS PRODUCTIVITY
1. Introducción
2. Personal Software Process
3. Team Software Process
4. Técnicas de Estimación
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”
1. Introducción
Fortalezas:
 Efectivos para
administrar el
performance de
cada individuo y su
equipo.
 Orientación
netamente práctica
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.
1. Introducción
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.
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.
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:
1. Controlar (estadísticamente) la calidad de sus
proyectos (todo es un proyecto!!!)
2. Hacer compromisos realistas (medibles!!!) y que va
a cumplir
3. Mejorar sus habilidades de estimación y planeación
4. Reducir los defectos en sus productos
5. 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 es responsable de 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..”
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
2. PSP - Estructura
2. PSP - Estructura
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
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.
2. PSP – Métricas
1. Esfuerzo: Total Horas Invertidas
2. Progreso: Variación entre tiempo estimado vs. esfuerzo
3. Productividad: KLOC/hora
4. Calidad: defectos/KLOC
5. Estabilidad: Cantidad de modificaciones al producto
2. PSP – Ejemplos de Plantillas
1. Reporte de Actividades (diario)
2. Plan Detallado (Cronograma)
3. Diseño Detallado (Inventario de clases a desarrollar,
Modelos UML clases, secuencias)
4. Reporte de Pruebas Individuales (antes de entregarlo al
PM)
5. Resumen de Resultados (métricas y análisis de toda la
iteración)
2. PSP – Indicadores
1. 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…”
2. 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 = 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.”
2. PSP
 Formal Model
(2005)
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
2. PSP
3. Team Software Process
Por que fallan los proyectos?
1. Compromisos no realistas
2. 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?
3. Team Software Process
Por que fallan los proyectos?
3. 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
4. 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
3. Team Software Process
1. Peopleware?
2. Teoría X Y
3. Etapas de todo equipo: Forming, Storming, Norming,
Performing
4. Metodologías de solución de conflictos:
 Scoring Model
 Norming
 “Face it!!!”
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
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.
3. Team Software Process
Estructura:
 Incepción
 Elaboración
 Construcción
 Transición
3. Team Software Process
RUP vs. TSP:
 Plan de Fase = Launch / Relaunch
 Previous Planning of the next phase or
planning at the beginning?
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
Construcción del
Equipo:
3. Team Software Process
Equipos Efectivos, Team-Building:
1.
El objetivo del equipo es claro, visible y realista
2.
Los recursos son adecuados para el trabajo (experiencia+conocimiento)
3.
Cada actividad del proyecto tienen un único responsable.
4.
Cada individuo debe tener claros y aceptar sus objetivos, roles y responsabilidades
5.
Para comprometerse a cualquier actividad el individuo debe dimensionar el tamaño y
evaluar el impacto de la tarea.
6.
Cada individuo es responsable de comunicar oportunamente los inconvenientes que se
le presenten.
7.
El éxito del proyecto es responsabilidad de todo el equipo
8.
Compromiso y motivación de los individuos
9.
Disciplina de los individuos (PSP)
10.
Los miembros del equipo se apoyan mutuamente (performing?)
3. Team Software Process
Roles TSP:
1. Team Leader
2. Planning Manager
3. Customer Interface Manager (GUI, Requirements)
4. Implementation Manager
5. Test Manager
6. Quality Manager
7. Process Manager (Experto en metodologías)
8. Support Manager (Admin Config.)
9. 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
Team-Working: “Manteniendo la productividad adquirida”
1. Liderazgo Activo: Asegurarse que cada individuo pueda
cumplir los compromisos
2. Comunicación constante de parte de la gerencia
3. Compromiso y motivación de los individuos. Reporte
oportuno de incidentes.
4. Gestionar la disciplina de los individuos (PSP)
5. Actualizar y balancear las cargas de trabajo
6. Promover la Competitividad: Calidad vs. Cantidad
3. Team Software Process
TSP Quality Management:
1. Defect Injection / phase (Historical)
2. Defect Removal / phase (Historical)
3. Phase Yield: %defects / phase (entry – closeup)
3. Team Software Process
TSP Inspections:
1. PSP (Personal Reviews: Automated + Manual)
2. Peer Reviews (Cross Checks)
3. Formal Inspections (per iteración – By an Expert/
discipline)
3. Team Software Process
TSP Inspections: “Los 4 pecados capitales...”
1. El revisor debe poder realizar el objeto de revisión al menos
con las mismas características.
2. Las revisiones no se planean. Los participantes no entienden
el objetivo de la revisión. Los revisores no están
contextualizados.
3. 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
4. Participación de roles no requeridos (manager)
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.
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
4. Técnicas de Estimación
 Puntos de Casos de Uso (UCP)
4. Técnicas de Estimación
 Análisis de Puntos de Función (FPA)
4. Técnicas de Estimación
 Registro Histórico de Tiempos Planeados vs.
Tiempos Reales
Finalmente…
Muchas gracias por su tiempo !!!
Descargar

Sdsadsad sadsadasdasd