Vous êtes sur la page 1sur 63

Mtodos giles en desarrollo de software

Carlos Reynoso
billyr@microsoft.com.ar
UNIVERSIDAD DE BUENOS AIRES

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

Objetivos
Proporcionar una reflexin sobre XP y los mtodos giles orientada a la academia
No es un curso introductorio, no es evangelizacin

Examinar los fundamentos formales, la relevancia metodolgica y el alcance prctico de los mtodos giles Identificar recursos para profundizar el tema

Agenda
Contexto de situacin Manifiesto gil Tabla de Mtodos giles eXtreme Programming (XP) Otros mtodos giles Mtodos giles & MSF 3.0 Crticas a Mtodos giles Conclusiones Estado de la cuestin Referencias y recursos http://www.microsoft.com/spanish/msdn/arquitec tura

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

CMM no es una metodologa ni un modelo en cascada, pero coincide con su espritu 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)
Dinmica no lineal, sensitividad a las condiciones iniciales (efecto mariposa), autmatas celulares, redes booleanas aleatorias (orden gratis)

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 MAs


Surge en libros con impacto en la industria y en el pblico, no en papers 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

Proceso iterativo e incremental


Entregas rpidas

Capacidad adaptativa
Rpida respuesta al cambio

Ideas cardicas en MAs


Scrum: conceptos de filo del caos y control de caos
Scrum: http//www.controlchaos.com

Microsoft implementa estrategias de caos controlado en procesos de desarrollo (Microsoft secrets) MSF 3.0: referencia a la naturaleza cardica de los procesos complejos (Dee Hock)

Ideas cardicas en MAs


Fred Brooks: no linealidad [MMM] Jeff DeLuca (FDD): afinidad con caos determinista y teora de la complejidad Larman sobre Scrum: referencias a John Holland sobre auto-organizacin y procesos adaptativos Jim Highsmith (Adaptive Software Development): control laxo, equilibrio en el filo del caos Lean Development: analoga con sociedades de insectos y modelos de agentes adaptativos

Ideas cardicas en MAs


Kent Beck: las races de XP se encuentran en la teora de los sistemas complejos Barry Boehm: la ingeniera de software deber estudiar los sistemas adaptativos, el orden emergente, los agentes que se autoorganizan Ideas de complejidad y caos en management y consultora organizativa Idem, en prediccin financiera

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

Prcticas independientes?

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 continua
Integracin diaria Disponer de una mquina para integracin

Tests funcionales
Cliente

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

Ventajas del espacio abierto:


mayor comunicacin agenda dinmica

Juego de planificacin (planning game)


Determinar rpidamente el alcance de la prxima versin
prioridades de negocio (cliente) estimaciones tcnicas (desarrolladores)

Por qu juego?
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

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

Hay herramientas
C#Refactory (Xtreme Simplicity)

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

Prcticas de Programador

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

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 (o corrida)


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 semi-catico, cambiante y tiene demasiado ruido como para que se le aplique un proceso definido.

Otros mtodos: FDD


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)


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.

DSDM
Mtodo estndar en Gran Bretaa
Prcticas escalables - Reglas MoSCoW [Must, Should, Could, Want]

Adaptive Software Development


James Highsmith III, consultor de Cutter Consortium, desarroll ASD hacia el 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 (ejemplo del agua)

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

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)

Lenguaje de especificacin Planguage


Descripcin de requerimientos, diseos y planes

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

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

Tom Gilb es el creador de la idea de mtricas de software

Mtodos giles en MSF


Fuerte tradicin de desarrollo gil en MS
Steve McConnell, Code Complete (1993)
Programacin en pares

Steve McConnell, Rapid Development (1996)


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

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/msf/m sfovrvw.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

Creencias insostenibles
Es posible diagramar a priori y en detalle la totalidad del ciclo de vida y sus artefactos El seguimiento de un plan garantiza la excelencia de un proceso de desarrollo El diseo previo implica correccin arquitectnica y/o mejora las cualidades no-funcionales El diseo previo incide sobre la calidad del cdigo La semntica de los lenguajes de diseo mapea punto a punto sobre la semntica de los frameworks de programacin El diseo y el plan documentan el desarrollo real y/o facilitan su mantenimiento o transferencia

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

Estado de la cuestin
Los mtodos giles llegaron para quedarse, aunque la histeria se est moderando El BUFD tambin lleg para quedarse CMU/SEI est desarrollando ambas estrategias simultneamente
El departamento de Ingeniera est ms cerca de los mtodos tradicionales (CMM, CMMI, etc) Pero hay fuertes crticas respecto de la adecuacin de UML para ese propsito Arquitectura de software no es diseo OO

El debate est lejos de resolverse en el mediano plazo No se puede negar el valor de la auto-organizacin (Internet, 9/11, Toyota) pero nadie sabe cmo se organiza lo que se autoorganiza No hay balas de plata Los grandes jugadores en la industria de software todava no estn ni a favor ni en contra. Yo tampoco

Vnculos y referencias
Reynoso/Kicillof en MSDN en Espaol:
http://www.microsoft.com/spanish/msdn/arquitectura

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

UNIVERSIDAD DE BUENOS AIRES