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

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)

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

Ideas caórdicas en MAsIdeas caórdicas en MAs

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 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 Simplest Thing That Can Possibly WorkDo The Simplest Thing That Can Possibly Work””; ; BUFD, BUFD, ““Big Upfront DesignBig 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 metodolmetodolóógicas de Microsoft, Borland y 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 que decida, ni otros tíítulos que tulos que ““miembros del miembros del equipoequipo”” o o ““cerdoscerdos””; la excepci; la excepcióón es el n es el Scrum Master Scrum 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 se llaman ““gallinasgallinas””; pueden observar, pero no ; 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 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 rculo. El encuentro diario impide caer en el dilema sediario impide caer en el dilema seññalado por Fred alado por Fred Brooks: Brooks: “¿“¿CCóómo es que un proyecto puede atrasarse un mo es que un proyecto puede atrasarse un aaññ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 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 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 n prohibidas. En los encuentros diarios, las gallinas deben estar fuera los encuentros diarios, las gallinas deben estar fuera del cdel cíírculo. 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 destinarse le cobra una multa que se destinaráá a obras de a obras de caridad. 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 e, p. Ej. Listas de Riesgos si se utiliza UP, Planguage si el mUP, Planguage si el méétodo es Evo, o los Planes de todo es Evo, o los Planes de Proyecto sugeridos en la disciplina de GestiProyecto sugeridos en la disciplina de Gestióón de 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-cacaóóticotico, 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

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

Ciclo de vidaCiclo de vida

Feature Driven Feature Driven Development (FDD)Development (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 Feature Driven Development (FDD)Development (FDD)

FDD es un mFDD es un méétodo de desarrollo de ciclos todo de desarrollo de ciclos cortos que se concentra en la fase de 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 El modelo de dominio consiste en diagramas de clases con clases, diagramas de clases con clases, relaciones, mrelaciones, méétodos y atributos. todos y atributos. Los mLos méétodos no reflejan conveniencias de todos no reflejan conveniencias de programaciprogramacióón sino rasgos funcionales.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, desarrollConsortium, desarrollóó ASD hacia el 2000 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 optimizacique la optimizacióón es la n es la úúnica solucinica solucióón para n para problemas de complejidad creciente. problemas de 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 amos buscar mmáás bien, afirma Highsmith, s bien, afirma Highsmith, ““el rigor el rigor estrictamente necesarioestrictamente 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-organizaciAuto-organizacióón, adaptacin, adaptacióón al cambio y n al cambio y orden orden emergenteemergenteAnalogAnalogíí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 celulares).matas celulares).Los proyectos de software son sistemas adaptativos Los proyectos de software son sistemas adaptativos complejoscomplejos y la optimizaci 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 miembros como agentes y el producto como el resultado producto como el resultado emergente de relaciones de competencia y cooperaciemergente de relaciones de competencia y cooperacióónn. . En los sistemas complejos En los sistemas complejos no es aplicable el anno es aplicable el anáálisislisis, , 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 caractercaracteríísticas del conjunto (ejemplo del agua)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 cubrIgual que Agile Modeling, que cubríía a aspectos de modelado y documentaciaspectos de modelado y documentacióón, n, LD y LSD han sido pensados como LD y LSD han sido pensados como complemento de otros mcomplemento de otros méétodos, y no como todos, y no como una metodologuna metodologíía excluyente.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 tPara las téécnicas concretas de cnicas concretas de programaciprogramacióón, LD promueve el uso de n, LD promueve el uso de otros MAs que sean consistentes con su otros MAs que sean consistentes con su visivisióón, como XPn, 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

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, Conjunto de principios, modelos, disciplinas, conceptos, lineamientos y prácticas probadas”conceptos, lineamientos y prácticas probadas”http://www.microsoft.com/technet/itsolutions/techguide/msf/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

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

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, Los métodos ágiles llegaron para quedarse, aunque la histeria se está moderando aunque la 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 Pero hay fuertes críticas respecto de la adecuación de UML para ese propósito – Arquitectura de software UML para ese propósito – Arquitectura de software no es no es diseño OOdiseño OO

El debate está lejos de resolverse en el mediano El debate está lejos de resolverse en el mediano plazoplazoNo se puede negar el valor de la auto-No se puede negar el valor de la auto-organización (Internet, 9/11, Toyota)organización (Internet, 9/11, Toyota)… … pero nadie sabe cómo se organiza lo que se pero nadie sabe cómo se organiza lo que se auto-organizaauto-organizaNo 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 todavía no están ni a favor ni en contra. Yo tampocotampoco

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 AIRESbillyr@microsoft.com.ar