Embed Size (px)
Citation preview
Administración de Proyectos de Software
Objetivo
Planear un proyecto de software considerando la administración de actividades y compromisos necesarios para su cumplimiento aplicando las técnicas apropiadas para darle seguimiento, así como las estrategias de comunicación que permitan a la totalidad de los integrantes del equipo de trabajo acordar los compromisos relacionados con el proyecto.
Antes de entrar en materia ...
Habilidades necesarias en un PM (Project Management)
Liderazgo Comunicación Solución de Problemas Negociación Influencia en la organización Mentoring Experiencia
Técnica Procesos
1.0 Introducción
PoliticasMétodosTécnicos
ProcesosDe Negocio
Ambiente de PMPM
1.1 Atributos de un proyecto
PMI “A project is a temporary endeavor undertaken to
create a unique product or service” Elaborado en forma progresiva
Con elementos repetitivos Tienen un PM
Conductor, Coach, Capitán ? Interacciones:
Sponsor, Ejecutivos, Equipo de trabajo, Clientes, Contratistas, Gerentes.
1.2 Ciclo de vida de un proyecto
1.2 Ciclo de vida de un proyecto
1.2 Ciclo de vida de un proyecto
1.3 Proceso de planeación El control del proyecto solo puede ser alcanzado cuando el
costo, calendario y los objetivos técnicos están claramente documentados, son realistas y están manejados en forma responsable y deliberada.
1.3 Proceso de planeación ...como un proceso cerrado
Crit
erio
s de
Sal
ida
Crit
erio
s de
Ent
rada
1.3 Proceso de planeación El proceso de planeación debe
resultar de la conjunción de las partes: sentido claro del costo, calendario y objetivos técnicos.
El establecimiento de estas partes deben de ser: Objetivos técnicos derivados
de un claro entendimiento de los requisitos del negocio.
Los costos deben de ser realistas y de acuerdo al presupuesto
El calendario debe de ser alcanzable y de acuerdo a las necesidades del negocio.
1.4 Identificación de las necesidades de un
proyecto: Estructura de una solicitud de propuesta
1 Resumen Ejecutivo 1.1 Nuestro Entendimiento de Sus Metas1.2 Nuestro Enfoque para Atender sus Metas1.3 Visión General de la Solución1.4 Cómo Entregaremos1.5 ¿Por qué nosotros?
2 Recomendación de Solución2.1 Capacidades de la Solución2.2 Ventajas de la Arquitectura de la Solución2.3 Recursos y Beneficios2.4 Cómo Nuestra Experiencia Puede Ayudarlo
1.5 Soluciones propuestas: Estructura de la propuesta de solución
3 Administración de Proyecto3.1 Plan de Implementación por Fase3.2 Metas de Rendimiento y Responsabilidad3.3 Plan de Trabajo del Proyecto y Cronograma Estimado3.4 Estructura Organizacional3.5 Equipo del Proyecto
4 Precio4.1 Visión General4.2 Entregables y Precio Estimado
5 Referencias Adicionales5.1 Estudio de Caso5.2 Miembros del Equipo y Roles5.3 Marca Registrada y Términos de Contrato
1.6 Consideración de la planeación y control en:CMM, ISO, MoProsoft
Capability Maturity Model Carnegie Mellon Software Engineering Institute
Modelo de Procesos para la Industria del Software
International Standard Office
Un poco de experiencia personal ! . . .
Actividades de un PM Definir el alcance del proyecto Identificar stakeholders, decision-makers, y proceso
de escalamiento Desarrollar la lista de actividades (work breakdown
structures) Estimación de tiempos Diagrama de flujo del manejo del proyecto Identificacion de recursos y presupuesto
Un poco de experiencia personal ! . . .
Mas actividades ! Evaluar requerimientos del proyecto Identificar y evaluar riesgos. Preparar el plan de contingencia Identificar interdependencias Identificar y dar seguimiento a compromisos/fechas
criticas Participar en las revisiones Asegurar los recursos necesarios Control de cambios Estatus del proyecto
Un poco de experiencia personal ! . . .
Errores que tenemos que evitar!!!
Relacionados a las personas Baja Motivación Personal técnicamente débil
Débil vs. Junior Problemas de los empleados sin control Heroes Agregar personal tarde al proyecto Oficinas ruidosas, congestionadas Fricciones cliente-desarrollador Expectativas no reales Política Ilusiones/deseos
Relacionados al proceso
Calendarios optimistas Manejo de riesgos insuficiente Fallas en el proveedor Planeación insuficiente Abandono del plan en caso de crisis Diseño inadecuado Controles gerenciales insuficientes Omisión de tareas necesarias en estimados Planear actividades de recuperacion Programación Code-like-hell
Relacionadas a la tecnología
Síndrome de “La Bala de Plata” Sobre-estimación de ahorros basados en
nuevas herramientas y métodos Cambios de herramientas a la mitad del
proyecto Falta de un control automático de código
fuente
1.3 Proceso de planeación El proceso de planeación debe
resultar de la conjunción de las partes: sentido claro del costo, calendario y objetivos técnicos.
El establecimiento de estas partes deben de ser: Objetivos técnicos derivados
de un claro entendimiento de los requisitos del negocio.
Los costos deben de ser realistas y de acuerdo al presupuesto
El calendario debe de ser alcanzable y de acuerdo a las necesidades del negocio.
2.0 Planeación del Proyecto de Software
...antes de iniciar PMI
Scope Planning Scope Definition Activity Definition Activity Sequencing Activity Duration
Estimating Resource Planning Cost Estimating Cost Budgeting Risk Planning Schedule
Development
PMI Quality Planning Communications
Planning Organization Planning Staff Acquisition Procurement Planning Project Plan
Development
2.1 Definición del Objetivo del proyecto Lo primero que tenemos que hacer !
Identificar alcance y objetivos Identificar el ambiente organizacional Analizar las características del proyecto Identificar los productos y las actividades Estimar el esfuerzo de cada actividad Identificar los riesgos Asegurar los recursos Revisar y comunicar el plan
En pocas palabras ! ... Entender que es lo que queremos hacer y ponerlo en blanco y negro.
Aquí comienza el SOW ( Statement of work )
2.2 Elección de un modelo de proceso de Software
Lineal Secuencial Prototipos Evolutivo
2.2 Elección de un modelo de proceso de Software
Conclusiones Podemos crear modelos que se ajusten a nuestras
necesidades Es critico el que evaluemos los modelos para seleccionar
el que mejor nos convenga. Debo de hacer un análisis previo del cliente, del recurso
humano y del objetivo del sistema para poder hacer una mejor elección del modelo
Nos damos cuenta de que los modelos no son excluyentes Respetar y seguir el modelo elegido No etiquetar modelos
2.3 Estructura de la división del trabajo ( WBS )
2.3 Ejemplo de un WBS 0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production
2.3 ¿Que es un WBS?
Es una lista de actividades, no de cosas La lista de las cosas viene de diferentes
fuentes. Describe las actividades No poner mas detalles del que pueda ser
manejado
2.3 Técnicas para hacer un WBS
Top-Down Bottom-Up Analógia Post-It en la pared
2.3 Técnicas para hacer un WBS
Top-Down Comienza a un nivel alto En forma sistemática se desarrolla mas detalle Es bueno si:
El problema es bien entendido Tecnología y Metodología no son nuevos Similar a un proyecto anterior.
Aplicado en muchas situaciones.
2.3 Técnicas para hacer un WBS
Botton - up Comienza desde abajo Se van agregando conforme se incrementa el
nivel Tiene en contra que consume tiempo Necesita tener los requerimientos completos. La ventaja es que es muy detallado
2.3 Técnicas para hacer un WBS
Analogía Se basa en un proyecto similar Se usa un template La estimación puede ser basada en la analogía
también Tiene la ventaja de basarse en la experiencia Pero necesita un proyecto comparable.
2.3 WBS
El WBS es la base de: Calendarización Costos Analísis de riesgos Estructura Organizacional Control Métricas
2.4 Estimación de tamaño de productos de trabajo
Primero hablemos de un par de verdades ! ...
Arte y Ciencia en la estimación del Software
Ciencia son herramientas bien desarrolladas y bien soportadas.
El arte de la estimación se basa aun en “rule of thumb” y todavia necesita mas trabajo
2.4 Estimación de tamaño de productos de trabajo Después hablemos de los pecados ! ...
El primero y mas importante ... NO APRENDER !!! Estimar cuanto nos vamos a tardar antes de saber que es lo que tenemos que
hacer. Asumir que las mejores estimaciones vienen de las personas con mas
influencia en la organización Comparar la estimación de un proyecto haciendo referencia a uno similar
(anterior)... Que fue mal !!!! Asumir que otros departamentos estiman mejor que los que harán realmente
el trabajo. No estimar educación y entrenamiento, o vacaciones, o gente que se puede ir
a otro proyecto, o se enferma, o ..., o .... Presentar un estimado muy exacto ( 67.4 días ) con un error muy alto de
exactitud ( +/- 2 meses ) El razonamiento de que entre mas rápido nos demos cuenta de que vamos
mal, mas tiempo tendremos de reponernos Asumir que los programadores dan el estimado por verse bien o por no hacer
rápido el trabajo
2.4 Estimación de tamaño de productos de trabajo
Después hablemos de los pecados MORTALES ! ... Asumir que las metas y los estimados, es lo mismo Decir SI cuando queremos decir NO
Programadores son jovenes
Comprometer los estimados demasiado temprano Asumir que una mala estimación no tiene impactos en los
resultados del proyecto Estimar lo imposible Sobre-estimar ahorros Usar una sola técnica de estimación No usar una herramienta No incluir los impactos del análisis de riesgos en el estimado
2.4 Estimación de tamaño de productos de trabajo ¿ Como se estima ?
Es necesario usar un método/modelo Tal vez el mas usado es “Function Points” COCOMO
Basarse en datos históricos o si no hay, en preguntar a expertos Hacer un análisis sensitivo
Mejor Caso Caso más probable Peor Caso
Incluir análisis de riesgos Bajo Riesgo Riesgo mediano Alto Riesgo
Normalizar la información (que de todo, saquemos una sola cosa, para que todos entendamos lo mismo)
Curva de aprendizaje (Considerar la curva de aprendizaje)
2.4 Estimación de tamaño de productos de trabajo
¿ Como se estima ? Establecimiento de métricas
Falta de compromiso gerencial Demasiadas métricas, demasiado rápido Pocas métricas, muy tarde (ver doc Clase 3) Medir algo incorrecto Indefinición en las métricas No debemos usar los datos para evaluar personas No usar las métricas para motivar personas sino para entender el
proceso. Recolectar información que no es usada (usen la info y
retroalimente, porque si no se corre el riesgo de que las personas dejen de capturar metricas)
Falta de comunicación y entrenamiento (Ya empezamos a medir, ¿alguien sabe, que estamos midiendo?
Mala interpretación de las métricas
2.4 Estimación de tamaño de productos de trabajo
2.4 Estimación de tamaño de productos de trabajo
2.5 Estimación de esfuerzo del proyecto.
2.5 Estimación de esfuerzo del proyecto.
2.5 Estimación de esfuerzo del proyecto.
El cono de la incertidumbre
2.5 Estimación de esfuerzo del proyecto.
Seguimiento a “El cono de la incertidumbre”
2.5 Estimación de esfuerzo del proyecto.
Vamos viendo los puntos importantes para poder estimar el esfuerzo de un proyecto
Calendario Tareas a realizar Análisis de riesgos Recursos Administración Operaciones Calidad Espacio/Equipo/Instalaciones Relaciones Publicas
2.5 Estimación de esfuerzo del proyecto.
Calendario Desarrolladores tienden a ser introve(Lamentablemente el
desarrollador no tiene habilidades de negociante)rtidos (los obligamos a decirnos los numeros que deseamos y no los que ellos realmente piensan)
El calendario típicamente se negocia entre el gerente y ventas Desarrolladores carecen de habilidades de negociación Algunos tips para negociar el calendario
Separar la persona del problema (Debemos buscar a la persona que entre en el perfil)
Enfocarse en el interés no en la posición (Debemos ver que es lo que mas nos conviene como compañia en vez de convenencias individuales)
Buscar una solución de ganar-ganar Establecer un criterio objetivo (Que? como? escritos y
firmados, por cumplimiento de actividades y no por satisfacción del cliente)
Juntas de Kickoff (Juantas de arranque, para aclarar fechas y compromisos y que todos las conozcan)
Planear e incluir en el calendario las juntas de estatus y la forma de comunicarse (Cuantas juntas por que medio)
Asignar responsables a las tareas a realizar
2.5 Estimación de esfuerzo del proyecto.
Tareas a realizar ( WBS ) Estimar cada una de las tareas
Juicio experto Experiencia Preguntando Técnica del mejor caso, peor caso, caso mas probable
Dependencias entre los recursos y las tareas (Por lo general asumimos que los recursos son ilimitados, nunca le asignaremos 59 tareas a una sola persona)
2.5 Estimación de esfuerzo del proyecto.
Análisis de Riesgos Basado en la experiencia Datos Históricos (es la mejor opción, solamente que
requiere cierta diciplina para monitorear la frecuencia de en que se presentan los riesgos, ¿Cada cuanto y Cuantas veces se va la luz?
¿Qué puede suceder? ¿cómo lo arreglamos?
2.5 Estimación de esfuerzo del proyecto.
Recursos ¿Qué podemos aprender de nuestros errores pasados? ¿Qué podemos aprender de nuestros éxitos pasados? Recursos con los que contamos Recursos faltantes
Plan para adquirirlos Restricciones de calendario
Algo similar Recursos ejecutivos
Plan estratégico Prioridades, direcciones, metas Posición competitiva
2.5 Estimación de esfuerzo del proyecto.
Administración Con quién se cuenta Líneas de comunicación Métodos de reporte Estructuras que necesitamos Personal necesario
Personal actual Contrataciones, subcontratos, consultores
Proceso de involucramiento (como van a ir entrando y como van a ir saliendo)
Habilidades y conocimientos (los que tenemos y los que hacen falta) Quién necesita saber que Entrenamiento ¿Quién necesita estar enterado?, ¿como ? Costos, Financiamiento
2.5 Estimación de esfuerzo del proyecto.
Operaciones Tiempos Fechas límite Que afecta a los tiempos Como aseguramos entregar a tiempo Quien hará el trabajo
2.5 Estimación de esfuerzo del proyecto.
Calidad Monitorear el progreso Como sabemos si estamos a tiempo o no Métricas Reportes Datos necesarios Quien reporta a quien.
2.5 Estimación de esfuerzo del proyecto.
Espacio/Equipo/Instalaciones Necesidades de infraestructura (Capacidad
instalada, colores) Herramientas Equipo de computo
