Post on 11-Jun-2015
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