Métodos Ágiles en desarrollo de software

Carlos ReynosoCarlos ReynosoUNIVERSIDAD DE BUENOS AIRESUNIVERSIDAD DE BUENOS AIRESbillyr@microsoft.com.arbillyr@microsoft.com.arhttp://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/arquitectura_soft.mspx

ObjetivosObjetivos

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

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

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

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/arquitechttp://www.microsoft.com/spanish/msdn/arquitecturatura

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 regidos por Crisis de confianza en los procesos regidos por metodologías prescriptivas con análisis metodologías prescriptivas con análisis completo de requerimientos y planificación completo de requerimientos y planificación detalladadetallada

CMM, CMMI, Spice, Bootstrap, TickIt, ISO 9000CMM, CMMI, Spice, Bootstrap, TickIt, ISO 9000

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

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

Auto-organización (B. Boehm)Auto-organización (B. Boehm)Modelo y ciclo de vida en Estrategia del Caos Modelo y ciclo de vida en Estrategia del Caos (Raccoon, 1995)(Raccoon, 1995)

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

Estamos poniendo al descubierto formas mejores de Estamos poniendo al descubierto formas mejores de desarrollo de software, haciéndolo y ayudando a desarrollo de software, haciéndolo y ayudando a otros a que lo hagan. A través de este trabajo hemos otros a que lo 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 planseguimiento de un plan..

Aunque hay valor en los elementos a la derecha, Aunque hay valor en los elementos a la derecha, valorizamos más los de la izquierda.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 (Crystal), Bennekum (DSDM), Alistair Cockburn (Crystal), Ward Cunningham (XP), Martin Fowler (XP), Ward Cunningham (XP), Martin Fowler (XP), James Grenning (XP), Jim Highsmith (ASD), James Grenning (XP), Jim Highsmith (ASD), Andrew Hunt (Pragmatic Programming), Ron Andrew Hunt (Pragmatic Programming), Ron Jeffries (XP), Jon Kern (FDD), Brian Marick, Jeffries (XP), Jon Kern (FDD), Brian Marick, Robert C. Martin (XP), Steve Mellor, Ken Robert C. Martin (XP), Steve Mellor, Ken Schwaber (Scrum), Jeff Sutherland (Scrum) y Schwaber (Scrum), Jeff Sutherland (Scrum) y Dave Thomas (Pragmatic Programming)Dave Thomas (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íbridosEnterprise XP (DSDM + XP) - Mike GriffithsEnterprise XP (DSDM + XP) - Mike GriffithsXP@Scrum - ScrumXP@Scrum - ScrumXbreed (XP+Scrum) - Mike BeedleXbreed (XP+Scrum) - Mike BeedleIndustrial XP - Industrial LogicIndustrial XP - Industrial LogicDispersed Extreme Programming (DXP) - Michael Dispersed Extreme Programming (DXP) - Michael Kircher, SiemensKircher, SiemensDispersed Development - Alan Cameron Wills Dispersed Development - Alan Cameron Wills (MS), FastnLoose - Patrones para desarrollo ágil (MS), FastnLoose - Patrones para desarrollo ágil distribuidodistribuidoGrizzly (“Large Agile”) - Ron Crocker, MotorolaGrizzly (“Large Agile”) - Ron Crocker, MotorolaEvo+XP, Evo+UP, Evo+Scrum, XP+UP, UP+ScrumEvo+XP, Evo+UP, Evo+Scrum, XP+UP, UP+Scrum

Constantes de los MAsConstantes de los MAsSurge en libros con impacto en la industria y Surge en libros con impacto en la industria y en el público, no en 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, ArtefactosValores, Principios, Prácticas, Roles, Artefactos

Equipos no jerárquicos y auto-organizadosEquipos no jerárquicos y auto-organizadosComunicació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 control Scrum: conceptos de filo del caos y control de caosde caosScrum: http//www.controlchaos.comScrum: http//www.controlchaos.com

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

Ideas caórdicas en MAsIdeas caórdicas en MAs

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

Ideas caórdicas en MAsIdeas caórdicas en MAs

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

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 “You Aren’t Gonna Need It”; TETCPB, “Test YAGNI “You Aren’t Gonna Need It”; TETCPB, “Test Everything That Can Possibly Broke”; DTSTTCPW, “Do The Everything That Can Possibly Broke”; DTSTTCPW, “Do The Simplest Thing That Can Possibly Work”; BUFD, “Big Simplest Thing That Can Possibly Work”; BUFD, “Big Upfront Design”.Upfront 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, valorsimplicidad, comunicación, retroalimentación, valor

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

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

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 programadoresuna 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 mirandoNo es una sesión de aprendizaje para un programador No es una sesión de aprendizaje para un programador juniorjuniorEl 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íaFundamentos:Fundamentos:

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

PruebasPruebas

TT est est DD riven riven DD evelopmentevelopmentDiseño e implementación de las pruebas Diseño e implementación de las pruebas antes de programar la funcionalidadantes de programar la funcionalidadEl programador crea sus propios tests de El programador crea sus propios tests de unidadunidad

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

Tests funcionalesTests funcionalesClienteCliente

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

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 próxima Determinar rápidamente el alcance de la próxima versión 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 producidoObjetivo: maximizar el valor del software producidoEstrategia: poner en producción las características más Estrategia: poner en producción las características más importantes lo antes posibleimportantes lo antes posiblePiezas: 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 códigoPropiedad colectiva del código

Cualquier integrante del grupo tiene Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del autoridad para cambiar cualquier parte del código fuentecó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 100%Los tests siempre deben funcionar al 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 posible Se debe mantener el diseño lo mas simple posible (YAGNI): “No vas a necesitarlo”(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 necesariasNo implementar características que no son necesarias

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 complicadoSi el código se está volviendo complicadomodificar el diseño, volver a uno más simplemodificar el diseño, volver a uno más simple

RefactoringRefactoring: modificar la forma del código : modificar la forma del código sin cambiar su funcionamientosin cambiar su funcionamiento

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

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

••            Una vez elegida una tarea, no se agrega trabajo extra. En caso Una vez elegida una tarea, no se agrega trabajo extra. En caso que se agregue algo, se recomienda quitar alguna otra cosa.que se agregue algo, se recomienda quitar alguna otra cosa.Encuentros diarios con las tres preguntas … Se realizan siempre Encuentros diarios con las tres preguntas … Se realizan siempre en el mismo lugar, en círculo. El encuentro diario impide caer en en el mismo lugar, en círculo. El encuentro diario impide caer en el dilema señalado por Fred Brooks: “¿Cómo es que un proyecto el dilema señalado por Fred Brooks: “¿Cómo es que un proyecto puede atrasarse un año?: Un día a la vez” [Bro95].puede atrasarse un año?: Un día a la vez” [Bro95].Iteraciones de treinta días; se admite que sean más frecuentes.Iteraciones de treinta días; se admite que sean más frecuentes.Demostración a participantes externos al fin de cada iteración.Demostración a participantes externos al fin de cada iteración.Al principio de cada iteración, planeamiento adaptativo guiado Al principio de cada iteración, planeamiento adaptativo guiado por el cliente.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 demostración a Al fin de cada iteración de treinta días hay una demostración a cargo del Scrum Master. cargo del Scrum Master. Las presentaciones en PowerPoint están prohibidas. En los Las presentaciones en PowerPoint están prohibidas. En los encuentros diarios, las gallinas deben estar fuera del círculo. encuentros diarios, las gallinas deben estar fuera del círculo. Todos tienen que ser puntuales; si alguien llega tarde, se le cobra Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinará a obras de caridad. una multa que se destinará a obras de caridad. Es permitido usar artefactos de los métodos a los que Scrum Es permitido usar artefactos de los métodos a los que Scrum acompañe, p. Ej. Listas de Riesgos si se utiliza UP, Planguage si acompañe, p. Ej. Listas de Riesgos si se utiliza UP, Planguage si el método es Evo, o los Planes de Proyecto sugeridos en la el método es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestión de Proyectos de MSF. disciplina de Gestión de Proyectos de MSF. No es legal el uso de instrumentos como diagramas PERTNo es legal el uso de instrumentos como diagramas PERT, , porque parten del supuesto de que las tareas de un proyecto se porque parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenarpueden identificar y ordenarEl supuesto dominante es que El supuesto dominante es que el desarrollo es semi-caóticoel desarrollo es semi-caótico, , cambiante y tiene demasiado ruido como para que se le aplique cambiante y tiene demasiado ruido como para que se le aplique un proceso definido.un proceso definido.

Otros métodos: FDDOtros métodos: FDD

Feature Driven Development Feature Driven Development (FDD) (FDD) [DeLuca, Coad][DeLuca, Coad]

No FOP, pero sí Desarrollo por RasgoNo FOP, pero sí Desarrollo por RasgoEl seguimiento del progreso se realiza mediante examen El seguimiento del progreso se realiza mediante examen de pequeñas funcionalidades descompuestas y funciones de pequeñas funcionalidades descompuestas y funciones valoradas por el cliente. valoradas por el cliente. Un rasgo es una función pequeña expresada en la forma Un rasgo es una función pequeña expresada en la forma <acción><acción> <<resultadoresultado>> <por | para | de | a> <por | para | de | a> <objeto><objeto> con con los operadores adecuados entre los términos. Por los operadores adecuados entre los términos. Por ejemplo,ejemplo, calcular calcular el importe total el importe total de de una venta una venta;; determinardeterminar la última operación la ú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 diseño y No cubre todo el ciclo de vida, sino diseño y construcciónconstrucciónSe considera apto para proyectos mayores o Se considera apto para proyectos mayores o de misión críticade misión críticaHay arquitectos en FDDHay arquitectos en FDDNumerosos 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)

FDD es un método de desarrollo de ciclos cortos FDD es un método de desarrollo de ciclos cortos que se concentra en la fase de diseño y que se concentra en la fase de diseño y construcción. construcción. En la primera fase, el modelo global de dominio es En la primera fase, el modelo global de dominio es elaborado por expertos del dominio y elaborado por expertos del dominio y desarrolladores; desarrolladores; El modelo de dominio consiste en diagramas de El modelo de dominio consiste en diagramas de clases con clases, relaciones, métodos y atributos. clases con clases, 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 BretañaMétodo estándar en Gran BretañaPrá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, desarrolló ASD hacia el 2000desarrolló ASD hacia el 2000Alternativa a la idea, propia de CMM Nivel 5, de que la Alternativa a la idea, propia de CMM Nivel 5, de que la optimización es la única solución para problemas de optimización es la única solución para problemas de complejidad creciente. complejidad creciente. Tercera vía entre el “desarrollo monumental de software” y Tercera vía entre el “desarrollo monumental de software” y el “desarrollo accidental”, o entre la burocracia y la el “desarrollo accidental”, o entre la burocracia y la adhocracia. Deberíamos buscar más bien, afirma adhocracia. Deberíamos buscar más bien, afirma Highsmith, “el rigor estrictamente necesario”Highsmith, “el rigor estrictamente necesario”Para ello hay que Para ello hay que situarse en coordenadas apenas un poco situarse en coordenadas apenas un poco fuera del caosfuera del caos y ejercer menos control que el que se cree y ejercer menos control que el que se cree necesario.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 emergenteorden emergenteAnalogías con los sistemas adaptativos complejos por excelencia: Analogías con los sistemas adaptativos complejos por excelencia: los organismos vivientes (o sus análogos digitales: redes los organismos vivientes (o sus análogos digitales: redes neuronales auto-organizativas de Teuvo Kohonen y autómatas neuronales auto-organizativas de Teuvo Kohonen y autómatas celulares).celulares).Los proyectos de software son sistemas adaptativos complejosLos proyectos de software son sistemas adaptativos complejos y la y la optimización no hace más que sofocar la emergencia necesaria optimización no hace más que sofocar la emergencia necesaria para afrontar el cambio. para afrontar el cambio. Highsmith interpreta la organización empresarial que emprende un Highsmith interpreta la organización empresarial que emprende un desarrollo como si fuera un ambiente, sus miembros como agentes desarrollo como si fuera un ambiente, sus miembros como agentes y el y el producto como el resultado emergente de relaciones de producto como el resultado emergente de relaciones de competencia y cooperacióncompetencia 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 no puede puede deducirsededucirse el comportamiento del todo a partir de la el comportamiento del todo a partir de la conducta de las partesconducta de las partes, ni sumarse las propiedades individuales , ni sumarse las propiedades individuales para determinar las características del conjunto (ejemplo del agua)para determinar las características del conjunto (ejemplo del agua)

Lean DevelopmentLean Development

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

Lean DevelopmentLean Development

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

EvoEvo

Competitive Engineering – Tom & Kai GilbCompetitive Engineering – Tom & Kai GilbPlanguagePlanguage

Vincula 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, Shewhart)Basado en Plan-Do-Study-Act (Deming, Juran, 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 cuantificadosEspecificación de requerimiento, con atributos cuantificadosEstimación de impacto: implementación vs requerimiento y Estimación de impacto: implementación vs requerimiento y evaluación de progresoevaluación de progresoControl de calidad de especificación (SQC - Excel)Control de calidad de especificación (SQC - Excel)Evolutionary Project Management: pasos pequeños (2%) Evolutionary Project Management: pasos pequeños (2%) evolutivos de alto valorevolutivos 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 en MSFuerte tradición de desarrollo ágil en MSSteve 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 talleres de Modelo de ciclo de vida evolutivo, encuentros y talleres de equipo, revisiones frecuentes, diseño para el cambio, equipo, revisiones frecuentes, diseño para el cambio, entrega evolutiva, reutilización, prototipado evolutivo, entrega evolutiva, reutilización, prototipado evolutivo, comunicación intensa, desarrollo iterativo e incrementalcomunicación intensa, desarrollo iterativo e incrementalNo ágilNo ágil: recomendación de establecer metas fijas de : recomendación de establecer metas fijas de antemano, contratar a terceros para realizar parte del antemano, contratar a terceros para realizar parte del código (código (outsourcingoutsourcing), trabajar en oficinas privadas, ), trabajar en oficinas privadas, ofrecerse a permanecer horas extraordinarias - Oposición ofrecerse a permanecer horas extraordinarias - Oposición de McConnell a XPde McConnell a XP

Ron Jeffries & Ward CunninghamRon Jeffries & Ward Cunningham

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

Microsoft Solutions FrameworkMicrosoft Solutions FrameworkEn 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/msf/msfovrvw.mspxhttp://www.microsoft.com/technet/itsolutions/techguide/msf/msfovrvw.mspxExplícitamente definido como framework apto para métodos Explícitamente definido como framework apto para métodos ágiles ágiles Modelo de Procesos iterativo e incremental, con participación Modelo de Procesos iterativo e incremental, con participación activa del clienteactiva 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

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 equipoEstablecer responsabilidad clara y compartidaEstablecer responsabilidad clara y compartidaConcentrarse en la entrega de valor de negociosConcentrarse en la entrega de valor de negociosPermanecer ágil, esperar el cambio (Highsmith)Permanecer ágil, esperar el cambio (Highsmith)Invertir en calidadInvertir en calidadAprender de todas las experienciasAprender de todas las experiencias

Críticas a Métodos ÁgilesCríticas a Métodos Á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 fits allone size fits all, , programación sin diseñoprogramació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 garage, TDD (Escalabilidad, casos, programación de garage, TDD caro, reusabilidad, pero no COTS)caro, reusabilidad, pero no COTS)Mellor, Smith – Consignas estridentes, artefactos no Mellor, Smith – Consignas estridentes, artefactos no reconocidosreconocidos

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 para HarnessIt™ - UnitTesting.com - Prueba de unidad para lenguajes CLRlenguajes CLRUnite.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ónC# Refactoring Tool 1.5.1C# Refactoring Tool 1.5.1Opnieuw - SourceForge, C#Opnieuw - SourceForge, C#Extreme Simplicity C# Extreme Simplicity C# Refactory - VB RefactoryRefactory - VB RefactoryReSharper - JetBrains! C# ReSharper - JetBrains! C# Refactoring ToolRefactoring ToolC# 2.0 Whidbey - Refactoring C# 2.0 Whidbey - Refactoring nativonativoGeneXusGeneXus

Creencias insostenibles

Es posible diagramar a priori y en detalle la totalidad del ciclo de vida y sus artefactosEl seguimiento de un plan garantiza la excelencia de un proceso de desarrolloEl diseño previo implica corrección arquitectónica y/o mejora las cualidades no-funcionalesEl diseño previo incide sobre la calidad del códigoLa semántica de los lenguajes de diseño mapea punto a punto sobre la semántica de los frameworks de programaciónEl diseño y el plan documentan el desarrollo real y/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 especificación de MSF marco general, Planguage como lenguaje de especificación de requerimiento, Scrum (con sus patrones organizacionales) como requerimiento, Scrum (con sus patrones organizacionales) como método de método de managementmanagement, XP (con patrones de diseño, , XP (con patrones de diseño, programación guiada por pruebas y refactorización) como programación guiada por pruebas y refactorización) como metodología de desarrollo, RUP como abastecedor de artefactos, metodología de desarrollo, RUP como abastecedor de artefactos, ASD como cultura empresarial y (si se requiere) CMM como ASD como cultura empresarial y (si se requiere) CMM como metodología de evaluación de madurezmetodología de evaluación de madurez

Desarrollo de conceptos y técnicas de uso generalDesarrollo de conceptos y técnicas de uso generalPatrones 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

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

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

El debate está lejos de resolverse en el mediano plazoNo se puede negar el valor de la auto-organización (Internet, 9/11, Toyota)… pero nadie sabe cómo se organiza lo que se auto-organizaNo hay balas de plataLos grandes jugadores en la industria de software todaví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/arquitecturahttp://www.microsoft.com/spanish/msdn/arquitectura

Martin Fowler, Kent Beck, John Brant, William Martin Fowler, Kent Beck, John Brant, William Opdyke y Don Roberts. Opdyke y Don Roberts. Refactoring: Improving the Refactoring: Improving the design of existing codedesign of existing code. Addison Wesley, 1999. Addison Wesley, 1999Kent 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, 2004Tom Gilb. Tom Gilb. Competitive EngineeringCompetitive Engineering, 2003., 2003.Will Stott, James Newkirk - “Test-driven C#”. Will Stott, James Newkirk - “Test-driven C#”. MSDN MagazineMSDN Magazine, Abril de 2004., Abril de 2004.Andy Hunt, Dave Thomas - Andy Hunt, Dave Thomas - Pragmatic Unit Pragmatic Unit Testing in C# with NUnitTesting in C# with NUnit, 2004., 2004.

¿Preguntas?

Billy ReynosoUNIVERSIDAD DE BUENOS AIRESbillyr@microsoft.com.ar