Principios de Desarrollo de Aplicaciones

Agenda Qué es MSF? Introducción al Modelo de Equipos Administración de riesgos Introducción al modelo de Procesos Hito Aprobación de Visión Hito Aprobación del Plan de Proyectos Hito Alcance Completo Hito Liberación Resumen

Qué es MSF?

Porcentaje de Proyectos fracasados Modificados Exitosos Fracasados 28% 46% 26% Proyectos de Desarrollo de Aplicaciones

Las principales causas de los fracasos Separación de objetivos y negocios Separación de negocios y tecnología Carencia de Lenguaje y proceso comunes Falla al comunicar y actuar como equipo Procesos que son inflexibles a los cambios “Cuando un proyecto falla, rara vez es por cuestiones técnicas.” Jim Johnson, The Standish Group

Principios del Desarrollo de Aplicaciones Apoya lo que considera Microsoft que son las mejores prácticas y principios del desarrollo de aplicaciones Es un miembro de la familia Microsoft Solutions Framework Representa un framework, no una metodología Se focaliza en la gente y en los procesos, no en la tecnología

Servicios de ConsultoríaMicrosoft Información Tecnológica Origen Grupos de Productos Microsoft todo mundo Servicios de ConsultoríaMicrosoft Información Tecnológica Microsoft Partners de Microsoft Mejores Prácticas

Curriculum MSF Planificar Construir MSF Gerenciar

Introducción al Modelo de Equipo

Equipos Jerárquicos Las dificultades del trabajo en equipos jerárquicos

Dificultades en Equipos Jerárquicos Alta sobrecarga de comunicaciones Malos entendidos por comunicaciones indirectas Objetivos confusos de equipo y roles Miembros no integrados del equipo Alta sobrecara de procesos

Metas del equipo para el éxito Clientes satisfechos Entregas dentro de las restricciones del proyecto Entregas bajo especificaciones basadas en los requerimientos del usuario Entregas después de tratar todas los temas conocidos Rendimiento incrementado del usuario Despliegue prolijo y administración en curso

Entendiendo los objetivos El éxito total requiere éxito en cada objetivo Cada objetivo debe ser igualmente valorado Cada objetivo requiere una disciplina que este enfocada a dicho objetivo Cada disciplina esta contenida en un rol Objetivos valorados equitativamente se corresponden con roles igualmente valorados, creando un equipo de pares

Equipo de pares Es un equipo cuyos miembros se relacionan como iguales Cada miembro tiene roles y responsabilidades específicos Potenciar a los individuos en sus roles Responsabilizar a los miembros por el éxito de sus roles Conducir las desiciones sobre la base del concenso Otorgar a todos los miembros del equipo un riesgo en el éxito del proyecto.

Modelo de Equipo para el Desarrollo de Aplicaciones Gerente de Desarrollo Desarrollador Testing Gerente De Logística Formación De Usuarios de Producto Comunicación

Rol del Gerente de Producto Actuar como un cliente dentro del equipo Actuar como equipo avocado a el cliente Conduce la visión compartida del proyecto Maneja expectativas del cliente Desarrolla, mantiene, y ejecuta el caso de negocio Conduce la identificación y priorización de las funcionalidades Desarrolla, mantiene y ejecuta el plan de comunicaciones.

Rol del Gerente de Desarrollo Conduce el proceso global Maneja la asignación de recursos Maneja el cronograma y reporta el estado del proyecto Maneja el alcance y la especificación del producto Facilita la comunicación y la negociación del equipo Conduce los cambios críticos de decisiones en su globalidad.

Desarrollador Rol del Desarrollador Construye y prueba funcionalidades para satisfacer las especificaciones y expectativas del cliente Participa del diseño Estima el tiempo y esfuerzo para completar cada funcionalidad Sirve al equipo como consultor tecnológico

Rol del Testing Desarrolla estrategias, planes, y scripts de testeo Manages the build process Maneja el proceso de construcción Conduce el testeo para determinar exactamente el estado del desarrollo del producto Participa en establecer la línea de calidad

Rol de Formación de Usuarios Actúa como equipo en el usuario final Actúa como usuario final dentro del equipo Participa en la definición de los requerimientos de usuario Participa de las características de diseño Diseñan y desarrollan sistemas de soporte al usuario Conduce el proceso de usabilidad

Rol del Gerente de Logística Actúa como mediador del equipo hacia las operaciones Actúa como mediador de las operaciones hacia el equipo Planea y administra el despliegue del producto Participa del diseño, centrándose en flexibilidad, portabilidad, y despliegue Apoya el producto durante la prueba beta Entrena al personal de operaciones y help desk para la liberación del producto

Alineación de Roles y Objetivos Rol de Equipo Gerente de Producto Gerente de Desarrollo Desarrollador Testing Formación de usuarios Gerente de logística Objetivo Clientes satisfechos Entregas cumpliendo los requisitos del proyecto Entregas cumpliendo las especificaciones Entregar después de resolver todos los temas Rendimiento mejorado del usuario Entrega afinada del producto

NO un organigrama tradicional Testing Desarrollo Manager Proyecto Logística Analista Educación de Usuario

Coordinación con equipos externos Usuarios Finales Foco de Negocios Usuarios Finales Formación de Usuario Gerente de Producto Clientes Equipo de Proyecto Testing Desarrollador Operaciones y grupos de soporte Arquitectos de negocio y planificadores Gerente de Logistica Gerente de Desarrollo Arquitectos de Tecnología Y comités de dirección Foco Tecnológico

Escalando para proyectos pequeños Product Management Program Management User Education Logistics Management Development Testing N P I Product Management Program Management Development Testing User Education Logistics Management Posible P Improbable I No N

Ejemplo: Roles combinados Gerente De Producto Gerente de Desarrollo Desarrollador Formación De Usuarios Gerente De Logística Testing

Escalando para proyectos grandes Dividir los equipos grandes en equipos pequeños, que tienen: Menor sobrecarga de proceso Menor sobrecarga de administración Menor sobrecarga de comunicación Implementación más rápida Crear equipos de funcionalidad- Subequipos multidisciplinarios organizados en torno a grupos de funcionalidades del producto Crear equipos de función-Subequipos unidisciplinarios organizados en torno a roles funcionales

Ejemplo: Equipos de Funcionalidad Program Management Product Management Development Equipo líder User Education Testing Logistics Management Program Management Program Management Development Development Equipo Impresión Equipo Central Program Management User Education User Education Testing Testing Development Equipo UI User Education Testing

Ejemplo: Equipos de Función Gerente de Grupo de Producto Planificador De Producto Evangelizador Gerente De Producto Relaciones Públicas Marketing

Administración de Riesgos

Riesgo Definición Características Diccionario: “Posibilidad de pérdida o perjuicio” Webster’s Collegiate Dictionary, 10th edition Común: Un problema esperando que suceda Características Inherente en cada proyecto Ni intrínsecamente bueno ni malo No para temer, si para administrar

Proceso de Administración de Riesgos Declaración De Riesgos 1. Identificar 2. Analizar Documento de estimación de riesgos Top 10 Riesgos Reiterados 5. Control 3. Plan 4. Track El entregable de este proceso es el documento de estimación de riesgos dinámico

Identificando Riesgos 1. Identificar Descubriendo y reconociendo problemas potenciales dentro del proyecto Ejemplo: Identificar el fuego como un riesgo potencial en un depósito Para identificar riesgos efectivamente Usar una estrategia colaborativa Buscar problemas potenciales desde diversas fuentes Examinar riesgos en dos direcciones Tópicos potenciales y sus consecuencias probables Consecuencias potenciales y sus causas probables

Analizando Riesgos 2. Analizar Convertir los datos de riesgos en información para la toma de desiciones Ejemplo: Comprender que podría causar el fuego en el depósito y cuál sería el costo del daño Para analizar riesgos efectivamente Evaluar la probabilidad del riesgo Evaluar el impacto del riesgo Calcular la exposición del riesgo

Diseñando el plan de riesgos Formular acciones para prevenir y minimizar el riesgo y qué hacer si ocurriera Ejemplo: Planificar como prevenir el fuego en el depósito y qué hacer si ocurre Priorizar las desiciones de planificación basadas en la prioridad de los riesgos Considerar cinco áreas claves Investigación: Conoce lo suficiente de los riesgos? Aceptación: Puede vivir con sus consecuencias? Evasión: Puede evitar el riesgo? Mitigación: Puede reducir la probabilidad? Contingencia: Puede reducir el impacto?

Rastreando Riesgos Monitorear los riesgos y sus planes de mitigación 4. Track Monitorear los riesgos y sus planes de mitigación Ejemplo: Revisar los 10 riesgos principales de la lista para un cambio de prioridades Para rastrear riesgos efectivamente Tratar el rastreo de riesgos como un ejercicio corriente a lo largo de todo el ciclo de vida del proyecto Seguir los riesgos por cualquier cambio en su condición o consecuencia Cuantificar el efecto del plan de mitigación Monitorear los disparadores de contingencias

Controlando Riesgos 5. Control Conducir los resultados del rastreo de riesgos y del proceso como un todo Ejemplo: Retirar un riesgo que haya sido exitosamente mitigado Para controlar riesgos efectivamente Adaptar la prioridad de los riesgos según los cambios Reaccionar a las variaciones del plan Responder a los eventos disparadores Evaluar el proceso de administración de riesgos

Introducción al Modelo de Procesos

Modelos de Procesos Los modelos del ciclo de vida establecen el orden para las actividades del proyecto Dos modelos son populares El modelo en cascada El modelo en espiral (o desarrollo rápido de aplicación) El modelo de procesos de MSF para desarrollo de aplicaciones combina los beneficios de ambos Proceso basado en Hitos Procesos flexibles e iterativos

Modelo de Proceso para el desarrollo de Aplicaciones V S O G P L A D T B Z Vision Approved Project Plan Approved Scope Complete Release

Proceso Guiado por Hitos Los hitos son puntos de revisión y sincronización, no puntos de congelamiento Los hitos permiten al equipo determinar progreso y hacer correcciones en el camino Los modelos de procesos usan dos tipos de hitos Hitos principales Hitos interinos Alcanzar un hito principal representa un acuerdo entre el equipo y el cliente de continuar Las entregas son la evidencia física de que los equipos alcanzaron un hito

Responsabilidades guiadas por hitos Visión aprobada Plan de proyecto aprobado Alcance completo Entrega Conductor Primario Gerente de producto Gerente de Desarrollo Desarrollador y Formación de usuarios Testing y Gerente de Logística

Principios de un Proceso Exitoso Crear documentación actualizada Utilizar entregas versionadas Hacer compensaciones del proyecto Resources Schedule Features

Matriz de compensaciones del proyecto Resources Features Schedule Optimize Constrain Accept Recursos Cronograma Características

Hito Visión Aprobada

Visionando Creando una vista de alto nivel de las metas y restricciones del proyecto Sirve como una forma temprana de planificación Ayuda al equipo a encontrar un acuerdo común para diferentes perspectivas Brinda la base para futuras planificaciones Captura lo que los clientes y los miembros claves consideran esencial para alcanzar el éxito

Definiendo el alcance Visionando Resources Schedule Features

Hito de Visión Aprobada Indica acuerdo en La razón del proyecto El producto esperado Factibilidad del proyecto Metas y restricciones del proyecto Oportunidades y riesgos Estructura del proyecto Release I E N V S O G S T A B I L Z N G Scope Complete Vision Approved D E V L O P I G N P L A N I G Project Plan Approved

Hitos interinos sugeridos Núcleo del equipo formado Borrador del Documento Vision Borrador del Documento de Estimación de Riesgos Vision Aprobado Se ven a nivel de equipo Dan oportunidad a los miembros de equipo para sincronizar su trabajo Dan a los miembros del equipo, la oportunidad de evaluar el progreso y el estado actual

Entregables de Visión Aprobado Propósito Dueño Documento Visión Documento de estimación de riesgos Documento de estructura del proyecto Describe lo que se quiere hacer y cómo se piensa hacerlo Describe los riesgos que conlleva el proyecto Describe la estructura organizacional del proyecto Gerente de Producto Gerente de Desarrollo

Documento Visión Documenta lo que se entiende inicialmente por objetivos y restricciones del proyecto Es el entregable principal de este hito Da las bases para decisiones de seguir o no seguir Da un punto de encuentro para el equipo Guía las decisiones del equipo a un nivel superior Da una guía para las expectativas de los clientes, usuarios finales y del equipo

Contenidos del Documento Visión Propósito Declaración del problema Declaración de la visión Concepto de la solución Perfiles del usuario Objetivos de negocio Metas de diseño Por qué se quiere hacerlo? Qué se quiere que sea el producto? Qué se realizará? Quién utilizará el producto? Qué se quiere lograr? Cómo se planea lograrlo?

Documento de estimación de riesgos Estimando los riesgos preliminares del proyecto y planificando su administración Se crea durante el proceso de administración de riesgos Es la estimación inicial de riesgos del proyecto Establece las bases para la posterior gestion del riesgo Provee las bases para organizar cronogramas y tomar decisiones

Documento de estructura del proyecto Describiendo la estructura organizacional del proyecto y del proceso de gerente de proyecto Brinda información sobre los miembros del equipo Incluye información logística del equipo Describe procesos del equipo Actúa como un repositorio de plantillas de documentación del proyecto

Hito Aprobación del Plan de Proyecto

Importancia de planificar Costo de reparar defectos por fase 100 80 60 40 20 Envisioning Planning Developing Stabilizing

Definiendo más el alcance Resources Schedule Planificando Features

Hito Plan de Proyecto Aprobado Indica acuerdo en Estrategia de compensaciones del proyecto Riesgos del proyecto Qué se construirá? Cuándo se construirá? Cómo será construido? Quién lo va a construir? Release L S T A B I Z N G I E N V S O G Scope Complete Vision Approved D E V L O P I G N P L A N I G Project Plan Approved

Hitos interinos sugeridos Borrador de especificación funcional Borrador del plan de proyecto maestro Borrador de Cronograma de proyecto maestro Plan de Proyecto Aprobado

Revisión del proceso de diseño Diseño conceptual Diseño Lógico Escenarios Diseño Físico Objetos y servicios, Unterfaz de usuario y base de datos lógica Componentes, interfaz de usuario, y base de datos física

Vínculo con la planificación Vision Aprobada Plan Proyecto Aprobado Línea base del Diseño Conceptual Diseño Conceptual Línea base del Diseño Lógico Diseño Lógico Línea base del Diseño Físico Diseño Físico

Modelo de aplicación MSF Servicios de Usuarios Servicios de Negocios Servicios De Datos

Entregables para la Aprobación del Plan de Proyectos Propósito Propietario Especificación funcional Plan de proyecto maestro Cronograma de proyecto maestro Documento revisado de estimación de riesgos Describe qué se va a construir Describe como será construido Describe cuándo se construirá Describe los obstáculos para construir Gerente de Desarrollo Gerente de Desarrollo

Principios para cronogramas Precisos Estimar desde abajo hacia arriba Tener la mente en una fecha fija de entrega Calendarizar guiado por los riesgos Calendarizar para un futuro incierto Sumar un margen de tiempo Utilizar hitos transitorios de desarrollo Utilizar tareas discretas

Hito Alcance Completo

Hito Alcance Completo Indica acuerdo en El conjunto de característica planeadas Si dichas características han sido desarrolladas Línea base de materiales para soportar el rendimiento del usuario El proceso estabilizado, incluyendo betas y testing Release S T A B I L Z N G I E N V S O G Scope Complete Vision Approved D E V L O P I G N P L A N I G Project Plan Approved

Hitos interinos sugeridos Alcance Completo Versión Interna n Versión Interna... Versión Interna 2 Versión Interna 1

Entregas Internas LLevar el producto a un estado conocido e incrementalmente construir sobre él Entrega Interna 1 Entrega Interna 2 Feature Development Testing y estabilización Tiempo de margen 6 a 8 semanas 2 a 4 semanas 2 a 3 semanas Test de aceptación Hito Revisión

Tendencia Defecto-Cero Consignar el más alto nivel de calidad posible dentro de las restricciones del proyecto Los miembros del equipo deben comprender el nivel de calidad requerido para su trabajo El trabajo no está completo hasta que no alcance ese nivel de calidad La tendencia Defecto-Cero está contenida en Tareas entregables Hitos

Testing Asegurarse que las cosas correctas sean hechas correctamente en el tiempo correcto Descubrir detalles para que puedan direccionarse Validar que el equipo está haciendo las cosas correctas Verificar que el equipo las esté haciendo correctamente Soportar decisiones de negocio y cambios Mirar el proceso, no solo el producto

Proceso continuo de Testing Release Versión Golden Release Versión Candidata S T A B I L Z N G Versión Cero-Bug Betas Especificación de Testing Completa/Alpha Scope Complete D E V L O P I G N Versión Interna n Versión Interna... Versión Interna 2 Project Plan Approved Versión Interna 1 Test Plan

Categorías de Pruebas Testing de aplicación Testing de uso Intenta probar a fondo cada característica del producto Intenta probar exhaustivamente el código base del producto Se usa principalmente durante la fase de desarrollo Testing de uso Intenta completar satisfactoriamente todos los escenarios de uso Intenta probar el producto en su ambiente esperado Se usa principalmente durante la fase de estabilización

Proceso de Bug Tracking Report Tester Bug Retired Close Tester Prioritize and Assign Development Lead Resolve Developers

Hito Liberación

Hito Liberación Indica acuerdo en Estabilidad de producto y resolución de los bugs conocidos Aceptación del cliente Transferencia del dominio para administración y soporte a largo plazo Cambio en el equipo centrándose en la próxima versión I E N V S O G P L A D T B Z Vision Approved Project Plan Approved Scope Complete Release

Testing durante la Fase Estabilización Es la transición del testing de aplicación al de uso Involucra tanto el testing interno como el externo El testing de uso interno se focaliza en completar los escenarios de uso y un amplio testing de configuración El testing de uso externo se realiza principalmente por medio de las betas Se aproxima al final del juego

Hitos interinos sugeridos Versión Golden Release Versión Candidata Versión Cero-Bug Convergencia de Bug

Focalizándose en el lanzamiento Beta Bug Convergence Zero-Bug Release Release Candidate Bugs Activos Golden Release Release Tiempo

Postmortem Formalizar el proceso de aprendizaje desde las experiencias pasadas Son encuentros de revisión post-hitos Se captura el aprendizaje del proyecto para el desarrollo de los miembros del equipo y la mejora del proceso Dar por finalizado el proyecto Son fundamentales para el aprendizaje de la organización

Para más Información Web sites Libros Microsoft Solutions Framework site at http://www.microsoft.com/MSF Steve McConnell’s Survival Guide site at http://www.construx.com/survivalguide/home.htm Libros Dynamics of Software Development, Jim McCarthy Rapid Development, Steve McConnell Software Project Survival Guide, Steve McConnell Debugging the Development Process, Steve Maguire Microsoft Secrets, Michael A. Cusumano y Richard W. Selby

Microsoft Solutions Framework at a Glance Key MSF Principles Customer-focused projects Project actions are determined by the goal of solving a particular business problem rather than for the sake of interesting technology. This focus helps to align business and technology, because technology is only being used to support the needs of the business. User-centric design This design focus means that the product design is based on how all of the different users need to use the system. This focus aligns what the system does with what it needs to do. If a feature exists in the design, it is to support a use of the product. NOTE: In MSF terminology, the customer is the individual, group, or organisation paying for the project. The user is the individual, group, or organisation that will use the system or the technology when the project is completed. Common language and terminology MSF acts as a baseline for communication. When teams are formed, each member has personal project experience and knowledge of different project methodologies. MSF allows the team to share a simple baseline that each member on the team can agree to and use. Defined team roles and responsibilities The MSF Team Model focuses each of its roles on a singular goal that must be accomplished for the project to be successful. 1st Avenue Plum Street Orange Street . Smith River 2nd Avenue 3rd Avenue 4th Avenue S MSF E W N A methodology, like a map, applies specific directions and a specific route to a known destination. Methodology Framework A framework, like a compass, verifies progress and provides directional guidance when the direction or route changes. MSF is a framework ! Its models, principles, and practices provide a guide for planning and building business solutions. MSF serves as a useful tool for measuring progress against the original goals. The Six Team Goals for Success Satisfied Customers Delivery within Project Constraints Delivery to Specification Release After Addressing All Known Issues Enhanced User Performance Smooth Deployment and Ongoing Management Why use MSF - Typical Root Causes of Failure: Separation of Goal and Function Separation of Business and Technology Lack of Common Language and Process Failure to Communicate and Act As a Team Processes That Are Inflexible to Change Potential Projects Enterprise Goals Enterprise architecture Selects the path Provides the guidance to get there Digital Nervous System Embodies business goals of organisation Relationship of MSF and the Enterprise Architecture Resources Features Schedule Project Tradeoffs Testing Developer Manager Project Logistics Analyst Education User SYSTEM Databases User Interface Services Data Layer Business Layer Presentation Layer Team roles Product management Program management Development Testing User education Logistics management Goal Satisfied customers Delivery within project constraints Delivery to product specifications Release after addressing all known issues Enhanced user performance Smooth product deployment Milestone Phase One Phase Four Phase Three Phase Two Versioned Releases Customer Database Orders Product Customers Traditional View Services View Network of Cooperating Services Application 1 Application 2 Application 3 Stovepiped Services Baseline Early Baseline planning efforts begin as early as possible for an earlier development start Freeze Late Consider documents as dynamic and subject to change Functional Specifications Vision Document Project Plans Project Schedule Risk Management Document Living Documents Steps of the MSF Risk Management Process 1. Identify the risk. Bring risks to the surface so teams can deal with them before the risks impact a project. Briefly, the five steps of the process are: 2. Analyse the risk. Convert risk data into information that a team can use to make decisions. 3. Plan for the risk. Devise plans that will support decision-making and actions taken. 4. Track the risk. Monitor the status of risks and any actions taken to mitigate them. 5. Control the risk. Move risk management into day-to-day project management, which is crucial in ensuring that risk management remains a high-profile activity. 1 Identify Risk Statements 2 Analyse Retired Risks Risk Asessment Document Top 10 5 Control 3 Plan 4 Track MSF Poster March 2001 The ongoing deliverable of this process is a living risk assessment document