Metodos agiles

Métodos Ágiles en desarrollo de software

Carlos ReynosoCarlos ReynosoUNIVERSIDAD DE BUENOS AIRESUNIVERSIDAD DE BUENOS [email protected]@microsoft.com.arhttp://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/arquitectura_soft.mspx

ObjetivosObjetivos

Proporcionar una reflexión sobre XP y Proporcionar una reflexión sobre XP y los métodos ágiles orientada a la los métodos ágiles orientada a la academiaacademia

No es un curso introductorio, no es No es un curso introductorio, no es evangelizaciónevangelización

Examinar los fundamentos formales, Examinar los fundamentos formales, la relevancia metodológica y el la relevancia metodológica y el alcance práctico de los métodos alcance práctico de los métodos ágileságilesIdentificar recursos para profundizar Identificar recursos para profundizar el temael tema

AgendaAgenda

Contexto de situaciónContexto de situaciónManifiesto ágilManifiesto ágilTabla de Métodos ágilesTabla de Métodos ágileseXtreme Programming (XP)eXtreme Programming (XP)Otros métodos ágiles Otros métodos ágiles Métodos ágiles & MSF 3.0Métodos ágiles & MSF 3.0Críticas a Métodos ÁgilesCríticas a Métodos ÁgilesConclusiones – Estado de la cuestiónConclusiones – Estado de la cuestiónReferencias y recursosReferencias y recursoshttp://www.microsoft.com/spanish/msdn/http://www.microsoft.com/spanish/msdn/arquitecturaarquitectura

Contexto de situaciónContexto de situación

Descrédito de los procesos en cascadaDescrédito de los procesos en cascadaDOD 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 con análisis completo de requerimientos y planificación requerimientos y planificación detalladadetallada

CMM, CMMI, Spice, Bootstrap, TickIt, ISO CMM, CMMI, Spice, Bootstrap, TickIt, ISO 90009000

CMM no es una metodología ni un CMM no es una metodología ni un modelo en cascada, pero “coincide con modelo en cascada, pero “coincide con su espíritu”su espíritu”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órdicasNo linealidad: El mítico hombre-mes No linealidad: El mítico hombre-mes (Brooks)(Brooks)Orden a partir del caos (Kauffman, Orden a partir del caos (Kauffman, Hock)Hock)Sistemas adaptativos complejos Sistemas adaptativos complejos (Holland)(Holland)

Dinámica no lineal, sensitividad a las Dinámica no lineal, sensitividad a las condiciones iniciales (“efecto mariposa”), condiciones iniciales (“efecto mariposa”), autómatas celulares, redes booleanas autómatas celulares, redes booleanas aleatorias (“orden gratis”)aleatorias (“orden gratis”)

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, mejores de desarrollo de software, haciéndolo y ayudando a otros a que lo haciéndolo y ayudando a otros a que lo hagan. A través de este trabajo hemos hagan. A través de este trabajo hemos llegado a valorar: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 derecha, valorizamos más los de la izquierda.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 Highsmith (ASD), Andrew Hunt (Pragmatic Programming), Ron Jeffries (Pragmatic Programming), Ron Jeffries (XP), Jon Kern (FDD), Brian Marick, (XP), Jon Kern (FDD), Brian Marick, Robert C. Martin (XP), Steve Mellor, Ken Robert C. Martin (XP), Steve Mellor, Ken Schwaber (Scrum), Jeff Sutherland Schwaber (Scrum), Jeff Sutherland (Scrum) y Dave Thomas (Pragmatic (Scrum) y Dave Thomas (Pragmatic Programming)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íbridosEnterprise XP (DSDM + XP) - Mike Enterprise XP (DSDM + XP) - Mike GriffithsGriffithsXP@Scrum - ScrumXP@Scrum - ScrumXbreed (XP+Scrum) - Mike BeedleXbreed (XP+Scrum) - Mike BeedleIndustrial XP - Industrial LogicIndustrial XP - Industrial LogicDispersed Extreme Programming (DXP) - Dispersed Extreme Programming (DXP) - Michael Kircher, SiemensMichael Kircher, SiemensDispersed Development - Alan Cameron Dispersed Development - Alan Cameron Wills (MS), FastnLoose - Patrones para Wills (MS), FastnLoose - Patrones para desarrollo ágil distribuidodesarrollo ágil distribuidoGrizzly (“Large Agile”) - Ron Crocker, Grizzly (“Large Agile”) - Ron Crocker, MotorolaMotorolaEvo+XP, Evo+UP, Evo+Scrum, XP+UP, Evo+XP, Evo+UP, Evo+Scrum, XP+UP, UP+ScrumUP+Scrum

Constantes de los MAsConstantes de los MAsSurge en libros con impacto en la Surge en libros con impacto en la industria y en el público, no en industria y en el público, no en paperspapersMetodología simple y fácil de aprenderMetodología simple y fácil de aprender

Valores, Principios, Prácticas, Roles, Valores, Principios, Prácticas, Roles, ArtefactosArtefactos

Equipos no jerárquicos y auto-Equipos no jerárquicos y auto-organizadosorganizadosComunicación intensivaComunicación intensivaMinimalismoMinimalismo

Prescindencia de arquitectura y modeladoPrescindencia de arquitectura y modelado

Proceso iterativo e incrementalProceso iterativo e incrementalEntregas rápidasEntregas rápidas

Capacidad adaptativaCapacidad adaptativaRápida respuesta al cambioRápida respuesta al cambio

Ideas caórdicas en MAsIdeas caórdicas en MAs

Scrum: conceptos de filo del caos y Scrum: conceptos de filo del caos y control de caoscontrol de caosScrum: http//www.controlchaos.comScrum: http//www.controlchaos.com

Microsoft implementa estrategias de Microsoft implementa estrategias de caos controlado en procesos de caos controlado en procesos de desarrollo (desarrollo (Microsoft secretsMicrosoft secrets))MSF 3.0: referencia a la naturaleza MSF 3.0: referencia a la naturaleza caórdica de los procesos complejos caórdica de los procesos complejos (Dee Hock)(Dee Hock)


Fred Brooks: no linealidad [MMM]Fred Brooks: no linealidad [MMM]Jeff DeLuca (FDD): afinidad con caos Jeff DeLuca (FDD): afinidad con caos determinista y teoría de la complejidaddeterminista y teoría de la complejidadLarman sobre Scrum: referencias a John Larman sobre Scrum: referencias a John Holland sobre auto-organización y Holland sobre auto-organización y procesos adaptativosprocesos adaptativosJim Highsmith (Adaptive Software Jim Highsmith (Adaptive Software Development): control laxo, equilibrio en el Development): control laxo, equilibrio en el filo del caosfilo del caosLean Development: analogía con Lean Development: analogía con sociedades de insectos y modelos de sociedades de insectos y modelos de agentes adaptativosagentes adaptativos


Kent Beck: “las raíces de XP se Kent Beck: “las raíces de XP se encuentran en la teoría de los encuentran en la teoría de los sistemas complejos”sistemas complejos”Barry BoehmBarry Boehm: “la ingeniería de : “la ingeniería de software deberá estudiar los software deberá estudiar los sistemas adaptativos, el orden sistemas adaptativos, el orden emergente, los agentes que se auto-emergente, los agentes que se auto-organizan…”organizan…”Ideas de complejidad y caos en Ideas de complejidad y caos en managementmanagement y consultoría y consultoría organizativaorganizativaIdem, en predicción financieraIdem, en predicción financiera

Acrónimos y jergaAcrónimos y jerga

ScrumScrum, gallinas, cerdos, corridas (, gallinas, cerdos, corridas (sprintssprints), pre-), pre-juego, juego y pos-juego (Scrum) - Púas (juego, juego y pos-juego (Scrum) - Púas (spikesspikes) ) (Scrum, XP)(Scrum, XP)““El minimalismo es esencial”, “Todo se puede El minimalismo es esencial”, “Todo se puede cambiar”, “Mejor 80% hoy que 100% mañana” cambiar”, “Mejor 80% hoy que 100% mañana” (LD), “Mirando basura (LSD), “Refactorización (LD), “Mirando basura (LSD), “Refactorización implacable” (XP)implacable” (XP)El Cono del Silencio, El Esqueleto Ambulante (CC)El Cono del Silencio, El Esqueleto Ambulante (CC)YAGNI “You Aren’t Gonna Need It”; TETCPB, “Test YAGNI “You Aren’t Gonna Need It”; TETCPB, “Test Everything That Can Possibly Broke”; DTSTTCPW, Everything That Can Possibly Broke”; DTSTTCPW, “Do The Simplest Thing That Can Possibly Work”; “Do The Simplest Thing That Can Possibly Work”; BUFD, “Big Upfront Design”.BUFD, “Big Upfront Design”.GoF, POSAGoF, POSA““Lo lamento por su vaca; no sabía que era Lo lamento por su vaca; no sabía que era sagrada” (Ron Jeffries)sagrada” (Ron Jeffries)““Si funciona bien, arréglelo de todos modos” Si funciona bien, arréglelo de todos modos” (Beck)(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

¿Prácticas ¿Prácticas independientes?independientes?

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

Todo el código es escrito por parejas de Todo el código es escrito por parejas de programadoresprogramadores

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 No es un programador trabajando y el otro mirandomirandoNo es una sesión de aprendizaje para un No es una sesión de aprendizaje para un programador juniorprogramador juniorEl 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 Los roles se pueden cambiar varias veces durante el díael díaFundamentos:Fundamentos:

dos programadores trabajando juntos son más efectivos dos programadores trabajando juntos son más efectivos que por separadoque por separadoel conocimiento grupal crece más rápidoel conocimiento grupal crece más rápidotrabajar es más divertidotrabajar es más divertido

PruebasPruebas

TTest est DDriven riven DDevelopmentevelopmentDiseño e implementación de las Diseño e implementación de las pruebas antes de programar la pruebas antes de programar la funcionalidadfuncionalidadEl programador crea sus propios tests El programador crea sus propios tests de unidadde unidad

Integración continuaIntegración continuaIntegración diariaIntegración diariaDisponer de una máquina para Disponer de una máquina para integraciónintegración

Tests funcionalesTests funcionalesClienteCliente

Semana de 40 horasSemana de 40 horas

El desarrollo de software es un El desarrollo de software es un ejercicio creativoejercicio creativo

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 personalMejora la calidad del productoMejora la calidad del productoSe permiten excepciones, con Se permiten excepciones, con cuidadocuidado

más de una semana de horas extra: más de una semana de horas extra: problemaproblema

Lugar de trabajoLugar de trabajo

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

Ventajas del espacio abierto:Ventajas del espacio abierto:mayor comunicaciónmayor comunicaciónagenda 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 producidoproducidoEstrategia: poner en producción las Estrategia: poner en producción las características más importantes lo antes características más importantes lo antes posibleposiblePiezas: Piezas: story cardsstory cardsJugadores: desarrolladores y clienteJugadores: desarrolladores y clienteMovidas: 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 continuaNo siempre se consigueNo siempre se consigue

muy junior, no sirvemuy junior, no sirvemuy 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 Cualquier integrante del grupo tiene autoridad para cambiar cualquier autoridad para cambiar cualquier parte del código fuenteparte del código fuenteTodos son dueños del códigoTodos son dueños del códigoSiempre se utilizan estándaresSiempre se utilizan estándaresLos tests siempre deben funcionar al Los tests siempre deben funcionar al 100%100%Se integra con todo el sistema Se integra con todo el sistema permanentementepermanentementeManejo 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 CRCDesign for changeDesign for change vs vs Design for today Design for today

Características útiles en términos del negocioCaracterísticas útiles en términos del negocioNo 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 posibleUnas 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 código sin cambiar su funcionamientofuncionamiento

Ejemplos: extraer método, renombrar Ejemplos: extraer método, renombrar (clase, método, variable, etc.), (clase, método, variable, etc.), reemplazarreemplazar

Hay herramientasHay herramientasC#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

clienteclientedesarrolladoresdesarrolladores

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

Ciclo de vidaCiclo de vida

XP - SíntesisXP - Síntesis

Prácticas conjuntasIteracionesVocabulario 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, Primera referencia: Takeuchi-Nonaka, 1986, 1986, The New Product Development The New Product Development GameGameEn software, Jeff Sutherland, Ken En software, Jeff Sutherland, Ken Schwaber, 1995Schwaber, 1995Aplica principios de procesos de control Aplica principios de procesos de control industrial, junto con experiencias industrial, junto con experiencias metodológicas de Microsoft, Borland y metodológicas de Microsoft, Borland y Hewlett-PackardHewlett-Packard No es método independiente, sino No es método independiente, sino complemento de otras metodologías (XP, complemento de otras metodologías (XP, MSF, RUP)MSF, RUP)Enfatiza valores y prácticas de gestión, no Enfatiza valores y prácticas de gestión, no cuestiones técnicas de desarrollocuestiones té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 títulos que “miembros que decida, ni otros títulos que “miembros del equipo” o “cerdos”; la excepción es el del equipo” o “cerdos”; la excepción es el Scrum Scrum Master Master que debe ser 50% programador y que resuelve que debe ser 50% programador y que resuelve problemas, pero no manda. Los observadores externos problemas, pero no manda. Los observadores externos se llaman “gallinas”; pueden observar, pero no se llaman “gallinas”; pueden observar, pero no interferir ni opinar.interferir ni opinar.

Una vez elegida una tarea, no se agrega trabajo extra. Una vez elegida una tarea, no se agrega trabajo extra. En caso que se agregue algo, se recomienda quitar En caso que se agregue algo, se recomienda quitar alguna otra cosa.alguna otra cosa.Encuentros diarios con las tres preguntas … Se realizan Encuentros diarios con las tres preguntas … Se realizan siempre en el mismo lugar, en círculo. El encuentro siempre en el mismo lugar, en círculo. El encuentro diario impide caer en el dilema señalado por Fred diario impide caer en el dilema señalado por Fred Brooks: “¿Cómo es que un proyecto puede atrasarse Brooks: “¿Cómo es que un proyecto puede atrasarse un año?: Un día a la vez” [Bro95].un año?: Un día a la vez” [Bro95].Iteraciones de treinta días; se admite que sean más Iteraciones de treinta días; se admite que sean más frecuentes.frecuentes.Demostración a participantes externos al fin de cada Demostración a participantes externos al fin de cada iteración.iteración.Al principio de cada iteración, planeamiento adaptativo Al principio de cada iteración, planeamiento adaptativo guiado por el cliente.guiado por el cliente.

Ciclo de ScrumCiclo de Scrum

Acumulación deProducto:

Acumulación de Carrera:

Artefactos de ScrumArtefactos de Scrum

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

Acumulación de carrera (o “corrida”)Acumulación de carrera (o “corrida”)

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 iteración de treinta días hay una Al fin de cada iteración de treinta días hay una demostración a cargo del Scrum Master. demostración a cargo del Scrum Master. Las presentaciones en PowerPoint están prohibidas. En Las presentaciones en PowerPoint están prohibidas. En los encuentros diarios, las gallinas deben estar fuera los encuentros diarios, las gallinas deben estar fuera del círculo. del círculo. Todos tienen que ser puntuales; si alguien llega tarde, Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinará a obras de se le cobra una multa que se destinará a obras de caridad. caridad. Es permitido usar artefactos de los métodos a los que Es permitido usar artefactos de los métodos a los que Scrum acompañe, p. Ej. Listas de Riesgos si se utiliza Scrum acompañe, p. Ej. Listas de Riesgos si se utiliza UP, Planguage si el método es Evo, o los Planes de UP, Planguage si el método es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestión de Proyecto sugeridos en la disciplina de Gestión de Proyectos de MSF. Proyectos de MSF. No es legal el uso de instrumentos como diagramas No es legal el uso de instrumentos como diagramas PERTPERT, porque parten del supuesto de que las tareas de , porque parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenarun proyecto se pueden identificar y ordenarEl supuesto dominante es que El supuesto dominante es que el desarrollo es semi-el desarrollo es semi-caóticocaótico, cambiante y tiene demasiado ruido como para , cambiante y tiene demasiado ruido como para que se le aplique un proceso definido.que se le aplique un proceso definido.

Otros métodos: FDDOtros métodos: FDD

Feature Driven Feature Driven Development (FDD) Development (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. cliente. Un rasgo es una función pequeña expresada en Un rasgo es una función pequeña expresada en la forma la forma <acción><acción> <<resultadoresultado>> <por | para | de <por | para | de | a> | a> <objeto><objeto> con los operadores adecuados con los operadores adecuados entre los términos. Por ejemplo,entre los términos. Por ejemplo, calcular calcular el el importe totalimporte total de de una venta una venta;; determinar determinar la última la última operaciónoperación de de un cajero;un cajero; validar validar la contraseña la contraseña dede un usuarioun usuario..

Feature Driven Feature Driven Development (FDD)Development (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ónSe considera apto para proyectos Se considera apto para proyectos mayores o de misión críticamayores o de misión críticaHay arquitectos en FDDHay arquitectos en FDDNumerosos artefactos para el control Numerosos artefactos para el control del procesodel proceso


Ciclo de vidaCiclo de vida


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


FDD es un método de desarrollo de ciclos FDD es un método de desarrollo de ciclos cortos que se concentra en la fase de cortos que se concentra en la fase de diseño y construcción. diseño y construcció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 El modelo de dominio consiste en diagramas de clases con clases, diagramas de clases con clases, relaciones, métodos y atributos. relaciones, métodos y atributos. Los métodos no reflejan conveniencias de Los métodos no reflejan conveniencias de programación sino rasgos funcionales.programación sino rasgos funcionales.

DSDMDSDM

Método estándar en Gran Método estándar en Gran BretañaBretaña

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 James Highsmith III, consultor de Cutter Consortium, desarrolló ASD hacia el 2000Consortium, desarrolló ASD hacia el 2000Alternativa a la idea, propia de CMM Nivel 5, de Alternativa a la idea, propia de CMM Nivel 5, de que la optimización es la única solución para que la optimización es la única solución para problemas de complejidad creciente. problemas de complejidad creciente. Tercera vía entre el “desarrollo monumental de Tercera vía entre el “desarrollo monumental de software” y el “desarrollo accidental”, o entre la software” y el “desarrollo accidental”, o entre la burocracia y la adhocracia. Deberíamos buscar burocracia y la adhocracia. Deberíamos buscar más bien, afirma Highsmith, “el rigor más bien, afirma Highsmith, “el rigor estrictamente necesario”estrictamente necesario”Para ello hay que Para ello hay que situarse en coordenadas apenas situarse en coordenadas apenas un poco fuera del caosun poco fuera del caos y ejercer menos control y ejercer menos control que el que se cree necesario.que el que se cree necesario.

Ciclo de ASDCiclo de ASD

Adaptive Software Adaptive Software DevelopmentDevelopment

Auto-organización, adaptación al cambio y Auto-organización, adaptación al cambio y orden orden emergenteemergenteAnalogías con los sistemas adaptativos complejos por Analogías con los sistemas adaptativos complejos por excelencia: los organismos vivientes (o sus análogos excelencia: los organismos vivientes (o sus análogos digitales: redes neuronales auto-organizativas de Teuvo digitales: redes neuronales auto-organizativas de Teuvo Kohonen y autómatas celulares).Kohonen y autómatas celulares).Los proyectos de software son sistemas adaptativos Los proyectos de software son sistemas adaptativos complejoscomplejos y la optimización no hace más que sofocar la y la optimización no hace más que sofocar la emergencia necesaria para afrontar el cambio. emergencia necesaria para afrontar el cambio. Highsmith interpreta la organización empresarial que Highsmith interpreta la organizació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 miembros como agentes y el producto como el resultado producto como el resultado emergente de relaciones de competencia y cooperaciónemergente de relaciones de competencia y cooperación. . En los sistemas complejos En los sistemas complejos no es aplicable el análisisno es aplicable el análisis, , porque porque no puede no puede deducirsededucirse el comportamiento del todo el comportamiento del todo a partir de la conducta de las partesa partir de la conducta de las partes, ni sumarse las , ni sumarse las propiedades individuales para determinar las propiedades individuales para determinar las características del conjunto (ejemplo del agua)características del conjunto (ejemplo del agua)

Lean DevelopmentLean Development

Lean: magro, enjuto – James Lean: magro, enjuto – James Womack, 1990, Womack, 1990, La máquina que La máquina que cambió al mundocambió al mundoPatrones organizacionalesPatrones organizacionalesHerramientas de TQM( Edward Herramientas de TQM( Edward Deming)Deming)Software: Bob Charette, 2001Software: Bob Charette, 2001No se limita al proceso de desarrollo No se limita al proceso de desarrollo – Hay que conocer el negocio de – Hay que conocer el negocio de punta a puntapunta a punta

Lean DevelopmentLean Development

Igual que Agile Modeling, que cubría Igual que Agile Modeling, que cubría aspectos de modelado y documentación, aspectos de modelado y documentación, LD y LSD han sido pensados como LD y LSD han sido pensados como complemento de otros métodos, y no complemento de otros métodos, y no como una metodología excluyente.como una metodología excluyente.LD prefiere concentrarse en las premisas y LD prefiere concentrarse en las premisas y modelos derivados de Lean Production modelos derivados de Lean Production (canon de la Escuela de Negocios de (canon de la Escuela de Negocios de Harvard). Harvard). Para las técnicas concretas de Para las técnicas concretas de programación, LD promueve el uso de programación, LD promueve el uso de otros MAs que sean consistentes con su otros MAs que sean consistentes con su visión, como XPvisión, como XP

EvoEvo

Competitive Engineering – Tom & Competitive Engineering – Tom & Kai GilbKai Gilb

PlanguagePlanguageVincula todas las disciplinas de SEVincula todas las disciplinas de SEExpresa objetivos, estrategia, diseño y riesgoExpresa objetivos, estrategia, diseño y riesgoBasado 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 PlanguageDescripción de requerimientos, diseños y planesDescripción de requerimientos, diseños y planes

Métodos PlanguageMétodos PlanguageEspecificación de requerimiento, con atributos Especificación de requerimiento, con atributos cuantificadoscuantificadosEstimación de impacto: implementación vs Estimación de impacto: implementación vs requerimiento y evaluación de progresorequerimiento y evaluación de progresoControl 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

•Tom Gilb es el creador de la idea de “métricas de software”

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

Fuerte tradición de desarrollo ágil Fuerte tradición de desarrollo ágil en MSen MS

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 incrementalNo á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 ), trabajar en oficinas privadas, ofrecerse a permanecer horas oficinas 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


Microsoft Solutions FrameworkMicrosoft Solutions FrameworkEn evolución desde 1994En evolución desde 1994““Conjunto de principios, modelos, disciplinas, Conjunto de principios, modelos, disciplinas, conceptos, lineamientos y prácticas probadas”conceptos, lineamientos y prácticas probadas”http://www.microsoft.com/technet/itsolutions/techguide/http://www.microsoft.com/technet/itsolutions/techguide/msf/msfovrvw.mspxmsf/msfovrvw.mspxExplí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 clienteProbado 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ónRUPRUPEvolutionary Project Management - Best practicesEvolutionary Project Management - Best practices

http://www.microsoft.com/technet/itsolutions/techguide/msf/msfovrvw.mspx

http://www.microsoft.com/technet/itsolutions/techguide/msf/msfovrvw.mspx


8 principios:8 principios:Alentar comunicaciones abiertas Alentar comunicaciones abiertas (Brooks)(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 Críticas a Métodos ÁgilesÁgiles

Rakitin, 2001 – Argumento Rakitin, 2001 – Argumento hackerhackerPete McBreen, 2002 – Questioning XPPete McBreen, 2002 – Questioning XPMcConnell, 2002 – Hipnosis colectiva, McConnell, 2002 – Hipnosis colectiva, one size one size fits allfits all, programación sin diseño, programación sin diseñoStephens-Rosenberg, 2003 – XP RefactoredStephens-Rosenberg, 2003 – XP RefactoredEd Berard, 2003 – “Falacias”Ed Berard, 2003 – “Falacias”Gerold Keffer, 2003 – Gerold Keffer, 2003 – XP considered harmful.XP considered harmful.. . (Escalabilidad, casos, programación de (Escalabilidad, casos, programación de garage, TDD caro, reusabilidad, pero no garage, TDD caro, reusabilidad, pero no COTS)COTS)Mellor, Smith – Consignas estridentes, Mellor, Smith – Consignas estridentes, artefactos no reconocidosartefactos no reconocidos

Herramientas para Herramientas para desarrollo ágildesarrollo ágil

Patterns & PracticesPatterns & PracticesPrueba de UnidadPrueba de Unidad

COMUnit - SourceForge, VB.NET & C#COMUnit - SourceForge, VB.NET & C#Nunit 2.1.4Nunit 2.1.4csUnitcsUnitvbUnit 3 - Visual Basic .NETvbUnit 3 - Visual Basic .NET.TEST - Parasoft Software - Soporta NUnit.TEST - Parasoft Software - Soporta NUnitHarnessIt™ - UnitTesting.com - Prueba de unidad HarnessIt™ - UnitTesting.com - Prueba de unidad para lenguajes CLRpara lenguajes CLRUnite.NET - Ascentiv - Prueba de unidad e Unite.NET - Ascentiv - Prueba de unidad e integración - Independiente de lenguajeintegración - Independiente de lenguaje

Herramientas para Herramientas para desarrollo ágildesarrollo ágil

RefactorizaciónRefactorizaciónC# Refactoring Tool 1.5.1C# Refactoring Tool 1.5.1Opnieuw - SourceForge, Opnieuw - SourceForge, C#C#Extreme Simplicity C# Extreme Simplicity C# Refactory - VB RefactoryRefactory - VB RefactoryReSharper - JetBrains! C# ReSharper - JetBrains! C# Refactoring ToolRefactoring ToolC# 2.0 Whidbey - C# 2.0 Whidbey - Refactoring nativoRefactoring nativoGeneXusGeneXus

Creencias insosteniblesCreencias insostenibles

Es posible diagramar a priori y en detalle la Es posible diagramar a priori y en detalle la totalidad del ciclo de vida y sus artefactostotalidad del ciclo de vida y sus artefactosEl seguimiento de un plan garantiza la excelencia El seguimiento de un plan garantiza la excelencia de un proceso de desarrollode un proceso de desarrolloEl diseño previo implica corrección arquitectónica El diseño previo implica corrección arquitectónica y/o mejora las cualidades no-funcionalesy/o mejora las cualidades no-funcionalesEl diseño previo incide sobre la calidad del códigoEl diseño previo incide sobre la calidad del códigoLa semántica de los lenguajes de diseño mapea La semántica de los lenguajes de diseño mapea punto a punto sobre la semántica de los punto a punto sobre la semántica de los frameworksframeworks de programación de programaciónEl diseño y el plan documentan el desarrollo real El diseño y el plan documentan el desarrollo real y/o facilitan su mantenimiento o transferenciay/o facilitan su mantenimiento o transferencia

ConclusionesConclusiones

Distintas categorías de métodos ágilesDistintas categorías de métodos ágilesLos 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 organizacionales) como método de managementmanagement, XP (con , 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 refactorización) como metodología de desarrollo, RUP como abastecedor de artefactos, ASD como cultura como abastecedor de artefactos, ASD como cultura empresarial y (si se requiere) CMM como metodología de empresarial y (si se requiere) CMM como metodología de evaluación de madurezevaluación de madurez

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 Development), refactorización, TDD, Testing PatternsPatterns

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

Estado de la cuestiónEstado de la cuestiónLos métodos ágiles llegaron para quedarse, aunque la Los métodos ágiles llegaron para quedarse, aunque la histeria se está moderando histeria se está moderando El BUFD también llegó para quedarseEl BUFD también llegó para quedarseCMU/SEI está desarrollando ambas estrategias CMU/SEI está desarrollando ambas estrategias simultáneamentesimultáneamente

El departamento de Ingeniería está más cerca de los El departamento de Ingeniería está más cerca de los métodos tradicionales (CMM, CMMI, etc)métodos tradicionales (CMM, CMMI, etc)Pero hay fuertes críticas respecto de la adecuación de UML Pero hay fuertes críticas respecto de la adecuación de UML para ese propósito – Arquitectura de software para ese propósito – Arquitectura de software no es diseño no es diseño OOOO

El debate está lejos de resolverse en el mediano plazoEl debate está lejos de resolverse en el mediano plazoNo se puede negar el valor de la auto-organización No se puede negar el valor de la auto-organización (Internet, 9/11, Toyota)(Internet, 9/11, Toyota)… … pero nadie sabe cómo se organiza lo que se auto-pero nadie sabe cómo se organiza lo que se auto-organizaorganizaNo hay balas de plataNo hay balas de plataLos grandes jugadores en la industria de software Los grandes jugadores en la industria de software todavía no están ni a favor ni en contra. Yo tampocotodavía no están ni a favor ni en contra. Yo tampoco

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: Improving the design of Refactoring: Improving the design of existing codeexisting code. Addison Wesley, 1999. Addison Wesley, 1999Kent Beck. Kent Beck. Extreme Programming Extreme Programming Explained: Embrace ChangeExplained: Embrace Change. Addison . Addison Wesley, 1999Wesley, 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, 2004Tom Gilb. Tom Gilb. Competitive EngineeringCompetitive Engineering, , 2003.2003.Will Stott, James Newkirk - “Test-Will Stott, James Newkirk - “Test-driven C#”. driven C#”. MSDN MagazineMSDN Magazine, Abril de , Abril de 2004.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?

Billy ReynosoUNIVERSIDAD DE BUENOS [email protected]

Technology

Metodos agiles