1 Procesos Ágiles

2 Contenido Introducción Contexto Manifiesto Ágil Reflexiones FDD Scrum Open-source AUP

3 Introducción

4 Contexto Nandhakumar & Avison 1999 –Metodologías tradicionales de desarrollo de sistemas de información “son tratadas principalmente como una ficción necesaria para presentar una imagen de control o para proveer un estatus simbólico”. Truex et al. 2000 –Es posible que los métodos tradicionales sean “meramente ideales inalcanzables y hipotéticos straw-men que proveen una guía normativa a situaciones de desarrollo utópicas.” McCauley 2001 –La filosofía en la cual se basan los métodos orientados a procesos establece que los requerimientos de un proyecto de software quedan congelados antes de que el diseño y desarrollo del software comience.

5 Manifiesto por el Desarrollo Ágil Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de esta experiencia hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Software que funciona sobre documentación exhaustiva Colaboración con el cliente sobre negociación de contratos Responder ante el cambio sobre seguimiento de un plan Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda. http://www.agilemanifesto.org

6 Principios Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Entregamos software frecuentemente. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto. Construimos proyectos con profesionales motivados. Conversación cara a cara. Software que funciona es la principal medida de progreso. Los procesos ágiles promueven el desarrollo sostenible. La atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad. Simplicidad es esencial. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se auto-organizan. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo. http://www.agilemanifesto.org/principles.html

7 Reflexiones Highsmith & Cockburn 2001 –“lo que es nuevo en los procesos ágiles no son las prácticas que usan, sino que reconozcan a las personas como primeros implicados en el éxito de un proyecto, además de un intenso foco en la efectividad y la manejabilidad. Esto genera una nueva combinación de valores y principios que definen una visión ágil del mundo.”

8 Reflexiones (2) Hawrysh & Ruprecht 2000 –Una sola metodología no puede funcionar para todo el espectro de proyectos, en vez de eso el administrador de cada proyecto debería identificar la naturaleza especifica de cada proyecto y seleccionar la mejor metodología de desarrollo aplicable. McCauley 2001 –Hay una necesidad de ambos métodos [ágiles y orientados a procesos] ya que no hay un modelo de desarrollo que se ajuste a todos los propósitos imaginables.

9 ¿Cuando un método es ágil? El desarrollo de software es –Incremental liberaciones pequeñas y ciclos rápidos. –Cooperativo clientes y desarrolladores trabajando juntos. –Simple y Directo el método es fácil de aprender y modificar. –Adaptativo es posible realizar cambios de último momento.

10 FDD Es un proceso ágil diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca. Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorizar. Las iteraciones se deciden en base a features o funcionalidades, que son pequeñas partes del software con significado para el cliente. Feature Driven Development

11 A diferencia de otros procesos ágiles no cubre todo el ciclo de vida sino sólo las fases de diseño y construcción. No requiere un modelo específico de proceso y se complementa con otras metodologías. Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluación del progreso.

12 FDD define tres categorías de roles: Roles claves - Gerente del proyecto - Arquitecto jefe - Gerente de desarrollo - Programador jefe - Propietarios de clases - Experto de dominio Roles de soporte - Administrador de entrega - “Guru” de lenguaje - “Herramientista” (toolsmith) - Administrador del sistema Roles Adicionales - “Tester” - Escritores de documentos técnicos FDD Roles

13 Proceso 1 FDD

14 FDD consiste en cinco procesos secuenciales durante los cuales se diseña y construye el sistema. La parte iterativa soporta desarrollo ágil con rápidas adaptaciones a cambios en requerimientos y necesidades del negocio. Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida. Proceso 2 FDD

15 Desarrollo de un modelo general: Cuando comienza el desarrollo, los expertos de dominio están al tanto de la visón, el contexto y los requerimientos del sistema a construir. A esta altura se espera que existan requerimientos tales como casos de uso o especificaciones funcionales. Construcción de la lista de rasgos: Los ensayos, modelos de objeto y documentación de requerimientos proporcionan la base para construir una amplia lista de rasgos. Estos rasgos son pequeños ítems útiles a los ojos del cliente. La lista de rasgos es revisada por los usuarios y patrocinadores para asegurar su validez y exhaustividad, los rasgos que requieran de más de diez días se descomponen en otros más pequeños. Proceso Fases 1 FDD

16 Planeamiento por rasgos: Incluye la creación de un plan de alto nivel, en el que los conjuntos de rasgos se ponen en secuencia conforme a su prioridad y dependencia, y se asigna a los programadores jefes. Diseño por rasgos y Construcción por rasgos: Se selecciona un pequeño conjunto de rasgos del conjunto, y los propietarios de clases seleccionan los correspondientes equipos dispuestos por rasgos. Se procede luego iterativamente hasta que se producen los rasgos seleccionados. Una iteración puede tomar de unos pocos días un máximo de dos semanas. El proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código. Proceso Fases 2 FDD

17 Algunos “agilistas” sienten que FDD es demasiado jerárquico para ser un método ágil, porque demanda un programador jefe, quien dirige a los propietarios de clases, quienes dirigen equipos de rasgos. Otros críticos sienten que la ausencia de procedimientos detallados de prueba en FDD es llamativa e impropia. FDD se utilizó por primera vez en grandes aplicaciones bancarias a fines de la década de 1990. Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemas existentes y recomiendan adoptarlo en forma gradual. Experiencias en su uso

18 "The New Product Development Game" (Harvard Business Review 86116:137-146, 1986) "The Knowledge Creating Company" Ikujiro Nonaka y Hirotaka Takeuchi (Universidad de Oxford, 1995). OOPSLA’95 ( Object-Oriented Programming Systems, Languages, and Applications 1995 ). Jeff Sutherland Ken Schwaber. PLOP Scrum pattern (Pattern Languages of Programs 1998). Mike Beedle, Linda Rising, et al. Orígenes SCRUM

19 Equipos auto-organizados El producto progresa en una serie de “sprints” que duran un mes Los requerimientos se encuentran en el “product backlog” reunidos en una lista No contiene practicas de ingeniería pre-descriptas Utiliza reglas generales para crear un ambiente ágil para la liberación de los proyectos Usado para proyectos complejos con requerimientos cambiantes Basado en un control de proceso empírico Características SCRUM

20 “Es típico adoptar un enfoque de modelado definido (teórico) cuando los mecanismos subyacentes por el cual el proceso opera son razonablemente bien entendidos. Cuando el proceso es demasiado complicado para el enfoque definido, el enfoque empírico es la elección apropiada.” “Process Dynamics, Modeling and Control” B. A. Ogunnaike y W.H. Ray, Bases Visibilidad Inspección Adaptación Control de proceso empírico

21 Esqueleto de SCRUM Proceso iterativo e incremental Estructura Corazón de SCRUM Iteraciones SCRUM

22 Ciclo de vida Todo el trabajo es realizado en Sprints (30 días) Durante el Sprint se realizan reuniones que constituyen la inspección empírica y las practicas de adaptación de Scrum. Sprint Reunión de planeamiento del Sprint (< 8hs) Primeras 4hs Requerimientos a realizarse en el sprint Segundas 4hs Plan de trabajo del sprint SCRUM

23 Daily sprint (< 15min) ¿ Qué has hecho en este proyecto desde el ultimo Daily sprint? ¿ Qué planeas hacer en el proyecto entre hoy y la próxima reunión Daily Scrum? ¿ Qué impedimentos se te han presentado para lograr lo prometido en el Sprint y proyecto? Sprint Review (< 4hs) Presentación de lo desarrollado durante el sprint Sprint Retrospective (< 3hs) Revisión y análisis del proceso de desarrollo Ciclo de vida SCRUM

24 Ciclo de vida

25 Product owner (dueño del producto) Team (equipo) ScrumMaster Roles SCRUM

26 Product backlog Sprint backlog Incremento de una funcionalidad del producto potencialmente despachable Artefactos SCRUM

27 Microsoft ha combinado los modelos de trabajo ágiles Scrum y Extreme programming para finalizar el lanzamiento de las nuevas versiones: SQL Server 2005, Visual Studio 2005 tool suite y Biztalk server 2006 integration servernuevas versiones Experiencia en su uso SCRUM

28 El término refiere en principio a una forma de licencia que debe tener fundamentalmente las siguientes características: Libre redistribución. Código fuente abierto. La redistribución de modificaciones debe estar permitida. Open-source

29 Proceso Típicamente un proyecto open-source contiene las siguientes fases: Descubrimiento del problema. Búsqueda de desarrolladores voluntarios. Identificación de la solución. Implementación y testeo. Revisión de cambios en el código. Aprobación del código y de la documentación. Liberación del producto. Estas fases se realizan en forma iterativa. OSS

30 Características del Proceso Los siguientes factores caracterizan al proceso de desarrollo open-source. Muchos desarrolladores voluntarios. El trabajo no se asigna. Cada cual elige libremente su tarea en función de su interés personal. No hay plan de proyecto, ni plazos, ni lista de entregables. Una buena división de las tareas es esencial para el éxito del proyecto. Internet como herramienta de comunicación es esencial para el desarrollo open-source. El sistema aumenta en pequeños incrementos. Los programas son testeados frecuentemente.

31 Una típica estructura de desarrollo open-source está compuesta por varios tipos de voluntarios. Líderes de Proyecto, son quienes tienen la responsabilidad general del proyecto y usualmente han escrito el código inicial. Desarrolladores voluntarios, crean y envían código para el proyecto. Personas que identifican bugs y envían reportes de problemas al usar el software. Personas que participan de newsgroups y foros de discusión. Roles y Responsabilidades

32 Diferencias Open-source opera generalmente en forma geográficamente distribuida. En tanto que, los métodos ágiles tradicionales recomiendan grupos de desarrollo pequeños y geográficamente cercanos. En open-source el cliente suele ser también desarrollador. En open-source cada participante elige su tarea. Open-Source vs. Procesos Ágiles

33 Similitudes Desarrollo incremental, entregas tempranas y frecuentes. El programa es frecuentemente testeado. Cooperación entre cliente y desarrollador. Open-source, no incluye ninguna norma de documentación formal predefinida. En un proceso de desarrollo open-source, los requerimientos son elaborados continuamente. Open-Source vs. Procesos Ágiles

34 Se ha argumentado que open-source difiere de los procesos ágiles en aspectos filosóficos, económicos y de estructura de equipos. Sin embargo, el proceso de desarrollo open- source resulta bastante cercano al de los procesos ágiles. Organizaciones dispersas geográfica y culturalmente podrían beneficiarse de las ventajas del paradigma open-source. Conclusiones OSS

35 Qué es? Cuándo y cómo surge? Ciclo de vida. Fases e hitos. AUP

36 Es una versión simplificada del RUP Aplica técnicas ágiles: –TDD: test driven development (TFD+refactoring) –AMDD: agile model driven development –Agile requirements change management –Database refactoring AUP Qué es?

37 1988: Objectory 1.0 1998: RUP 5.0 Feb/2004: EUP Sep/2005: AUP 13/5/2006: v1.1 AUP Cuándo surge? AUP

38 Scott W. Ambler 1999: Cómo extender RUP? 2001: Cómo agilizar RUP? 2002: Publica “Agile Modeling book” –AM vs XP –AM vs RUP 2004: EUP 2005: AUP Cómo surge? AUP

39 Ciclo de Vida AUP

40 Inicio Elaboración Construcción Transición Ciclo de vida AUP

41 Objetivos: Identificar el alcance inicial del proyecto, proveer una arquitectura potencial para el sistema, y obtener un financiamiento inicial del proyecto y la aceptación de los stakeholders. Ciclo de vida: Inicio AUP

42 Objetivos: Probar la arquitectura del sistema; hacer un prototipo de arquitectura que elimine los riesgos técnicos para probar que el proyecto es factible. Ciclo de vida: Elaboración AUP

43 Objetivos: De forma regular e incremental, construir software que funcione y satisfaga las necesidades de mayor prioridad de los stakeholders del proyecto. Ciclo de vida: Construcción AUP

44 Objetivos: Validar e instalar el sistema en el ambiente de producción. Ciclo de vida: Transición AUP

45 Fases e hitos AUP Elab.Cons.Tran. Objetivos del ciclo de vida (LCO) Inicio Arquitectura del ciclo de vida (LCA) Capacidad operacional inicial (IOC) Lanzamiento del producto (PR)

46 Inicio Definir alcance del proyecto Estimar costos y plazos Definir riesgos Determinar factibilidad del proyecto Preparar el ambiente Fases e hitos AUP Objetivos del ciclo de vida (LCO) Acuerdo del alcance Def. inicial de reqs. Acuerdo del plan Aceptación de riesgos Aceptación del proceso Factibilidad Plan del proyecto Conformidad de la lista

47 Elaboración Identificar arquitectura Validar la arquitectura Desarrollar el ambiente el proyecto Equipo del personal del proyecto Fases e hitos AUP Arquitectura del ciclo de vida (LCA) Estabilidad de la visión Estabilidad de la arquitectura Aceptación de riesgos Factibilidad Plan de proyecto Conformidad con la empresa

48 Construcción Modelado, construcción y testeo del sistema Creado de documentación de apoyo Fases e hitos AUP Capacidad operacional inicial (IOC) Estabilidad del sistema Stakeholders preparados Aceptación de riesgos Plan de proyecto Conformidad con la empresa

49 Transición Test del sistema Test de usuarios Retrabajo del sistema Instalación del sistema Fases e hitos AUP Lanzamiento del producto (PR) Aceptación por los stakeholders del negocio Aceptación de operaciones Aceptación de soporte Aceptación de costo y estimaciones

50 Definen actividades que el equipo de desarrolladores debe realizar para construir, validar y entregar un software que satisfaga las necesidades de los stakeholders.  Modelado  Implementación  Testeo  Deployment  Configuration Management  Project Management  Environment Disciplinas

51 Modelado  El objetivo de esta disciplina es comprender el negocio de la organización, comprender el dominio del problema abordado por el proyecto, e identificar una solución al mismo que sea viable. Modelado

52  No es necesario mucho detalle durante las fases de inicio y elaboración.  Model storming se realiza en el momento para obtener los detalles necesarios.  El objetivo es crear modelos con la profundidad necesaria para lo que se está haciendo.  La mayor parte de los modelos se descarta.  Siempre hay que tener en cuenta oportunidades de reuso.  La participación activa de los stakeholders es fundamental para el éxito.  Se recomienda la arquitectura en capas. Recomendaciones

53 Agile Model Driven Development

54 Modelado Fase a Fase Inicio Explorar la utilización del producto escribiendo casos de uso. Identificar los procesos de negocio por medio de la creación de diagramas de flujo de datos. Identificar las principales entidades de negocio y sus relaciones. Identificar las principales reglas de negocio y los principales requerimientos técnicos. Comenzar el desarrollo de un glosario que contenga los términos importantes técnicos y del negocio.

55 Elaboración Identificar riesgos técnicos. Modelado de la arquitectura. Realizar un prototipo de la interfaz de usuario. Modelado Fase a Fase

56 Construcción Participación activa del stakeholder y modelado inclusivo. Mostrar los detalles de los casos de uso. Explorar reglas de negocios y requerimientos técnicos con la misma profundidad. Aplicar model storming para el diseño. Puede resultar útil realizar diagramas de secuencia UML, modelo de deployment, diagramas de clase UML, modelo de seguridad frente a amenazas, modelos de datos físicos. Documentar las decisiones de diseño críticas. Modelado Fase a Fase

57 Transición Aplicar model storming para intentar comprender la causa de defectos detectados. Finalizar la documentaci ó n general del sistema. Modelado Fase a Fase

58 Implementación Objetivo Transformar el modelo realizado en código ejecutable y realizar tests de nivel básico, en particular tests unitarios. Consejos Programación por pares Desarrollo dirigido por tests (TDD) Modelar antes de codificar Seguir guías y estándares de codificación Rescribir el código y los esquemas de base de datos Tener ambientes de desarrollo separados (sandboxes)

59 Inicial Prototipo Técnico Elaboración Probar la arquitectura Construcción Testear primero Realizar builds continuamente Desarrollar la lógica del dominio Desarrollar la interfaz grafica Desarrollar el esquema de datos Desarrollar interfaces para sistemas externos Escribir scripts para conversión de datos Transición Corregir defectos Implementación - Fases

60 Implementación - TDD Objetivo Escribir código claro y limpio Enfoque Se debe testear con un propósito, y saber porque se esta testeando y hasta que nivel testearlo TDD Escribir el test Escribir el código para satisfacer el test Rescribir el código

61 Objetivo Realizar una evaluación objetiva para asegurar la calidad. Esto incluye buscar defectos, validar que el sistema funcione como debería, y verificar que se cumplen los requerimientos. Consejos Realizar test durante el ciclo de vida (FLOOT) Desarrollo dirigido por tests (TDD) Automatizar el test suite Realizar practicas que promuevan la revisión continua Si vale la pena crearlo, vale la pena validarlo Realizar test de aceptación para los requerimientos y los artefactos de testeo Test

62 Test - FLOOT

63 Inicio Plan de testeo inicial Realizar una revisión de los artefactos iniciales de la administración del proyecto Realizar una revisión de los modelos iniciales Elaboración Validar la arquitectura Desarrollar el modelo de testeo Construcción Testear el software Desarrollar el modelo de testeo Transición Validar el sistema Validar la documentación Finalizar el modelo de testeo Test - Fases

64 Objetivo Planificar la liberación del sistema. Sugerencias: Desarrollar los scripts de instalación/desinstalación durante la fase de construcción. Tener un área de pre-producción donde poder validar el sistema antes de la liberación. Deployment

65 Tener en mente los periodos de pausa en la organización, ya que en estos periodos no se podrá realizar la liberación. Definir puntos de decisión (seguir/no seguir). Ser capas de desinstalar el sistema si surgen problemas. Realizar testeo de scripts instalación/desinstalación. Deployment

66

67 Deployment Fases Inicial: - Identificar la liberación potencial. - Comienzo de la planificación de la liberación. Elaboración: - Actualizar el plan de liberación.

68 Deployment Fases Construcción: - Desarrollo de los scripts. - Desarrollo de las notas de liberación. - Desarrollo inicial de la documentación. - Actualización del plan. - Liberación pre-producción.

69 Deployment Fases Transición: - Finalización del empaquetado del sistema. - Finalización de la documentación. - Anuncio de la liberación. - Entrenamiento del personal.

70 AUP define los siguientes: DBA, administrador de bases de datos Agile Modeler, responsable de crear y desarrollar modelos. Configuration Manager, responsable de proveer toda la infraestructura necesaria para el equipo de desarrollo. Deployer, responsable de la liberación del sistema. Roles y Responsabilidades 1

71 Developer, escribe, realiza pruebas unitarias y construye el software. Process Engineer, desarrolla, adapta y mantiene el proceso de software de la organización. Project Manager Reviewer, evalua los artefactos generados por el proyecto. Roles y Responsabilidades 2

72 Stakeholder Technical Writer, responsable de producir la documentación para los stakeholders, documentación operacional, de soporte y para usuarios. Test Manager, responsable de la planificación del testeo del sistema. Tester, responsable de escribir y ejecutar las pruebas. Roles y Responsabilidades 3

73 Tool Specialist, responsable de seleccionar, adquirir, configurar las herramientas a utilizar. Un mismo rol puede ser asumido por varias personas. Una persona puede asumir varios roles. Roles y Responsabilidades 4

74 Entregables Consejos –Mantener los entregables tan simples y concisos como se pueda. –Se necesita mucha menos documentación de la que se piensa. –Trabajar conjuntamente con la gente que crea los entregables, para producir sólo lo necesario. –Documentos ágiles son justo lo suficientemente buenos. –Producir documentos es la peor manera de comunicar la información. –Utilizar pizarrones, papel y Wikis para modelar y capturar la documentación.

75 Entegables Minimos Sistema Código Fuente Casos de Testeo Scripts de Instalación Documentación del Sistema Release Notes Modelo de Requerimientos –Test de Aceptación, Procesos de Negocio, Dominio, Casos de Uso, Interfaz de Usuario Modelo de Diseño –El mejor lugar para documentar el diseño es en los test unitarios y en el código fuente

76 Otros… Oportunidades de Automatización –Una lista Reportes de Defectos –Un mail o una planilla Excel Modelo de Interfaz de Usuario –Un papel o una pizarra

77

78 Filosofía Los integrantes saben lo que hacen. Simple –Todo es Conciso Ágil Mantener el foco en las actividades de alto valor. Independiente de la Herramienta –Brinda soporte a herramientas CASE Customizable

79 Y Entonces… Casos de Éxito ? “AUP no es para todos, ningún proceso lo es. AUP es adecuado si se busca una versión ágil y racionalizada del Unified Process.”

80 ¿ Preguntas ?