MetodologÍas Y Procesos De Desarrollo
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

MetodologÍas Y Procesos De Desarrollo

  • 18,720 views
Uploaded on

Metodologías Y Procesos De Desarrollo

Metodologías Y Procesos De Desarrollo

More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
18,720
On Slideshare
18,685
From Embeds
35
Number of Embeds
1

Actions

Shares
Downloads
285
Comments
0
Likes
3

Embeds 35

http://www.slideshare.net 35

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Transcript

  • 1. Metodologías en procesos de desarrollo Aurelio Porras
  • 2. Agenda
    • Introducción: Metodologías y Procesos
    • Metodologías Ágiles y SCRUM
    • Café
    • Metodologías Formales y CMMI
    • Team Foundation Server
    • Plantillas de Procesos
  • 3. METODOLOGÍAS Y PROCESOS
  • 4. El éxito es raro 2000 28% 23% 49% Existosos Problemáticos Fallidos Fuente: The Standish Group International, “ Extreme Chaos”, 2004 2004 34% 15% 51% Se pasan en coste: 45% Se pasan en tiempo: 63% No llegan a la funcionalidad: 67%
  • 5. El Problema con el Proceso Predecible Repetible Productivo
    • Complejo
    • Desconectado
    • Difícil
  • 6. Gestión de Proyectos del Siglo XX
    • “ El triángulo de Hierro”
    • (Tetraedro más bien?)
    Funcionalidad Tiempo Recursos Calidad Imagen copyright de Tetra Pak
  • 7. “ Mantra” del Siglo XXI
    • Hacer más con menos!
    • Pero si tus únicas variables son:
      • Funcionalidad
      • Recursos
      • Tiempo
      • Calidad
    • … entonces cómo vamos a hacerlo?
  • 8. Dos Paradigmas de Proceso El tradicional: descomponemos tareas y medimos su grado de completitud Filosofía: “Contabilidad de Costes” El alternativo: contabilizamos el valor para el cliente y lo vamos entregando incrementalmente Filosofía: “ Lean Manufactoring ” y “Teoría de las Restricciones”
  • 9. Dos Paradigmas de Proceso Work-down Sacar trabajo adelante Value-up Incrementar valor Planificación y gestión del cambio Get planning and design right up front El cambio ocurre, acostúmbrate Medida principal Finalización de tarea Sólo entregables que cuentan para el cliente Definición de calidad Conformidad con la especificación Valor para el cliente Tolerancia a la variabilidad Las tareas se pueden identificar y estimar determinísticamente La variabilidad es parte de todos los flujos del proceso Productos intermedios Documentos, modelos y otros artefactos Solo lo suficiente para minimizar la incertidumbre Aproximación a la resolución de desviaciones Ajustar tiempo, recurso, funcionalidad, y/o calidad Detectar y eliminar cuellos de botella Aproximación a la confianza Monitorizar y medir; rendimiento relativo al plan Orgullo del equipo humano y del trabajo colaborativo
  • 10. Work-Down vs. Value-Up
    • Work-Down es un caso especial
      • Similar a la Física: Newton vs. Einstein
      • En general
        • El proceso no fluye suavemente, hay bloqueos y marchas atrás
        • La productividad de los recursos no se distribuye uniformemente a lo largo del tiempo
        • Hay varianza en la efectividad a la hora de completar tareas
      • Sólo en proyectos de bajo riesgo, funciona el paradigma work-down ya que se puede repetir el proceso
  • 11. Transparencia en Proyectos
    • Informes en tiempo real de data warehouse
    • Seguimiento para conformidad
    • Mejora la predictibilidad y reduce el riesgo
    Resultados Predecibles Requisitos de Negocio Requisitos de Calidad de Servicio Informes en tiempo real Planificación Diseño Desarrollo Pruebas Despliegue
  • 12. Cómo se registran las métricas
    • Transparencia: se registra todo el trabajo del equipo según se sigue el proceso metodológico escogido para el proyecto
  • 13. Cómo se registran las métricas
    • Componentes de la Arquitectura
  • 14. Cómo se registran las métricas
    • Los datos que se incluyen en el cubo OLAP están especificados en la Plantilla de Proceso
    • Atributo “Reportable” en la definición del campo del elemento de trabajo que queremos incluir
      • Como “Measure”: Cantidad que se puede sumarizar
      • Como “Dimension”: Campo para sumarizar medidas
      • Como “Detail”: Dato inque se incluye en la base de datos pero no en el cubo
  • 15. Cómo extraigo estado del proyecto
    • A través de informes
      • Informes por defecto según el proceso escogido
        • CMMI Process Improvement
        • Agile Development
      • Informes a medida que desarrollo e incorporo a los informes y a los documentos del proyecto
    • Visualización de informes desde
      • Team Explorer, en visor HTML
      • Portal de Proyecto, en visor HTML o en WebPart de SQL Reporting Services
      • Portal de Reporting Services, desde Team Explorer
    • Análisis de datos desde
      • Excel, accediendo directamente al cubo OLAP
  • 16. METODOLOGÍAS ÁGILES
  • 17. El manifiesto ágil
    • http://www.agilemanifesto.org
    • “ Preferimos…”
      • Individuos e interacción a procesos y herramientas
      • Software funcional a documentación exahustiva
      • Colaboración con el cliente a negociación de contratos
      • Respuesta ante los cambios al seguimiento de un plan
    • Aunque hay valor en lo segundo, preferimos lo primero
  • 18. Principios del manifiesto
    • Adaptabilidad
    • Colaboración
    • Integración continua
    • Simplicidad
  • 19. Adaptabilidad
    • El análisis inicial es una guía, no una biblia intocable
    • El cliente propondrá cambios que han de introducirse en el desarrollo
    • Los presupuestos han de contar con esos cambios
    • La métrica ha de reflejar el impacto de los cambios
    • Se consigue un software más satisfactorio
  • 20. Colaboración
    • El equipo es importante, no los procesos
      • Todo el mundo tiene algo que decir
    • El equipo ha de estar motivado
      • Implicación de los desarrolladores
      • Libertad de exploración
    • La visión general del proyecto es conocida por todos
    • Las reuniones son imprescindibles
      • Cortas, concretas, pero frecuentes
      • Se discute el estado del proyecto
    • La organización es dinámica
      • Liderar un equipo, no gestionarlo
  • 21. Integración continua
    • El software se entrega por partes
    • Las diversas entregas han de ser ejecutables
    • Cada integración supone una evualuación de la misma
      • Eso permite corregir errores y cambiar funcionalidad
    • El cliente tiene un papel en la integración continua
  • 22. Simplicidad
    • Lo simple es bello
    • Mantener una estructura organizativa sencilla
    • No complicar innecesariamente los procesos
    • No saturar el proyecto con documentación superflua
    • Crear un sistema de comunicaciones rápido y ágil
  • 23. Conceptos
    • Roles
    • Actividades
    • Iteraciones
  • 24. Roles
    • Un rol es una función dentro del equipo de desarrollo
    • Los roles pueden desempeñarse por más de una persona
    • Una persona puede desempeñar más de un rol
    • Las actividades están asociadas a roles
    • Los roles pueden tener ciertos permisos dentro de la organización
  • 25. Actividades
    • Las tareas se definen como actividades
    • Incluyen cualquier cosa que haya de hacerse durante el proyecto
      • Captura de requerimientos, testeo, codificación...
    • Una iteración será un conjunto de actividades
    • Las actividades se asignan a personas que pertenecen a roles
    • Es deseable monitorizar las actividades
  • 26. Iteraciones
    • Ciclos de desarrollo cortos
      • Suelen ser de un mes
    • Al principio se decide que actividadaes incluirá cada iteración
    • Al final se obtiene software instalable y ejecutable
      • Integración continua
    • Durante la iteración las reuniones han de permitir controlar el estado de la iteración
    • Las iteraciones son revisables
  • 27. MSF For Agile
    • MSF For Agile implementa una versión de metodología ágil
    • TFS incluye MSF For Agile como plantilla de procesos
    • Define roles, WorkItems, documentación básica...
    • Incluye métricas del proyecto
    • Incluye un portal de colaboración con la guía de procesos
  • 28. SCRUM
    • Es una implementación de metodología ágil
    • Creada por Hirotaka Takeuchi e Ikujiro Nonaka en 1986
  • 29. Principios de SCRUM
    • Equipo muy simple
    • Pila de funcionalidades (Backlog)
    • Reuniones diarias (Scrums)
    • Iteraciones (Sprints)
  • 30. Equipo
    • Propietario del producto
      • Da los requerimientos
      • ¡Paga!
    • Equipo
      • Autogestionado
      • Multidisciplinar
    • Scrum Manager
      • Supervisa y coordina los roles
      • Comprueba las tareas
  • 31. Backlogs
    • Listado de requisitos
    • Recopilado por el propietario del producto
    • Es una lista dinámica
    • Se subdivide en los diferentes sprints
  • 32. Sprints
    • Representan iteraciones
      • Por lo general de un mes
    • Cada sprint posee una pila extraida del backlog de producto
    • Los sprints se revisan al final para evaluarlos (retrospectivas)
    • Cada día se realiza una reunión para realizar el seguimiento del sprint (SCRUM)
      • Reuniones cortas (15 minutos)
      • Sólo hablan los implicados
  • 33. METODOLOGÍAS FORMALES: CMMI
  • 34. CMMI
    • Capability Model Maturity Integration
      • Carnegie Mellon Software Engineering Institute (www.sei.cmu.edu/cmmi)
      • Diseñado originalmente para contratos del gobierno de USA
    • Fuertemente basado en el diseño de procesos de producción
    • Muy auditable, con multitud de métricas
    • Mucha documentacion
  • 35. Niveles de madurez
    • Nivel 0: Proceso incompleto
    • Nivel 1: Proceso realizado
      • No hay control de proceso. El resultado no es predecible. Muchas variaciones especiales. No hay planificación.
    • Nivel 2: Proceso gestionado
      • Se satisfacen los requisitos del proyecto. Hay una planificación y cada trabajo es realizado por la gente correspondiente.
    • Nivel 3: Proceso definido
      • Se desarrollan un cierto número de procesos que cubren las priincipales áreas de desarrollo
    • Nivel 4: Proceso gestionado cuantitativamente
      • Todos los aspectos de un proceso poseen métricas que permiten controlarlo
    • Nivel 5: Proceso optimizado
      • Mejora continua de los procesos
  • 36. Cobertura de CMMI en TFS
    • Nivel 0: Proceso incompleto
    • Nivel 1: Proceso realizado
      • No hay control de proceso. El resultado no es predecible. Muchas variaciones especiales. No hay planificación.
    • Nivel 2: Proceso gestionado
      • Se satisfacen los requisitos del proyecto. Hay una planificación y cada trabajo es realizado por la gente correspondiente.
    • Nivel 3: Proceso definido
      • Se desarrollan un cierto número de procesos que cubren las priincipales áreas de desarrollo
    • Nivel 4: Proceso gestionado cuantitativamente
      • Todos los aspectos de un proceso poseen métricas que permiten controlarlo
    • Nivel 5: Proceso optimizado
      • Mejora continua de los procesos
  • 37. Nivel 2 Planificación de Proyecto Monitorización y control Medidas y análisis Gestión de requisitos Gestión de configuración Control de Calidad del producto Gestión de conformancia con el proveedor Nivel 3 Gestión integrada Gestión de riesgos Integración del equipo Desarrollo de requisitos Solución técnica Integración del producto Verificación Validación Resolución de análisis Definición organizativa Entorno de integración Organización del proceso Formación organizada Gestión del proveedor integrada Omitido 50% cobertura 20% cobertura
  • 38. Valoración
    • Cada práctica tiene un cierto número de subprácticas
    • La valoración del conjunto proporciona una métrica sobre la calidad del proceso
    • SCAMPI ( Standard CMMI Appraisal Method for Process Improvement )
      • Proporciona un modelo de valoración
      • Cada subpráctica requiere evidencias directas e indirectas
      • Basado en la documentación
  • 39. MSF For CMMI
    • Es una interpretación “ágil” de CMMI
    • Incluye ciertas características de Agile
    • Menos documentación
    • Utiliza el mismo paradigma
      • WorkItems, Iteraciones, roles...
    • Los informes proporcionan las métricas necesarias para valorar el estado del proyecto.
  • 40. Gracias por su atención