Procesos

giles
www.fing.edu.uy/inco/cursos/gestsoft/Presentaciones/Procesos%20Agile
s%20-%20G4/Procesos%20Agiles.ppt
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.

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
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 define tres categoras 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 tcnicos

FDD Roles
Proceso 1 FDD
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.
Proceso 2
FDD
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.
Proceso Fases 1
FDD
Planeamiento por rasgos:
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.
Proceso Fases 2 FDD

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.
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).
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.
Orgenes
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 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
Caractersticas
SCRUM
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
Control de proceso emprico

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
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
Ciclo de vida
Product owner (dueo del producto)

Team (equipo)

ScrumMaster
Roles
SCRUM
Product backlog

Sprint backlog

Incremento de una
funcionalidad
del producto
potencialmente
despachable

Artefactos
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
Experiencia en su uso
SCRUM
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.
Open-source
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.
OSS
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.
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.
Roles y Responsabilidades
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.
Open-Source vs. Procesos giles
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 open-
source resulta bastante cercano al de los
procesos giles.

Organizaciones dispersas geogrfica y
culturalmente podran beneficiarse de las
ventajas del paradigma open-source.
Conclusiones
OSS
Qu es?
Cundo y cmo surge?
Ciclo de vida.
Fases e hitos.

AUP
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 Qu es?
1988: Objectory 1.0
1998: RUP 5.0
Feb/2004: EUP
Sep/2005: AUP
13/5/2006: v1.1 AUP
Cundo surge? AUP
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

Cmo surge? AUP
Ciclo de Vida AUP
Inicio
Elaboracin
Construccin
Transicin

Ciclo de vida AUP
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.
Ciclo de vida: Inicio AUP
Objetivos: Probar la arquitectura del
sistema; hacer un prototipo de
arquitectura que elimine los riesgos
tcnicos para probar que el proyecto es
factible.
Ciclo de vida: Elaboracin AUP
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: Construccin AUP
Objetivos: Validar e instalar el sistema en
el ambiente de produccin.


Ciclo de vida: Transicin AUP
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)
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
Aceptacin de riesgos
Aceptacin del proceso
Factibilidad
Plan del proyecto
Conformidad de la lista

Elaboracin
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 visin
Estabilidad de la
arquitectura
Aceptacin de riesgos
Factibilidad
Plan de proyecto
Conformidad con la
empresa
Construccin
Modelado, construccin
y testeo del sistema
Creado de
documentacin de
apoyo

Fases e hitos AUP
Capacidad operacional
inicial (IOC)
Estabilidad del sistema
Stakeholders preparados
Aceptacin de riesgos
Plan de proyecto
Conformidad con la
empresa
Transicin
Test del sistema
Test de usuarios
Retrabajo del sistema
Instalacin del sistema
Fases e hitos AUP
Lanzamiento del
producto (PR)
Aceptacin por los
stakeholders del
negocio
Aceptacin de
operaciones
Aceptacin de soporte
Aceptacin 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
Implementacin
Testeo
Deployment
Configuration Management
Project Management
Environment

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

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

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

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.


Modelado Fase a Fase
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)
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 - Fases
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
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
Test - FLOOT
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
Test - Fases
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



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.


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 1
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 2
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 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 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 ?