Procesos Ágiles

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. Feature Driven Development 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.

11. Feature Driven Development • 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. Roles FDD 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

13. Proceso 1 FDD

14. Proceso 2 FDD • 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.

15. Proceso Fases 1 FDD • 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.

16. Proceso Fases 2 FDD • 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.

17. Experiencias en su uso • 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.

18. Orígenes SCRUM • "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.

19. Características SCRUM • 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

20. Control de proceso empírico • “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

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

22. Ciclo de vida SCRUM • 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

23. Ciclo de vida SCRUM • 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

24. Ciclo de vida

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

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

27. Experiencia en su uso SCRUM • 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 server

28. Open-source 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.

29. Proceso OSS 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.

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. Roles y Responsabilidades 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.

32. Open-Source vs. Procesos Ágiles 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.

33. Open-Source vs. Procesos Ágiles 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.

34. Conclusiones OSS Se ha argumentado que open-sourcedifiere 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.

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

36. AUP Qué es? • 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

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

38. Cómo surge? AUP 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

39. Ciclo de Vida AUP

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

41. Ciclo de vida: Inicio AUP • 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.

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

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

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

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

46. 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 Inicio • Definir alcance del proyecto • Estimar costos y plazos • Definir riesgos • Determinar factibilidad del proyecto • Preparar el ambiente

47. Fases e hitos AUP Elaboración • Identificar arquitectura • Validar la arquitectura • Desarrollar el ambiente el proyecto • Equipo del personal del proyecto 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. Fases e hitos AUP Construcción • Modelado, construcción y testeo del sistema • Creado de documentación de apoyo Capacidad operacional inicial (IOC) • Estabilidad del sistema • Stakeholders preparados • Aceptación de riesgos • Plan de proyecto • Conformidad con la empresa

49. Fases e hitos AUP Transición • Test del sistema • Test de usuarios • Retrabajo del sistema • Instalación del sistema 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. Disciplinas 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