Procesos Agiles (1).ppt

7/27/2019 Procesos Agiles (1).ppt

1/80

Procesos

giles


2/80

Contenido

Introduccin Contexto Manifiesto gil Reflexiones FDD Scrum Open-source AUP


3/80

Introduccin


4/80

Contexto

Nandhakumar & Avison 1999 Metodologas tradicionales de desarrollo de sistemas de

informacin son tratadas principalmente como una ficcinnecesaria para presentar una imagen de control o para

proveer un estatus simblico. Truex et al. 2000

Es posible que los mtodos tradicionales sean meramenteideales inalcanzables y hipotticos straw-men que proveenuna 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 proyectode software quedan congelados antes de que el diseo y

desarrollo del software comience.


5/80

Manifiesto por el Desarrollo gil

Estamos descubriendo mejores maneras de desarrollarsoftware tanto por nuestra propia experiencia comoayudando a terceros. A travs de esta experiencia hemosaprendido a valorar:

Individuos e interacciones sobreprocesos y herramientas Software que funciona sobre documentacin exhaustiva Colaboracin con el cliente sobre negociacin decontratos 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 laizquierda.

http://www.agilemanifesto.org
http://www.agilemanifesto.org/http://www.agilemanifesto.org/


6/80

Principios

Nuestra mayor prioridad es satisfacer al cliente a travs de laentrega 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
http://www.agilemanifesto.org/principles.htmlhttp://www.agilemanifesto.org/principles.html


7/80

Reflexiones

Highsmith & Cockburn 2001 lo que es nuevo en los procesos giles no

son las prcticas que usan, sino quereconozcan a las personas como primerosimplicados en el xito de un proyecto,adems de un intenso foco en la efectividad

y la manejabilidad. Esto genera una nuevacombinacin de valores y principios quedefinen una visin gildel mundo.


8/80

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 deberaidentificar la naturaleza especifica de cadaproyecto y seleccionar la mejor metodologa dedesarrollo aplicable.

McCauley 2001 Hay una necesidad de ambos mtodos [giles yorientados a procesos] ya que no hay un modelode desarrollo que se ajuste a todos lospropsitos imaginables.


9/80

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.


10/80

FDD Es un proceso gil diseado por Peter Coad, Eric

Lefebvre y Jeff DeLuca.

Se basa en un proceso iterativo con iteracionescortas que producen un software funcional queel cliente y la direccin de la empresa puedenver y monitorizar.

Las iteraciones se deciden en base a features ofuncionalidades, que son pequeas partes delsoftware con significado para el cliente.

Feature Driven Development


11/80

Feature Driven Development

A diferencia de otros procesos giles no cubretodo el ciclo de vida sino slo las fases dediseo y construccin.

No requiere un modelo especfico de proceso yse complementa con otras metodologas. Enfatiza cuestiones de calidad y define

claramente entregas tangibles y formas de

evaluacin del progreso.


12/80

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


13/80

Proceso 1FDD


14/80

FDD consiste en cinco procesos secuencialesdurante los cuales se disea y construye elsistema.

La parte iterativa soporta desarrollo gil conrpidas adaptaciones a cambios enrequerimientos y necesidades del negocio.

Cada fase del proceso tiene un criterio deentrada, tareas, pruebas y un criterio de salida.

Proceso 2FDD


15/80

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 aconstruir. A esta altura se espera que existan requerimientos talescomo 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 amplialista de rasgos. Estos rasgos son pequeos tems tiles a los ojosdel cliente. La lista de rasgos es revisada por los usuarios ypatrocinadores para asegurar su validez y exhaustividad, los rasgosque requieran de ms de diez das se descomponen en otros mspequeos.

Proceso Fases 1FDD


16/80

Planeamiento por rasgos:

Incluye la creacin de un plan de alto nivel, en el que los conjuntosde rasgos se ponen en secuencia conforme a su prioridad y dependencia, yse asigna a los programadores jefes.

Diseo por rasgos y Construccin por rasgos:

Se selecciona un pequeo conjunto de rasgos del conjunto, y lospropietarios de clases seleccionan los correspondientes equipos dispuestos

por rasgos. Se procede luego iterativamente hasta que se producen losrasgos seleccionados. Una iteracin puede tomar de unos pocos das unmximo de dos semanas. El proceso iterativo incluye inspeccin de diseo,codificacin, pruebas unitarias, integracin e inspeccin de cdigo.

Proceso Fases 2FDD


17/80

Algunos agilistas sienten que FDD es demasiadojerrquico para ser un mtodo gil, porque demanda unprogramador jefe, quien dirige a los propietarios declases, quienes dirigen equipos de rasgos.

Otros crticos sienten que la ausencia deprocedimientos detallados de prueba en FDDes llamativa e impropia.

FDD se utiliz por primera vez en grandes aplicacionesbancarias a fines de la dcada de 1990. Los autoressugieren su uso para proyectos nuevos o actualizacionesde sistemas existentes y recomiendan adoptarlo enforma gradual.

Experiencias en su uso


18/80

"The New Product Development Game" (Harvard BusinessReview 86116:137-146, 1986)

"The Knowledge Creating Company" Ikujiro Nonaka y HirotakaTakeuchi (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.

OrgenesSCRUM


19/80

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 gilpara la liberacin de los proyectos

Usado para proyectos complejos con requerimientoscambiantes

Basado en un control de proceso emprico

CaractersticasSCRUM


20/80

Es tpico adoptar un enfoque de modelado definido(terico) cuando los mecanismos subyacentes por el cualel proceso opera son razonablemente bien entendidos.Cuando el proceso es demasiado complicado para elenfoque definido, el enfoque emprico es la eleccinapropiada.

Process Dynamics, Modeling and Control

B. A. Ogunnaike y W.H. Ray,

Bases Visibilidad

Inspeccin

Adaptacin

Control de proceso emprico


21/80

Esqueleto de SCRUM Proceso iterativo e

incremental

Estructura

Corazn de SCRUMIteraciones

SCRUM


22/80

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

Sprint

Reunin de planeamiento del Sprint (< 8hs)

Primeras 4hs

Requerimientos a realizarse en el sprint

Segundas 4hs

Plan de trabajo del sprint

SCRUM


23/80

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 vidaSCRUM


24/80

Ciclo de vida


25/80

Product owner (dueo del producto)

Team (equipo)

ScrumMaster

RolesSCRUM


26/80

Product backlog

Sprint backlog

Incremento de una

funcionalidad

del producto

potencialmentedespachable

ArtefactosSCRUM


27/80

Microsoft ha combinado los modelos de trabajo gilesScrum y Extreme programming para finalizar ellanzamiento de las nuevas versiones: SQL Server2005, Visual Studio 2005 tool suite y Biztalk server

2006 integration server

Experiencia en su usoSCRUM
http://www.eweek.com/article2/0,1895,1882143,00.asphttp://www.eweek.com/article2/0,1895,1882143,00.asp


28/80

El trmino refiere en principio a una forma delicencia que debe tener fundamentalmente lassiguientes caractersticas:

Libre redistribucin.

Cdigo fuente abierto.

La redistribucin de modificaciones debe estarpermitida.

Open-source


29/80

ProcesoTpicamente un proyecto open-source contienelas 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


30/80

Caractersticas del ProcesoLos siguientes factores caracterizan al procesode 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 esencialpara el desarrollo open-source.

El sistema aumenta en pequeos incrementos. Los programas son testeados frecuentemente.


31/80

Una tpica estructura de desarrollo open-sourceest compuesta por varios tipos de voluntarios.

Lderes de Proyecto, son quienes tienen la

responsabilidad general del proyecto y usualmente hanescrito el cdigo inicial.

Desarrolladores voluntarios, crean y envan cdigo parael proyecto.

Personas que identifican bugs y envan reportes deproblemas al usar el software.

Personas que participan de newsgroups y foros dediscusin.

Roles y Responsabilidades


32/80

Diferencias

Open-source opera generalmente en formageogrficamente distribuida. En tanto que, los mtodos

giles tradicionales recomiendan grupos de desarrollopequeos 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


33/80

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


34/80

Se ha argumentado que open-sourcedifiere delos procesos giles en aspectos filosficos,econmicos y de estructura de equipos.

Sin embargo, el proceso de desarrollo open-source resulta bastante cercano al de losprocesos giles.

Organizaciones dispersas geogrfica yculturalmente podran beneficiarse de lasventajas del paradigma open-source.

ConclusionesOSS


35/80

Qu es? Cundo y cmo surge?

Ciclo de vida. Fases e hitos.

AUP
http://www.ambysoft.com/scottAmbler.html


36/80


37/80

1988: Objectory 1.0 1998: RUP 5.0

Feb/2004: EUP Sep/2005: AUP 13/5/2006: v1.1 AUP

Cundo surge?AUP


38/80

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


39/80

Ciclo de VidaAUP


40/80

Inicio Elaboracin

Construccin Transicin

Ciclo de vidaAUP


41/80

Objetivos: Identificar el alcance inicialdel proyecto, proveer una arquitecturapotencial para el sistema, y obtener un

financiamiento inicial del proyecto y laaceptacin de los stakeholders.

Ciclo de vida: InicioAUP


42/80

Objetivos: Probar la arquitectura delsistema; hacer un prototipo dearquitectura que elimine los riesgos

tcnicos para probar que el proyecto esfactible.

Ciclo de vida: ElaboracinAUP


43/80

Objetivos: De forma regular eincremental, construir software quefuncione y satisfaga las necesidades de

mayor prioridad de los stakeholders delproyecto.

Ciclo de vida: ConstruccinAUP


44/80

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

Ciclo de vida: TransicinAUP


45/80

Fases e hitosAUP

Elab. Cons. Tran.

Objetivos

del ciclo devida (LCO)

Inicio

Arquitectura

del ciclo devida (LCA)

Capacidad

operacionalinicial (IOC)

Lanzamiento

del producto(PR)


46/80

Inicio Definir alcance del

proyecto

Estimar costos y plazos Definir riesgos

Determinar factibilidaddel proyecto

Preparar el ambiente

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


47/80

Elaboracin Identificar arquitectura

Validar la arquitectura

Desarrollar el ambienteel proyecto

Equipo del personal delproyecto

Fases e hitosAUP

Arquitectura del ciclode vida (LCA)

Estabilidad de la visin

Estabilidad de laarquitectura

Aceptacin de riesgos

Factibilidad Plan de proyecto

Conformidad con laempresa


48/80

Construccin Modelado, construccin

y testeo del sistema

Creado dedocumentacin deapoyo

Fases e hitosAUP

Capacidad operacionalinicial (IOC)

Estabilidad del sistema Stakeholders preparados

Aceptacin de riesgos

Plan de proyecto

Conformidad con laempresa


49/80

Transicin Test del sistema

Test de usuarios

Retrabajo del sistema Instalacin del sistema

Fases e hitosAUP

Lanzamiento delproducto (PR)

Aceptacin por los

stakeholders delnegocio

Aceptacin deoperaciones

Aceptacin de soporte

Aceptacin de costo yestimaciones


50/80

Definen actividades que el equipo de desarrolladoresdebe realizar para construir, validar y entregar unsoftware que satisfaga las necesidades de losstakeholders.

Modelado Implementacin Testeo Deployment

Configuration Management Project Management Environment

Disciplinas

d l d


51/80

Modelado El objetivo de esta disciplina es comprender el

negocio de la organizacin, comprender el

dominio del problema abordado por elproyecto, e identificar una solucin al mismoque sea viable.

Modelado

R d i


52/80

No es necesario mucho detalle durante las fases deinicio 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

A il M d l D i D l


53/80

Agile Model Driven Development

M d l d F F


54/80

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.

M d l d F F


55/80

Elaboracin

Identificar riesgos tcnicos.

Modelado de la arquitectura.

Realizar un prototipo de la interfaz de usuario.


M d l d F F


56/80

Construccin Participacin activa del stakeholder y modeladoinclusivo.

Mostrar los detalles de los casos de uso.

Explorar reglas de negocios y requerimientos tcnicoscon 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 dedatos fsicos.

Documentar las decisiones de diseo crticas.


M d l d F F


57/80

Transicin

Aplicar model storming para intentar comprender la

causa de defectos detectados.

Finalizar la documentacin general del sistema.


I l t i


58/80

Implementacin Objetivo

Transformar el modelo realizado en cdigo ejecutable yrealizar 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)

I l t i F


59/80

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

I l t i TDD


60/80

Implementacin - TDD Objetivo

Escribir cdigo claro y limpio

Enfoque

Se debe testear con un

propsito, y saber porque seesta testeando y hasta que niveltestearlo

TDD

Escribir el test

Escribir el cdigo para satisfacerel test

Rescribir el cdigo

T t


61/80

Objetivo

Realizar una evaluacin objetiva para asegurar la calidad.Esto incluye buscar defectos, validar que el sistema funcionecomo 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 losartefactos de testeo

Test

T t FLOOT


62/80

Test - FLOOT

T t F


63/80

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

Deplo ment


64/80

ObjetivoPlanificar la liberacin del sistema.

Sugerencias:

Desarrollar los scripts de instalacin/desinstalacindurante la fase de construccin.

Tener un rea de pre-produccin donde poder validarel sistema antes de la liberacin.

Deployment

Deployment


65/80

Tener en mente los periodos de pausa en laorganizacin, ya que en estos periodos no sepodr realizar la liberacin.

Definir puntos de decisin (seguir/no seguir) .

Ser capas de desinstalar el sistema si surgenproblemas.

Realizar testeo de scriptsinstalacin/desinstalacin.

Deployment

Deployment


66/80

Deployment

Deployment Fases


67/80

Deployment Fases

Inicial:

- Identificar la liberacin potencial.

- Comienzo de la planificacin de laliberacin.

Elaboracin:

- Actualizar el plan de liberacin.

Deployment Fases


68/80

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


69/80

Deployment Fases

Transicin:- Finalizacin del empaquetado del

sistema.

- Finalizacin de la documentacin.- Anuncio de la liberacin.

- Entrenamiento del personal.

Roles y Responsabilidades 1


70/80

AUP define los siguientes:

DBA, administrador de bases de datos

Agile Modeler, responsable de crear y desarrollarmodelos.

Configuration Manager, responsable de proveer toda la

infraestructura necesaria para el equipo de desarrollo.

Deployer, responsable de la liberacin del sistema.




71/80

Developer, escribe, realiza pruebas unitariasy construye el software.

Process Engineer, desarrolla, adapta y mantiene elproceso de software de la organizacin.

Project Manager

Reviewer, evalua los artefactos generados por el

proyecto.




72/80

Stakeholder

Technical Writer, responsable de producir ladocumentacin para los stakeholders, documentacin

operacional, de soporte y para usuarios.

Test Manager, responsable de la planificacin deltesteo del sistema.

Tester, responsable de escribir y ejecutar las pruebas.




73/80

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


74/80

Entregables

Consejos Mantener los entregables tan simples y concisoscomo se pueda.

Se necesita mucha menos documentacin de la quese piensa.

Trabajar conjuntamente con la gente que crea losentregables, para producir slo lo necesario.

Documentos giles son justo lo suficientementebuenos.

Producir documentos es la peor manera decomunicar la informacin.

Utilizar pizarrones, papel y Wikis para modelar ycapturar la documentacin.


75/80

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


76/80

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


77/80


78/80

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 E


79/80

Y Entonces

Casos de xito ?

AUP no es para todos, ningn proceso lo

es. AUP es adecuado si se busca unaversin gil y racionalizada del UnifiedProcess.

Preguntas ?


80/80

Preguntas ?

Procesos Agiles (1).ppt

Documents

Transcript of Procesos Agiles (1).ppt