Procesos giles

Contenido
Introduccin Contexto Manifiesto gil Reflexiones FDD Scrum Open-source AUP

Introduccin

Contexto
Nandhakumar & Avison 1999
Metodologas tradicionales de desarrollo de sistemas de informacin son tratadas principalmente como una ficcin necesaria para presentar una imagen de control o para proveer un estatus simblico.

Truex et al. 2000

Es posible que los mtodos tradicionales sean meramente ideales inalcanzables y hipotticos straw-men que proveen una gua normativa a situaciones de desarrollo utpicas.

McCauley 2001
La filosofa en la cual se basan los mtodos orientados a procesos establece que los requerimientos de un proyecto de software quedan congelados antes de que el diseo 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 travs de esta experiencia hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Software que funciona sobre documentacin exhaustiva Colaboracin con el cliente sobre negociacin 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 estn a la izquierda.
http://www.agilemanifesto.org

Principios
Nuestra mayor prioridad es satisfacer al cliente a travs 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. Conversacin cara a cara. Software que funciona es la principal medida de progreso. Los procesos giles promueven el desarrollo sostenible. La atencin continua a la excelencia tcnica y los buenos diseos mejoran la agilidad. Simplicidad es esencial. Las mejores arquitecturas, requisitos y diseos surgen de equipos que se auto-organizan. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo.
http://www.agilemanifesto.org/principles.html

Reflexiones
Highsmith & Cockburn 2001
lo que es nuevo en los procesos giles no son las prcticas que usan, sino que reconozcan a las personas como primeros implicados en el xito de un proyecto, adems de un intenso foco en la efectividad y la manejabilidad. Esto genera una nueva combinacin de valores y principios que definen una visin gil del mundo.

Reflexiones (2)
Hawrysh & Ruprecht 2000
Una sola metodologa no puede funcionar para todo el espectro de proyectos, en vez de eso el administrador de cada proyecto debera identificar la naturaleza especifica de cada proyecto y seleccionar la mejor metodologa de desarrollo aplicable.

McCauley 2001
Hay una necesidad de ambos mtodos [giles y orientados a procesos] ya que no hay un modelo de desarrollo que se ajuste a todos los propsitos imaginables.

Cuando un mtodo es gil?

El desarrollo de software es
Incremental
liberaciones pequeas y ciclos rpidos.

Cooperativo
clientes y desarrolladores trabajando juntos.

Simple y Directo
el mtodo es fcil de aprender y modificar.

Adaptativo
es posible realizar cambios de ltimo momento.

Feature Driven Development

FDD Es un proceso gil diseado 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 direccin de la empresa pueden ver y monitorizar. Las iteraciones se deciden en base a features o funcionalidades, que son pequeas 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 slo las fases de diseo y construccin. No requiere un modelo especfico de proceso y se complementa con otras metodologas. Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluacin del progreso.

FDD
FDD define tres categoras de roles: Roles claves

Roles
- 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 tcnicos

FDD

Proceso 1

FDD

Proceso 2

FDD consiste en cinco procesos secuenciales durante los cuales se disea y construye el sistema. La parte iterativa soporta desarrollo gil con rpidas 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 estn al tanto de la visn, 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.

Construccin de la lista de rasgos:

Los ensayos, modelos de objeto y documentacin de requerimientos proporcionan la base para construir una amplia lista de rasgos. Estos rasgos son pequeos 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 ms de diez das se descomponen en otros ms pequeos.

FDD
Planeamiento por rasgos:

Proceso Fases 2

Incluye la creacin 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.

Diseo por rasgos y Construccin por rasgos:

Se selecciona un pequeo 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 iteracin puede tomar de unos pocos das un mximo de dos semanas. El proceso iterativo incluye inspeccin de diseo, codificacin, pruebas unitarias, integracin e inspeccin de cdigo.

Experiencias en su uso
Algunos agilistas sienten que FDD es demasiado jerrquico para ser un mtodo gil, porque demanda un programador jefe, quien dirige a los propietarios de clases, quienes dirigen equipos de rasgos. Otros crticos 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 dcada de 1990. Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemas existentes y recomiendan adoptarlo en forma gradual.

SCRUM

Orgenes

"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). OOPSLA95 (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

Caractersticas

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 ingeniera pre-descriptas Utiliza reglas generales para crear un ambiente gil para la liberacin de los proyectos Usado para proyectos complejos con requerimientos cambiantes Basado en un control de proceso emprico

Control de proceso emprico

Es tpico adoptar un enfoque de modelado definido (terico) 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 emprico es la eleccin apropiada. Process Dynamics, Modeling and Control B. A. Ogunnaike y W.H. Ray, Bases Visibilidad Inspeccin Adaptacin

SCRUM
Esqueleto de SCRUM Proceso iterativo e incremental

Estructura
Corazn de SCRUM Iteraciones

SCRUM

Ciclo de vida

Todo el trabajo es realizado en Sprints (30 das) Durante el Sprint se realizan reuniones que constituyen la inspeccin emprica y las practicas de adaptacin de Scrum.

Sprint Reunin de planeamiento del Sprint (< 8hs) Primeras 4hs Requerimientos a realizarse en el sprint Segundas 4hs Plan de trabajo del sprint

SCRUM

Ciclo de vida

Daily sprint (< 15min) Qu has hecho en este proyecto desde el ultimo Daily sprint? Qu planeas hacer en el proyecto entre hoy y la prxima reunin Daily Scrum? Qu impedimentos se te han presentado para lograr lo prometido en el Sprint y proyecto? Sprint Review (< 4hs) Presentacin de lo desarrollado durante el sprint Sprint Retrospective (< 3hs) Revisin y anlisis del proceso de desarrollo

Ciclo de vida

SCRUM
Product owner (dueo del producto) Team (equipo) ScrumMaster

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 trmino refiere en principio a una forma de licencia que debe tener fundamentalmente las siguientes caractersticas:
Libre redistribucin. Cdigo fuente abierto.

La redistribucin de modificaciones debe estar permitida.

OSS

Proceso

Tpicamente un proyecto open-source contiene las siguientes fases:

Descubrimiento del problema. Bsqueda de desarrolladores voluntarios. Identificacin de la solucin. Implementacin y testeo. Revisin de cambios en el cdigo. Aprobacin del cdigo y de la documentacin. Liberacin del producto.

Estas fases se realizan en forma iterativa.

Caractersticas 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 funcin de su inters personal. No hay plan de proyecto, ni plazos, ni lista de entregables. Una buena divisin de las tareas es esencial para el xito del proyecto. Internet como herramienta de comunicacin es esencial para el desarrollo open-source. El sistema aumenta en pequeos incrementos. Los programas son testeados frecuentemente.

Roles y Responsabilidades
Una tpica estructura de desarrollo open-source est compuesta por varios tipos de voluntarios.
Lderes de Proyecto, son quienes tienen la responsabilidad general del proyecto y usualmente han escrito el cdigo inicial. Desarrolladores voluntarios, crean y envan cdigo para el proyecto. Personas que identifican bugs y envan reportes de problemas al usar el software. Personas que participan de newsgroups y foros de discusin.

Open-Source vs. Procesos giles

Diferencias
Open-source opera generalmente en forma geogrficamente distribuida. En tanto que, los mtodos giles tradicionales recomiendan grupos de desarrollo pequeos y geogrficamente cercanos. En open-source el cliente suele ser tambin 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. Cooperacin entre cliente y desarrollador. Open-source, no incluye ninguna norma de documentacin 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 filosficos, econmicos y de estructura de equipos. Sin embargo, el proceso de desarrollo opensource resulta bastante cercano al de los procesos giles. Organizaciones dispersas geogrfica y culturalmente podran beneficiarse de las ventajas del paradigma open-source.

AUP
Qu es? Cundo y cmo surge? Ciclo de vida. Fases e hitos.

AUP

Qu es?

Es una versin simplificada del RUP Aplica tcnicas 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: v1.1 AUP

Cundo surge?

AUP

Cmo surge?

Scott W. Ambler 1999: Cmo extender RUP? 2001: Cmo agilizar RUP? 2002: Publica Agile Modeling book
AM vs XP AM vs RUP

2004: EUP 2005: AUP

AUP

Ciclo de Vida

AUP
Inicio Elaboracin Construccin Transicin

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 aceptacin de los stakeholders.

AUP

Ciclo de vida: Elaboracin

Objetivos: Probar la arquitectura del sistema; hacer un prototipo de arquitectura que elimine los riesgos tcnicos para probar que el proyecto es factible.

AUP

Ciclo de vida: Construccin

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: Transicin

Objetivos: Validar e instalar el sistema en el ambiente de produccin.

AUP
Inicio Elab. Cons.

Fases e hitos
Tran.

Objetivos Arquitectura del ciclo de del ciclo de vida (LCO) vida (LCA)

Capacidad Lanzamiento operacional del producto inicial (IOC) (PR)

AUP
Inicio
Definir alcance del proyecto Estimar costos y plazos Definir riesgos Determinar factibilidad del proyecto Preparar el ambiente

Fases e hitos
Objetivos del ciclo de vida (LCO) Acuerdo del alcance Def. inicial de reqs. Acuerdo del plan Aceptacin de riesgos Aceptacin del proceso Factibilidad Plan del proyecto Conformidad de la lista

AUP
Elaboracin
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 visin Estabilidad de la arquitectura Aceptacin de riesgos Factibilidad Plan de proyecto Conformidad con la empresa

AUP
Construccin
Modelado, construccin y testeo del sistema Creado de documentacin de apoyo

Fases e hitos
Capacidad operacional inicial (IOC)
Estabilidad del sistema Stakeholders preparados Aceptacin de riesgos Plan de proyecto Conformidad con la empresa

AUP
Transicin
Test del sistema Test de usuarios Retrabajo del sistema Instalacin del sistema

Fases e hitos
Lanzamiento del producto (PR)
Aceptacin por los stakeholders del negocio Aceptacin de operaciones Aceptacin de soporte Aceptacin 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 Implementacin Testeo Deployment Configuration Management Project Management Environment

Modelado
Modelado
El objetivo de esta disciplina es comprender el negocio de la organizacin, comprender el dominio del problema abordado por el proyecto, e identificar una solucin al mismo que sea viable.

Recomendaciones
No es necesario mucho detalle durante las fases de inicio y elaboracin. 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 participacin activa de los stakeholders es fundamental para el xito. Se recomienda la arquitectura en capas.

Agile Model Driven Development

Modelado Fase a Fase

Inicio
Explorar la utilizacin del producto escribiendo casos de uso. Identificar los procesos de negocio por medio de la creacin 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 tcnicos. Comenzar el desarrollo de un glosario que contenga los trminos importantes tcnicos y del negocio.

Modelado Fase a Fase

Elaboracin
Identificar riesgos tcnicos. Modelado de la arquitectura. Realizar un prototipo de la interfaz de usuario.

Modelado Fase a Fase

Construccin
Participacin activa del stakeholder y modelado inclusivo. Mostrar los detalles de los casos de uso. Explorar reglas de negocios y requerimientos tcnicos con la misma profundidad. Aplicar model storming para el diseo. Puede resultar til realizar diagramas de secuencia UML, modelo de deployment, diagramas de clase UML, modelo de seguridad frente a amenazas, modelos de datos fsicos. Documentar las decisiones de diseo crticas.

Modelado Fase a Fase

Transicin
Aplicar model storming para intentar comprender la causa de defectos detectados. Finalizar la documentacin general del sistema.

Implementacin
Objetivo Transformar el modelo realizado en cdigo ejecutable y realizar tests de nivel bsico, en particular tests unitarios.

Consejos Programacin por pares Desarrollo dirigido por tests (TDD) Modelar antes de codificar Seguir guas y estndares de codificacin Rescribir el cdigo y los esquemas de base de datos Tener ambientes de desarrollo separados (sandboxes)

Implementacin - Fases
Inicial Prototipo Tcnico Elaboracin Probar la arquitectura Construccin Testear primero Realizar builds continuamente Desarrollar la lgica del dominio Desarrollar la interfaz grafica Desarrollar el esquema de datos Desarrollar interfaces para sistemas externos Escribir scripts para conversin de datos Transicin Corregir defectos

Implementacin - TDD
Objetivo Escribir cdigo claro y limpio Enfoque Se debe testear con un propsito, y saber porque se esta testeando y hasta que nivel testearlo TDD Escribir el test Escribir el cdigo para satisfacer el test Rescribir el cdigo

Test
Objetivo Realizar una evaluacin objetiva para asegurar la calidad. Esto incluye buscar defectos, validar que el sistema funcione como debera, 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 revisin continua Si vale la pena crearlo, vale la pena validarlo Realizar test de aceptacin para los requerimientos y los artefactos de testeo

Test - FLOOT

Test - Fases
Inicio Plan de testeo inicial Realizar una revisin de los artefactos iniciales de la administracin del proyecto Realizar una revisin de los modelos iniciales Elaboracin Validar la arquitectura Desarrollar el modelo de testeo Construccin Testear el software Desarrollar el modelo de testeo Transicin Validar el sistema Validar la documentacin Finalizar el modelo de testeo

Deployment
Objetivo Planificar la liberacin del sistema. Sugerencias:

Desarrollar los scripts de instalacin/desinstalacin durante la fase de construccin. Tener un rea de pre-produccin donde poder validar el sistema antes de la liberacin.

Deployment
Tener en mente los periodos de pausa en la organizacin, ya que en estos periodos no se podr realizar la liberacin. Definir puntos de decisin (seguir/no seguir) . Ser capas de desinstalar el sistema si surgen problemas. Realizar testeo de scripts instalacin/desinstalacin.

Deployment

Deployment Fases
Inicial: - Identificar la liberacin potencial. - Comienzo de la planificacin de la liberacin. Elaboracin: - Actualizar el plan de liberacin.

Deployment Fases
Construccin: - Desarrollo de los scripts. - Desarrollo de las notas de liberacin. - Desarrollo inicial de la documentacin. - Actualizacin del plan. - Liberacin pre-produccin.

Deployment Fases
Transicin:
- Finalizacin del empaquetado del sistema. - Finalizacin de la documentacin. - Anuncio de la liberacin. - 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 liberacin 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 organizacin. Project Manager Reviewer, evalua los artefactos generados por el proyecto.

Roles y Responsabilidades 3
Stakeholder Technical Writer, responsable de producir la documentacin para los stakeholders, documentacin operacional, de soporte y para usuarios. Test Manager, responsable de la planificacin 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 documentacin de la que se piensa. Trabajar conjuntamente con la gente que crea los entregables, para producir slo lo necesario. Documentos giles son justo lo suficientemente buenos. Producir documentos es la peor manera de comunicar la informacin. Utilizar pizarrones, papel y Wikis para modelar y capturar la documentacin.

Entegables Minimos
Sistema Cdigo Fuente Casos de Testeo Scripts de Instalacin Documentacin del Sistema Release Notes Modelo de Requerimientos
Test de Aceptacin, Procesos de Negocio, Dominio, Casos de Uso, Interfaz de Usuario

Modelo de Diseo
El mejor lugar para documentar el diseo es en los test unitarios y en el cdigo fuente

Otros
Oportunidades de Automatizacin
Una lista

Reportes de Defectos
Un mail o una planilla Excel

Modelo de Interfaz de Usuario

Un papel o una pizarra

Filosofa
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, ningn proceso lo es. AUP es adecuado si se busca una versin gil y racionalizada del Unified Process.

 Preguntas ?