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