Alternativas Alternativas metodológicasmetodológicas

Carlos ReynosoCarlos ReynosoUNIVERSIDAD DE BUENOS AIRESUNIVERSIDAD DE BUENOS AIRESbillyreyno@hotmail.combillyreyno@hotmail.comhttp://www.microsoft.com/spanish/msdn/http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/arquitectura_soft.mspxarquitectura/roadmap_arq/arquitectura_soft.mspx

AgendaAgenda

Alternativas de peso completo vs ágilesAlternativas de peso completo vs ágiles Contexto de situaciónContexto de situación Manifiesto ágilManifiesto ágil Métodos ágilesMétodos ágiles eXtreme Programming (XP)eXtreme Programming (XP) Otros métodos ágilesOtros métodos ágiles Métodos ágiles & MSF 3.0Métodos ágiles & MSF 3.0 Críticas a Métodos ÁgilesCríticas a Métodos Ágiles ConclusionesConclusiones http://www.microsoft.com/spanish/msdn/arquitecturahttp://www.microsoft.com/spanish/msdn/arquitectura

Paper

Tabla de Métodos Tabla de Métodos SEI/CMUSEI/CMU Architecture Tradeoff Analysis Method (ATAM)Architecture Tradeoff Analysis Method (ATAM) Quality Attribute Workshops (QAW)Quality Attribute Workshops (QAW) Attribute-Driven Design (ADD)Attribute-Driven Design (ADD) Active Reviews for Intermediate Designs (ARID)Active Reviews for Intermediate Designs (ARID) Cost-Benefit Analysis Method (CBAM)Cost-Benefit Analysis Method (CBAM) Software Architecture Comparison Analysis Software Architecture Comparison Analysis

Method (SACAM)Method (SACAM) Quality-Attribute-Driven Software Architecture Quality-Attribute-Driven Software Architecture

Reconstruction (QADSAR)Reconstruction (QADSAR) Architecture Based Design Method (ABD)Architecture Based Design Method (ABD) Software Architecture Analysis Method (SAAM)Software Architecture Analysis Method (SAAM)

Métodos y frameworksMétodos y frameworks

Estándares de certificación (CMMI)Estándares de certificación (CMMI) Paraguas envolventes (MSF)Paraguas envolventes (MSF) Artefactos y disciplinas (RUP)Artefactos y disciplinas (RUP) Métodos puntuales (Evo)Métodos puntuales (Evo) Metodologías basadas en arquitecturaMetodologías basadas en arquitectura Anti-arquitecturasAnti-arquitecturas Frameworks diversos…Frameworks diversos…

Contexto de situaciónContexto de situación

Descrédito de los procesos en cascadaDescrédito de los procesos en cascada DOD STD 2167 DOD STD 2167 MIL STD 498 MIL STD 498

Crisis de confianza en los procesos Crisis de confianza en los procesos regidos por metodologías prescriptivas regidos por metodologías prescriptivas con análisis completo de requerimientos y con análisis completo de requerimientos y planificación detalladaplanificación detallada CMM, CMMI, Spice, Bootstrap, TickIt, ISO CMM, CMMI, Spice, Bootstrap, TickIt, ISO

90009000 Legislación negativa sobre conformidad Legislación negativa sobre conformidad

con estándares de calidadcon estándares de calidad

Contexto de situaciónContexto de situación

Surgimiento de ideas caórdicasSurgimiento de ideas caórdicas No linealidad: El mítico hombre-mes No linealidad: El mítico hombre-mes

(Brooks)(Brooks) Orden a partir del caos (Kauffman, Hock)Orden a partir del caos (Kauffman, Hock) Sistemas adaptativos complejos (Holland)Sistemas adaptativos complejos (Holland) Auto-organización (B. Boehm)Auto-organización (B. Boehm) Modelo y ciclo de vida en Estrategia del Modelo y ciclo de vida en Estrategia del

Caos (Raccoon, 1995)Caos (Raccoon, 1995)

Manifiesto ágilManifiesto ágilhttp://agilemanifesto.orghttp://agilemanifesto.org

Estamos poniendo al descubierto formas Estamos poniendo al descubierto formas mejores de desarrollo de software, haciéndolo mejores de desarrollo de software, haciéndolo y ayudando a otros a que lo hagan. A través de y ayudando a otros a que lo hagan. A través de este trabajo hemos llegado a valorar:este trabajo hemos llegado a valorar:

Los individuos y la interacciónLos individuos y la interacción por encima de por encima de los procesos y los procesos y herramientasherramientas..

El software que funcionaEl software que funciona por encima de por encima de la documentación la documentación abarcadoraabarcadora..

La colaboración con el clienteLa colaboración con el cliente por encima de por encima de la negociación la negociación contractualcontractual..

La respuesta al cambioLa respuesta al cambio por encima del por encima del seguimiento de un seguimiento de un planplan..

Aunque hay valor en los elementos a la Aunque hay valor en los elementos a la derecha, valorizamos más los de la izquierda.derecha, valorizamos más los de la izquierda.

Manifiesto ágilManifiesto ágilhttp://agilemanifesto.orghttp://agilemanifesto.org

Kent Beck (XP), Mike Beedle, Arie van Kent Beck (XP), Mike Beedle, Arie van Bennekum (DSDM), Alistair Cockburn Bennekum (DSDM), Alistair Cockburn (Crystal), Ward Cunningham (XP), Martin (Crystal), Ward Cunningham (XP), Martin Fowler (XP), James Grenning (XP), Jim Fowler (XP), James Grenning (XP), Jim Highsmith (ASD), Andrew Hunt (Pragmatic Highsmith (ASD), Andrew Hunt (Pragmatic Programming), Ron Jeffries (XP), Jon Kern Programming), Ron Jeffries (XP), Jon Kern (FDD), Brian Marick, Robert C. Martin (XP), (FDD), Brian Marick, Robert C. Martin (XP), Steve Mellor, Ken Schwaber (Scrum), Jeff Steve Mellor, Ken Schwaber (Scrum), Jeff Sutherland (Scrum) y Dave Thomas Sutherland (Scrum) y Dave Thomas (Pragmatic Programming)(Pragmatic Programming)

Métodos ágilesMétodos ágilesMetodología Acrónimo Creación Tipo de modelo CaracterísticaAdaptive SoftwareDevelopment

ASD Highsmith 2000 Prácticas + Ciclo devida

Inspirado en sistemasadaptativos complejos

Agile Modeling AM Ambler 2002 “Metodología basada enla práctica”

Suministra modelado ágila otros métodos

Crystal Methods CM Cockburn 1998 “Familia demetodologías”

MA con énfasis enmodelo de ciclos

Agile RUP dX Booch, Martin, Newkirk1998

Framework / Disciplina XP dado vuelta conartefactos RUP

Dynamic SolutionsDelivery Model

DSDM Stapleton 1997 Framework / Modelo deciclo de vida

Creado por 16 expertosen RAD

Evolutionary ProjectManagement

Evo Gilb 1976 Framework adaptativo Primer método ágilexistente

ExtremeProgramming

XP Beck 1999 “Disciplina en prácticasde ingeniería”

Método ágil radical

Feature-drivendevelopment

FDD De Luca & Coad 1998Palmer & Felsing 2002

“Metodología” Método ágil de diseño yconstrucción

Lean Development LD Charette 2001, Mary yTom Poppendieck

“Forma de pensar” –Modelo logístico

Metodología basada enprocesos productivos

Microsoft SolutionsFramework

MSF Microsoft 1994 Lineamientos,Disciplinas, Prácticas

Framework de desarrollode soluciones

Rapid Development RAD McConnell 1996 Survey de técnicas ymodelos

Selección de bestpractices, no método

Rational UnifiedProcess

RUP Kruchten 1996 Proceso unificado Método (¿ágil?) conmodelado

Scrum Scrum Sutherland 1994 -Schwaber 1995

“Proceso” (frameworkde management)

Complemento de otrosmétodos, ágiles o no

HíbridosHíbridos

Enterprise XP (DSDM + XP) - Mike GriffithsEnterprise XP (DSDM + XP) - Mike Griffiths XP@Scrum - ScrumXP@Scrum - Scrum Xbreed (XP+Scrum) - Mike BeedleXbreed (XP+Scrum) - Mike Beedle Industrial XP - Industrial LogicIndustrial XP - Industrial Logic Dispersed Extreme Programming (DXP) - Michael Dispersed Extreme Programming (DXP) - Michael

Kircher, SiemensKircher, Siemens Dispersed Development - Alan Cameron Wills (MS), Dispersed Development - Alan Cameron Wills (MS),

FastnLoose - Patrones para desarrollo ágil FastnLoose - Patrones para desarrollo ágil distribuidodistribuido

Grizzly (“large Agile”) - Ron Crocker, MotorolaGrizzly (“large Agile”) - Ron Crocker, Motorola Evo+XP, Evo+UP, Evo+Scrum, XP+UP, UP+ScrumEvo+XP, Evo+UP, Evo+Scrum, XP+UP, UP+Scrum

Constantes de los Constantes de los métodos ágilesmétodos ágiles Metodología simple y fácil de aprenderMetodología simple y fácil de aprender

Valores, Principios, Prácticas, Roles, ArtefactosValores, Principios, Prácticas, Roles, Artefactos

Equipos no jerárquicos y auto-organizadosEquipos no jerárquicos y auto-organizados Comunicación intensivaComunicación intensiva MinimalismoMinimalismo

Prescindencia de arquitectura y modeladoPrescindencia de arquitectura y modelado

Proceso iterativo e incrementalProceso iterativo e incremental Entregas rápidasEntregas rápidas

Capacidad adaptativaCapacidad adaptativa Rápida respuesta al cambioRápida respuesta al cambio

Acrónimos y jergaAcrónimos y jerga

ScrumScrum, gallinas, cerdos, corridas (, gallinas, cerdos, corridas (sprintssprints), pre-juego, juego ), pre-juego, juego y pos-juego (Scrum) - Púas (y pos-juego (Scrum) - Púas (spikesspikes) (Scrum, XP)) (Scrum, XP)

““El minimalismo es esencial”, “Todo se puede cambiar”, El minimalismo es esencial”, “Todo se puede cambiar”, “Mejor 80% hoy que 100% mañana” (LD), “Mirando basura “Mejor 80% hoy que 100% mañana” (LD), “Mirando basura (LSD), “Refactorización implacable” (XP)(LSD), “Refactorización implacable” (XP)

El Cono del Silencio, El Esqueleto Ambulante (CC)El Cono del Silencio, El Esqueleto Ambulante (CC) YAGNI YAGNI ““You ArenYou Aren’’t Gonna Need Itt Gonna Need It””; TETCPB, ; TETCPB, ““Test Test

Everything That Can Possibly BrokeEverything That Can Possibly Broke””; DTSTTCPW, ; DTSTTCPW, ““Do The Do The Simplest Thing That Can Possibly WorkSimplest Thing That Can Possibly Work””; BUFD, ; BUFD, ““Big Big Upfront DesignUpfront Design””..

GoF, POSAGoF, POSA ““Lo lamento por su vaca; no sabía que era sagrada” (Ron Lo lamento por su vaca; no sabía que era sagrada” (Ron

Jeffries)Jeffries) ““Si funciona bien, arréglelo de todos modos” (Beck)Si funciona bien, arréglelo de todos modos” (Beck)

eXtreme ProgrammingeXtreme Programming

Método ágil basado en cuatro principios:Método ágil basado en cuatro principios:

simplicidad, comunicación, retroalimentación, simplicidad, comunicación, retroalimentación, valorvalor

Y varias prácticas:Y varias prácticas:

juego de planeamiento, entregas pequeñas, juego de planeamiento, entregas pequeñas, metáforas, diseño simple, pruebas continuas, metáforas, diseño simple, pruebas continuas, refactorización, programación por pares, refactorización, programación por pares, propiedad colectiva, integración continua, propiedad colectiva, integración continua, semana de 40 horas, cliente en el sitio, semana de 40 horas, cliente en el sitio, estándares de codificaciónestándares de codificación

Programación por paresProgramación por pares((pair programmingpair programming))

Todo el código es escrito por parejas de programadoresTodo el código es escrito por parejas de programadores una sola máquina con un teclado y un mouseuna sola máquina con un teclado y un mouse

No es un programador trabajando y el otro mirandoNo es un programador trabajando y el otro mirando No es una sesión de aprendizaje para un programador juniorNo es una sesión de aprendizaje para un programador junior El que no está escribiendoEl que no está escribiendo

piensa más estratégicamente piensa más estratégicamente revisa el código en tiempo realrevisa el código en tiempo real

Los roles se pueden cambiar varias veces durante el díaLos roles se pueden cambiar varias veces durante el día Fundamentos:Fundamentos:

dos programadores trabajando juntos son más efectivos que por dos programadores trabajando juntos son más efectivos que por separadoseparado

el conocimiento grupal crece más rápidoel conocimiento grupal crece más rápido trabajar es más divertidotrabajar es más divertido

PruebasPruebas

TTest est DDriven riven DDevelopmentevelopment Diseño e implementación de las pruebas antes Diseño e implementación de las pruebas antes

de programar la funcionalidadde programar la funcionalidad El programador crea sus propios tests de El programador crea sus propios tests de

unidadunidad Integración continuaIntegración continua

Integración diariaIntegración diaria Disponer de una máquina para integraciónDisponer de una máquina para integración

Tests funcionalesTests funcionales ClienteCliente

Semana de 40 horasSemana de 40 horas

El desarrollo de software es un ejercicio El desarrollo de software es un ejercicio creativocreativo hay que estar fresco y descansadohay que estar fresco y descansado

Sin “héroes”Sin “héroes” Se reduce la rotación de personalSe reduce la rotación de personal Mejora la calidad del productoMejora la calidad del producto Se permiten excepciones, con cuidadoSe permiten excepciones, con cuidado

más de una semana de horas extra: problemamás de una semana de horas extra: problema

Lugar de trabajoLugar de trabajo

Sala amplia (mejor, sin divisiones)Sala amplia (mejor, sin divisiones) Centro: pares de programadoresCentro: pares de programadores Periferia: máquinas individualesPeriferia: máquinas individuales

Ventajas del espacio abierto:Ventajas del espacio abierto: mayor comunicaciónmayor comunicación agenda dinámicaagenda dinámica

Juego de planificaciónJuego de planificación((planning gameplanning game)) Determinar rápidamente el alcance de la Determinar rápidamente el alcance de la

próxima versión próxima versión prioridades de negocio (cliente)prioridades de negocio (cliente) estimaciones técnicas (desarrolladores)estimaciones técnicas (desarrolladores)

¿Por qué juego?¿Por qué juego? Objetivo: maximizar el valor del software Objetivo: maximizar el valor del software

producidoproducido Estrategia: poner en producción las características Estrategia: poner en producción las características

más importantes lo antes posiblemás importantes lo antes posible Piezas: Piezas: story cardsstory cards Jugadores: desarrolladores y clienteJugadores: desarrolladores y cliente Movidas: Exploración, Selección y ActualizaciónMovidas: Exploración, Selección y Actualización

Story CardsStory Cards

Cliente en el sitioCliente en el sitio

Interacción continuaInteracción continua No siempre se consigueNo siempre se consigue

muy junior, no sirvemuy junior, no sirve muy senior, no quieremuy senior, no quiere

Actualmente se pide un “analista”Actualmente se pide un “analista”

Propiedad colectiva del Propiedad colectiva del códigocódigo

Cualquier integrante del grupo tiene autoridad Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del código fuentepara cambiar cualquier parte del código fuente

Todos son dueños del códigoTodos son dueños del código Siempre se utilizan estándaresSiempre se utilizan estándares Los tests siempre deben funcionar al 100%Los tests siempre deben funcionar al 100% Se integra con todo el sistema Se integra con todo el sistema

permanentementepermanentemente Manejo de configuraciónManejo de configuración

Diseño simple, entregas Diseño simple, entregas pequeñaspequeñas

Se debe mantener el diseño lo mas simple Se debe mantener el diseño lo mas simple posible (YAGNI): “No vas a necesitarlo”posible (YAGNI): “No vas a necesitarlo”

Tarjetas CRCTarjetas CRC Design for change vs Design for todayDesign for change vs Design for today

Características útiles en términos del negocioCaracterísticas útiles en términos del negocio No implementar características que no son No implementar características que no son

necesariasnecesarias Poner en producción lo antes posiblePoner en producción lo antes posible Unas pocas semanas por entregaUnas pocas semanas por entrega

Tarjetas CRCTarjetas CRC Clase – Responsabilidad – Colaboración Clase – Responsabilidad – Colaboración

RefactorizaciónRefactorización

Si el código se está volviendo Si el código se está volviendo complicadocomplicado modificar el diseño, volver a uno más modificar el diseño, volver a uno más

simplesimple RefactoringRefactoring: modificar la forma del : modificar la forma del

código sin cambiar su funcionamientocódigo sin cambiar su funcionamiento Ejemplos: extraer método, renombrar Ejemplos: extraer método, renombrar

(clase, método, variable, etc.), reemplazar(clase, método, variable, etc.), reemplazar Hay herramientasHay herramientas

C#Refactory (Xtreme Simplicity)C#Refactory (Xtreme Simplicity)

MetáforaMetáfora

Reemplaza a la arquitecturaReemplaza a la arquitectura ““Historia compartida sobre cómo Historia compartida sobre cómo

funciona todo el sistema”funciona todo el sistema” Lenguaje común que todos puedan Lenguaje común que todos puedan

entenderentender clientecliente desarrolladoresdesarrolladores

La metáfora puede cambiar La metáfora puede cambiar permanentementepermanentemente

Ciclo de vidaCiclo de vida

XP - SíntesisXP - Síntesis

Prácticas conjuntas

IteracionesVocabulario Común – Reemplaza a MetáforasEspacio de trabajo abiertoRetrospectivas

Prácticas de Programador

Desarrollo orientado a pruebasProgramación en paresRefactorizaciónPropiedad colectivaIntegración continuaYAGNI (“No habrás de necesitarlo”) – Equivale a Diseño Simple

Prácticas de Management

Responsabilidad aceptadaCobertura aérea para el equipoRevisión trimestralEspejo – El manager debe comunicar un fiel reflejo del estado de cosasRitmo sostenible

Prácticas de ClienteNarración de historiasPlaneamiento de entregaPrueba de aceptaciónEntregas frecuentes

ScrumScrum

Primera referencia: Takeuchi-Nonaka, 1986, Primera referencia: Takeuchi-Nonaka, 1986, The New The New Product Development GameProduct Development Game

En software, Jeff Sutherland, Ken Schwaber, 1995En software, Jeff Sutherland, Ken Schwaber, 1995 Aplica principios de procesos de control industrial, Aplica principios de procesos de control industrial,

junto con experiencias metodoljunto con experiencias metodolóógicas de Microsoft, gicas de Microsoft, Borland y Hewlett-PackardBorland y Hewlett-Packard

No es método independiente, sino complemento de No es método independiente, sino complemento de otras metodologías XP, MSF, RUP)otras metodologías XP, MSF, RUP)

Enfatiza valores y prácticas de gestión, no cuestiones Enfatiza valores y prácticas de gestión, no cuestiones técnicas de desarrollotécnicas de desarrollo

Principios de ScrumPrincipios de Scrum                Equipos auto-dirigidos y auto-organizados. No hay Equipos auto-dirigidos y auto-organizados. No hay managermanager

que decida, ni otros tque decida, ni otros tíítulos que tulos que ““miembros del equipomiembros del equipo”” o o ““cerdoscerdos””; la excepci; la excepcióón es el n es el Scrum Master Scrum Master que debe ser 50% que debe ser 50% programador y que resuelve problemas, pero no manda. Los programador y que resuelve problemas, pero no manda. Los observadores externos se llaman observadores externos se llaman ““gallinasgallinas””; pueden observar, ; pueden observar, pero no interferir ni opinar.pero no interferir ni opinar.

                 Una vez elegida una tarea, no se agrega trabajo extra. En Una vez elegida una tarea, no se agrega trabajo extra. En caso que se agregue algo, se recomienda quitar alguna otra cosa.caso que se agregue algo, se recomienda quitar alguna otra cosa.

                 Encuentros diarios con las tres preguntas Encuentros diarios con las tres preguntas …… Se realizan Se realizan siempre en el mismo lugar, en csiempre en el mismo lugar, en cíírculo. El encuentro diario impide rculo. El encuentro diario impide caer en el dilema secaer en el dilema seññalado por Fred Brooks: alado por Fred Brooks: “¿“¿CCóómo es que un mo es que un proyecto puede atrasarse un aproyecto puede atrasarse un añño?: Un do?: Un díía a la veza a la vez”” [Bro95]. [Bro95].

                 Iteraciones de treinta dIteraciones de treinta díías; se admite que sean mas; se admite que sean máás s frecuentes.frecuentes.

                 DemostraciDemostracióón a participantes externos al fin de cada n a participantes externos al fin de cada iteraciiteracióón.n.

Al principio de cada iteraciAl principio de cada iteracióón, planeamiento adaptativo guiado n, planeamiento adaptativo guiado por el cliente.por el cliente.

Ciclo de ScrumCiclo de Scrum

Ciclo de Scrum (2)Ciclo de Scrum (2)

Acumulación deProducto:

Acumulación de Carrera:

Artefactos de ScrumArtefactos de Scrum

Acumulación (backlog) de productoAcumulación (backlog) de producto

Acumulación de carreraAcumulación de carrera

Fecha: Acumulación de Producto: Estimado:

Tipo: Nuevo __ Mejora __ Arreglo: __ Fuente: Descripción Notas

Acumulación de Corrida: Fecha:

Propietario: Trabajo Pendiente/Fecha

Status: Pendiente___ Activo___Completo___

Descripción:

Notas:

Prácticas de ScrumPrácticas de Scrum

Al fin de cada iteraciAl fin de cada iteracióón de treinta dn de treinta díías hay una as hay una demostracidemostracióón a cargo del Scrum Master. n a cargo del Scrum Master.

Las presentaciones en PowerPoint estLas presentaciones en PowerPoint estáán prohibidas. En los n prohibidas. En los encuentros diarios, las gallinas deben estar fuera del encuentros diarios, las gallinas deben estar fuera del ccíírculo. rculo.

Todos tienen que ser puntuales; si alguien llega tarde, se le Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinarcobra una multa que se destinaráá a obras de caridad. a obras de caridad.

Es permitido usar artefactos de los mEs permitido usar artefactos de los méétodos a los que todos a los que Scrum acompaScrum acompaññe, p. Ej. Listas de Riesgos si se utiliza UP, e, p. Ej. Listas de Riesgos si se utiliza UP, Planguage si el mPlanguage si el méétodo es Evo, o los Planes de Proyecto todo es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestisugeridos en la disciplina de Gestióón de Proyectos de MSF. n de Proyectos de MSF.

No es legal el uso de instrumentos como diagramas PERT, No es legal el uso de instrumentos como diagramas PERT, porque parten del supuesto de que las tareas de un porque parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenarproyecto se pueden identificar y ordenar

El supuesto dominante es que el desarrollo es semi-El supuesto dominante es que el desarrollo es semi-cacaóótico, cambiante y tiene demasiado ruido como para que tico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido.se le aplique un proceso definido.

Feature Driven Development Feature Driven Development (FDD) (FDD) [DeLuca, Coad][DeLuca, Coad] No FOP, pero sí Desarrollo por No FOP, pero sí Desarrollo por

RasgoRasgo El seguimiento del progreso se realiza mediante El seguimiento del progreso se realiza mediante

examen de pequeñas funcionalidades examen de pequeñas funcionalidades descompuestas y funciones valoradas por el descompuestas y funciones valoradas por el cliente. Un rasgo es una función pequeña cliente. Un rasgo es una función pequeña expresada en la forma expresada en la forma <acción><acción> <<resultadoresultado>> <por | <por | para | de | a> para | de | a> <objeto><objeto> con los operadores con los operadores adecuados entre los términos. Por ejemplo,adecuados entre los términos. Por ejemplo, calcularcalcular el importe total el importe total de de una venta una venta;; determinar determinar la última operaciónla última operación de de un cajero;un cajero; validar validar la la contraseña contraseña dede un usuario un usuario..

Feature Driven Development Feature Driven Development (FDD)(FDD) No cubre todo el ciclo de vida, sino No cubre todo el ciclo de vida, sino

diseño y construccióndiseño y construcción Se considera apto para proyectos Se considera apto para proyectos

mayores o de misión críticamayores o de misión crítica Hay arquitectos en FDDHay arquitectos en FDD Numerosos artefactos para el control del Numerosos artefactos para el control del

procesoproceso

Feature Driven Development Feature Driven Development (FDD)(FDD) Ciclo de vidaCiclo de vida

Feature Driven Development Feature Driven Development (FDD)(FDD)

Ensayo Diseño Inspección de Diseño

Código Inspección de Código

Promover a Build

Id Descripción Pro

g. Jefe.

Prop.

Clase Pla

n Act

ual Pla

n Act

ual Pla

n Act

ual Pla

n Act

ual Pla

n Actual

Plan

Actual

MD125

Validar los límites transaccionales de un CAO contra una instrucción de implementación

CP AB

C 23/

12/98 23/

12/98 31/

01/99 31/

01/99 01/

02/99 01/

02/99 10/

02/99

18/02/99

20/

02/99

MD126

Definir el estado de una instrucción de implementación

CP AB

C 23/

12/98 23/

12/98 31/

01/99 31/

01/99 01/

02/99 01/

02/99 10/

02/99 18/

02/99 20/

02/99

MD127

Especificar el oficial de autorización de una instrucción de implementación

CP AB

C 23/

12/98 23/

12/98 31/

01/99 31/

01/99 01/

02/99 01/

02/99 10/

02/99 18/

02/99 20/

02/99

MD128

Rechazar una instrucción de implementación para un conjunto de líneas

CP AB

C STATUS: Inactivo NOTA: [agregado por CK: 3/2/99] No aplicable

MD129

Confirmar una instrucción de implementación para un conjunto de líneas

CP AB

C 23/

12/98 23/

12/98 31/

01/99 31/

01/99 01/

02/99 01/

02/99 10/

02/99 18/

02/99 20/

02/99

23/12/98

23/12/98

31/01/99

31/01/99

01/02/99

01/02/99

05/02/99

08/02/99

10/02/99

MD1

30

Determinar si todos los documentos se han completado para un prestatario

CP AB

C NOTA: [agregado por SL: 3/2/99] Bloqueado en AS

23/12/98

23/12/98

31/01/99

31/01/99

01/02/99

01/02/99

05/02/99

08/02/99

10/02/99

MD1

31

Validar los límites transaccionales de un CAO contra una instrucción de desembolso

CP AB

C NOTA: [agregado por: 3/2/99] Atrasado según estimaciones iniciales

MD132

Enviar para autorización una instrucción de implementación

CP AB

C 23/

12/98 23/

12/98 31/

01/99 31/

01/99 01/

02/99 01/

02/99 05/

02/99 05/

02/99 06/

02/99 06/02

/99 08/

02/99 08/02

/99

MD133

Validar fecha de baja de una instrucción de implementación

CP AB

C 23/

12/98 23/

12/98 31/

01/99 31/

01/99 01/

02/99 01/

02/99 05/

02/99 05/

02/99 06/

02/99 06/02

/99 08/

02/99 08/02

/99

Feature Driven Development Feature Driven Development (FDD)(FDD) En sEn sííntesis, FDD es un mntesis, FDD es un méétodo de desarrollo todo de desarrollo

de ciclos cortos que se concentra en la fase de de ciclos cortos que se concentra en la fase de disediseñño y construccio y construccióón. n.

En la primera fase, el modelo global de En la primera fase, el modelo global de dominio es elaborado por expertos del dominio es elaborado por expertos del dominio y desarrolladores; dominio y desarrolladores;

El modelo de dominio consiste en diagramas El modelo de dominio consiste en diagramas de clases con clases, relaciones, mde clases con clases, relaciones, méétodos y todos y atributos. atributos.

Los mLos méétodos no reflejan conveniencias de todos no reflejan conveniencias de programaciprogramacióón sino rasgos funcionales.n sino rasgos funcionales.

Best practicesBest practices en otros en otros métodosmétodos DSDMDSDM

Prácticas escalables - Reglas Prácticas escalables - Reglas MoSCoW MoSCoW [Must, Should, Could, Want][Must, Should, Could, Want]

Adaptive Software Adaptive Software DevelopmentDevelopment James Highsmith III, consultor de Cutter Consortium, James Highsmith III, consultor de Cutter Consortium,

desarrolldesarrollóó ASD hacia el a ASD hacia el añño 2000o 2000 Alternativa a la idea, propia de CMM Nivel 5, de que la Alternativa a la idea, propia de CMM Nivel 5, de que la

optimizacioptimizacióón es la n es la úúnica solucinica solucióón para problemas de n para problemas de complejidad creciente. complejidad creciente.

Tercera vTercera víía entre el a entre el ““desarrollo monumental de desarrollo monumental de softwaresoftware”” y el y el ““desarrollo accidentaldesarrollo accidental””, o entre la , o entre la burocracia y la adhocracia. Deberburocracia y la adhocracia. Deberííamos buscar mamos buscar máás s bien, afirma Highsmith, bien, afirma Highsmith, ““el rigor estrictamente el rigor estrictamente necesarionecesario””

Para ello hay que situarse en coordenadas apenas un Para ello hay que situarse en coordenadas apenas un poco fuera del caos y ejercer menos control que el que poco fuera del caos y ejercer menos control que el que se cree necesario.se cree necesario.

Ciclo de ASDCiclo de ASD

Adaptive Software Adaptive Software DevelopmentDevelopment Auto-organizaciAuto-organizacióón, adaptacin, adaptacióón al cambio y orden emergenten al cambio y orden emergente AnalogAnalogíías con los sistemas adaptativos complejos por as con los sistemas adaptativos complejos por

excelencia: los organismos vivientes (o sus anexcelencia: los organismos vivientes (o sus anáálogos logos digitales: redes neuronales auto-organizativas de Teuvo digitales: redes neuronales auto-organizativas de Teuvo Kohonen y autKohonen y autóómatas celularesmatas celulares

Los proyectos de software son sistemas adaptativos Los proyectos de software son sistemas adaptativos complejos y la optimizacicomplejos y la optimizacióón no hace mn no hace máás que sofocar la s que sofocar la emergencia necesaria para afrontar el cambio. emergencia necesaria para afrontar el cambio.

Highsmith interpreta la organizaciHighsmith interpreta la organizacióón empresarial que n empresarial que emprende un desarrollo como si fuera un ambiente, sus emprende un desarrollo como si fuera un ambiente, sus miembros como agentes y el producto como el resultado miembros como agentes y el producto como el resultado emergente de relaciones de competencia y cooperaciemergente de relaciones de competencia y cooperacióón. n.

En los sistemas complejos no es aplicable el anEn los sistemas complejos no es aplicable el anáálisis, porque lisis, porque no puede no puede deducirsededucirse el comportamiento del todo a partir de la el comportamiento del todo a partir de la conducta de las partes, ni sumarse las propiedades conducta de las partes, ni sumarse las propiedades individuales para determinar las caracterindividuales para determinar las caracteríísticas del conjuntosticas del conjunto

Lean DevelopmentLean Development

Lean: magro, enjuto – James Womack, Lean: magro, enjuto – James Womack, 1990, La máquina que cambió al mundo1990, La máquina que cambió al mundo

Patrones organizacionalesPatrones organizacionales Herramientas de TQM( Edward Deming)Herramientas de TQM( Edward Deming) Software: Bob Charette, 2001Software: Bob Charette, 2001 No se limita al proceso de desarrollo – No se limita al proceso de desarrollo –

Hay que conocer el negocio de punta a Hay que conocer el negocio de punta a puntapunta

Principios de Lean Principios de Lean DevelopmentDevelopment

1.      Satisfacer al cliente es la máxima prioridad.1.      Satisfacer al cliente es la máxima prioridad. 2.2.           Proporcionar siempre el mejor valor por la inversi Proporcionar siempre el mejor valor por la inversióón.n. 3.3.           El El ééxito depende de la activa participacixito depende de la activa participacióón del cliente.n del cliente. 4.4.           Cada proyecto LD es un esfuerzo de equipo. Cada proyecto LD es un esfuerzo de equipo. 5.5.           Todo se puede cambiar. Todo se puede cambiar. 6.6.           Soluciones de dominio, no puntos. Soluciones de dominio, no puntos. 7.7.           Completar, no construir. Completar, no construir. 8.8.           Una soluci Una solucióón al 80% hoy, en vez de una al 100% man al 80% hoy, en vez de una al 100% maññana.ana. 9.9.           El minimalismo es esencial. El minimalismo es esencial. 10.10.   La necesidad determina la tecnolog La necesidad determina la tecnologíía.a. 11.11.   El crecimiento del producto es el incremento de sus El crecimiento del producto es el incremento de sus

prestaciones, no de su tamaprestaciones, no de su tamañño.o. 12.12.   Nunca empujes LD m Nunca empujes LD máás alls alláá de sus l de sus líímites.mites.

Reformulación de Darell Reformulación de Darell NortonNorton 1.1.           Eliminar basura (las herramientas son Eliminar basura (las herramientas son Seeing Seeing

Waste, Value Stream MappingWaste, Value Stream Mapping). Basura es todo lo que ). Basura es todo lo que no agregue valor a un producto, desde la no agregue valor a un producto, desde la óóptica del ptica del sistema de valores del cliente. Este principio equivale sistema de valores del cliente. Este principio equivale a la reduccia la reduccióón del inventario en manufactura. El n del inventario en manufactura. El inventario del desarrollo de software es el conjunto de inventario del desarrollo de software es el conjunto de artefactos intermedios. Un estudio del Standish Group artefactos intermedios. Un estudio del Standish Group revelrevelóó que en un sistema t que en un sistema tíípico, las prestaciones que pico, las prestaciones que se usan siempre suman el 7%, las que se usan a se usan siempre suman el 7%, las que se usan a menudo el 13%, menudo el 13%, ““algunas vecesalgunas veces”” el 16%, el 16%, ““raras vecesraras veces”” el 19% y el 19% y ““nuncanunca”” el 45%. Esto es un claro 80/20: el el 45%. Esto es un claro 80/20: el 80% del valor proviene del 20% de los rasgos. 80% del valor proviene del 20% de los rasgos.

Concentrarse en el 20% Concentrarse en el 20% úútil es una aplicacitil es una aplicacióón del n del mismo principio que subyace a la idea de YAGNI.mismo principio que subyace a la idea de YAGNI.

Lean DevelopmentLean Development

Igual que Agile Modeling, que cubrIgual que Agile Modeling, que cubríía aspectos a aspectos de modelado y documentacide modelado y documentacióón, LD y LSD han n, LD y LSD han sido pensados como complemento de otros sido pensados como complemento de otros mméétodos, y no como una metodologtodos, y no como una metodologíía a excluyente.excluyente.

LD prefiere concentrarse en las premisas y LD prefiere concentrarse en las premisas y modelos derivados de Lean Production (canon modelos derivados de Lean Production (canon de la Escuela de Negocios de Harvard). de la Escuela de Negocios de Harvard).

Para las tPara las téécnicas concretas de programacicnicas concretas de programacióón, n, LD promueve el uso de otros MAs que sean LD promueve el uso de otros MAs que sean consistentes con su visiconsistentes con su visióón, como XPn, como XP

EvoEvo

Competitive Engineering – Tom & Kai GilbCompetitive Engineering – Tom & Kai Gilb PlanguagePlanguage

Vincula todas las disciplinas de SEVincula todas las disciplinas de SE Expresa objetivos, estrategia, diseño y riesgoExpresa objetivos, estrategia, diseño y riesgo Basado en Plan-Do-Study-Act (Deming, Juran, Basado en Plan-Do-Study-Act (Deming, Juran,

Shewhart)Shewhart)

Lenguaje de especificación PlanguageLenguaje de especificación Planguage Descripción de requerimientos, diseños y planesDescripción de requerimientos, diseños y planes

Métodos PlanguageMétodos Planguage Especificación de requerimiento, con atributos Especificación de requerimiento, con atributos

cuantificadoscuantificados Estimación de impacto: implementación vs Estimación de impacto: implementación vs

requerimiento y evaluación de progresorequerimiento y evaluación de progreso Control de calidad de especificación (SQC - Excel)Control de calidad de especificación (SQC - Excel) Evolutionary Project Management: pasos pequeños Evolutionary Project Management: pasos pequeños

(2%) evolutivos de alto valor(2%) evolutivos de alto valor

EvoEvo

PlanguagePlanguage

CUSTOMER.SATISFACTION

SCALE: evaluación promedio de la satisfacción de un cliente, de 1 a 5, siendo 1 la peor y 5 la mejor

PAST [2003] 2.5

GOAL [2004] 3.5

Evo

Agile ModelingAgile Modeling

Diagrama de artefactosDiagrama de artefactos

Métodos ágiles en MSFMétodos ágiles en MSF

Fuerte tradición de desarrollo ágil en Fuerte tradición de desarrollo ágil en MSMS Steve McConnell, Steve McConnell, Code CompleteCode Complete (1993) (1993)

Programación en paresProgramación en pares

Steve McConnell, Steve McConnell, Rapid DevelopmentRapid Development (1996) (1996) Modelo de ciclo de vida evolutivo, encuentros y Modelo de ciclo de vida evolutivo, encuentros y

talleres de equipo, revisiones frecuentes, diseño talleres de equipo, revisiones frecuentes, diseño para el cambio, entrega evolutiva, reutilización, para el cambio, entrega evolutiva, reutilización, prototipado evolutivo, comunicación intensa, prototipado evolutivo, comunicación intensa, desarrollo iterativo e incrementaldesarrollo iterativo e incremental

No ágilNo ágil: recomendación de establecer metas fijas : recomendación de establecer metas fijas de antemano, contratar a terceros para realizar de antemano, contratar a terceros para realizar parte del código (parte del código (outsourcingoutsourcing), trabajar en oficinas ), trabajar en oficinas privadas, ofrecerse a permanecer horas privadas, ofrecerse a permanecer horas extraordinarias - Oposición de McConnell a XPextraordinarias - Oposición de McConnell a XP

Ron Jeffries & Ward CunninghamRon Jeffries & Ward Cunningham

Métodos ágiles en MSFMétodos ágiles en MSF

Microsoft Solutions FrameworkMicrosoft Solutions Framework En evolución desde 1994En evolución desde 1994 ““Conjunto de principios, modelos, disciplinas, conceptos, Conjunto de principios, modelos, disciplinas, conceptos,

lineamientos y prácticas probadas”lineamientos y prácticas probadas” http://www.microsoft.com/technet/itsolutions/techguide/ms

f/msfovrvw.mspx Explícitamente definido como framework apto para Explícitamente definido como framework apto para

métodos ágiles métodos ágiles Modelo de Procesos iterativo e incremental, con Modelo de Procesos iterativo e incremental, con

participación activa del clienteparticipación activa del cliente Probado en combinación con métodos ágilesProbado en combinación con métodos ágiles

Agile Modeling (Ambler)Agile Modeling (Ambler) DSDM - Documento conjunto de coordinaciónDSDM - Documento conjunto de coordinación RUPRUP Evolutionary Project Management - Best practicesEvolutionary Project Management - Best practices

Métodos ágiles en MSFMétodos ágiles en MSF 8 principios:8 principios:

Alentar comunicaciones abiertas (Brooks)Alentar comunicaciones abiertas (Brooks) Trabajar hacia una visión compartida Trabajar hacia una visión compartida

(Highsmith)(Highsmith) Otorgar poder a los miembros del equipoOtorgar poder a los miembros del equipo Establecer responsabilidad clara y Establecer responsabilidad clara y

compartidacompartida Concentrarse en la entrega de valor de Concentrarse en la entrega de valor de

negociosnegocios Permanecer ágil, esperar el cambio Permanecer ágil, esperar el cambio

(Highsmith)(Highsmith) Invertir en calidadInvertir en calidad Aprender de todas las experienciasAprender de todas las experiencias

Críticas a Métodos ÁgilesCríticas a Métodos Ágiles

Rakitin, 2001 – Argumento hackerRakitin, 2001 – Argumento hacker Pete McBreen, 2002 – Questioning XPPete McBreen, 2002 – Questioning XP McConnell, 2002 – Hipnosis colectiva, McConnell, 2002 – Hipnosis colectiva, one size one size

fits allfits all, programación sin diseño, programación sin diseño Stephens-Rosenberg, 2003 – XP RefactoredStephens-Rosenberg, 2003 – XP Refactored Ed Berard, 2003 – “Falacias”Ed Berard, 2003 – “Falacias” Gerold Keffer, 2003 – Gerold Keffer, 2003 – XP considered harmful.XP considered harmful.. .

(Escalabilidad, casos, programación de garage, (Escalabilidad, casos, programación de garage, TDD caro, reusabilidad, pero no COTS)TDD caro, reusabilidad, pero no COTS)

Mellor, Smith – Consignas estridentes, artefactos Mellor, Smith – Consignas estridentes, artefactos no reconocidosno reconocidos

Herramientas para Herramientas para desarrollo ágildesarrollo ágil

Patterns & PracticesPatterns & Practices Prueba de UnidadPrueba de Unidad

COMUnit - SourceForge, VB.NET & C#COMUnit - SourceForge, VB.NET & C# Nunit 2.1.4Nunit 2.1.4 csUnitcsUnit vbUnit 3 - Visual Basic .NETvbUnit 3 - Visual Basic .NET .TEST - Parasoft Software - Soporta NUnit.TEST - Parasoft Software - Soporta NUnit HarnessIt™ - UnitTesting.com - Prueba de unidad para HarnessIt™ - UnitTesting.com - Prueba de unidad para

lenguajes CLRlenguajes CLR Unite.NET - Ascentiv - Prueba de unidad e integración - Unite.NET - Ascentiv - Prueba de unidad e integración -

Independiente de lenguajeIndependiente de lenguaje

Herramientas para Herramientas para desarrollo ágildesarrollo ágil

RefactorizaciónRefactorización C# Refactoring Tool 1.5.1C# Refactoring Tool 1.5.1 Opnieuw - SourceForge, C#Opnieuw - SourceForge, C# Extreme Simplicity C# Refactory - VB Extreme Simplicity C# Refactory - VB

RefactoryRefactory ReSharper - JetBrains! C# Refactoring ToolReSharper - JetBrains! C# Refactoring Tool C# 2.0 Whidbey - Refactoring nativoC# 2.0 Whidbey - Refactoring nativo GeneXusGeneXus

ConclusionesConclusiones Distintas categorías de métodos ágilesDistintas categorías de métodos ágiles Los métodos ágiles son fundamentalmente Los métodos ágiles son fundamentalmente

combinablescombinables MSF marco general, Planguage como lenguaje de MSF marco general, Planguage como lenguaje de

especificación de requerimiento, Scrum (con sus patrones especificación de requerimiento, Scrum (con sus patrones organizacionales) como método de management, XP (con organizacionales) como método de management, XP (con patrones de diseño, programación guiada por pruebas y patrones de diseño, programación guiada por pruebas y refactorización) como metodología de desarrollo, RUP como refactorización) como metodología de desarrollo, RUP como abastecedor de artefactos, ASD como cultura empresarial y abastecedor de artefactos, ASD como cultura empresarial y (si se requiere) CMM como metodología de evaluación de (si se requiere) CMM como metodología de evaluación de madurezmadurez

Desarrollo de conceptos y técnicas de uso Desarrollo de conceptos y técnicas de uso generalgeneral

Patrones organizacionales (Scrum, Lean Software Patrones organizacionales (Scrum, Lean Software Development), refactorización, TDD, Testing PatternsDevelopment), refactorización, TDD, Testing Patterns

Democratización de las metodologías - Ahora los Democratización de las metodologías - Ahora los métodos son métodos son mainstreammainstream

Vínculos y referenciasVínculos y referencias

Reynoso/Kicillof en MSDN en Español:Reynoso/Kicillof en MSDN en Español: http://www.microsoft.com/spanish/msdn/http://www.microsoft.com/spanish/msdn/

arquitecturaarquitectura Martin Fowler, Kent Beck, John Brant, Martin Fowler, Kent Beck, John Brant,

William Opdyke y Don Roberts. William Opdyke y Don Roberts. Refactoring: Refactoring: Improving the design of existing codeImproving the design of existing code. . Addison Wesley, 1999Addison Wesley, 1999

Kent Beck. Kent Beck. Extreme Programming Explained: Extreme Programming Explained: Embrace ChangeEmbrace Change. Addison Wesley, 1999. Addison Wesley, 1999

Vínculos y referenciasVínculos y referencias

Ron Jeffries - Ron Jeffries - Extreme Programming Extreme Programming adventures in C#.adventures in C#. MS Press, 2004 MS Press, 2004

Tom Gilb. Tom Gilb. Competitive EngineeringCompetitive Engineering, , 2003.2003.

Will Stott, James Newkirk - “Test-driven Will Stott, James Newkirk - “Test-driven C#”. C#”. MSDN MagazineMSDN Magazine, Abril de 2004., Abril de 2004.

Andy Hunt, Dave Thomas - Andy Hunt, Dave Thomas - Pragmatic Pragmatic Unit Testing in C# with NUnitUnit Testing in C# with NUnit, 2004., 2004.

¿Preguntas?¿Preguntas?

Billy ReynosoBilly ReynosoUNIVERSIDAD DE BUENOS AIRESUNIVERSIDAD DE BUENOS AIRESbillyr@microsoft.com.arbillyr@microsoft.com.ar