Manual 02

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


¿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

2


¿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

3


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

4


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

5


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

6


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

7


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

8


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

9


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

10


XP - Iteración

*

21

XP – Desarrollo

*

22

11


XP – Propiedad colectiva del código

*

23

XP - Retroalimentación

24

12


Agenda

 ¿Qué es XP?
 Errores comunes

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

13


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


 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

14


 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

 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

15



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

16



33


34

17


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

18


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

19


 Juego de la Planeación:

39

Core practices-Requirements (Release
Planning game)

40

20


 Juego de la Planeación del Release:

41


 Realizaremos ahora un Ejercicio de
Juego de la planeación.

42

21


 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


44

22



45


 Realizaremos ahora un Ejercicio de
Juego de la planeación.

46

23



 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


 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

24


 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

25


 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

 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

26


 Refactorización frecuente: Haremos un ejercicio de
refactoring.

53

 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

27


 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

28


 Coding standards:

57

 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

29


 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


 Pair programming:
 Realizaremos un ejercicio de pair
programming simulado

60

30



 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

 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

31


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

32


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

33


 Integración continua.

67


 Cuarto común del proyecto:
 El valor que justifica esta práctica es la
comunicación.
 Realizaremos un ejercicio.

68

34


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

 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

35


 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

 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

36


 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

37


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?
 Errores comunes

76

38


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


 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

39


 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


 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

40


Casos de éxito

 Proyectos grandes. (ThoughtWorks)
 Proyectos medianos. (Symantec)
 Pequeños (Chrysler-Nómina).

81

Agenda

 ¿Qué es XP?
 Errores comunes

82

41


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

42


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

43


Agenda

 ¿Qué es XP?
 Errores comunes

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

44


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

45


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

46


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

47


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

48

CASE STUDY

Chrysler Goes to “Extremes”

By the “C3 Team”

24 DISTRIBUTED
Computing October 1998

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

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

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

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

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

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

Manual 02

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Manual 02

Ähnlich wie Manual 02 (20)

Mehr von Ricardo Quintero

Mehr von Ricardo Quintero (17)

Manual 02