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

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

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

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.

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

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

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

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 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 Role

s

Proceso 1FDD

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

• 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

• 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

• 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

• "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ígenesSCRUM

• 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ísticasSCRUM

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

• 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 (< 8hs)

•Primeras 4hs•Requerimientos a realizarse en el sprint

•Segundas 4hs•Plan de trabajo del sprint

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

Ciclo de vidaSCRUM

Ciclo de vida

• Product owner (dueño del producto)

• Team (equipo)

• ScrumMaster

RolesSCRUM

• Product backlog

• Sprint backlog

• Incremento de una funcionalidad del producto potencialmente despachable

ArtefactosSCRUM

• 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

Experiencia en su usoSCRUM

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

ProcesoTí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

Características del ProcesoLos 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.

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

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.

Open-Source vs. Procesos Ágiles

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

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

AUP

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

• 1988: Objectory 1.0• 1998: RUP 5.0• Feb/2004: EUP• Sep/2005: AUP• 13/5/2006: v1.1 AUP

Cuándo 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

Cómo surge?AUP

Ciclo de VidaAUP

• Inicio• Elaboración• Construcción• Transición

Ciclo de vidaAUP

• 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: InicioAUP

• 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ónAUP

• 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ónAUP

• Objetivos: Validar e instalar el sistema en el ambiente de producción.

Ciclo de vida: TransiciónAUP

Fases e hitosAUP

Elab. Cons. Tran.

Objetivos del ciclo de vida (LCO)

Inicio

Arquitectura del ciclo de vida (LCA)

Capacidad operacional inicial (IOC)

Lanzamiento del producto (PR)

Inicio• Definir alcance del

proyecto• Estimar costos y

plazos• Definir riesgos• Determinar factibilidad

del proyecto• Preparar el ambiente

Fases e hitosAUPObjetivos 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

Elaboración• Identificar

arquitectura• Validar la

arquitectura• Desarrollar el

ambiente el proyecto• Equipo del personal

del proyecto

Fases e hitosAUP

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

Construcción• Modelado,

construcción y testeo del sistema

• Creado de documentación de apoyo

Fases e hitosAUP

Capacidad operacional inicial

(IOC)• Estabilidad del sistema• Stakeholders

preparados• Aceptación de riesgos• Plan de proyecto• Conformidad con la

empresa

Transición• Test del sistema• Test de usuarios• Retrabajo del sistema• Instalación del

sistema

Fases e hitosAUP

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

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

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

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

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.

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.

Modelado Fase a Fase

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)

• 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

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

• 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

Test - FLOOT

• 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

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

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.

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

• 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

• 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

• 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

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 ?