alternativas metodológicas
TRANSCRIPT
Alternativas Alternativas metodológicasmetodológicas
Carlos ReynosoCarlos ReynosoUNIVERSIDAD DE BUENOS AIRESUNIVERSIDAD DE BUENOS [email protected]@hotmail.comhttp://www.microsoft.com/spanish/msdn/http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/arquitectura_soft.mspxarquitectura/roadmap_arq/arquitectura_soft.mspx
AgendaAgenda
Alternativas de peso completo vs ágilesAlternativas de peso completo vs ágiles Contexto de situaciónContexto de situación Manifiesto ágilManifiesto ágil Métodos ágilesMétodos ágiles eXtreme Programming (XP)eXtreme Programming (XP) Otros métodos ágilesOtros métodos ágiles Métodos ágiles & MSF 3.0Métodos ágiles & MSF 3.0 Críticas a Métodos ÁgilesCríticas a Métodos Ágiles ConclusionesConclusiones http://www.microsoft.com/spanish/msdn/arquitecturahttp://www.microsoft.com/spanish/msdn/arquitectura
Paper
Tabla de Métodos Tabla de Métodos SEI/CMUSEI/CMU Architecture Tradeoff Analysis Method (ATAM)Architecture Tradeoff Analysis Method (ATAM) Quality Attribute Workshops (QAW)Quality Attribute Workshops (QAW) Attribute-Driven Design (ADD)Attribute-Driven Design (ADD) Active Reviews for Intermediate Designs (ARID)Active Reviews for Intermediate Designs (ARID) Cost-Benefit Analysis Method (CBAM)Cost-Benefit Analysis Method (CBAM) Software Architecture Comparison Analysis Software Architecture Comparison Analysis
Method (SACAM)Method (SACAM) Quality-Attribute-Driven Software Architecture Quality-Attribute-Driven Software Architecture
Reconstruction (QADSAR)Reconstruction (QADSAR) Architecture Based Design Method (ABD)Architecture Based Design Method (ABD) Software Architecture Analysis Method (SAAM)Software Architecture Analysis Method (SAAM)
Métodos y frameworksMétodos y frameworks
Estándares de certificación (CMMI)Estándares de certificación (CMMI) Paraguas envolventes (MSF)Paraguas envolventes (MSF) Artefactos y disciplinas (RUP)Artefactos y disciplinas (RUP) Métodos puntuales (Evo)Métodos puntuales (Evo) Metodologías basadas en arquitecturaMetodologías basadas en arquitectura Anti-arquitecturasAnti-arquitecturas Frameworks diversos…Frameworks diversos…
Contexto de situaciónContexto de situación
Descrédito de los procesos en cascadaDescrédito de los procesos en cascada DOD 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 requerimientos y con análisis completo de requerimientos y planificación detalladaplanificación detallada CMM, CMMI, Spice, Bootstrap, TickIt, ISO CMM, CMMI, Spice, Bootstrap, TickIt, ISO
90009000 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órdicas No linealidad: El mítico hombre-mes No linealidad: El mítico hombre-mes
(Brooks)(Brooks) Orden a partir del caos (Kauffman, Hock)Orden a partir del caos (Kauffman, Hock) Sistemas adaptativos complejos (Holland)Sistemas adaptativos complejos (Holland) 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, haciéndolo mejores de desarrollo de software, haciéndolo y ayudando a otros a que lo hagan. A través de y ayudando a otros a que lo hagan. A través de este trabajo hemos llegado a valorar:este trabajo hemos 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 izquierda.derecha, 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 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 (Pragmatic Highsmith (ASD), Andrew Hunt (Pragmatic Programming), Ron Jeffries (XP), Jon Kern Programming), Ron Jeffries (XP), Jon Kern (FDD), Brian Marick, Robert C. Martin (XP), (FDD), Brian Marick, Robert C. Martin (XP), Steve Mellor, Ken Schwaber (Scrum), Jeff Steve Mellor, Ken Schwaber (Scrum), Jeff Sutherland (Scrum) y Dave Thomas Sutherland (Scrum) y Dave Thomas (Pragmatic Programming)(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íbridos
Enterprise XP (DSDM + XP) - Mike GriffithsEnterprise XP (DSDM + XP) - Mike Griffiths XP@Scrum - ScrumXP@Scrum - Scrum Xbreed (XP+Scrum) - Mike BeedleXbreed (XP+Scrum) - Mike Beedle Industrial XP - Industrial LogicIndustrial XP - Industrial Logic Dispersed Extreme Programming (DXP) - Michael Dispersed Extreme Programming (DXP) - Michael
Kircher, SiemensKircher, Siemens Dispersed Development - Alan Cameron Wills (MS), Dispersed Development - Alan Cameron Wills (MS),
FastnLoose - Patrones para desarrollo ágil FastnLoose - Patrones para desarrollo ágil distribuidodistribuido
Grizzly (“large Agile”) - Ron Crocker, MotorolaGrizzly (“large Agile”) - Ron Crocker, Motorola Evo+XP, Evo+UP, Evo+Scrum, XP+UP, UP+ScrumEvo+XP, Evo+UP, Evo+Scrum, XP+UP, UP+Scrum
Constantes de los Constantes de los métodos ágilesmétodos ágiles Metodologí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-organizados Comunicación intensivaComunicación intensiva MinimalismoMinimalismo
Prescindencia de arquitectura y modeladoPrescindencia de arquitectura y modelado
Proceso iterativo e incrementalProceso iterativo e incremental Entregas rápidasEntregas rápidas
Capacidad adaptativaCapacidad adaptativa Rápida respuesta al cambioRápida respuesta al cambio
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 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 Do The Simplest Thing That Can Possibly WorkSimplest Thing That Can Possibly Work””; BUFD, ; BUFD, ““Big Big Upfront DesignUpfront 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, 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
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 programadores 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 mirandoNo es un programador trabajando y el otro mirando No es una sesión de aprendizaje para un programador juniorNo es una sesión de aprendizaje para un programador junior El 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ía Fundamentos:Fundamentos:
dos programadores trabajando juntos son más efectivos que por dos programadores trabajando juntos son más efectivos que por separadoseparado
el conocimiento grupal crece más rápidoel conocimiento grupal crece más rápido trabajar es más divertidotrabajar es más divertido
PruebasPruebas
TTest est DDriven riven DDevelopmentevelopment Diseño e implementación de las pruebas antes Diseño e implementación de las pruebas antes
de programar la funcionalidadde programar la funcionalidad El programador crea sus propios tests de El programador crea sus propios tests de
unidadunidad Integración continuaIntegración continua
Integración diariaIntegración diaria Disponer de una máquina para integraciónDisponer de una máquina para integración
Tests funcionalesTests funcionales ClienteCliente
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 personal Mejora la calidad del productoMejora la calidad del producto Se permiten excepciones, con cuidadoSe permiten excepciones, con cuidado
más de una semana de horas extra: problemamás de una semana de horas extra: problema
Lugar de trabajoLugar de trabajo
Sala amplia (mejor, sin divisiones)Sala amplia (mejor, sin divisiones) Centro: pares de programadoresCentro: pares de programadores Periferia: máquinas individualesPeriferia: máquinas individuales
Ventajas del espacio abierto:Ventajas del espacio abierto: mayor comunicaciónmayor comunicación agenda 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
producidoproducido Estrategia: poner en producción las características Estrategia: poner en producción las características
más importantes lo antes posiblemás importantes lo antes posible Piezas: Piezas: story cardsstory cards Jugadores: desarrolladores y clienteJugadores: desarrolladores y cliente Movidas: 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 continua No siempre se consigueNo siempre se consigue
muy junior, no sirvemuy junior, no sirve muy 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 autoridad Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del código fuentepara cambiar cualquier parte del código fuente
Todos son dueños del códigoTodos son dueños del código Siempre se utilizan estándaresSiempre se utilizan estándares Los 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
permanentementepermanentemente Manejo 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 CRC Design for change vs Design for todayDesign for change vs Design for today
Características útiles en términos del negocioCaracterísticas útiles en términos del negocio No 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 posible Unas 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 funcionamientocódigo sin cambiar su funcionamiento Ejemplos: extraer método, renombrar Ejemplos: extraer método, renombrar
(clase, método, variable, etc.), reemplazar(clase, método, variable, etc.), reemplazar Hay herramientasHay herramientas
C#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 clientecliente desarrolladoresdesarrolladores
La metáfora puede cambiar La metáfora puede cambiar permanentementepermanentemente
Ciclo de vidaCiclo de vida
XP - SíntesisXP - Síntesis
Prácticas conjuntas
IteracionesVocabulario 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 New The New Product Development GameProduct Development Game
En software, Jeff Sutherland, Ken Schwaber, 1995En software, Jeff Sutherland, Ken Schwaber, 1995 Aplica principios de procesos de control industrial, Aplica principios de procesos de control industrial,
junto con experiencias metodoljunto con experiencias metodolóógicas de Microsoft, gicas de Microsoft, Borland y Hewlett-PackardBorland y Hewlett-Packard
No es método independiente, sino complemento de No es método independiente, sino complemento de otras metodologías XP, MSF, RUP)otras metodologías XP, MSF, RUP)
Enfatiza valores y prácticas de gestión, no cuestiones Enfatiza valores y prácticas de gestión, no cuestiones técnicas de desarrolloté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 tque decida, ni otros tíítulos que tulos que ““miembros del equipomiembros del equipo”” o o ““cerdoscerdos””; la excepci; la excepcióón es el n es el Scrum Master Scrum Master que debe ser 50% que debe ser 50% programador y que resuelve problemas, pero no manda. Los programador y que resuelve problemas, pero no manda. Los observadores externos se llaman observadores externos se llaman ““gallinasgallinas””; pueden observar, ; pueden observar, pero no interferir ni opinar.pero no interferir ni opinar.
Una vez elegida una tarea, no se agrega trabajo extra. En Una vez elegida una tarea, no se agrega trabajo extra. En caso que se agregue algo, se recomienda quitar alguna otra cosa.caso que se agregue algo, se recomienda quitar 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 diario impide rculo. El encuentro diario impide caer en el dilema secaer en el dilema seññalado por Fred Brooks: alado por Fred Brooks: “¿“¿CCóómo es que un mo es que un proyecto puede atrasarse un aproyecto puede atrasarse un aññ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 guiado n, planeamiento adaptativo guiado por el cliente.por el cliente.
Ciclo de ScrumCiclo de Scrum
Ciclo de Scrum (2)Ciclo de Scrum (2)
Acumulación deProducto:
Acumulación de Carrera:
Artefactos de ScrumArtefactos de Scrum
Acumulación (backlog) de productoAcumulación (backlog) de producto
Acumulación de carreraAcumulación de carrera
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 los n prohibidas. En los encuentros diarios, las gallinas deben estar fuera del encuentros diarios, las gallinas deben estar fuera del ccíírculo. rculo.
Todos tienen que ser puntuales; si alguien llega tarde, se le Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinarcobra una multa que se destinaráá a obras de caridad. a obras de 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 UP, e, p. Ej. Listas de Riesgos si se utiliza UP, Planguage si el mPlanguage si el méétodo es Evo, o los Planes de Proyecto todo es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestisugeridos en la disciplina de Gestióón de Proyectos de MSF. n de Proyectos de MSF.
No es legal el uso de instrumentos como diagramas PERT, No es legal el uso de instrumentos como diagramas PERT, porque parten del supuesto de que las tareas de un porque parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenarproyecto se pueden identificar y ordenar
El supuesto dominante es que el desarrollo es semi-El supuesto dominante es que el desarrollo es semi-cacaóótico, cambiante y tiene demasiado ruido como para que tico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido.se le aplique un proceso definido.
Feature Driven Development Feature Driven Development (FDD) (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. Un rasgo es una función pequeña cliente. Un rasgo es una función pequeña expresada en la forma expresada en la forma <acción><acción> <<resultadoresultado>> <por | <por | para | de | a> para | de | a> <objeto><objeto> con los operadores con los operadores adecuados entre los términos. Por ejemplo,adecuados entre los términos. Por ejemplo, calcularcalcular el importe total el importe total de de una venta una venta;; determinar determinar la última operaciónla ú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 No cubre todo el ciclo de vida, sino
diseño y construccióndiseño y construcción Se considera apto para proyectos Se considera apto para proyectos
mayores o de misión críticamayores o de misión crítica Hay arquitectos en FDDHay arquitectos en FDD Numerosos artefactos para el control del Numerosos artefactos para el control del
procesoproceso
Feature Driven Development Feature Driven Development (FDD)(FDD) Ciclo de vidaCiclo de vida
Feature Driven Development Feature Driven Development (FDD)(FDD)
Ensayo Diseño Inspección de Diseño
Código Inspección de Código
Promover a Build
Id Descripción Pro
g. Jefe.
Prop.
Clase Pla
n Act
ual Pla
n Act
ual Pla
n Act
ual Pla
n Act
ual Pla
n Actual
Plan
Actual
MD125
Validar los límites transaccionales de un CAO contra una instrucción de implementación
CP AB
C 23/
12/98 23/
12/98 31/
01/99 31/
01/99 01/
02/99 01/
02/99 10/
02/99
18/02/99
20/
02/99
MD126
Definir el estado de una instrucción de implementación
CP AB
C 23/
12/98 23/
12/98 31/
01/99 31/
01/99 01/
02/99 01/
02/99 10/
02/99 18/
02/99 20/
02/99
MD127
Especificar el oficial de autorización de una instrucción de implementación
CP AB
C 23/
12/98 23/
12/98 31/
01/99 31/
01/99 01/
02/99 01/
02/99 10/
02/99 18/
02/99 20/
02/99
MD128
Rechazar una instrucción de implementación para un conjunto de líneas
CP AB
C STATUS: Inactivo NOTA: [agregado por CK: 3/2/99] No aplicable
MD129
Confirmar una instrucción de implementación para un conjunto de líneas
CP AB
C 23/
12/98 23/
12/98 31/
01/99 31/
01/99 01/
02/99 01/
02/99 10/
02/99 18/
02/99 20/
02/99
23/12/98
23/12/98
31/01/99
31/01/99
01/02/99
01/02/99
05/02/99
08/02/99
10/02/99
MD1
30
Determinar si todos los documentos se han completado para un prestatario
CP AB
C NOTA: [agregado por SL: 3/2/99] Bloqueado en AS
23/12/98
23/12/98
31/01/99
31/01/99
01/02/99
01/02/99
05/02/99
08/02/99
10/02/99
MD1
31
Validar los límites transaccionales de un CAO contra una instrucción de desembolso
CP AB
C NOTA: [agregado por: 3/2/99] Atrasado según estimaciones iniciales
MD132
Enviar para autorización una instrucción de implementación
CP AB
C 23/
12/98 23/
12/98 31/
01/99 31/
01/99 01/
02/99 01/
02/99 05/
02/99 05/
02/99 06/
02/99 06/02
/99 08/
02/99 08/02
/99
MD133
Validar fecha de baja de una instrucción de implementación
CP AB
C 23/
12/98 23/
12/98 31/
01/99 31/
01/99 01/
02/99 01/
02/99 05/
02/99 05/
02/99 06/
02/99 06/02
/99 08/
02/99 08/02
/99
Feature Driven Development Feature Driven Development (FDD)(FDD) En sEn sííntesis, FDD es un mntesis, FDD es un méétodo de desarrollo todo de desarrollo
de ciclos cortos que se concentra en la fase de de ciclos 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 diagramas El modelo de dominio consiste en diagramas de clases con clases, relaciones, mde clases con clases, relaciones, méétodos y todos y atributos. atributos.
Los mLos méétodos no reflejan conveniencias de todos no reflejan conveniencias de programaciprogramacióón sino rasgos funcionales.n sino rasgos funcionales.
Best practicesBest practices en otros en otros métodosmétodos DSDMDSDM
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 Consortium, James Highsmith III, consultor de Cutter Consortium,
desarrolldesarrollóó ASD hacia el a ASD hacia el añño 2000o 2000 Alternativa a la idea, propia de CMM Nivel 5, de que la Alternativa a la idea, propia de CMM Nivel 5, de que la
optimizacioptimizacióón es la n es la úúnica solucinica solucióón para problemas de n para problemas de complejidad creciente. 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 mamos buscar máás s bien, afirma Highsmith, bien, afirma Highsmith, ““el rigor estrictamente el rigor estrictamente necesarionecesario””
Para ello hay que situarse en coordenadas apenas un Para ello hay que situarse en coordenadas apenas un poco fuera del caos y ejercer menos control que el que poco fuera del caos y ejercer menos control que el que se cree necesario.se cree necesario.
Ciclo de ASDCiclo de ASD
Adaptive Software Adaptive Software DevelopmentDevelopment Auto-organizaciAuto-organizacióón, adaptacin, adaptacióón al cambio y orden emergenten al cambio y orden emergente AnalogAnalogíí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 celularesmatas celulares
Los proyectos de software son sistemas adaptativos Los proyectos de software son sistemas adaptativos complejos y la optimizacicomplejos 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 producto como el resultado miembros como agentes y el producto como el resultado emergente de relaciones de competencia y cooperaciemergente de relaciones de competencia y cooperacióón. n.
En los sistemas complejos no es aplicable el anEn los sistemas complejos no es aplicable el anáálisis, porque lisis, porque no puede no puede deducirsededucirse el comportamiento del todo a partir de la el comportamiento del todo a partir de la conducta de las partes, ni sumarse las propiedades conducta de las partes, ni sumarse las propiedades individuales para determinar las caracterindividuales para determinar las caracteríísticas del conjuntosticas del conjunto
Lean DevelopmentLean Development
Lean: magro, enjuto – James Womack, Lean: magro, enjuto – James Womack, 1990, La máquina que cambió al mundo1990, La máquina que cambió al mundo
Patrones organizacionalesPatrones organizacionales Herramientas de TQM( Edward Deming)Herramientas de TQM( Edward Deming) Software: Bob Charette, 2001Software: Bob Charette, 2001 No se limita al proceso de desarrollo – No se limita al proceso de desarrollo –
Hay que conocer el negocio de punta a Hay que conocer el negocio de punta a puntapunta
Principios de Lean Principios de Lean DevelopmentDevelopment
1. Satisfacer al cliente es la máxima prioridad.1. Satisfacer al cliente es la máxima prioridad. 2.2. Proporcionar siempre el mejor valor por la inversi Proporcionar siempre el mejor valor por la inversióón.n. 3.3. El El ééxito depende de la activa participacixito depende de la activa participacióón del cliente.n del cliente. 4.4. Cada proyecto LD es un esfuerzo de equipo. Cada proyecto LD es un esfuerzo de equipo. 5.5. Todo se puede cambiar. Todo se puede cambiar. 6.6. Soluciones de dominio, no puntos. Soluciones de dominio, no puntos. 7.7. Completar, no construir. Completar, no construir. 8.8. Una soluci Una solucióón al 80% hoy, en vez de una al 100% man al 80% hoy, en vez de una al 100% maññana.ana. 9.9. El minimalismo es esencial. El minimalismo es esencial. 10.10. La necesidad determina la tecnolog La necesidad determina la tecnologíía.a. 11.11. El crecimiento del producto es el incremento de sus El crecimiento del producto es el incremento de sus
prestaciones, no de su tamaprestaciones, no de su tamañño.o. 12.12. Nunca empujes LD m Nunca empujes LD máás alls alláá de sus l de sus líímites.mites.
Reformulación de Darell Reformulación de Darell NortonNorton 1.1. Eliminar basura (las herramientas son Eliminar basura (las herramientas son Seeing Seeing
Waste, Value Stream MappingWaste, Value Stream Mapping). Basura es todo lo que ). Basura es todo lo que no agregue valor a un producto, desde la no agregue valor a un producto, desde la óóptica del ptica del sistema de valores del cliente. Este principio equivale sistema de valores del cliente. Este principio equivale a la reduccia la reduccióón del inventario en manufactura. El n del inventario en manufactura. El inventario del desarrollo de software es el conjunto de inventario del desarrollo de software es el conjunto de artefactos intermedios. Un estudio del Standish Group artefactos intermedios. Un estudio del Standish Group revelrevelóó que en un sistema t que en un sistema tíípico, las prestaciones que pico, las prestaciones que se usan siempre suman el 7%, las que se usan a se usan siempre suman el 7%, las que se usan a menudo el 13%, menudo el 13%, ““algunas vecesalgunas veces”” el 16%, el 16%, ““raras vecesraras veces”” el 19% y el 19% y ““nuncanunca”” el 45%. Esto es un claro 80/20: el el 45%. Esto es un claro 80/20: el 80% del valor proviene del 20% de los rasgos. 80% del valor proviene del 20% de los rasgos.
Concentrarse en el 20% Concentrarse en el 20% úútil es una aplicacitil es una aplicacióón del n del mismo principio que subyace a la idea de YAGNI.mismo principio que subyace a la idea de YAGNI.
Lean DevelopmentLean Development
Igual que Agile Modeling, que cubrIgual que Agile Modeling, que cubríía aspectos a aspectos de modelado y documentacide modelado y documentacióón, LD y LSD han n, LD y LSD han sido pensados como complemento de otros sido pensados como complemento de otros mméétodos, y no como una metodologtodos, y no como una metodologíía a excluyente.excluyente.
LD prefiere concentrarse en las premisas y LD prefiere concentrarse en las premisas y modelos derivados de Lean Production (canon modelos derivados de Lean Production (canon de la Escuela de Negocios de Harvard). de la Escuela de Negocios de Harvard).
Para las tPara las téécnicas concretas de programacicnicas concretas de programacióón, n, LD promueve el uso de otros MAs que sean LD promueve el uso de otros MAs que sean consistentes con su visiconsistentes con su visióón, como XPn, como XP
EvoEvo
Competitive Engineering – Tom & Kai GilbCompetitive Engineering – Tom & Kai Gilb PlanguagePlanguage
Vincula todas las disciplinas de SEVincula todas las disciplinas de SE Expresa objetivos, estrategia, diseño y riesgoExpresa objetivos, estrategia, diseño y riesgo Basado 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 Planguage Descripción de requerimientos, diseños y planesDescripción de requerimientos, diseños y planes
Métodos PlanguageMétodos Planguage Especificación de requerimiento, con atributos Especificación de requerimiento, con atributos
cuantificadoscuantificados Estimación de impacto: implementación vs Estimación de impacto: implementación vs
requerimiento y evaluación de progresorequerimiento y evaluación de progreso Control 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
Evo
Agile ModelingAgile Modeling
Diagrama de artefactosDiagrama de artefactos
Métodos ágiles en MSFMétodos ágiles en MSF
Fuerte tradición de desarrollo ágil en Fuerte tradición de desarrollo ágil en MSMS 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 incremental
No á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 oficinas ), trabajar en oficinas privadas, ofrecerse a permanecer horas 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 Framework En 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/ms
f/msfovrvw.mspx Explí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 cliente Probado 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ón RUPRUP Evolutionary 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 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 ÁgilesCríticas a Métodos Ágiles
Rakitin, 2001 – Argumento hackerRakitin, 2001 – Argumento hacker Pete McBreen, 2002 – Questioning XPPete McBreen, 2002 – Questioning XP McConnell, 2002 – Hipnosis colectiva, McConnell, 2002 – Hipnosis colectiva, one size one size
fits allfits all, programación sin diseño, programación sin diseño Stephens-Rosenberg, 2003 – XP RefactoredStephens-Rosenberg, 2003 – XP Refactored Ed 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, (Escalabilidad, casos, programación de garage, TDD caro, reusabilidad, pero no COTS)TDD caro, reusabilidad, pero no COTS)
Mellor, Smith – Consignas estridentes, artefactos Mellor, Smith – Consignas estridentes, artefactos no reconocidosno reconocidos
Herramientas para Herramientas para desarrollo ágildesarrollo ágil
Patterns & PracticesPatterns & Practices Prueba de UnidadPrueba de Unidad
COMUnit - SourceForge, VB.NET & C#COMUnit - SourceForge, VB.NET & C# Nunit 2.1.4Nunit 2.1.4 csUnitcsUnit vbUnit 3 - Visual Basic .NETvbUnit 3 - Visual Basic .NET .TEST - Parasoft Software - Soporta NUnit.TEST - Parasoft Software - Soporta NUnit HarnessIt™ - UnitTesting.com - Prueba de unidad para HarnessIt™ - UnitTesting.com - Prueba de unidad para
lenguajes CLRlenguajes CLR Unite.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ón C# Refactoring Tool 1.5.1C# Refactoring Tool 1.5.1 Opnieuw - SourceForge, C#Opnieuw - SourceForge, C# Extreme Simplicity C# Refactory - VB Extreme Simplicity C# Refactory - VB
RefactoryRefactory ReSharper - JetBrains! C# Refactoring ToolReSharper - JetBrains! C# Refactoring Tool C# 2.0 Whidbey - Refactoring nativoC# 2.0 Whidbey - Refactoring nativo GeneXusGeneXus
ConclusionesConclusiones Distintas categorías de métodos ágilesDistintas categorías de métodos ágiles Los 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 management, XP (con organizacionales) como método de management, 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 como refactorización) como metodología de desarrollo, RUP como abastecedor de artefactos, ASD como cultura empresarial y abastecedor de artefactos, ASD como cultura empresarial y (si se requiere) CMM como metodología de evaluación de (si se requiere) CMM como metodología de evaluación de madurezmadurez
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 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
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: Refactoring: Improving the design of existing codeImproving the design of existing code. . Addison Wesley, 1999Addison Wesley, 1999
Kent 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, 2004
Tom Gilb. Tom Gilb. Competitive EngineeringCompetitive Engineering, , 2003.2003.
Will Stott, James Newkirk - “Test-driven Will Stott, James Newkirk - “Test-driven C#”. C#”. MSDN MagazineMSDN Magazine, Abril de 2004., Abril de 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?¿Preguntas?
Billy ReynosoBilly ReynosoUNIVERSIDAD DE BUENOS AIRESUNIVERSIDAD DE BUENOS [email protected]@microsoft.com.ar