Your SlideShare is downloading. ×
Manual 02
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Manual 02

2,735
views

Published on


1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,735
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
1
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Métodos Ágiles-Scrum y XP El Desarrollo Iterativo y Evolutivo: Scrum y XP Tema 4: Extreme Programming (XP) (Dr. Ricardo Quintero) 1 Agenda  ¿Qué es XP?  Workproducts, roles y prácticas  Errores comunes  Adopción y mezcla de procesos  Fortalezas y debilidades 2 Dr. Ricardo Quintero 1
  • 2. Métodos Ágiles-Scrum y XP ¿Qué es XP?  Extreme Programming (XP) es un método ágil que da énfasis a:  La colaboración.  La creación rápida y temprana del software.  Prácticas efectivas de desarrollo de software.  Se fundamenta en 4 valores:  Comunicación.  Simplicidad.  Retroalimentación.  Coraje. 3 Ejercicio de aprendizaje adaptativo de los valores de XP  XP fue creado por Kent Beck al trabajar como consultor para el sistema C3 de DaimlerChrysler.  Después de leer el artículo dividiremos el grupo en 4 equipos.  Cada equipo a su vez se dividirá en 4 partes.  Cada equipo haremos una araña de 4 patas c/u correspondiendo a uno de los valores de XP.  Afinaremos los diagramas con un carrousel.  Al final uno de cada equipo explicará los valores al resto (lo seleccionará el instructor, por lo que puede ser cualquiera). 4 Dr. Ricardo Quintero 2
  • 3. Métodos Ágiles-Scrum y XP ¿Qué es XP?  Además del IID, recomienda 12 prácticas: 1. Juego de planeación. 2. Releases frecuentes y pequeños. 3. Metáforas de sistema. 4. Diseño simple. 5. Pruebas. 6. Refactoring frecuente. 7. Programación en parejas. 8. Membrecía del código por el equipo. 9. Integración continua. 10. Paz sustentable. 11. El equipo trabajando como un todo. 12. Estándares de codificación. 5 Las 12 prácticas de XP 6 Dr. Ricardo Quintero 3
  • 4. Métodos Ágiles-Scrum y XP XP en la escala de ciclos y ceremonia Estrictamente cascada(secuencial) Baja ceremonialidad: un conjunto pequeño Longitud de las iteraciones de predefinido informal 1 a 3 semanas de workproducts Ciclos Pocos documentos Muchos documentos Pocos pasos Ceremonia Muchos Pasos formales Scrum UP XP Evo Muchas iteraciones pequeñas (5 días) 7 XP en la escala de Cockburn Principalmente ha sido probado en proyectos que involucran 10 o menos desarrolladores y no ha sido probado en proyectos de misión crítica. Últimamente ha sido probado en proyectos con equipos grandes 8 Dr. Ricardo Quintero 4
  • 5. Métodos Ágiles-Scrum y XP XP-Introducción  Es un método IID que busca la satisfacción del cliente a través de:  La rápida creación de software de alto valor.  Técnicas expertas y sustentables de desarrollo de software.  Respuestas flexibles al cambio.  Está orientado a proyectos con equipos relativamente pequeños, con fechas de entrega menores a 1 año. 9 XP-Introducción  Como lo sugiere la palabra programming, ofrece métodos explícitos (test-driven development, refactoring, pair progamming) para los programadores de tal manera que puedan responder confiadamente a los cambios de requisitos, aún en etapas tardías del proyecto y producir aún en esas circunstancias código de calidad. 10 Dr. Ricardo Quintero 5
  • 6. Métodos Ágiles-Scrum y XP XP-Introducción  Está muy orientado a la comunicación y al trabajo en equipo: los clientes, desarrolladores y administradores forman un equipo de trabajo en un cuarto común para el proyecto que permite la rápida entrega de software con alto valor para el negocio. 11 XP-Introducción  Su distinción principal es que no requiere workproducts detallados excepto el código del programa y las pruebas.  A diferencia de otros métodos iterativos que promueven planeación solo para la iteración siguiente, XP enfatiza en la comunicación oral para los requisitos y el diseño.  Ej.- Si una característica es: “Encontrar las ofertas con costo menor”, ésta se escribe en una story card, después cuando se trabaja en la característica, los programadores aprenden los detalles hablando con los clientes que trabajan de tiempo completo en el cuarto del proyecto. 12 Dr. Ricardo Quintero 6
  • 7. Métodos Ágiles-Scrum y XP XP-Introducción  Esto puede sonar desorganizado, pero más bien XP se posiciona con la siguiente pregunta: ¿Existirá una forma sana y disciplinada para obtener rápidamente éxito –en proyectos típicos pequeños- enfocándose en el código y las pruebas, mientras se evita mucho del “overhead” de la documentación? 13 XP-Introducción  No se trata de una estrategia “code-and- fix”; más bien su premisa es que existe una forma nueva, estructurada y sustentable de lograr el éxito con un enfoque en la rápida producción de código y la comunicación oral, evitando “overhead” adicional.  Muchas de sus prácticas trabajan en forma sinérgica: sus piezas individuales no tienen sentido, pero cuando se combinan se puede ver la “imagen completa”. 14 Dr. Ricardo Quintero 7
  • 8. Métodos Ágiles-Scrum y XP Lo “extremo” de XP  Por sus buenas prácticas:  Probar es bueno, por lo que se escriben “pruebas unitarias” (unit test) para (casi) todo el código y “pruebas de aceptación” para todas las características (Historias de Usuario).  Las revisiones de código son buenas –y mucho mejores en el día de su creación- por lo que se hacen revisiones de código en tiempo real y todo el tiempo vía “programación en parejas”.  La integración frecuente de código a través de todos los miembros del equipo es buena, por lo que se hace en una política 24/7 con procesos automáticos de integración continua, en una máquina dedicada a la construcción. 15 Lo “extremo” de XP  Por sus buenas prácticas:  Las iteraciones cortas y la rápida retroalimentación son buenas, por lo que se hacen iteraciones de 1 a 3 semanas.  El mayor involucramiento del cliente es bueno, por lo que trae clientes de tiempo completo al proyecto, colocándolos en un cuarto común del proyecto.  La comunicación es buena, por lo que todos están juntos: se programa en parejas, se incluyen clientes en el sitio y se involucra frecuentemente al cliente en planeación, conducción y evaluación. 16 Dr. Ricardo Quintero 8
  • 9. Métodos Ágiles-Scrum y XP Ciclo de vida Exploración Planeación Iteraciones Producción Mantenimiento para el primer release Propósito Propósito -Propósito Propósito -Extender, -Suficientes -Acordar story-cards fechas e Propósito -Instalación arreglar. para el primer historias para -Implementar operacional. -Construir release. el primer un sistema releases -Factibilidad release. probado listo mayores. asegurada. Actividades para liberar. Actividades Actividades -Juego de Actividades -Documentación. Actividades: -Prototipos. planeación del -Pruebas y -Entrenamiento. -Puede volver release. programación. -Marketing. a incluirse -Pruebas exploratorias -Juego de la estas fases de de tecnología -Escritura de planeación nuevo, para de story-card y para iteración. releases programación. estimaciones. -Escritura de incrementales. -Escritura de tareas y story-card y estimación estimación 17 Ciclo de vida 1. Como muchos proyectos, XP puede iniciar con exploración. Se escriben algunas story cards (características) con estimados burdos. 2. En el Juego de Planeación del Release, los clientes y desarrolladores completan las story- cards y los estimados burdos y después deciden que hacer para el siguiente release. 18 Dr. Ricardo Quintero 9
  • 10. Métodos Ágiles-Scrum y XP Ciclo de vida 3. Para la siguiente iteración, en el Juego de Planeación de Iteración, los clientes seleccionan las historias a implementar, con lo cual el cliente conduce el proyecto. Los desarrolladores después dividen las historias en tareas estimadas y cortas. Finalmente una revisión del esfuerzo total estimado a nivel de tarea puede dirigir el reajuste de las historias seleccionadas en pro del espíritu de evitar el “trabajo extra”. Este “trabajo extra” es seriamente descartado en XP, ya que es visto como un síntoma de un proyecto disfuncional, que rápidamente incrementa el descontento de la gente y no favorece la productividad y calidad. 4. Los desarrolladores implementan las historias en el periodo de tiempo acordado (timeboxing), con colaboración continua con los clientes (en un cuarto común del proyecto) en pruebas y detalles de requisitos. 5. Si no se termina el release, regrese al paso 3 para la siguiente iteración. 19 XP – Proceso General * * Retroalimentación 20 Dr. Ricardo Quintero 10
  • 11. Métodos Ágiles-Scrum y XP XP - Iteración * * Retroalimentación 21 XP – Desarrollo * * Retroalimentación 22 Dr. Ricardo Quintero 11
  • 12. Métodos Ágiles-Scrum y XP XP – Propiedad colectiva del código * * Retroalimentación 23 XP - Retroalimentación 24 Dr. Ricardo Quintero 12
  • 13. Métodos Ágiles-Scrum y XP Agenda  ¿Qué es XP?  Workproducts, roles y prácticas  Errores comunes  Adopción y mezcla de procesos  Fortalezas y debilidades 25 Workproducts-no software Requisitos Diseño Tarjetas de papel sobre las Tarjetas de papel sobre las cuales se escriben cuales se escribe brevemente las ideas brevemente una sobre clases colaboradoras característica (no UC). Son y responsabilidades sólo un “compromiso de hablar” con el cliente por los detalles. Granularidad de 2 a 10 días Implementación Pruebas & Verificación Gestión del proyecto Configuración & Ambiente de Tarjetas de papel o listas en pizarrón blanco en las Gestión de Cambios que se escriben las tareas de las Historias, dentro de una iteración. Granularidad de 1 a 2 días En la pared, con el propósito de comunicar mejor. Su contenido depende de los equipos. Por ej: número de pruebas definidas Vs aceptadas 26 Dr. Ricardo Quintero 13
  • 14. Métodos Ágiles-Scrum y XP Workproducts-Story Cards  Story card: Una nota escrita a mano por los clientes ayudado por los desarrolladores en una tarjeta tipo “ficha biliográfica”.  Durante el Juego de Planeación, muchas de estas se escriben. El ejemplo mostrado enfatiza el enfoque minimalista para registrar requisitos que XP recomienda. 27 Workproducts-Story Cards  80% +/- 20% es un número perfecto para el Juego de Planeación del Release.  Enfoque las story-cards en necesidades del cliente, no tecnología específica, no db, no algoritmos o GUI layouts. 28 Dr. Ricardo Quintero 14
  • 15. Métodos Ágiles-Scrum y XP Workproducts-Story Cards  Las story cards registran historias de usuario: características, reparaciones o requisitos no funcionales que los usuarios desean.  Pueden incluso utilizarse para crear documentación.  Las historias tienen un rango de duración estimado de 1 día a 3 semanas.  Las historias de usuario no son casos de uso o escenarios, suelen representar características. Es su intención: describir los requisitos como características más que como casos de uso.  ¿Y los UC? Bueno, se busca lograr lo mismo pero de forma ágil: mediante comunicación oral constante con el usuario. 29 Workproducts-Story Cards  El propósito del story card no es detallar una historia de usuario, sino hacer referencias a otros documentos y, en general, ver la tarjeta como una “promesa para platicar” con el cliente quien la escribió, para que los desarrolladores las implementen.  Como una práctica de XP es trabajo conjunto del equipo, el donador de la tarjeta debe estar disponible.  Las story cards conducen la creación de las pruebas de aceptación. 1 story card puede generar 1 o más pruebas de aceptación. 30 Dr. Ricardo Quintero 15
  • 16. Métodos Ágiles-Scrum y XP Workproducts-Story Cards 31 Workproducts-Task list  Durante el Juego de Planeación de Iteración, el equipo se reúne frente a un pizarrón y genera la lista de tareas para todas las historias seleccionadas para la iteración así como para las pruebas fallidas de la iteración anterior.  Otra alternativa popular es generar tarjetas individuales de tareas. Una vez que una tarea es seleccionada por un voluntario, ellos entran en un esfuerzo de estimación (en horas ideales de ingeniería). Cada tarea debería estar en un rango de 1 a 2 días de duración. 32 Dr. Ricardo Quintero 16
  • 17. Métodos Ágiles-Scrum y XP Workproducts-Task list 33 Workproducts-Task list 34 Dr. Ricardo Quintero 17
  • 18. Métodos Ágiles-Scrum y XP Workproducts-Visible graphs  El objetivo es comunicar fácilmente al equipo lo que es fácil de medir. Medir al menos algo.  XP no obliga que debe ser, aunque ejemplos conocidos incluyen pruebas de aceptación definidas y aprobadas, progreso de historias y progreso de tareas. 35 Roles Customer Development •Escribe Historias y Pruebas de aceptación •Selecciona Historias para •Escribe Pruebas, •Ayuda al cliente a el release y para la Diseña y Codifica escribir y iteración •Refactoriza desarrollar las •Identifica tareas y pruebas estima Management Other •Tiene conciencia del •Colecciona las proceso métricas •Particulariza el •Informa el progreso •Consultoría técnica proceso •Retroalimenta en •Coaching •Intervención estimaciones pobres •Enseñanza 36 Dr. Ricardo Quintero 18
  • 19. Métodos Ágiles-Scrum y XP Prácticas-una puede soportar múltiples disciplinas Requisitos Diseño Implementación Pruebas & Verificación Gestión del proyecto Configuración & Ambiente de Gestión de Cambios (Otras prácticas) 37 Core practices-Requirements  Juego de la Planeación: Existen dos:  Juego de la Planeación del Release: Su objetivo es definir el ámbito del siguiente “release” operacional, con software de máximo valor para el cliente.  En una sesión de 1 día (hasta medio-día) los clientes escriben las story-cards para describir características y los desarrolladores las estiman (en hrs). Pueden existir story-cards de trabajo exploratorio de la fase anterior.  Después, el cliente selecciona que incluir en el siguiente “release” 1) Definiendo la fecha final y agregando tarjetas que consuman el tiempo total disponible o 2) Seleccionando tarjetas y calculando la fecha del release basado en sus estimados. Para esto toma en cuenta la velocidad del proyecto (la suma de las estimaciones de las tareas realizadas en la iteración anterior). 38 Dr. Ricardo Quintero 19
  • 20. Métodos Ágiles-Scrum y XP Core practices-Requirements  Juego de la Planeación:  Juego de la Planeación del Release: 39 Core practices-Requirements (Release Planning game) 40 Dr. Ricardo Quintero 20
  • 21. Métodos Ágiles-Scrum y XP Core practices-Requirements  Juego de la Planeación del Release: 41 Core practices-Requirements  Juego de la Planeación:  Juego de la Planeación del Release:  Realizaremos ahora un Ejercicio de Juego de la planeación. 42 Dr. Ricardo Quintero 21
  • 22. Métodos Ágiles-Scrum y XP Core practices-Requirements  Juego de la Planeación: Existen dos:  Juego de la Planeación de la Iteración: Su objetivo es seleccionar las historias a implementar, planeando y asignando tareas para la iteración. Se realiza brevemente antes de cada nueva iteración.  Los clientes seleccionan las story-cards para la iteración.  Para c/story-card el programador crea una lista de tareas (en tarjetas o en pizarrón) que realizará las historias.  Cada programador estima el tiempo que le tomará cada tarea.  Si las tareas no se estiman con una duración de ½ día a 2 días, entonces son refactorizadas (divididas principalmente). 43 Core practices-Requirements  Juego de la Planeación:  Juego de la Planeación de la Iteración: 44 Dr. Ricardo Quintero 22
  • 23. Métodos Ágiles-Scrum y XP Core practices-Requirements  Juego de la Planeación:  Juego de la Planeación de la Iteración: 45 Core practices-Requirements  Juego de la Planeación:  Juego de la Planeación de la Iteración:  Realizaremos ahora un Ejercicio de Juego de la planeación. 46 Dr. Ricardo Quintero 23
  • 24. Métodos Ágiles-Scrum y XP Core practices-Requirements  Cliente en el sitio:  Todo el equipo (programadores y clientes) trabaja en un cuarto común del proyecto. Uno o más clientes se establece “más o menos” de tiempo completo con el equipo. Se espera que sean expertos en el dominio y tengan capacidad de tomar decisiones respecto a requisitos y su prioridad. 47 Core practices-Requirements  Cliente en el sitio:  La contribución del cliente incluye explicación detallada –a los programadores- de las características brevemente sumarizadas en las story- cards, participación en el Juego de la Planeación, clarificación y escritura de pruebas de aceptación en colaboración con el programador. 48 Dr. Ricardo Quintero 24
  • 25. Métodos Ágiles-Scrum y XP Core practices-Requirements  Pruebas de Aceptación:  Todas las características deben tener pruebas (funcionales) de aceptación.  Todas las pruebas deben correr con un resultado binario de pasa/falla, de tal forma que no sea necesaria la inspección humana de pruebas individuales.  Las pruebas de aceptación son escritas en colaboración con el cliente –ellos definen el estatuto de lo que significa la aceptación.  Esto es llamado Customer tests en XP. 49 Core practices-Design  Metáfora del Sistema:  Para ayudar en la comunicación del diseño, captura el sistema completo o cada subsistema con metáforas fáciles de memorizar para describir los temas arquitectónicos clave.  Muchos reportan que esta es una de las prácticas menos necesaria. 50 Dr. Ricardo Quintero 25
  • 26. Métodos Ágiles-Scrum y XP Core practices-Design  Refactorización frecuente: "Es fácil tener una idea complicada, pero es realmente complicado tener una idea simple." Carver Mead "La simplicidad es la máxima sofisticación" Leonardo da Vinci Any fool can write code that a computer can understand. Good programmers write code that humans can understand. --Martin Fowler, from Refactoring: Improving the Design of Existing Code 51 Core practices-Design  Refactorización frecuente:  Es el esfuerzo continuo por simplificar el código de grano fino y los elementos de diseño grueso, asegurando que se pasen todas las pruebas.  Es decir, limpiar el código y el diseño sin cambiar la funcionalidad.  Debe existir gran cantidad de “refactoring” en XP. Esta práctica es conocida también como mejora continua de diseño.  El objetivo es código simple, mínimo y comprensible. Se logra mediante pequeños cambios, verificación de pruebas cada vez e idealmente el uso de herramientas de refactoring (hoy disponibles en algunas IDEs). 52 Dr. Ricardo Quintero 26
  • 27. Métodos Ágiles-Scrum y XP Core practices-Design  Refactorización frecuente: Haremos un ejercicio de refactoring. 53 Core practices-Design  Diseño Simple:  Evita diseño especulativo para posibles cambios futuros.  Evita la creación de componentes generalizados que no se requieren inmediatamente.  El diseño debería evitar código duplicado, tener un conjunto mínimo de clases y métodos y ser fácilmente comprensible. 54 Dr. Ricardo Quintero 27
  • 28. Métodos Ágiles-Scrum y XP Core practices-Design  Diseño simple: 55 Core practices-Implementation  Estándares de codificación:  Con el hecho de tener propiedad colectiva del código, los frecuentes refactorings y los intercambios regulares de parejas de programación, todos deben seguir el mismo estilo de codificación. 56 Dr. Ricardo Quintero 28
  • 29. Métodos Ágiles-Scrum y XP Core practices-Implementation  Coding standards: 57 Core practices-Implementation  Programación en parejas: Pair programming is a dialogue between two people trying to simultaneously program (and analyze and design and test) and understand together how to program better. It is a conversation at many levels, assisted by and focused on a computer -- Kent Beck in Extreme Programming Explained 58 Dr. Ricardo Quintero 29
  • 30. Métodos Ágiles-Scrum y XP Core practices-Implementation  Programación en parejas:  Todo el código se crea con 2 programadores en una computadora que se rotan el teclado (o mouse) periódicamente.  Las parejas pueden cambiar frecuentemente, para diferentes tareas.  El observador realiza revisión del código en tiempo-real y, quizá, piensa con mayor amplitud (visión) que el que teclea, considerando pruebas por ejemplo. 59 Core practices-Implementation  Pair programming:  Realizaremos un ejercicio de pair programming simulado 60 Dr. Ricardo Quintero 30
  • 31. Métodos Ágiles-Scrum y XP Core practices-Implementation  Propiedad colectiva del código:  Cualquier pareja de programadores puede mejorar el código y el valor que defiende XP es que “todo el equipo es colectivamente responsable de todo el código”.  No se promueve el valor de “es su código, es su problema”.  Un objetivo relacionado es desarrollar más rápidamente removiendo los típicos obstáculos que suelen asociarse a las solicitudes de cambios en los modelos típicos de código con propiedad individual. 61 Core practices-Implementation  Propiedad colectiva del código:  El peligro obvio de modificar código que originalmente uno no escribió se disminuye en XP mediante algunas otras prácticas:  La garantía de la presencia de las pruebas unitarias y de aceptación corriendo en un proceso de integración automática continua e informando si los cambios han dañado el código.  La pareja ofrece otro par de ojos al cambio.  La presencia de los estándares de codificación asegura que todo el código se vea igual. 62 Dr. Ricardo Quintero 31
  • 32. Métodos Ágiles-Scrum y XP Core practices-Pruebas & Verificación  Desarrollo dirigido por las pruebas y pruebas unitarias:  Se escriben pruebas unitarias para la mayor parte del código (Unit test).  Se sigue la estrategia test-driven development (y test-first development): las Unit test se escriben por el programador antes de que el código sea probado. Es un ciclo test->code en lugar de code->test.  Se aplica algún miembro de la familia de frameworks de testing XUnit (JUnit o NUnit).  Todas las pruebas unitarias o de aceptación se ejecutan repetida y automáticamente en un proceso de integración continua 24/7. 63 Core practices-Gestión del proyecto  Releases frecuentes y pequeños.  Entregas evolutivas.  No es aplicable a todos los proyectos.  No debe confundirse con organizaciones con un solo ciclo de release en muchas iteraciones pequeñas. 64 Dr. Ricardo Quintero 32
  • 33. Métodos Ágiles-Scrum y XP Core practices-Gestión del proyecto  Paz sustentable.  La pregunta clave es: ¿Qué tan bien estás tú cuando estás cansado?  “Overtime” frecuente es considerado síntoma de problemas.  No conlleva a programadores felices, creativos, familias saludables, calidad y código mantenible.  XP no lo soporta, en su lugar promueve “no overtime”. 65 Core practices-Configuration & Change Management Environment  Integración continua.  Todo el código verificado se reintegra y prueba en una máquina separada de construcción, en proceso automático 24/7 de compilación, ejecución de todas las pruebas de unidad y de todas o la mayoría de las pruebas de aceptación. 66 Dr. Ricardo Quintero 33
  • 34. Métodos Ágiles-Scrum y XP Core practices-Configuration & Change Management Environment  Integración continua. 67 Core practices-Configuration & Change Management Environment  Cuarto común del proyecto:  El valor que justifica esta práctica es la comunicación.  Realizaremos un ejercicio. 68 Dr. Ricardo Quintero 34
  • 35. Métodos Ágiles-Scrum y XP Otras prácticas y valores  Onsite customer proxies: Si no es posible tener al cliente de “tiempo completo” se pueden utilizar proxies de clientes que tiene conocimiento suficiente del dominio y los requisitos y que representan al cliente.  Es importante que, al menos, los clientes verdaderos al menos participen de los demos al final de las iteraciones y, preferentemente en los Juegos de la Planeación. 69 Otras prácticas y valores  Customer on call: si no es posible el cliente de “tiempo completo”, su representante debería estar disponible de forma rápida (celular).  Only by volunteering (accepted responsability): no se asignan las tareas a la gente, en su lugar en el juego de planeación de la iteración, la gente selecciona voluntariamente las tareas. Esto logra alto grado de compromiso y satisfaccción. 70 Dr. Ricardo Quintero 35
  • 36. Métodos Ágiles-Scrum y XP Otras prácticas y valores  Modelado ligero: en pizarrones con sketches y notas. Que no ocupe mucho tiempo.  Documentación mínima o “sólo suficiente”: XP evita la escritura de documentos de requisitos, diseño y gestión “innecesarios”. La práctica de “evitar documentación” se compensa con la presencia del cliente en el sitio. XP no es anti-documentación, pero nota que esto tiene un costo, mejor invertir en programación. 71 Otras prácticas y valores  Métricas: XP recomienda medición diaria de progreso y calidad. No indica que métricas exactamente, sólo recomienda “la más simple que podría funcionar”. Ej.- número de tareas e historias completadas, número y razón de éxito de pruebas.  Tracking and Daily Tracker: recolección regular del progreso de tareas e historias. Se prefiere con preguntas directas a todos los programadores aunque podrían automatizarse. Responsabilidad del tracker.  Incremental infrastructure: la infraestructura de back-end (capa de datos) no debe ser el foco principal en las primeras iteraciones, implemente lo suficiente para los requisitos funcionales de la iteración. 72 Dr. Ricardo Quintero 36
  • 37. Métodos Ágiles-Scrum y XP Otras prácticas y valores  Ideal Engineering Hours (IEH): las estimaciones para tareas se hacen en términos de las IEH (tiempo no interrumpido, dedicado y enfocado para completar las tareas).  Story estimates: para estimar historias largas, algunos practicantes de XP recomiendan utilizar valores de grano grueso (1, 2 o 3 semanas de duración) en lugar de estimaciones a nivel IEH o diaria. 73 Otras prácticas-Aprendizaje continuo 74 Dr. Ricardo Quintero 37
  • 38. Métodos Ágiles-Scrum y XP Un día en la vida de un programador XP  Haremos a continuación el ejercicio del cubo del programador XP. 75 Agenda  ¿Qué es XP?  Workproducts, roles y prácticas  Errores comunes  Adopción y mezcla de procesos  Fortalezas y debilidades 76 Dr. Ricardo Quintero 38
  • 39. Métodos Ágiles-Scrum y XP Errores comúnes y malos entendidos  No tener cliente en el sitio; en su lugar, utilizar especificaciones (UC) para la siguiente iteración.  Aplicar un subconjunto de prácticas no compensadas, “customizar” antes de intentar.  XP es: desarrollo iterativo+documentación mínima+unit testing  No escribir las unit test primero.  El cliente no decide.  Mínimo refactoring.  Tener solo un cliente en el sitio del proyecto.  Muchas tarjetas de tareas de grano fino.  Mantener una pareja por mucho tiempo. 77 Errores comúnes y malos entendidos  El cliente o el manager es el “tracker”.  No integrar el equipo de QA, para escribir las pruebas de aceptación en colaboración el cliente.  La documentación de diseño post- desarrollo es mala.  Diagramación mala.  Sólo programadores jóvenes.  Parejas de programadores novatos.  Una pareja avanzando más rápido. 78 Dr. Ricardo Quintero 39
  • 40. Métodos Ágiles-Scrum y XP Errores comúnes y malos entendidos  El observador no puede ver fácilmente el monitor.  No dispuesto a aprender; no dispuesto a explicar.  No querer integrarse al equipo. Programadores solitarios.  Reuniones de pie muy largas o no enfocadas.  No tener un “tester” de aceptación dedicado.  El cliente del proyecto y su jefe no alineados.  El cliente que escribe las pruebas de aceptación no es el revisor de su ejecución. 79 Errores comúnes y malos entendidos  Iteraciones muy largas.  Iteraciones no “timeboxed”.  Iteraciones que no terminan en un “baseline” integrado y probado  Cada iteración termina en un release de producción.  Planeación predicitiva. 80 Dr. Ricardo Quintero 40
  • 41. Métodos Ágiles-Scrum y XP Casos de éxito  Proyectos grandes. (ThoughtWorks)  Proyectos medianos. (Symantec)  Pequeños (Chrysler-Nómina). 81 Agenda  ¿Qué es XP?  Workproducts, roles y prácticas  Errores comunes  Adopción y mezcla de procesos  Fortalezas y debilidades 82 Dr. Ricardo Quintero 41
  • 42. Métodos Ágiles-Scrum y XP XP+Scrum  La Scrum meeting es un refinamiento de la XP-standup meeting (de ahí tomó la idea Beck).  Ambos recomiendan un cuarto común para el proyecto.  Ambos recomiendan mostrar demos a los stakeholders al final de la iteración.  El Scrum backlog y el Sprint Backlog son variaciones a la verificación continua de XP.  XP recomienda tener un grupo de clientes en el sitio, Scrum solo 1. 83 XP+UP  Muchas de las prácticas de XP son especializaciones de las prácticas de UP.  Test-first development es una especialización de la práctica de verificación continua de la calidad de UP.  UP no promueve la creación de documentación innecesaria.  Una diferencia es el nivel de diagramación recomendado. UP recomienda más tiempo de diagramación.  La especificación de requisitos es más detallada en UP (con los UC).  En XP no necesariamente las primeras iteraciones son para clarificar los requisitos, como en UP.  Las story-cards representan características del sistema, no UC.  XP recomienda un enfoque dirigida por características para los requisitos. UP promueve un enfoque dirigido por UC, aunque UP acepta y permite características en lugar de UC. 84 Dr. Ricardo Quintero 42
  • 43. Métodos Ágiles-Scrum y XP Estrategias de adopción  Contra UP, XP recomienda:  Selecciona el proyecto o problema más difícil.  Aplica XP hasta resolverlo.  Repite. 85 Estrategias de adopción  Si no es posible aplicar todas las recomendaciones de XP empieza por:  Todo el equipo en un cuarto común de proyecto.  Test-first development.  Pruebas de aceptación escritas por los clientes.  Juego de planeación.  Programación en parejas. 86 Dr. Ricardo Quintero 43
  • 44. Métodos Ágiles-Scrum y XP Agenda  ¿Qué es XP?  Workproducts, roles y prácticas  Errores comunes  Adopción y mezcla de procesos  Fortalezas y debilidades 87 Realidad VS Fantasía  Estudiando las prácticas de XP se podría pensar de que son “la bala de plata”, pero por supuesto no lo son.  Como siempre:  El Proceso es solamente un efecto de segundo orden. La singularidad de las personas, sus sentimientos y cualidades son más influyentes. 88 Dr. Ricardo Quintero 44
  • 45. Métodos Ágiles-Scrum y XP Realidad VS Fantasía  Una fantasía es creer que si un grupo adopta desarrollo iterativo-evolutivo y evita la completa especificación de requisitos está haciendo XP.  Lo mismo si sólo se hace unit testing, se trabaja en un cuarto común, o modelado ágil, etc.  La resistencia a la programación en parejas es otra realidad que continuamente se presenta. A veces resulta difícil encontrar un cuarto común para el proyecto o tener suficientes pizarrones.  Lo que suele ser ampliamente aceptado son la construcción temprana de pruebas de aceptación del usuario, el refactoring constante y la integración continua. 89 Fortalezas VS “otros”  Técnicas prácticas, de alto impacto y de fácil adopción por los desarrolladores (test-driven o integración continua).  La participación y conducción del cliente.  Requisitos y desarrollo evolutivos e incrementales así como comportamiento adaptativo.  Los programadores estiman las tareas que han seleccionado y la planeación que siguen (la planificación es racional).  El énfasis en la comunicación entre todos los stakeholders. 90 Dr. Ricardo Quintero 45
  • 46. Métodos Ágiles-Scrum y XP Fortalezas VS “otros”  El énfasis en la calidad a través de sus múltiples prácticas.  Clarificación de lo que es un sistema aceptable solicitando al cliente que defina las pruebas de aceptación.  Medición diaria y desarrolladores involucrados en la medición y definición de lo que se mide.  Cada iteración los desarrolladores obtienen práctica (durante el juego de Planeación) identificando tareas y estimándolas, dirigiendo las mejoras en estas habilidades vitales.  Revisiones e inspecciones frecuentes y detalladas, con el trabajo frecuente y significativo hecho en parejas. La inspección está fuertemente correlacionada con la reducción de los niveles de defectos. 91 Debilidades  La presencia del cliente en el lugar. Si esto no es posible, resulta difícil o imposible la práctica de “requisitos orales” y el uso de las story-cards. Ante esto, se tendrá que utilizar otras técnicas (como los UC del UP).  Depende de la historia oral para conocer los requisitos del diseño y de los requisitos. Esto tiene limitaciones respecto a rápidamente ayudar a nuevos miembros o escalar a grandes proyectos. 92 Dr. Ricardo Quintero 46
  • 47. Métodos Ágiles-Scrum y XP Debilidades  Las prácticas de XP son interdependientes y mutuamente soportadas. La omisión de alguna de ella puede afectar seriamente al método.  No hay forma estándar de describir o documentar el diseño del software como ayuda de aprendizaje.  Algunos programadores no les gusta hacer programación en parejas.  Carencia de un énfasis orientado a la arquitectura en las primeras iteraciones. Carencia de métodos de diseño arquitectónico. XP indica que el diseño simple y el refactoring permiten alcanzar el mismo objetivo. 93 XP y CMM  CMM (Capability Maturity Model) del Software Engineering Institute (SEI) influyó a muchos de los ingenieros de procesos a finales de los 80’s y 90’s hacia prácticas encauzadas, dirigidas-por- documentos y de cascada.  Aunque un enfoque IID puede certificarse como CMM-maduro, las primeras discusiones CMM tuvieron un tono dirigido por planeación y documentos, orientado a fases y planeación predictiva. 94 Dr. Ricardo Quintero 47
  • 48. Métodos Ágiles-Scrum y XP XP y CMM  Muchos certificadores CMM y consultores tenían un background en valores y prácticas de cascada y en procesos prescriptivos, sin experiencia en métodos iterativos y adaptativos.  Más recientemente, CMM tienen líderes que promueven el IID y los métodos ágiles. 95 Dr. Ricardo Quintero 48
  • 49. CASE STUDY Chrysler Goes to “Extremes” By the “C3 Team” 24 DISTRIBUTED Computing October 1998
  • 50. CASE STUDY At Chrysler, Objects Pay  C C- over from scratch and delivered a very suc- C  (C3) was launched in May 1997. A little over a year before that, the project had been declared a failure and all cessful result. C3 pays some 10,000 monthly- paid employees and is being extended to sup- port the biweekly-paid and weekly-paid pop- code thrown away. Using Kent Beck’s Extreme ulations. The team believes that its use of Programming methodology, Chrysler started Extreme Programming made it all possible. Extreme Programming Communication: Customer/Developer E xtreme Programming rests on the values of simplicity, Developers are communication, testing, and aggressiveness. In this article, afraid that customers will demand everything at once; cus- we’ll comment briefly on simplicity, testing, and aggres- tomers are afraid we won’t get enough done; managers are siveness, while looking primarily at communication, the basis afraid they won’t know what’s really going on. And we’re all of our planning and tracking process. afraid of too much overhead. “Do the simplest thing” also applies to communication. Ex- Simplicity We can start with just one of Chrysler’s pay popu- treme Programming helps us communicate better than most lations, to keep things simple. But we have to be able to pay all projects, while avoiding delay and overhead. the populations, with all their complexity. We’re afraid that if It all starts with the customer. In Extreme Programming, we don’t get all the requirements down, and if we don’t build customers must be part of the project; they have the final say for the future, we may paint ourselves into a corner. on what is needed and how good it has to be. Customers are part of the team throughout development. Extreme programmers do the simplest thing that could possibly work. The usual relationship between customer and developer can We do not build generality into the system in expectation of become adversarial: Customers demand all the features they future requirements. We build the simplest objects that can might want, and developers resist making changes to make the support the feature we’re working on right now. deadline. C3 built healthy power sharing by considering just four measurable variables: Extreme programmers leave the system in the simplest condition possible. • scope—what is done and what remains to be done Having built these simple objects, we refactor our code to elim- • quality—correctness and other such measures inate any redundancy and ugliness from the code just installed. • resources—personnel, equipment, space These two rules together keep our objects well factored, • time—duration of the project containing only what we really need. When new requirements If any three of these variables are chosen, we can figure out arise, the code is lean, mean, and easy to extend. the fourth. Normally, customers define scope and quality, and Yes, this goes against age-old programming lore: Get all your resources are given; we figure out how long the project will requirements up front; build general code to support the future. take. Here’s how. This thinking no longer applies in the flexible world of objects. Three Out of Four Ain’t Bad Customers define scope with user sto- You go fastest with the least code to drag around; with properly ries, which are like use cases. They write each story on a sepa- factored objects, the risk of cornering yourself is eliminated. rate card. Stories should encompass from one to three weeks of We have been developing C3 for over two years—in produc- ideal development time; we learn to size them by experience. tion for over one—and we have never once wished we had Customers also define quality. They define functional tests done something sooner or more generally. In fact we have that the system must accomplish before it can be released. By many times wished we had built even less into the system, doing more testing of more important capabilities, customers which would have let us go faster—additional function often have complete control over system quality. gets in the way when the real requirement arrives. With explicit public tests, everyone knows whether we are We tried it, we know it’s true. You go fastest when you “do meeting the required quality level. We can’t accidentally let qual- the simplest thing that could possibly work.” ity decline because scope has increased or time has decreased. www.DistributedComputing.com DISTRIBUTED Computing 25
  • 51. CASE STUDY Now we know scope, and quality, and resources. We need ence in estimating, and each is much more accurate than the to predict what we’re going to do and how long it will take, but one before. we aren’t sure the customers really know what they want and Now we get down to work on the engineering tasks for the will ask for everything. We’re afraid they’ll change everything iteration. Communication remains central to what we do. later, and that no one will understand the impact of change on Communication with the Customer. We now need to assure the schedule. that the developers know the details of what to do, and it does- Commitment scheduling. We do commitment scheduling both n’t take too long for them to find out, so that no one loses before development starts and regularly thereafter. We take touch with the process. all the story cards and spread them out on the table. We go Developers work in a single large room that we designed for through the cards, giving each an estimate of 1, 2, or 3 weeks ourselves. The room is set up for pair programming—two devel- of “ideal engineering time.” Once we have estimated all cards, opers sit together to write all production code—and the customer we arrange them according to priority, divide them into groups space is right next to the developers. Communication between encompassing three weeks’ work, count up the weeks, adjust customers and developers couldn’t be easier. When we have a for load factor, and come up with our delivery date. question, we just walk over and ask. The key is immediacy: You But we don’t know whether the cus- can ask a question at any time, and get an tomers even have all the stories yet. The de- answer right away. velopers’ estimates might be wrong. We We don’t write memos back and forth, can’t guarantee that everything will turn out we sit down and talk. We have informal ses- T according to the commitment scheduling prediction. o go fast, sions, a couple of people resolving some is- sue, all the time. We have a daily stand-up All these concerns are valid. We accept that our commitment schedule is an estimate, and we build meeting where developers and customers stand in a circle and give a brief progress re- at first it might not be a very good one. We port. This makes sure everyone always knows commit to refining that estimate and publish- only what and agrees with what’s going on, at a very ing the result over the course of the project. low cost. But even at the beginning, an estimate made by the actual developers is better than we really need, Communication with Management. We need to make sure we know how well any date made up by someone else. Estimates get better as we go along, and we use the thus keeping the we’re doing, and that those higher up in the organization know how well we’re do- commitment schedule as part of our report- ing process. It converges on reality and system lean and ing. But we don’t want a lot of fancy show and tell to waste time and obscure what’s rapidly builds trust between customers and developers. mean. really going. So we do our reporting, all the way up to the vice-presidential level, in Iteration planning. To make sure developers terms of the four variables. We tell every- know what to do, and that customers see how one the same story: tasks relate back to stories, we work in three- • Scope. What percentage of the story week iterations and do iteration planning on the first Monday of cards has been completed, and what percentage of the way each iteration. Customers select the user stories for the itera- through the schedule are we? tion and write them on the whiteboard. We discuss each story • Quality. Show the graph of the functional test scores and to make sure we understand it. Developers then write the engi- whether they’re improving and are converging on 100%. neering tasks for the story on the whiteboard. Once we have all • Resources. Do we have the personnel and other resources the tasks, developers sign up for the tasks they want to do and called for in our original estimates? estimate how much time they expect the task to take. If the es- • Time. Give the current expected date for release from the timates add up to less than the total engineering time available, most recent commitment schedule. then the customers add more stories; if the estimates add up to That’s really all there is to reporting. The essence of our pro- more, then the customers remove the lowest-priority stories. ject status can be reported in four simple paragraphs, based on At the end of the iteration planning meeting, we all know what the four variables. we have to do for that iteration, and everyone has a good over- Communication Developer to Developer. We need to make sure all picture of the next three weeks. that going fast will not mean that code will be put in willy-nilly, Each iteration corresponds to one of the three-week peri- without enough planning or design—especially that there will ods from the commitment schedule. As the iterations go by, not be code in the system that only one person understands, we get immediate feedback on how the schedule is holding maybe even code that no one understands. Because we add up. Because we redo the commitment schedule every three it- function so quickly, we must ensure quality and understanding erations, each subsequent schedule is based on more experi- through some simple communication practices. 26 DISTRIBUTED Computing October 1998
  • 52. CASE STUDY The Business Case T HE C3 SYSTEM will allow Payroll group decided to replace the three sys- • Simplified external interfaces. Sys- Services and IS to more easily tems under their control with a unified tems providing input to payroll now manage the requirements for ac- system. The C3 team first tried a pay- divide their data into separate feeds curate and timely service to its 86,000 roll package from a leading vendor. It for each payroll system and in return employees by reducing the duplication couldn’t handle the complexities of receive separate reconciliation reports. of effort the legacy systems require. Chrysler’s pay rules, and further analy- Transactions sent to the wrong payroll Chrysler divides its employees into four sis showed that no package could. The system require manual correction in groups for payroll purposes; each group only option was to design and write a the payroll department and may result is paid with a separate payroll system. new payroll system. in the employee being incorrectly paid. The hourly system pays 60,000 union- Systems that feed payroll can send represented employees each week. The Advantages of C3 their files to a single point and C3 will salary system pays 16,000 union and • Simplified movement between pay- find the employee’s record regardless nonunion employees every other week. roll systems. A complex and often of pay frequency. The executive system pays 10,000 man- manual procedure is required to move • Opportunity to improve external in- agement and technical employees once employees between payroll systems. terfaces. The core of the legacy sys- a month. The incentive compensation C3 eliminates this procedure, since tems is its flat file masters and unit system pays 1,500 nonunion upper-man- there will only be one system. record transactions. However the sys- agement and international employees • Improved quality of manual input. tems that interact with payroll up- once a month. The corporate payroll de- Manual input is currently written on graded their technology, they couldn’t partment is responsible for the hourly, forms and sent out for keypunch. C3 alter their interfaces. While C3 sup- salary, and executive payrolls; the hu- allows direct entry and immediate ports the legacy master files and man resources group is responsible for editing of data through GUIs. transactions, it does so only as a con- the incentive compensation payroll. • Elimination of paper and microfiche venience. C3 can accept input from al- The payroll department’s three sys- reports. Payment history can be most any source, including directly tems are twenty years old and show- viewed online. reading the other system’s relational ing it. Designed when a user interface • Automation of manual procedures. table or a Web-based GUI using meant an eighty-character punch card, Many processes now done manually CORBA. each system requires a separate pro- are automated in C3. By the end of October, the salary sys- gramming staff to maintain it and a • Better support for decision making. tem’s 16,000 employees will be paid by separate customer staff to use it. C3 stores earnings and deduction in- the C3 system. They will be joining the formation at the finest granularity. Re- 10,000 executive system employees C3 Quest for New System In porting is done by adding up detail in- has been paying since May of 1997. It is the early 1990s, the Payroll Services De- stead of backing down from aggre- expected that the remaining 60,000 em- partment and the Information Services gate values. ployees will move to C3 in mid-1999. Products & Services Used • Sun workstations running Solaris V2.5 with OpenWin/CDE • BSI tax package (MicroFocus COBOL) statically linked into • PC workstations running Win95 the VisualWorks virtual machine • VisualWorks Smalltalk V2.5.1 with ENVY V3.01 on Sun • C, ProC, MicroFocus Cobol interface programs server Enterprise 2 (development) • Sybase Net Gateway to MVS with CICS and DB2 (legacy in- • GemStone V4.1.4.1 running on Sun server Enterprise 3000 put) • Kent Beck Testing Framework • Interfaced to KBMS expert system module (wage attach- • Refactoring Browser (UIUC) ment) • Block Profiler (Jim Haungs) • BeeperStrategy object beeps support in times of stress To go fast, we have to know what we’re going to do before system as simple as possible, making it easy to understand at we do it. Each chunk of development starts with a CRC-card all times. design session. Several developers attend this session, and for We go fastest when we work in pairs. Every line of produc- anything interesting, customers attend as well. At the end of tion code must be written by two people sitting together at the the CRC session, the customers know we understand what has same terminal. This gives fast progress with high quality on to be done, and several developers know how the new features everything we do. Plus, there are always at least two developers will fit into the system. intimately familiar with any part of the system. To go fast, the system must be kept lean and mean. When To go fast, we have to be able to change any objects that we put in our simple code, we then refactor to keep the whole support the feature we’re building. This means that any devel- www.DistributedComputing.com DISTRIBUTED Computing 27
  • 53. CASE STUDY opment pair must read and edit code created by any other. So There’s no waiting for features needed in some other class, so we all code exactly the same way: We name classes the same we move quickly. way, name methods the same way, even format our code ex- Simplicity is the core of aggressiveness: It’s easy to be ag- actly the same way. All the code looks familiar to everyone gressive when you can understand what you’re doing. and is easy for everyone to understand. Finally, there are extensive tests for the whole system, amount- Conclusion Currently, C3 is supporting Chrysler’s monthly-paid ing to sample code showing how everything is supposed to work. employees and developing the next payment population, the bi- When we need to learn (or be reminded) how weekly. We maintain a single source: All new something works, we can review the tests as development is integrated weekly into the well as the actual usage of the objects. production system. e only W The C3 team found our old waterfall Testing It is critical that, while going fast, we methodology too complex and cumbersome. maintain quality. When we evolve the system to new capabilities, we don’t want to break release Seeing the shortcomings of that approach and knowing it wouldn’t get the job done, things that used to work. We have over 3000 unit tests, testing every code we were ready for Extreme Programming. Extreme Programming is a great approach method that could possibly fail. We always for teams implementing object-based applica- write unit tests before releasing any code, usu- ally before even writing the code. Our com- when all the unit tions. Object-orientation lends itself well to evolutionary development of systems. With plete suite of unit tests, exercising the entire domain, runs in less than ten minutes, so we tests in the entire CRC, new team members, developers, and customers quickly learn the meaning of C3’s can afford to run all the tests every time any- one releases any code. And we do: We only re- system run at key objects. They are able to join the team and immediately contribute. Our team mem- lease code when all the unit tests in the entire bers’ experience ranges from less than one system run at 100%. We know we didn’t break anything, which increases our confidence and 100%. year to over thirty years. None of us would consider using any other methodology. lets us be aggressive in making necessary We have focused on communication here, changes. but many Extreme Programming practices have contributed to Customers are rightly concerned that we won’t understand C3’s success: the requirements, or that we will make mistakes, or break OLD WAY EXTREME WAY things as we go along. Customers have responsibility for release, Limited Customer Contact Dedicated Customers on Team and they don’t want to make a mistake. No metaphor Good metaphor Our customers own over six hundred functional tests, Central up-front design Open evolving design which are the final certification of the system. Developers pro- Build for the future Evolve to the future, just in time vided the tools for building and running the tests, but cus- Complex implementation Radical simplicity Developers in isolation Pair programming tomers define the tests and make the final decision for produc- Tasks assigned Tasks self-chosen tion release by examining the test results. Infrequent big-bang integration Continuous integration Each functional test has a corresponding user story. The test GUI-driven Model driven describes an employee, pays that employee, and checks tens to Fear Aggressiveness hundreds of results. Groups of tests are organized into suites, Ad-hoc workspace testing Unit / Functional Testing Limited top-down communication Communicate, communicate, with each suite testing development from one project iteration. communicate We graph functional test scores every day, showing green for correct results and red for incorrect. Anyone can see from Using the process described, the C3 team was able to start over anywhere in the room how well we’re moving toward function on a very difficult problem and deliver a high-quality applica- complete. tion on time and within budget. The combination of simplicity, communication, testing, and aggressiveness, applied by a disci- Aggressiveness With Extreme Programming, simplicity plined team, gave the best results—and the most fun—any of plus communication plus testing yields aggressiveness. us has ever seen. o Testing helps keep the system simple: We can always refac- tor, using the tests to make sure everything is working. The Ann Anderson, Ralph Beattie, Kent Beck, David Bryant, Marie DeArment, system stays simple, easy to understand and change. Martin Fowler, Margaret Fronczak, Rich Garzaniti, Dennis Gore, Brian Hacker, Communication lets us know exactly what has to be done, Chet Hendrickson, Ron Jeffries, Doug Joppie, David Kim, Paul Kowalsky, and what everyone else is up to. Since we all work the same Debbie Mueller, Tom Murasky, Richard Nutter, Adrian Pantea, and Don way, we can quickly edit any objects as we build what we need. Thomas are the C3 Team, Chrysler Corporation. 28 DISTRIBUTED Computing October 1998
  • 54. Página 1 de 5 XP123 → XPlorations → Programmer's Cube (June 2000) XP Programmer's Cube - A Day in the Life June, 2000 The XP Programmer's Cube is an artifact that captures the key activities in a day in the life of an XP programmer. XP Programming Activities XP is unusual as methodologies go, in that it prescribes activities at the day-by-day (and even at the minute-by-minute) level. A state machine is a traditional way to show a set of activities and the possible transitions between them. We might show XP's programming activities like this: The triangle in the middle catches a key idea in XP: test, then code, then refactor This is the opposite of traditional programming: design, then code, then test http://www.xp123.com/xplor/xp0006/index.shtml 05/07/2005
  • 55. Página 2 de 5 Let's look at the activities one at a time: Standup Meeting at 9 AM This is not an official part of XP. Many teams use it to get focused for the day. The fixed starting time helps remind the team to work a 40-hour week. Pair Up All production code is produced by a pair. The typist thinks tactically, the partner thinks strategically. Switch roles periodically. Test Write only small bits of unit test code at a time. Verify that the test fails before coding. (It's sure interesting if it doesn't fail.) "Test everything that could possibly break." Code "Do the Simplest Thing That Could Possibly Work." Implement just enough to make the test pass. Follow the team's coding standard. Refactor Seek out "code smells" (places that don't feel right); apply a refactoring; verify that the unit tests still pass. The code should: Run all unit tests Communicate what it needs to Have no duplicate logic Have as few classes and methods as possible Take small steps, and unit-test after each. See Refactoring, by Martin Fowler. Q&A The customer is available on-site to provide immediate answers. Many questions require decisions (not facts) - and the customer should be prepared to make them. The customer should write an acceptance test or (more rarely) a story to capture their answer. http://www.xp123.com/xplor/xp0006/index.shtml 05/07/2005
  • 56. Página 3 de 5 Integrate or Toss Move the code to the integration machine, build the system, and run all tests. Fix things to bring the unit tests back to 100%. If you can't easily integrate, throw it away and try again tomorrow. Return to "Pair Up" If you have time left in the day, you can pair up (or at least switch roles), and start over on another task. Go Home @ 5PM Going home on time reinforces the practice of having a 40-hour week. Notice that nothing is hanging over your head - everything you've done for the day is integrated (or tossed). The XP Programmer's Cube By a lucky twist (and a little fiddling), it turns out that the core of this cycle can be embedded onto the shape of a cube: http://www.xp123.com/xplor/xp0006/index.shtml 05/07/2005
  • 57. Página 4 de 5 It's unlikely that a real team will follow the process by sitting down and flipping the cube every time they make a move - so why bother? A 3-dimensional artifact can't be left under a pile of paper - it has a better chance of being looked at. The cube can help in training, giving beginners something concrete to look at and think about. The cube helps remind you of important aspects of XP: Always have a partner. http://www.xp123.com/xplor/xp0006/index.shtml 05/07/2005
  • 58. Página 5 de 5 Get answers before you code. Test-first programming. Throw it away when you need to. Go home "clean". Conclusion The XP Programmer's Cube embodies the daily activities of the XP lifecycle: Pair Up, Q&A, Test, Code, Refactor, and Integrate or Toss The cube is a visible artifact that can remind us of important practices that an XP team values. Link: Word document with a cutout cube. NOTE: I'm still giving away pre-made cubes. Send me your physical address and I'll send you one. Resources and Related Articles Extreme Programming Explored, by Bill Wake. This article is the basis for chapter 9. Extreme Programming Explained: Embrace Change, Kent Beck. [Written 5-31-2000; fixed typo 6-5-00.] Copyright 2000-2004, William C. Wake ....... Email ....... Top of Site http://www.xp123.com/xplor/xp0006/index.shtml 05/07/2005
  • 59. Code   Refactor Q&A   Test  Start:  Pair Up XP Programmer’s Cube Copyright 2000 by William C. Wake  Integrate or Toss