Alternativas metodolgicas

Carlos Reynoso
UNIVERSIDAD DE BUENOS AIRES billyreyno@hotmail.com

http://www.microsoft.com/spanish/msdn/arquitectura/ roadmap_arq/arquitectura_soft.mspx

Agenda

Alternativas de peso completo vs giles Contexto de situacin Manifiesto gil Mtodos giles eXtreme Programming (XP) Otros mtodos giles Mtodos giles & MSF 3.0 Crticas a Mtodos giles Conclusiones http://www.microsoft.com/spanish/msdn/arquitectura Paper

Tabla de Mtodos SEI/CMU

Architecture Tradeoff Analysis Method (ATAM) Quality Attribute Workshops (QAW) Attribute-Driven Design (ADD) Active Reviews for Intermediate Designs (ARID) Cost-Benefit Analysis Method (CBAM) Software Architecture Comparison Analysis Method (SACAM) Quality-Attribute-Driven Software Architecture Reconstruction (QADSAR) Architecture Based Design Method (ABD) Software Architecture Analysis Method (SAAM)

Mtodos y frameworks

Estndares de certificacin (CMMI) Paraguas envolventes (MSF) Artefactos y disciplinas (RUP) Mtodos puntuales (Evo) Metodologas basadas en arquitectura Anti-arquitecturas Frameworks diversos

Contexto de situacin

Descrdito de los procesos en cascada

DOD STD 2167 MIL STD 498

Crisis de confianza en los procesos regidos por metodologas prescriptivas con anlisis completo de requerimientos y planificacin detallada

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

Legislacin negativa sobre conformidad con estndares de calidad

Contexto de situacin

Surgimiento de ideas cardicas

No linealidad: El mtico hombre-mes (Brooks) Orden a partir del caos (Kauffman, Hock) Sistemas adaptativos complejos (Holland) Auto-organizacin (B. Boehm) Modelo y ciclo de vida en Estrategia del Caos (Raccoon, 1995)

Manifiesto gil
http://agilemanifesto.org

Estamos poniendo al descubierto formas mejores de desarrollo de software, hacindolo y ayudando a otros a que lo hagan. A travs de este trabajo hemos llegado a valorar:

Los individuos y la interaccin por encima de los procesos y herramientas. El software que funciona por encima de la documentacin abarcadora. La colaboracin con el cliente por encima de la negociacin contractual. La respuesta al cambio por encima del seguimiento de un plan.

Aunque hay valor en los elementos a la derecha, valorizamos ms los de la izquierda.

Manifiesto gil
http://agilemanifesto.org

Kent Beck (XP), Mike Beedle, Arie van Bennekum (DSDM), Alistair Cockburn (Crystal), Ward Cunningham (XP), Martin Fowler (XP), James Grenning (XP), Jim Highsmith (ASD), Andrew Hunt (Pragmatic Programming), Ron Jeffries (XP), Jon Kern (FDD), Brian Marick, Robert C. Martin (XP), Steve Mellor, Ken Schwaber (Scrum), Jeff Sutherland (Scrum) y Dave Thomas (Pragmatic Programming)

Mtodos giles
Metodologa Adaptive Software Development Agile Modeling Crystal Methods Agile RUP Dynamic Solutions Delivery Model Evolutionary Project Management Extreme Programming Feature-driven development Lean Development Microsoft Solutions Framework Rapid Development Rational Unified Process Scrum Acrnimo ASD AM CM dX DSDM Evo XP FDD LD MSF RAD RUP Scrum Creacin Highsmith 2000 Ambler 2002 Cockburn 1998 Booch, Martin, Newkirk 1998 Stapleton 1997 Gilb 1976 Beck 1999 De Luca & Coad 1998 Palmer & Felsing 2002 Charette 2001, Mary y Tom Poppendieck Microsoft 1994 McConnell 1996 Kruchten 1996 Sutherland 1994 Schwaber 1995 Tipo de modelo Prcticas + Ciclo de vida Metodologa basada en la prctica Familia de metodologas Framework / Disciplina Framework / Modelo de ciclo de vida Framework adaptativo Disciplina en prcticas de ingeniera Metodologa Forma de pensar Modelo logstico Lineamientos, Disciplinas, Prcticas Survey de tcnicas y modelos Proceso unificado Proceso (framework de management) Caracterstica Inspirado en sistemas adaptativos complejos Suministra modelado gil a otros mtodos MA con nfasis en modelo de ciclos XP dado vuelta con artefactos RUP Creado por 16 expertos en RAD Primer mtodo gil existente Mtodo gil radical Mtodo gil de diseo y construccin Metodologa basada en procesos productivos Framework de desarrollo de soluciones Seleccin de best practices, no mtodo Mtodo (gil?) con modelado Complemento de otros mtodos, giles o no

Hbridos

Enterprise XP (DSDM + XP) - Mike Griffiths XP@Scrum - Scrum Xbreed (XP+Scrum) - Mike Beedle Industrial XP - Industrial Logic Dispersed Extreme Programming (DXP) - Michael Kircher, Siemens Dispersed Development - Alan Cameron Wills (MS), FastnLoose - Patrones para desarrollo gil distribuido Grizzly (large Agile) - Ron Crocker, Motorola Evo+XP, Evo+UP, Evo+Scrum, XP+UP, UP+Scrum

Constantes de los mtodos giles

Metodologa simple y fcil de aprender

Valores, Principios, Prcticas, Roles, Artefactos

Equipos no jerrquicos y auto-organizados Comunicacin intensiva Minimalismo

Prescindencia de arquitectura y modelado Entregas rpidas Rpida respuesta al cambio

Proceso iterativo e incremental

Capacidad adaptativa

Acrnimos y jerga

Scrum, gallinas, cerdos, corridas (sprints), pre-juego, juego y pos-juego (Scrum) - Pas (spikes) (Scrum, XP) El minimalismo es esencial, Todo se puede cambiar, Mejor 80% hoy que 100% maana (LD), Mirando basura (LSD), Refactorizacin implacable (XP) El Cono del Silencio, El Esqueleto Ambulante (CC) YAGNI You Arent Gonna Need It; TETCPB, Test Everything That Can Possibly Broke; DTSTTCPW, Do The Simplest Thing That Can Possibly Work; BUFD, Big Upfront Design. GoF, POSA Lo lamento por su vaca; no saba que era sagrada (Ron Jeffries) Si funciona bien, arrglelo de todos modos (Beck)

eXtreme Programming
Mtodo gil basado en cuatro principios: simplicidad, comunicacin, retroalimentacin, valor

Y varias prcticas: juego de planeamiento, entregas pequeas, metforas, diseo simple, pruebas continuas, refactorizacin, programacin por pares, propiedad colectiva, integracin continua, semana de 40 horas, cliente en el sitio, estndares de codificacin

Programacin por pares (pair programming)

Todo el cdigo es escrito por parejas de programadores

una sola mquina con un teclado y un mouse

No es un programador trabajando y el otro mirando No es una sesin de aprendizaje para un programador junior El que no est escribiendo

piensa ms estratgicamente revisa el cdigo en tiempo real

Los roles se pueden cambiar varias veces durante el da Fundamentos:

dos programadores trabajando juntos son ms efectivos que por separado el conocimiento grupal crece ms rpido trabajar es ms divertido

Pruebas

Test Driven Development

Diseo e implementacin de las pruebas antes de programar la funcionalidad El programador crea sus propios tests de unidad Integracin diaria Disponer de una mquina para integracin Cliente

Integracin continua

Tests funcionales

Semana de 40 horas

El desarrollo de software es un ejercicio creativo

hay que estar fresco y descansado

Sin hroes Se reduce la rotacin de personal Mejora la calidad del producto Se permiten excepciones, con cuidado

ms de una semana de horas extra: problema

Lugar de trabajo

Sala amplia (mejor, sin divisiones)

Centro: pares de programadores Periferia: mquinas individuales mayor comunicacin agenda dinmica

Ventajas del espacio abierto:

Juego de planificacin (planning game)

Determinar rpidamente el alcance de la prxima versin

prioridades de negocio (cliente) estimaciones tcnicas (desarrolladores) Objetivo: maximizar el valor del software producido Estrategia: poner en produccin las caractersticas ms importantes lo antes posible Piezas: story cards Jugadores: desarrolladores y cliente Movidas: Exploracin, Seleccin y Actualizacin

Por qu juego?

Story Cards

Cliente en el sitio

Interaccin continua No siempre se consigue

muy junior, no sirve muy senior, no quiere

Actualmente se pide un analista

Propiedad colectiva del cdigo

Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del cdigo fuente Todos son dueos del cdigo Siempre se utilizan estndares Los tests siempre deben funcionar al 100% Se integra con todo el sistema permanentemente Manejo de configuracin

Diseo simple, entregas pequeas

Se debe mantener el diseo lo mas simple posible (YAGNI): No vas a necesitarlo Tarjetas CRC Design for change vs Design for today

Caractersticas tiles en trminos del negocio No implementar caractersticas que no son necesarias

Poner en produccin lo antes posible Unas pocas semanas por entrega

Tarjetas CRC

Clase Responsabilidad Colaboracin

Refactorizacin

Si el cdigo se est volviendo complicado

modificar el diseo, volver a uno ms simple

Refactoring: modificar la forma del cdigo sin cambiar su funcionamiento

Ejemplos: extraer mtodo, renombrar (clase, mtodo, variable, etc.), reemplazar C#Refactory (Xtreme Simplicity)

Hay herramientas

Metfora

Reemplaza a la arquitectura Historia compartida sobre cmo funciona todo el sistema Lenguaje comn que todos puedan entender

cliente desarrolladores

La metfora puede cambiar permanentemente

Ciclo de vida

XP - Sntesis
Prcticas conjuntas

Iteraciones Vocabulario Comn Reemplaza a Metforas Espacio de trabajo abierto Retrospectivas Desarrollo orientado a pruebas Programacin en pares Refactorizacin Propiedad colectiva Integracin continua YAGNI (No habrs de necesitarlo) Equivale a Diseo Simple Responsabilidad aceptada Cobertura area para el equipo Revisin trimestral Espejo El manager debe comunicar un fiel reflejo del estado de cosas Ritmo sostenible Narracin de historias Planeamiento de entrega Prueba de aceptacin Entregas frecuentes

Prcticas de Programador

Prcticas de Management

Prcticas de Cliente

Scrum

Primera referencia: Takeuchi-Nonaka, 1986, The New Product Development Game En software, Jeff Sutherland, Ken Schwaber, 1995 Aplica principios de procesos de control industrial, junto con experiencias metodolgicas de Microsoft, Borland y Hewlett-Packard No es mtodo independiente, sino complemento de otras metodologas XP, MSF, RUP) Enfatiza valores y prcticas de gestin, no cuestiones tcnicas de desarrollo

Principios de Scrum

Equipos auto-dirigidos y auto-organizados. No hay manager que decida, ni otros ttulos que miembros del equipo o cerdos; la excepcin es el Scrum Master que debe ser 50% programador y que resuelve problemas, pero no manda. Los observadores externos se llaman gallinas; pueden observar, pero no interferir ni opinar. Una vez elegida una tarea, no se agrega trabajo extra. En caso que se agregue algo, se recomienda quitar alguna otra cosa. Encuentros diarios con las tres preguntas Se realizan siempre en el mismo lugar, en crculo. El encuentro diario impide caer en el dilema sealado por Fred Brooks: Cmo es que un proyecto puede atrasarse un ao?: Un da a la vez [Bro95]. Iteraciones de treinta das; se admite que sean ms frecuentes. Demostracin a participantes externos al fin de cada iteracin. Al principio de cada iteracin, planeamiento adaptativo guiado por el cliente.

Ciclo de Scrum

Ciclo de Scrum (2)

Acumulacin de Producto:

Acumulacin de Carrera:

Artefactos de Scrum

Acumulacin (backlog) de producto

Acumulacin de Producto:
Tipo: Nuevo __ Mejora __ Arreglo: __ Descripcin Notas Fuente: Fecha: Estimado:

Acumulacin de carrera
Fecha: Acumulacin de Corrida: Propietario: Status: Activo___Completo___ Descripcin: Pendiente___

Trabajo Pendiente/Fecha

Notas:

Prcticas de Scrum

Al fin de cada iteracin de treinta das hay una demostracin a cargo del Scrum Master. Las presentaciones en PowerPoint estn prohibidas. En los encuentros diarios, las gallinas deben estar fuera del crculo. Todos tienen que ser puntuales; si alguien llega tarde, se le cobra una multa que se destinar a obras de caridad. Es permitido usar artefactos de los mtodos a los que Scrum acompae, p. Ej. Listas de Riesgos si se utiliza UP, Planguage si el mtodo es Evo, o los Planes de Proyecto sugeridos en la disciplina de Gestin de Proyectos de MSF. No es legal el uso de instrumentos como diagramas PERT, porque parten del supuesto de que las tareas de un proyecto se pueden identificar y ordenar El supuesto dominante es que el desarrollo es semicatico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido.

Feature Driven Development (FDD) [DeLuca, Coad]

No

FOP, pero s Desarrollo por Rasgo

El seguimiento del progreso se realiza mediante examen de pequeas funcionalidades descompuestas y funciones valoradas por el cliente. Un rasgo es una funcin pequea expresada en la forma <accin> <resultado> <por | para | de | a> <objeto> con los operadores adecuados entre los trminos. Por ejemplo, calcular el importe total de una venta; determinar la ltima operacin de un cajero; validar la contrasea de un usuario.

Feature Driven Development (FDD)

No cubre todo el ciclo de vida, sino diseo y construccin Se considera apto para proyectos mayores o de misin crtica Hay arquitectos en FDD Numerosos artefactos para el control del proceso

Feature Driven Development (FDD)

Ciclo de vida

Feature Driven Development (FDD)

Id Descripcin Validar los lmites MD1 transaccionales de un CAO contra una instruccin de implementacin Definir el estado de una MD1 instruccin de implementacin Especificar el oficial de MD1 autorizacin de una instruccin de implementacin Rechazar una MD1 instruccin de implementacin para un conjunto de lneas Confirmar una MD1 instruccin de implementacin para un conjunto de lneas Determinar si todos los MD1 documentos se han completado para un prestatario Validar los lmites MD1 transaccionales de un CAO contra una instruccin de desembolso Enviar para autorizacin MD1 una instruccin de implementacin Validar fecha de baja de MD1 una instruccin de implementacin Pro Pro g. p. Jefe. Clase CP AB C AB C AB C AB C Ensayo Pla n Act ual Diseo Pla n Act ual Inspeccin de Diseo Pla Act n ual Cdigo Pla n Act ual Inspeccin de Cdigo Pla Actu n al 18/ 02/99 18/ 02/99 18/ 02/99 Promover a Build Pla Actu n al 20/ 02/99 20/ 02/99 20/ 02/99 25 23/ 23/ 31/ 31/ 01/ 01/ 10/ 12/98 12/98 01/99 01/99 02/99 02/99 02/99 23/ 23/ 31/ 31/ 01/ 01/ 10/ 12/98 12/98 01/99 01/99 02/99 02/99 02/99 23/ 23/ 31/ 31/ 01/ 01/ 10/ 12/98 12/98 01/99 01/99 02/99 02/99 02/99

26

CP

27

CP

28

CP

STATUS: Inactivo NOTA: [agregado por CK: 3/2/99] No aplicable

29

CP

AB C

23/ 23/ 31/ 31/ 01/ 01/ 10/ 12/98 12/98 01/99 01/99 02/99 02/99 02/99

18/ 02/99 08/ 02/99 08/ 02/99

20/ 02/99 10/ 02/99 10/ 02/99

30

CP

23/ 23/ 31/ 31/ 01/ 01/ 05/ AB 12/98 12/98 01/99 01/99 02/99 02/99 02/99 C NOTA: [agregado por SL: 3/2/99] Bloqueado en AS 23/ 23/ 31/ 31/ 01/ 01/ 05/ AB 12/98 12/98 01/99 01/99 02/99 02/99 02/99 C AB C AB C NOTA: [agregado por: 3/2/99] Atrasado segn estimaciones iniciales

31

CP

32

CP CP

23/ 23/ 31/ 31/ 01/ 01/ 05/ 05/ 06/ 06/02 08/ 08/02 12/98 12/98 01/99 01/99 02/99 02/99 02/99 02/99 02/99 /99 02/99 /99 23/ 23/ 31/ 31/ 01/ 01/ 05/ 05/ 06/ 06/02 08/ 08/02 12/98 12/98 01/99 01/99 02/99 02/99 02/99 02/99 02/99 /99 02/99 /99

33

Feature Driven Development (FDD)

En sntesis, FDD es un mtodo de desarrollo de ciclos cortos que se concentra en la fase de diseo y construccin. En la primera fase, el modelo global de dominio es elaborado por expertos del dominio y desarrolladores; El modelo de dominio consiste en diagramas de clases con clases, relaciones, mtodos y atributos. Los mtodos no reflejan conveniencias de programacin sino rasgos funcionales.

Best practices en otros mtodos

DSDM

Prcticas escalables - Reglas MoSCoW [Must, Should, Could, Want]

Adaptive Software Development

James Highsmith III, consultor de Cutter Consortium, desarroll ASD hacia el ao 2000 Alternativa a la idea, propia de CMM Nivel 5, de que la optimizacin es la nica solucin para problemas de complejidad creciente. Tercera va entre el desarrollo monumental de software y el desarrollo accidental, o entre la burocracia y la adhocracia. Deberamos buscar ms bien, afirma Highsmith, el rigor estrictamente necesario Para ello hay que situarse en coordenadas apenas un poco fuera del caos y ejercer menos control que el que se cree necesario.

Ciclo de ASD

Adaptive Software Development

Auto-organizacin, adaptacin al cambio y orden emergente Analogas con los sistemas adaptativos complejos por excelencia: los organismos vivientes (o sus anlogos digitales: redes neuronales auto-organizativas de Teuvo Kohonen y autmatas celulares Los proyectos de software son sistemas adaptativos complejos y la optimizacin no hace ms que sofocar la emergencia necesaria para afrontar el cambio. Highsmith interpreta la organizacin empresarial que emprende un desarrollo como si fuera un ambiente, sus miembros como agentes y el producto como el resultado emergente de relaciones de competencia y cooperacin. En los sistemas complejos no es aplicable el anlisis, porque no puede deducirse el comportamiento del todo a partir de la conducta de las partes, ni sumarse las propiedades individuales para determinar las caractersticas del conjunto

Lean Development

Lean: magro, enjuto James Womack, 1990, La mquina que cambi al mundo Patrones organizacionales Herramientas de TQM( Edward Deming) Software: Bob Charette, 2001 No se limita al proceso de desarrollo Hay que conocer el negocio de punta a punta

Principios de Lean Development

1. Satisfacer al cliente es la mxima prioridad. 2. Proporcionar siempre el mejor valor por la inversin. 3. El xito depende de la activa participacin del cliente. 4. Cada proyecto LD es un esfuerzo de equipo. 5. Todo se puede cambiar. 6. Soluciones de dominio, no puntos. 7. Completar, no construir. 8. Una solucin al 80% hoy, en vez de una al 100% maana. 9. El minimalismo es esencial. 10. La necesidad determina la tecnologa. 11. El crecimiento del producto es el incremento de sus prestaciones, no de su tamao. 12. Nunca empujes LD ms all de sus lmites.

Reformulacin de Darell Norton

1. Eliminar basura (las herramientas son Seeing Waste, Value Stream Mapping). Basura es todo lo que no agregue valor a un producto, desde la ptica del sistema de valores del cliente. Este principio equivale a la reduccin del inventario en manufactura. El inventario del desarrollo de software es el conjunto de artefactos intermedios. Un estudio del Standish Group revel que en un sistema tpico, las prestaciones que se usan siempre suman el 7%, las que se usan a menudo el 13%, algunas veces el 16%, raras veces el 19% y nunca el 45%. Esto es un claro 80/20: el 80% del valor proviene del 20% de los rasgos. Concentrarse en el 20% til es una aplicacin del mismo principio que subyace a la idea de YAGNI.

Lean Development

Igual que Agile Modeling, que cubra aspectos de modelado y documentacin, LD y LSD han sido pensados como complemento de otros mtodos, y no como una metodologa excluyente. LD prefiere concentrarse en las premisas y modelos derivados de Lean Production (canon de la Escuela de Negocios de Harvard). Para las tcnicas concretas de programacin, LD promueve el uso de otros MAs que sean consistentes con su visin, como XP

Evo

Competitive Engineering Tom & Kai Gilb

Planguage

Vincula todas las disciplinas de SE Expresa objetivos, estrategia, diseo y riesgo Basado en Plan-Do-Study-Act (Deming, Juran, Shewhart) Descripcin de requerimientos, diseos y planes Especificacin de requerimiento, con atributos cuantificados Estimacin de impacto: implementacin vs requerimiento y evaluacin de progreso Control de calidad de especificacin (SQC - Excel) Evolutionary Project Management: pasos pequeos (2%) evolutivos de alto valor

Lenguaje de especificacin Planguage

Mtodos Planguage

Evo

Planguage

CUSTOMER.SATISFACTION SCALE: evaluacin promedio de la satisfaccin 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 Modeling

Diagrama de artefactos

Mtodos giles en MSF

Fuerte tradicin de desarrollo gil en MS

Steve McConnell, Code Complete (1993)

Programacin en pares Modelo de ciclo de vida evolutivo, encuentros y talleres de equipo, revisiones frecuentes, diseo para el cambio, entrega evolutiva, reutilizacin, prototipado evolutivo, comunicacin intensa, desarrollo iterativo e incremental No gil: recomendacin de establecer metas fijas de antemano, contratar a terceros para realizar parte del cdigo (outsourcing), trabajar en oficinas privadas, ofrecerse a permanecer horas extraordinarias - Oposicin de McConnell a XP

Steve McConnell, Rapid Development (1996)

Ron Jeffries & Ward Cunningham

Mtodos giles en MSF

Microsoft Solutions Framework

En evolucin desde 1994 Conjunto de principios, modelos, disciplinas, conceptos, lineamientos y prcticas probadas http://www.microsoft.com/technet/itsolutions/techguide/ms f/msfovrvw.mspx Explcitamente definido como framework apto para mtodos giles Modelo de Procesos iterativo e incremental, con participacin activa del cliente Probado en combinacin con mtodos giles

Agile Modeling (Ambler) DSDM - Documento conjunto de coordinacin RUP Evolutionary Project Management - Best practices

Mtodos giles en MSF

8 principios:

Alentar comunicaciones abiertas (Brooks)

Trabajar hacia una visin compartida (Highsmith) Otorgar poder a los miembros del equipo Establecer responsabilidad clara y compartida Concentrarse en la entrega de valor de negocios Permanecer gil, esperar el cambio (Highsmith) Invertir en calidad

Aprender de todas las experiencias

Crticas a Mtodos giles

Rakitin, 2001 Argumento hacker Pete McBreen, 2002 Questioning XP McConnell, 2002 Hipnosis colectiva, one size fits all, programacin sin diseo Stephens-Rosenberg, 2003 XP Refactored Ed Berard, 2003 Falacias Gerold Keffer, 2003 XP considered harmful.. (Escalabilidad, casos, programacin de garage, TDD caro, reusabilidad, pero no COTS) Mellor, Smith Consignas estridentes, artefactos no reconocidos

Herramientas para desarrollo gil

Patterns & Practices Prueba de Unidad

COMUnit - SourceForge, VB.NET & C# Nunit 2.1.4 csUnit vbUnit 3 - Visual Basic .NET .TEST - Parasoft Software - Soporta NUnit HarnessIt - UnitTesting.com - Prueba de unidad para lenguajes CLR Unite.NET - Ascentiv - Prueba de unidad e integracin Independiente de lenguaje

Herramientas para desarrollo gil

Refactorizacin

C# Refactoring Tool 1.5.1 Opnieuw - SourceForge, C# Extreme Simplicity C# Refactory - VB Refactory ReSharper - JetBrains! C# Refactoring Tool C# 2.0 Whidbey - Refactoring nativo GeneXus

Conclusiones

Distintas categoras de mtodos giles Los mtodos giles son fundamentalmente combinables

MSF marco general, Planguage como lenguaje de especificacin de requerimiento, Scrum (con sus patrones organizacionales) como mtodo de management, XP (con patrones de diseo, programacin guiada por pruebas y refactorizacin) como metodologa de desarrollo, RUP como abastecedor de artefactos, ASD como cultura empresarial y (si se requiere) CMM como metodologa de evaluacin de madurez

Desarrollo de conceptos y tcnicas de uso general

Patrones organizacionales (Scrum, Lean Software Development), refactorizacin, TDD, Testing Patterns

Democratizacin de las metodologas - Ahora los mtodos son mainstream

Vnculos y referencias

Reynoso/Kicillof en MSDN en Espaol:

http://www.microsoft.com/spanish/msdn/arquitec tura

Martin Fowler, Kent Beck, John Brant, William Opdyke y Don Roberts. Refactoring: Improving the design of existing code. Addison Wesley, 1999 Kent Beck. Extreme Programming Explained: Embrace Change. Addison Wesley, 1999

Vnculos y referencias

Ron Jeffries - Extreme Programming adventures in C#. MS Press, 2004 Tom Gilb. Competitive Engineering, 2003. Will Stott, James Newkirk - Test-driven C#. MSDN Magazine, Abril de 2004. Andy Hunt, Dave Thomas - Pragmatic Unit Testing in C# with NUnit, 2004.

Preguntas?
Billy Reynoso
UNIVERSIDAD DE BUENOS AIRES billyr@microsoft.com.ar