Procesos giles Contenido Introduccin Contexto Manifiesto gil Reflexiones

Procesos Ágiles

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

Introducción

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. ” • Mc. Cauley 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.

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 que están a la izquierda. http: //www. agilemanifesto. org

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

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. ”

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. • Mc. Cauley 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.

¿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.

Feature Driven Development FDD • Es un proceso ágil diseñado por Peter Coad, Eric Lefebvre y Jeff De. Luca. • 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 • 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.

FDD Roles 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 Proceso 1

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

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

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

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.

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

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

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

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

SCRUM 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 (< 8 hs) • Primeras 4 hs • Requerimientos a realizarse en el sprint • Segundas 4 hs • Plan de trabajo del sprint

SCRUM Ciclo de vida • Daily sprint (< 15 min) • ¿ 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 (< 4 hs) • Presentación de lo desarrollado durante el sprint • Sprint Retrospective (< 3 hs) • Revisión y análisis del proceso de desarrollo

Ciclo de vida

SCRUM • Product owner (dueño del producto) • Team (equipo) • Scrum. Master Roles

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

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

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.

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

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.

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.

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.

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.

OSS Conclusiones 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 opensource resulta bastante cercano al de los procesos ágiles. Organizaciones dispersas geográfica y culturalmente podrían beneficiarse de las ventajas del paradigma open-source.

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

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

AUP • • • 1988: Objectory 1. 0 1998: RUP 5. 0 Feb/2004: EUP Sep/2005: AUP 13/5/2006: v 1. 1 AUP Cuándo surge?

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

AUP Ciclo de Vida

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

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

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

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

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

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

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

AUP Elaboración • Identificar arquitectura • Validar la arquitectura • Desarrollar el ambiente el proyecto • Equipo del personal del proyecto Fases e hitos 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

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

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

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

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.

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

Agile Model Driven Development

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.

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

Modelado Fase a Fase 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 Transición • Aplicar model storming para intentar comprender la causa de defectos detectados. • Finalizar la documentación general del sistema.

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)

Implementación - Fases • 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 - 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

Test • 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 - FLOOT

Test - Fases • 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

Deployment 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 • 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

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.

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.

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

Roles y Responsabilidades 1 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 2 • 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 3 • 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 4 • 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.

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.

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

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

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

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. ”

¿ Preguntas ?