Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Carlos Reynoso Metodos Agiles Academia
Carlos Reynoso Metodos Agiles Academia
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.
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
Capacidad adaptativa
Rpida respuesta al cambio
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)
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?
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
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
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
Tarjetas CRC
Clase Responsabilidad Colaboracin
Refactorizacin
Si el cdigo se est volviendo complicado
modificar el diseo, volver a uno ms simple
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
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:
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.
26
CP
27
CP
28
CP
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
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
DSDM
Mtodo estndar en Gran Bretaa
Prcticas escalables - Reglas MoSCoW [Must, Should, Could, Want]
Ciclo de ASD
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)
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
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
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