FANDOM


Prólogo:

Éste es un libro sobre la Programación Extrema (XP) es un método ligero para que equipo de tamaño mediano a pequeño desarrollen software frente a requisitos imprecisos y muy cambiantes. Este libro pretende ayudarle a decidir si XP es adecuada para ti. 

Para algunas personas, XP parece algo de sentido común. Entonces, ¿por qué "extrema" en el nombre? XP toma principios y práctico de sentido común a niveles extremos. 

  • Si las revisiones de código son buenas,revisaremos el código todo el tiempo (programación en parejas).
  • Si las pruebas son buenas, todos probarán durante todo el tiempo (prueba unitaria), incluso los clientes (prueba funcional).
  • Si el diseño es bueno, haremos que forme parte de la ocupación diaria de todos (recodificación).
  • Si la simplicidad es buena, siempre dejaremos el sistema con el diseño más sencillo que soporte su funcionalidad actual (la cosa más sencilla que probablemente pudiese funcionar).
  • Si la arquitectura es importante, todos trabajarán definiendo y refinando la arquitectura todo el tiempo (metáfora).
  • Si las pruebas de integración son importantes,entonces integraremos y probaremos varias veces al día (integración continua).
  • Si las iteraciones cortas son buenas, haremos iteraciones realmente cortas, segundos, minutos y horas, y no semanas, meses y años (el juego de la planificación). 

XP promete reducir el riesgo del proyecto, mejorando la sensibilidad a los cambios del negocio, mejorando la productividad a lo largo de la vida de un sistema; y añade diversión a la construcción de software en equipo.

¿Qué es xp?

Es una forma ligera, eficiente, de bajo riesgo, predecible, científica y divertida de Desarrollar software.

  •  Se diferencia de otros métodos por:
  • Su inmediata, concreta y continúa realimentación de los ciclos cortos
  • Su enfoque de planificación incremental
  • Su capacidad para programar de forma flexible la implementación de funcionalidades.
  • Su confianza en las pruebas automatizadas, escritas por los programadores y los clientes para controlar el progreso del desarrollo, para permitir la evolución del sistema y captar los defectos lo antes posible.
  • XP es una disciplina de desarrollo del software, que  está diseñada para trabajar con proyectos, con equipos de dos a diez programadores, que no estén fuertemente condicionados por el entorno de computación existente, y en donde un trabajo razonable de ejecución de pruebas puede hacerse en una fracción de

un día.

La novedad de XP está en:

•       Poner todas estas prácticas bajo un mismo paraguas.

•       Asegurar que todas son practicadas tan minuciosamente como sea posible.

•       Asegurar que las prácticas se apoyan unas a otras en el mayor grado posible.

XP surge como un experimento en respuesta a la pregunta: "¿Cómo podrías programar si tuvieses el tiempo suficiente?". Actualmente, no puedes tener tiempo extra, pero si tuvieses tiempo suficiente, podrías escribir pruebas; reestructurar el sistema cuando aprendieses algo, y podrías hablar mucho con los compañeros programadores y con el cliente. 

Capítulo 1:

El riesgo: el problema básico

El desarrollo del software fracasa en la entrega, y en la entrega de valor. Este fracaso tiene un gran impacto económico y humano. Necesitamos encontrar una nueva forma de desarrollar.

El problema básico del desarrollo del software es el riesgo. Ejemplos de riesgo:

·         Proyecto cancelado: después de numerosos retrasos, el prefecto se cancela sin haber entrado nunca en producción.

·         Retraso de planificación

·         El sistema se deteriora: los costes de hacer cambios o la tasa de defectos crecen tanto que el sistema debe ser reemplazado.

·         Tasa de defectos, tasa de defectos es tan alta que no se usa

·         Requisitos mal comprendidos: resuelve el requisito planteado inicialmente

·         Cambios en el negocio: el problema de negocio para el que se diseñó la solución inicial fue remplazado hace seis meses por otro problema

·         Falsa riqueza de características, un montón de características potencialmente

               Interesantes, todas las cuales fueron divertidas de programar, pero ninguna de las      cuales hace que el cliente gane más dinero.

·         Cambios de personal: después de dos años, todos los buenos programadores del proyecto, comienzan a odiar el programa y se marchan.

XP es una disciplina de desarrollo del software que trata el riesgo en todos los niveles del proceso de desarrollo. Además, es muy productiva, produce software de alta calidad, y es muy divertida de ejecutar.

¿Cómo trata el riesgo?

·         Desviaciones de planificación: propone un ciclo de versión corto, unos pocos meses como máximo, de tal manera que el alcance de cualquier desviación sea limitado

·         Proyecto cancelado: propone al cliente que elija la versión más pequeña que tenga más sentido para su negocio

·         El sistema se deteriora: crea y mantiene con todo detalle un conjunto de pruebas

·         Tasa de defectos: realiza pruebas tanto desde la perspectiva de los programadores que escriben pruebas función a función como de los clientes que escriben pruebas prestación a prestación.

·         Requisitos mal comprendidos: el cliente se integra como parte del equipo, la especificación se refina continuamente durante el desarrollo.

·         Cambios en el negocio: reduce los ciclos de las versiones, menos cambios durante el desarrollo de una versión, se favorece que el cliente sustituta nuevas funcionalidades por funcionalidades aun no completadas.

·         Falsa riqueza de prestaciones: insiste en que solamente se traten las tareas de prioridad más alta.

·         Cambios de persona: pide a los programadores que acepten la responsabilidad de estimar y completar su propio trabajo. También anima al contacto humano entre el equipo, reduciendo el aislamiento, que es a menudo el origen de la insatisfacción en el trabajo. XP alienta a los nuevos miembros de equipo a aceptar gradualmente más y más responsabilidad y son asistidos durante su trabajo por los otros.

Nuestra misión

Si aceptamos que el riesgo de un proyecto es el problema a resolver, necesitamos inventar un estilo de desarrollo de software que trate esos riesgos. Para ello, es necesario comunicar esta disciplina claramente a los programadores, directos y clientes.

Capítulo 2:

Un episodio de desarrollo

La programación de todos los días se desarrolla como una tarea claramente conectada con una presentación que el cliente quiere, con pruebas, con implementación, con diseño pasando por la integración.

Este capítulo es la historia de un latido de XP —el episodio de desarrollo—. Es donde un programador implementa una tarea de ingeniería (la menor unidad de planificación) y lo integra con el resto del sistema. 

Éste es el ciclo de desarrollo completo de la XP. Observa que:

•        Las parejas de programadores programan juntos.

•        El desarrollo es guiado por pruebas. Primero pruebas y después codificas. Hasta que todas las pruebas funcionan, no has terminado. Cuando todas las pruebas funcionan, y no puedes pensar en ninguna otra prueba que podría fallar, has finalizado de añadir funcionalidad.

•        Las parejas no sólo ejecutan los casos de prueba, sino también se encargan de la evolución del diseño del sistema. Los cambios no se restringen a un área particular. Las parejas añaden valor al análisis, diseño, implementación y pruebas del sistema.

•        La integración sigue inmediatamente al desarrollo, incluyendo las pruebas de integración.

Capítulo 3:

Economía del desarrollo del software

Necesitamos hacer nuestro desarrollo de software económicamente más valioso gastando el dinero más lentamente, obteniendo beneficios más rápidamente, e incrementando la cantidad de tiempo en que el proyecto siga siendo productivo. Pero sobre todo necesitamos aumentar las opciones para las decisiones de negocio.

 

Factores que hacen que nuestro proyecto sea valioso:

•        Flujos de caja de entrada y salida.

•        Tipos de interés.

•        Mortalidad del proyecto.

Con estos podernos crear una estrategia para maximizar el valor económico del proyecto. A continuación los ejemplos:

•        Gastando menos uno comienza casi con las mismas herramientas y habilidades. Gastando menos, lo cual es difícil porque cada uno comienza casi con las mismas herramientas y habilidades.

•        Ganando más, lo cual es solamente posible con una organización excelente de marketing y ventas, estos aspectos no los trataremos en este libro (gracias a Dios).

•        Gastando más tarde y ganando antes, así pagaremos menos intereses del dinero que gastemos y ganaremos más intereses del dinero que recibamos.

•        Aumentando la probabilidad de que el proyecto siga vivo, de tal forma que tengamos más probabilidad de obtener el pago importante de finalización del proyecto.

Opciones

La economía de un proyecto software, como una sucesión de opciones. En la gestión de un proyecto software en donde pueden observarse cuatro clases de opciones:

•        Opción de abandonar. Cuanto más valor puedas obtener del proyecto sin entregarlo, mejor.

•        Opción de cambiar. si a mitad del proyecto los clientes pueden cambiar los requisitos. Cuanto mayor sea la frecuencia y profundidad de los cambios de los requisitos que puedas hacer, mejor.

•        Opción de aplazar: puedes esperar a gastar el dinero sin perder totalmente la posibilidad de inversión. Cuanto mayor sea el aplazamiento y mayor la cantidad de dinero que se pueda aplazar, mejor.

•        Opción de crecer. Si un mercado empieza a tener éxito, puedes crecer rápidamente para obtener ventaja de ello.

Hay cinco factores implicados:

·         La cantidad de inversión requerida para obtener la opción.

·         El precio al que puedas comprar otra cosa si procedes con la opción.

·         El valor actual de la otra cosa.

·         La cantidad de tiempo en que puedes ejercer las opciones.

·         La incertidumbre en el valor final del precio.

De las cinco, el valor de las opciones está generalmente determinado por el último factor, la incertidumbre. A partir de esto podemos hacer una predicción concreta.

Cuanto mayor es la incertidumbre, más valiosa será la estrategia. Esto es cierto si la incertidumbre proviene del riesgo técnico, de un entorno de negocios cambiante, o de una evolución rápida de los  requisitos.

Entonces la pregunta es: ¿Cuándo deberíamos utilizar XP? Utiliza XP cuando los requisitos sean vagos o cambiantes.

Capítulo 4:

 

Cuatro variables

Controlaremos cuatro variables en nuestros proyectos - coste, tiempo, calidad y ámbito.

Modelo de desarrollo del software desde la perspectiva de un sistema de variables de control. En este modelo, hay cuatro variables en el desarrollo del software:

•        Coste

•        Tiempo

•        Calidad

•        Ámbito

Las fuerzas externas eligen los valores de tres variables cualesquiera. El equipo de desarrollo el valor resultante de la cuarta variable.

Hacer visible las cuatros variables te permite escoger las variables a controlar. Si no les gusta resultado que corresponde a la cuarta variable, pueden cambiar las entradas, o pueden elegir otras tres variable diferentes a controlar.

Interacciones entre las variables

•        Coste: Mucho dinero puede engrasar la maquinaria un poco, muy poco dinero, no seremos capaces de resolver el problema

•        Tiempo: Disponer de más tiempo para la entrega puede mejorar la calidad e incrementar el ámbito.

•        Calidad: La calidad es terrible como variable de control. Puedes obtener beneficios a corto plazo, pero el coste  es enorme

•        Ámbito: Menos ámbito hace posible entregar mejor. También permite entregar más rápido y barato. No hay una relación sencilla entre las cuatro variables.

No hay una relación sencilla entre las cuatro variables. El coste es la variable más limitada. No puedes gastar sólo en calidad, o ámbito, o ciclos de entrega cortos. Al comienzo de un proyecto, no puedes gastar mucho. La inversión tiene que comenzar siendo pequeña y crecer con el tiempo.

El coste está profundamente relacionado con las otras variables. Dentro del rango de inversión que pueda sensatamente hacerse, gastando más dinero puedes aumentar el ámbito, o puedes intentar de forma más deliberada aumentar la calidad, o puedes (hasta cierto punto) reducir el tiempo de salida al mercado.

La calidad es otra variable extraña. A menudo, al insistir en la mejora de la calidad puedes hacer que el proyecto esté listo antes, o puedes conseguir hacer más en una cantidad de tiempo dado.

Hay una extraña relación entre la calidad interna y la externa. La calidad externa es la calidad que mide el cliente. La calidad interna es la calidad que miden los programadores. Sacrificar temporalmente la calidad interna para reducir el tiempo de salida al mercado del producto, con la esperanza que la calidad externa no se vea muy dañada es tentador a corto plazo. Y puedes con frecuencia hacerlo impunemente generando una confusión en cuestión de semanas o meses. Al fin y al cabo, los problemas de calidad interna te alcanzan a ti y hacen que tu software sea prohibitivamente caro de mantener, o incapaz de alcanzar un nivel de competitividad de calidad externa.

Hay un efecto humano en la calidad. Cualquiera quiere hacer un buen trabajo, y se trabaja mejor si se siente que se está haciendo un buen trabajo. Si deliberadamente se degrada la calidad, el equipo puede ir más rápido al principio, pero pronto la desmoralización de producir un software basura aplastará cualquier ganancia que temporalmente se haya obtenido de no hacer las pruebas, o las revisiones, o utilizar estándares.

Para el desarrollo de software, el ámbito es la variable más importante a tener en cuenta.Si se gestiona activamente el ámbito, se puede proporcionar a los directores de proyecto y clientes control sobre el coste, calidad y tiempo.

Una de las principales cuestiones acerca del ámbito, es que es una variable que varía mucho. Durante décadas los programadores han estado gimiendo "los clientes no nos pueden decir lo que ellos quieren. Cuando le damos lo que ellos dicen que quieren, no les gusta". Esto es una verdad absoluta en el desarrollo de software. Los requisitos nunca son claros al principio. Los clientes no pueden decirnos exactamente lo que ellos quieren. Este aprendizaje solamente puede venir de la experiencia.

Si dejas fuera importante funcionalidad al final de cada ciclo de versión, el cliente quedará disgustado. Para evitar esto, XP utiliza dos estrategias: 

1.       Consigue mucha práctica haciendo estimaciones y realimentando los resultados reales. Mejores estimaciones reducen la probabilidad de que tengas que dejar fuera funcionalidad.

2.       Implementa en primer lugar los requisitos más importantes del cliente, de tal manera que si se deja después alguna funcionalidad, es menos importante que la funcionalidad que ya está incorporada al sistema.

Capítulo 5:

El coste del cambio

Una de las suposiciones universales en la ingeniería del software es que el coste del cambio de un programa crece exponencialmente con el tiempo. "El coste de corregir un problema en un software crece exponencialmente con el tiempo. Un problema que puede costar un euro corregirlo si lo encuentras durante el análisis de requisitos, puede costar miles de euros resolverlo si el software está en producción".

Bajo ciertas circunstancias, el crecimiento exponencial del coste de cambiar el software con el tiempo se puede aplanar. Si podemos aplanar la curva, las viejas suposiciones sobre la mejor forma de desarrollar el software no se mantendrán.

Mantener el coste del cambio bajo no sucede mágicamente. Hay tecnologías y prácticas que mantienen el software flexible. Existen varios factores que hacen que nuestro código sea más fácil de modificar, incluso después de varios años de producción:

•        Un diseño simple, sin elementos extra de diseño.

•        Pruebas automatizadas, con ellas tenemos confianza en que conoceremos si cambiamos accidentalmente el comportamiento del sistema.

•        Más práctica en modificar el diseño, de tal forma que cuando vienen los tiempos de cambio del sistema, no tenemos temor a tratarlos.

•        Con este cambio de suposición sobre el coste del cambio aparece la oportunidad de adoptar una aproximación totalmente diferente sobre el desarrollo del software.

•        En vez de ser cuidadoso en tomar grandes decisiones al principio y pocas posteriormente, podemos idear una aproximación para desarrollar software en la que se tome cada decisión rápidamente, pero apoyada cada decisión en las pruebas automatizadas, y que te prepara para mejorar el diseño del software cuando aprendas una mejor forma de diseñarlo.

Capítulo 6:

Aprender a conducir

Necesitamos controlar el desarrollo del software haciendo muchos cambios pequeños, y no haciendo pocos grandes cambios. Esto significa que necesitaremos realimentación para conocer cuando nos estamos desviando, necesitaremos muchas oportunidades para hacer correcciones, y tendremos que ser capaces de hacer esas correcciones a un coste razonable.

Éste es el paradigma para XP. Las cosas no son rectas y llanas. Aunque las cosas parezcan ir perfectamente, no debes quitar los ojos de la carretera. El cambio es la única constante. Has de estar siempre preparado para moverte un poco en este sentido, y un poco en este otro, etc. Algunas veces puede ser que te tengas que mover en una dirección completamente diferente. Ésa es la vida del programador.

En el software todo cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí, ya que el cambio va a suceder; el problema es la incapacidad para enfrentarse con el cambio cuando aparezca.

Capítulo 7:

Cuatro valores

Tendremos éxito cuando tengamos un estilo que reúna un conjunto consistente de valores que sirvan tanto a las necesidades humanos como a las comerciales.

Necesitamos algún criterio para saber si vamos en la dirección correcta. No sería adecuado idear un estilo de desarrollo y descubrir que no nos gusta o no funciona.

Los cuatro valores de XP son:

•        Comunicación: XP ayuda a mantener el flujo de comunicaciones apropiado empleando muchas prácticas que no se pueden hacer sin comunicación. La comunicación tienen sentido a corto plazo. El efecto de probar, emparejarse y estimar hace que los programadores, clientes y directores de proyecto tengan que comunicarse.

•        Sencillez: XP es apostar. Estás apostando que es mucho mejor hacer una cosa sencilla hoy y pagar un poco más mañana para cambiar, si es que es necesario, que hacer una cosa más complicada hoy y no utilizarla después.

•        Realimentación: La realimentación trabaja a diferentes escalas de tiempo. Primero, la realimentación trabaja a escala de minutos y de días. Los programadores escriben pruebas de unidad para toda la lógica en el sistema que podría posiblemente fallar.La realimentación también trabaja a escala de semanas y meses. Los clientes y las personas que realizan las pruebas escriben pruebas funcionales de todas las historias (piénsese "casos de uso simplificados") implementadas en el sistema.

•        Valentía: La comunicación apoya la valentía porque abre la posibilidad para experimentos de alto riesgo y grandes recompensas. La sencillez apoya a la valentía porque se puede proporcionar mucho más valor con un sistema sencillo, ya que es menos probable estropearlo sin querer. La valentía apoya la sencillez porque tan pronto como ves la posibilidad de simplificar el sistema, lo intentas. La realimentación concreta apoya a la valentía porque sientes una mayor seguridad al intentar un cambio radical sobre el código si puedes pulsar un botón y ver que las pruebas funcionan bien (o no, en cuyo caso vuelves sobre el código otra vez).

Capítulo 8:

Principios básicos

De los cuatro valores descriptos anteriormente deducimos una docena de principios básicos para guiar nuestro nuevo estilo. Estos principios nos ayudaran a escoger entre alternativas. Preferiremos una alternativa que coincida con los principios más plenamente que otra que no lo haga. Cada principio incorpora los valores. Los principios fundamentales son:

·         Realimentación rápida.

·         Asumir la sencillez.

·         Cambio incremental.

·         Aceptar el cambio.

·         Trabajar con calidad.

Principios menos importantes:

·         Enseñar a aprender.

·         Pequeñas inversiones iniciales.

·         Jugar a ganar.

·         Experimentos concretos.

·         Comunicación abierta y honesta.

·         Trabajar con los instintos de las personas, no contra ellos.

·         Aceptar la responsabilidad.

·         Adaptación particular.

·         Ir ligero de equipaje.

·         Medidas honestas.

 

Capítulo 9:

 

Vuelta a lo básico

Queremos hacer cualquier cosa que debamos hacer para tener un desarrollo de software estable y predecible. Pero no tenemos tiempo para hacer cosas extras. Las cuatro actividades básicas del desarrollo son: codificar, probar, escuchar y  diseñar.

Las cuatro actividades básicas del desarrollo son: codificar, probar, escuchar y diseñar.

Codificar

Si dibujas diagramas que generan código o escribes en un editor, estás codificando. Cuando codificas algo, también tienes la oportunidad para comprender la mejor estructura para el código. El código te da la oportunidad de comunicarte de forma clara y concisa. Permite ver la forma de tus ideas no como las ves en tu mente, sino cómo ellas encuentran su expresión en el mundo exterior. Esta comunicación fácilmente se torna en aprendizaje. Yo veo tu idea y la hago mía. Tengo dificultad en expresártela, vuelvo a codificar. Es importante aclarar que el código es el único artefacto sin el que sin lugar a dudas el desarrollo no puede vivir.

Hacer pruebas

Las pruebas dicen si lo que se implemento es lo que se pensaba que había implementado. Las pruebas indican cuándo has acabado (cuando las pruebas funcionan, has finalizado de momento la codificación). Cuando no puedes pensar en ninguna prueba que pudiese originar un fallo, has acabado por completo. A largo plazo las pruebas mantienen el programa vivo más tiempo (si las pruebas funcionan y son mantenidas). Cuando tienes las pruebas, puedes hacer más cambios durante más tiempo que si no las tuvieses. A corto plazo tener pruebas es más divertido que cuando no las tienes. Codificas con más confianza, ejecutas el programa y si se enciende la luz verde, estás preparado para hacer la siguiente cosa con la confianza renovada.

Programar y probar a la vez, es también más rápido que solamente programar. Sin embargo, hay un peligro. Las pruebas hechas erróneamente se convierten en un puñado de gafas de color de rosa. Adquieres la falsa confianza de que tu sistema funciona bien porque todas las pruebas funcionan. El truco con las pruebas es encontrar el nivel de defectos que quieras tolerar. Si puedes soportar una queja del cliente por mes, entonces invierte en pruebas y mejora tu proceso de pruebas hasta que alcances ese nivel.

Escuchar

Los programadores no conocen las cosas que las personas del negocio piensan que son interesantes. Si vas a hacer preguntas, entonces deberías estar mejor preparado para escuchar las respuestas. Ya que escuchar es la tercera actividad en el desarrollo del software. La escucha activa por parte del programador ayuda al cliente a entender lo que es difícil y lo que es fácil. La realimentación que proporcionan ayuda al cliente a entender mejor sus problemas.

Diseñar

Un buen diseño organiza la lógica, de tal forma que un cambio en una parte del sistema no siempre requiere un cambio en otra parte del sistema. Un buen diseño asegura que cada trozo de lógica en el sistema está en uno y solamente un lugar. Un buen diseño pone la lógica cerca de los datos sobre los que opera. Un buen diseño permite el crecimiento del sistema con cambios en un solo lugar. Un mal diseño es justo lo opuesto.

Así, la última actividad que tenemos que estructurar en nuestra nueva disciplina es el diseño. Tenemos que proporcionar un contexto en el que buenos diseños sean creados, y diseños malos sean corregidos, y el diseño actual sea aprendido por cualquiera que lo necesite aprender.

 

Capítulo 10:

 

Una visión general rápida

Principales áreas de práctica en XP:

  • El juego de la planificación: El desarrollo del
    software es siempre un diálogo que evoluciona entre lo posible y lo
    deseable. La naturaleza del diálogo es lo que cambia entre lo que se
    percibe como posible y lo que se percibe como deseable.  
  • Pequeñas versiones: Cada versión debería ser tan
    pequeña como fuese posible, conteniendo los requisitos del negocio más
    importantes. La versión tiene que tener sentido como un todo, es decir, no
    puedes implementar la mitad de una característica y lanzar la versión, lo
    que tienes que hacer es reducir el ciclo de la versión.
  • Metáfora: Cada proyecto de software de
    XP está guiado por una única metáfora compartida por todos. La metáfora en
    XP sustituye mucho de lo que otra gente llama "arquitectura".
    Ésta ayuda a cualquier persona del proyecto a entender los elementos
    básicos y sus relaciones.
  • Diseño sencillo: En
    cualquier momento dado, el sistema debería ser diseñado tan simple como
    sea posible. La complejidad extra se eliminará tan pronto como ésta sea
    descubierto. El diseño
    adecuado para el software es aquel que funciona con todas las pruebas, no
    tiene lógica duplicada, manifiesta cada intención importante para los
    programadores, tiene el menor número posible de clases y métodos.
  • Hacer
    pruebas: Los
    programadores escriben pruebas de unidad para que su confianza en el
    funcionamiento del programa pueda ser parte del programa mismo. No es
    necesario escribir una prueba para cada método sencillo que se escriba,
    solamente para los métodos en producción que posiblemente fallasen.
  • Recodificación: los programadores se preguntan
    cómo pueden hacer el programa más sencillo, mientras todavía funcionan
    todas las pruebas. Esto se denomina recodificar (refactoring). Si un
    programador ve que en un minuto escaso puede conseguir que una prueba
    funcione y que en diez minutos puede hacer que funcione con un diseño
    sencillo, la elección correcta es invertir los diez minutos.
  • Programación en parejas: Hay dos papeles en cada pareja. Uno de los
    miembros, con el teclado y el ratón, está pensando la mejor forma de
    implementar el método correcto. El otro miembro está pensando más
    estratégicamente: ¿Esta aproximación global va a funcionar? ¿Todavía,
    hay algunos casos de prueba que pueden hacer que no funcione? ¿Hay alguna
    forma de simplificar el sistema global para que el problema actual
    desaparezca?
  • Propiedad colectiva: Cualquiera
    que vea una oportunidad de añadir valor a cualquier parte del código, es
    necesario que lo haga en cualquier momento.  En XP, cualquiera tiene responsabilidad sobre todo el sistema. Nadie conoce
    cada parte igual de bien, aunque cualquiera conoce algo sobre cada parte.
    Si una pareja está trabajando y ven una oportunidad de mejorar el código,
    siguen adelante y lo mejoran si esto hace sus vidas más fáciles.
  • Integración continua: El código es integrado y
    probado después de unas pocas horas (un día de desarrollo como máximo).
    Una forma de hacer esto es tener una máquina dedicada a la integración.
    Cuando la máquina está libre, una pareja con código para integrar, se
    sienta, carga la versión actual, carga sus cambios (probando y resolviendo
    cualquier colisión) y ejecuta las pruebas hasta que funcionan (100%
    correctas).
  • 40 horas semanales: Las horas extras son un
    síntoma de un problema serio en el proyecto. La regla de XP es sencilla:
    no puedes trabajar una segunda semana de horas extraordinarias. Una
    semana, bien, arrancas y metes algunas horas extra. Si llegas el lunes y
    dices "para conseguir los objetivos, tendremos que trabajar aún
    más" entonces tienes ya un problema que no se puede resolver trabajando
    más horas.
  • El cliente
    in-situ: Un cliente
    real debe sentarse con el equipo, estar disponible para responder a las
    preguntas, resolver discusiones, y fijar prioridades a pequeña escala. La
    parte negativa de un cliente in-situ es si ellos dedican cientos de horas
    a ayudar a los programadores y el proyecto es cancelado. Entonces se ha
    perdido el trabajo que hicieron y se ha perdido el trabajo que podrían
    haber hecho si no hubiesen contribuido a un proyecto fracasado.
  • Estándares
    de codificación: Sin
    normas, sería imposible decir quién del equipo escribió qué código. El
    estándar debería exigir la menor cantidad de trabajo posible y ser
    consistente con la Única y Solamente Única regla (no duplicar código). El
    estándar debería hacer hincapié en la comunicación. Finalmente, el
    estándar debería ser adoptado voluntariamente por todo el equipo.

 

Capítulo 11:

 

¿Cómo podríamos hacer?

Las prácticas se apoyan entre sí. La debilidad de una se cubre con los puntos fuertes de las otras.

·         El juego de la planificación: En principio, no podrías empezar el desarrollo con tan sólo un plan aproximado. No podrías actualizar el plan constantemente, ya que te llevaría tiempo y molestaría a los clientes.

Entonces quizá podrías comenzar el desarrollo con un plan sencillo, y refinarlo continuamente conforme fuese avanzando.

·         Versiones reducidas: En principio, no podrías llegar a la producción después de unos pocos meses. No podrías crear nuevas versiones del sistema en ciclos de tiempo comprendidos entre unos días y un par de meses.

Entonces quizá podrías hacer pequeñas versiones, comenzando poco después del inicio del desarrollo.

·         Metáfora: En principio, no podrías comenzar a desarrollar con tan sólo una metáfora. No hay el suficiente nivel de detalle en ella, y además, ¿y si estuvieses equivocado?

Entonces quizá podrías comenzar a desarrollar con una sola metáfora.

·         Diseño sencillo: En principio, no tendrías bastante diseñando para codificar hoy. Diseñarías hasta que llegasen las dificultades y entonces te quedarías atascado, incapaz de continuar evolucionando el sistema.

Entonces quizá podrías hacer el mejor trabajo posible haciendo un diseño para el día.

·         Hacer pruebas: En principio no escribirías todas esas pruebas. Te llevaría mucho tiempo. Los programadores no escribirán pruebas.

Entonces quizá los programadores y clientes escribirán pruebas. Además, si no escribes pruebas automatizadas, el resto de XP no funcionará bien.

·         Recodificación: En principio, no podrías hacer recodificación del diseño del sistema durante todo el tiempo. Te llevaría mucho tiempo, y sería difícil de controlar, y probablemente el sistema no funcionaría.

Entonces quizá podrías hacer recodificación donde vieses la posibilidad de simplificar el sistema, o reducir la duplicación, o comunicarte de forma más clara.

·         Programación en parejas: En principio, no podrías escribir todo el código de producción en parejas. Eso sería muy lento. ¿Qué ocurre si dos personas no pueden continuar juntas?

Entonces podrías escribir todo el código de producción en parejas. Además, si las personas programan solas, es más probable que cometan errores, que diseñen de más y que escapen de las otras prácticas, especialmente si están bajo presión.

·         Propiedad colectiva: En principio, no podrías tener a todo el mundo en potencia cambiando cualquier cosa en cualquier lugar. Las personas estropearían cosas a diestra y siniestra, y el coste de la integración crecería dramáticamente.

Entonces quizá, cualquiera podría cambiar el código en el sistema cuando vea la posibilidad de mejorarlo. Además, sin una propiedad colectiva la velocidad de evolución del diseño es mucho más lenta.

·         Integración continua: Posiblemente no podrás integrar después de unas pocas horas de trabajo. La integración lleva mucho tiempo y hay muchos conflictos, y la posibilidad de dañar accidentalmente algo.

Entonces quizá podrías integrar después de unas pocas horas. Además, si no integras rápidamente, entonces la posibilidad de conflictos crece y el coste de integración crece rápidamente.

·         40 horas semanales: En principio, no podrías trabajar 40 horas semanales. No puedes crear suficiente valor de negocio en 40 horas.

Entonces podrás producir suficiente valor de negocio en 40 horas semanales. Además, si el equipo no está fresco y con energías, no será capaz de llevar a cabo el resto de las prácticas

·         El cliente in-situ: En principio, no podrías tener un cliente real en el equipo, dedicado a tiempo completo. Pueden producir más valor para el negocio en otra parte.

Entonces quizá puedan producir más valor para la compañía mediante su contribución al proyecto. Además, si el equipo no incluye un cliente, ellos tendrán que añadir un riesgo al proyecto conforme la planificación y la codificación avancen, ya que no se conocerá exactamente qué pruebas tienen que satisfacer y qué pruebas pueden ignorar.

·         Estándares de codificación: En principio, no podrías pedirle al equipo que codificase con un estándar común. Los programadores son muy individualistas, y abandonarían antes de poner sus corchetes en alguna otra parte.

Entonces quizá querrán cambiar un poco su estilo. Además, sin estándares de codificación las discusiones adicionales harán mucho más lenta la programación en parejas y la recodificación.

 

Capítulo 12:

 

Estrategia de gestión

Se gestiona un proyecto utilizando técnicas de negocio: entrega por fases, realimentación rápida y precisa, articulación clara de las necesidades de negocio del sistema,  y especialistas para tareas  especificas.

El trabajo del director de proyecto es poner en marcha el juego de la planificación, reunir métricas, y asegurarse que las métricas son observadas por aquellos cuyo trabajo está siendo medido, y ocasionalmente intervenir en situaciones que no puedan resolverse de forma descentralizada.

 

Métricas

La herramienta de gestión básica de XP es la métrica.No es recomendable tener muchas métricas y prepárate para eliminar las métricas que hayan cumplido su propósito. Tres o cuatro medidas es lo que normalmente un equipo puede tolerar al mismo tiempo. Las métricas tienden a degradarse con el tiempo. En particular, cualquier métrica que está llegando al 100% es probable que sea inservible. Esto no sugiere que puedas gestionar un proyecto XP "con los números", y constituyen una  amable y no coercitiva forma de comunicar la necesidad de cambio.

 

Preparación

Lo que mucha gente piensa que es la gestión está dividida en dos roles en XP: el preparador y el controlador (estos puestos pueden o no estar ocupados por la misma persona). El preparador está principalmente relacionado con la ejecución técnica (y evaluación) del proceso. El preparador ideal es un buen comunicador, no se asusta fácilmente, es técnicamente habilidoso (aunque éste no es un requisito necesario) y seguro de sí mismo. El preparador no tiene responsabilidad sobre muchas tareas de desarrollo. Más bien, su trabajo debe ser el siguiente:

·         Estar disponible como un compañero de desarrollo, especialmente para que los nuevos programadores comiencen a tomar responsabilidades o para tareas técnicas difíciles.

·         Ver objetivos de recodificación a largo plazo, y alentar la recodificación a pequeña escala para alcanzar parte de estos objetivos.

·         Ayudar a los programadores con habilidades técnicas individuales, como hacer pruebas, dar formato al código y recodificar.

·         Explicar el proceso a los directivos de niveles superiores.

Control

El otro componente principal de la gestión en XP. Se pueden hacer todas las estimaciones que se quieran, pero si no se mide lo que realmente sucede frente a lo que se estimó que sucedería, nunca se aprenderá. El trabajo del controlador es reunir lo que las métricas están controlando en un momento y asegurarse que el equipo es consciente de lo que se estaba midiendo realmente (y recordar lo que se había estimado o deseado). El controlador necesita conocer las reglas del juego en frío y estar preparado para hacerlas cumplir incluso en situaciones emocionales (la planificación es siempre emocional).

 

Intervención

Hay veces que los problemas simplemente no pueden ser resueltos por la brillantez del equipo, animado por un director de proyecto cariñoso y atento. En situaciones como éstas, el director de proyecto de XP debe sentirse cómodo e intervenir, tomando decisiones —algunas impopulares— y viendo las consecuencias hasta el final.

Un asunto serio para una intervención son los cambios de personal. Si un miembro del equipo no está trabajando bien, el director de proyecto debe pedirle que abandone el equipo. Y decisiones como ésta es mejor tomarlas antes que después. Un deber un poco más agradable es intervenir cuando el proceso del equipo necesita cambiar.

Generalmente, no es trabajo del director de proyecto ordenar lo que hay que cambiar y cómo, sino señalar la necesidad del cambio. El equipo debería presentar un experimento a realizar. Entonces el director de proyecto es informado sobre los cambios causados por el experimento. La última responsabilidad para una intervención del director de proyecto es para cancelar el proyecto. El director de proyecto es responsable de ser consciente de cuándo se ha cruzado el umbral y de informar a la alta dirección de la necesidad de un cambio.

Capítulo 13:

 

Estrategia de instalaciones

Crearemos un espacio de trabajo abierto para nuestro equipo, con pequeños espacios privados alrededor y un área de codificación común en el centro.   Si no tienes un lugar razonable para trabajar tu proyecto no tendrá éxito. XP es una disciplina comunal de desarrollo de software. Los miembros del equipo necesitan poder verse unos a otros, oír problemas excepcionales gritados, oír "accidentalmente" conversaciones en las cuales puedan hacer contribuciones esenciales. Todas estas cuestiones relacionadas con el mobiliario pueden traerte problemas. El personal encargado de la gestión de las instalaciones puede agarrarse enfados al encontrar que alguien ha estado moviendo mesas sin su autorización o compromiso.

 

Capítulo 14:

 

La división de las responsabilidades técnicas y de negocio

Una clave de nuestra estrategia es hacer que el personal técnico se centre en los problemas técnicos y el personal del negocio se centré en los problemas del negocio. El proyecto debe ser dirigido por decisiones del negocio, pero las decisiones de negocio deben basarse en decisiones técnicas sobre el Coste y el riesgo.  

Hay dos modos comunes de fracaso en la relación entre Negocio y Desarrollo. Tanto si Negocio o Desarrollo ganan mucho poder, el proyecto sufre.

 

Negocio

Si Negocio tiene el poder, se siente capaz de imponer las cuatro variables a Desarrollo. Negocio siempre especifica demasiado. Si Desarrollo no tiene algún poder, no pueden oponerse, no pueden forzar a Negocio a que escoja cuál es cuál. De esta manera Desarrollo va a trabajar sumisamente, con la cabeza baja, en la tarea imposible que le han asignado. El resultado del escenario "Negocio Responsable", es que el proyecto carga con demasiado esfuerzo y poco a poco con demasiado riesgo para una pequeña ganancia.

Desarrollo

Cuando Desarrollo está al mando, ponen todos los procesos y tecnología, instalan nuevas herramientas, nuevos lenguajes, nuevas tecnologías, ya que son interesantes y son de última novedad.

Así, el resultado del escenario "Desarrollo Responsable" es que el proyecto carga con demasiado esfuerzo y poco a poco con demasiado riesgo para una pequeña ganancia.

¿Qué hacer?

La solución es que de algún modo se divida la responsabilidad y el poder entre Negocio y Desarrollo. Cada parte que toma la decisión debería informar a la otra. Ninguna parte debería ser capaz de decidir cualquier cosa de forma unilateral.  Puesto que las decisiones del negocio tienen lugar a lo largo de la vida del proyecto, dar la responsabilidad al personal del negocio para las decisiones de negocio, implica que un cliente es una parte del equipo de XP tanto como lo es el programador.

 

Elección de la tecnología

La elección de una tecnología es en realidad una decisión de negocio que debe contar con Desarrollo. El cliente tendrá que convivir con una base de datos o un lenguaje durante muchos años, y tiene que estar cómodo con la relación, tanto desde el punto de vista de negocio como del punto de vista técnico.

Si un cliente me dice "queremos este sistema, y tienes que utilizar esta base de datos relacional y ese IDE de Java," mi trabajo es indicar las consecuencias de esa decisión. Si pienso que una base de datos de objetos y C++ son más adecuados, estimaré el proyecto de ambas formas. Entonces el personal del negocio podrá tomar una decisión de negocio.

Capítulo 15:

 

Estrategia de planificación

La planificación es el proceso de adivinar lo que significará desarrollar una aplicación con un cliente. Algunos de los propósitos de la planificación son:

·         Conducir al equipo unido.

·         Decidir sobre el ámbito y las prioridades.

·         Estimar el coste y la planificación

·         Dar a todas las personas implicadas la garantía de que el sistema puede realmente construirse.

·         Proporcionar un valor de referencia para la realimentación. 

Principios que afectan a la planificación:

·         Haz solamente la planificación que necesitas para el horizonte más cercano.

·         Responsabilidad aceptada: (La responsabilidad sólo se puede aceptar, no imponer).

·         La persona responsable de la implementación hará la estimación.

·         Ignorar las dependencias entre partes.

·         Planificación por prioridades vs. Planificación para desarrollar.

 

 

 

 

El juego de la planificación

La planificación de XP separa a propósito el proceso de planificación entre dos participantes — Negocio y Desarrollo. A Negocio, a menudo, no le gusta Desarrollo. Las relaciones entre el personal que necesita los sistemas y el personal que construye los sistemas son tirantes. Abundando la desconfianza, las acusaciones y las sutiles e indirectas maniobras.

El mejor entorno es el de la confianza mutua. Cada parte respeta a la otra. Cada parte cree que la otra tiene en el fondo su mejor interés y los intereses de la mayoría.

Lo que se necesita para que se dé una relación mutua respetuosa es un conjunto de reglas que gobiernen cómo se lleva a cabo esa relación —quién tomará las decisiones, cuándo se tomarán, cómo se registrarán—. Las reglas están ahí para recordar a todos cómo deberían actuar, y proporcionan una referencia común cuando las cosas no van bien.

Aprender  a trabajar con regla:

·         El objetivo: El objetivo del juego es maximizar el valor del software producido por el equipo.

·         La estrategia: Invertir lo menos posible para poner la mayor funcionalidad válida en producción tan rápidamente como sea posible, sólo en conjunción con las estrategias de diseño y programación diseñadas para reducir el riesgo.

·         Las piezas: Las piezas en el juego de la planificación son las fichas de historias.

·         Los jugadores: Los dos jugadores en el juego de la planificación son Desarrollo y Negocio.

·         Desarrollo consta colectivamente de todas las personas que se responsabilizarán de implementar el sistema. Negocio consta de todas las personas que tomarán decisiones sobre lo que se supone que el sistema debe de hacer.

·         Los movimientos: Hay tres movimientos en el juego: Exploración. Compromiso. Dirigir.

 

Planificación de la iteración

El juego de la planificación citado da al cliente la capacidad de dirigir el desarrollo cada tres semanas. En cada iteración, el equipo de desarrollo aplica aproximadamente las mismas reglas para planificar sus actividades.  Es similar al juego de la planificación, sin embargo, las piezas son fichas de tareas en vez de fichas de historias. Los jugadores son todos los programadores individuales. La escala de tiempo se reduce (de una a cuatro semanas). Las fases y los movimientos son similares.

•        Fase de exploración

Escribir una tarea: Coge las historias para la iteración y transfórmalas en tareas.

Dividir una tarea/combinar tareas: Si no puedes estimar una tarea en unos pocos días, divídela en tareas más pequeñas. Si varias tareas necesitan una hora, combínalas para formar una tarea mayor.

•        Fase de compromiso

Aceptar una tarea.

Estimar una tarea: El programador responsable estima.

Conjunto de factores de carga: Cada programador elige su factor de carga para la iteración —el porcentaje de tiempo que dedicará realmente al desarrollo—. Es un valor numérico —la relación entre el número ideal de días de programación y los que han transcurrido—.

Balanceo: Cada programador suma sus estimaciones de las tareas y las multiplica por su factor de carga.

•        Fase de dirección

Implementar una tarea.

Registrar el progreso. Cada dos o tres días un miembro del equipo pregunta a cada programador cuánto tiempo han dedicado a cada una de sus tareas y cuántos días les quedan.

Recuperación. Los programadores que están comprometidos en exceso, piden ayuda para reducir algunas tareas, algunas historias, quitar tareas no esenciales, obtener ayuda.

Verificar la historia.  Tan pronto como las pruebas funcionales estén preparadas y completadas las tareas para una historia, se ponen en funcionamiento las pruebas funcionales para verificar que la historia funciona. Los casos interesantes que surjan durante la implementación pueden añadirse al conjunto de pruebas funcionales. 

Capítulo 16:

 

 Estrategia  de desarrollo

A diferencia de la estrategia de gestión, la estrategia de desarrollo supone una desviación radial de las ideas comúnmente aceptadas, ideamos hoy, con sumo cuidado y habilidad, una solución para los problemas de hoy y confiamos que mañana podremos resolver los problemas de mañana.

La estrategia de desarrollo comienza con la planificación de la iteración. La integración continua reduce los conflictos del desarrollo y crea un final natural para un episodio del desarrollo. La propiedad colectiva anima a todo el equipo a mejorar todo el sistema. Finalmente, la programación en parejas mantiene unido todo el proceso. 

Integración continúa

El código no puede permanecer sin integrarse más de un par de horas. Al final de cada episodio de desarrollo, el código es integrado con la última versión y todas las pruebas deben funcionar al 100%.

La integración después de unas pocas horas (ciertamente no más de un día), da muchos de los beneficios de ambos estilos —programador individual e integración instantánea—. Mientras estés desarrollando, puedes actuar como si tú y tu compañero fueseis la única pareja del proyecto.

Es importante tener herramientas que soporten un ciclo rápido de integración/ construcción/ pruebas. La integración continua reduce de manera drástica el riesgo del proyecto. La integración continua también proporciona un valioso beneficio humano durante el desarrollo. Podemos: Aprender/probar/programar/versión, es decir, creas una idea, expresarla, y la añadirla al sistema.

Propiedad colectiva

Uno de los efectos de la propiedad colectiva es que el código complejo no dura mucho tiempo, porque todo el mundo suele mirar todo el sistema, y dicho código se encontrará tarde o temprano.

Otro efecto es que tiende a prevenir que sea introducido código complejo al sistema desde el primer momento.

La propiedad colectiva también tiende a diseminar el conocimiento del sistema sobre todo el equipo. Esto además reduce el riesgo del proyecto.

Programación en pareja

La programación en parejas es un dialogo entre dos personas que intentan simultáneamente programar (y analizar, diseñar y probar) y comprender juntos como programar mejor.La programación en parejas funciona para XP porque tiene la ventaja de: fomentar la comunicación, se más productiva que la división del trabajo entre dos programadores y la posterior integración de los resultados, la calidad del código resultante es mucho mayor. Mientras un compañero está ocupado escribiendo, el otro está pensando a un nivel más estratégico, las ocasiones de ignorar los compromisos con el resto del equipo son muchos menores en parejas que cuando estás trabajando solo, mejora el proceso de desarrollo de software.

 

Capítulo 17:

 

Estrategia de diseño

Continuaremos refinando el diseño del sistema, comenzando con algo muy simple. Eliminaremos cualquier flexibilidad que no demuestre ser útil. La estrategia de diseño en XP consiste en tener siempre el diseño más sencillo que funcione con todas las pruebas actuales.

La cosa más sencilla que posiblemente podría funcionar:Volvamos un paso atrás y respondamos al mismo tiempo. Los cuatro valores que participan en esta estrategia son: 

·         Comunicación.    Un diseño complicado es más difícil de comunicar que uno simple. Por lo tanto, deberíamos de crear una estrategia de diseño que proponga el diseño más sencillo posible, coherente con el resto de nuestros objetivos. Por otra parte, deberíamos crear una estrategia de diseño que proponga diseños comunicativos, donde los elementos del diseño comunican al lector aspectos importantes del sistema.

·         Sencillez.    Deberíamos tener una estrategia de diseño que produjese diseños sencillos, pero la propia estrategia debería ser simple. Esto no significa que necesita ser fácil de llevar a cabo. Un buen diseño nunca es fácil. Pero la expresión de la estrategia debería ser sencilla.

·         Realimentación.    Uno de los problemas que siempre tenía cuando Diseñaba, antes de comenzar a practicar XP, era precisamente que no Sabía cuándo era correcto o no el diseño. Cuanto más diseñaba, más se agudizaba este problema. Un diseño sencillo resuelve esto al hacerse rápidamente. Lo siguiente que haces es codificarlo y ver cómo funciona el código.

·         Valentía.    ¿Qué podría ser más valioso que detenerte después de realizar un pequeño diseño, convencido de que cuando llegue el momento, puedas añadir más, cuándo y cómo lo necesites?

Siguiendo estos valores, debemos: crear una estrategia de diseño que dé lugar a un diseño que sea sencillo, encontrar rápidamente la forma de comprobar su calidad, realimentarnos de lo que aprendamos en el diseño, hacer de forma cíclica todo el proceso tan pronto como sea posible.

Los principios que también funcionan en la estrategia de diseño son: Inversión inicial pequeña, asumir la simplicidad, cambio incremental, viajar ligero.

Esta estrategia funciona si nada cambia entre lo que tenemos ahora y tendremos más adelante. Es generalmente mejor añadir lo que se necesita ahora y también lo que se necesitará más adelante.El problema con esta estrategia es la incertidumbre.

Necesitamos cambiar la figura para reflejar que diseñaremos hoy para los problemas de hoy y mañana para los problemas de mañana.

Esto nos conduce a la siguiente estrategia de diseño:

1.       Comenzar con una prueba, Tenemos que hacer una cierta cantidad de diseño mínimo para poder escribir la prueba.

2.       Diseñar e implementar justo lo suficiente para conseguir que la prueba funcione.

3.       Repetir.

4.       Si siempre ves la posibilidad de hacer el diseño más simple, hazlo.

Esta estrategia es sencilla y es capaz de crear sistemas grandes y sofisticados. Sin embargo, no es fácil. Nada es más difícil que trabajar bajo la presión de una fecha límite ajustada.

Arquitectura del sistema

La arquitectura es tan importante en los proyectos XP como en cualquier proyecto software. Parte de la arquitectura se captura en la metáfora del sistema. Si tienes una buena metáfora, todo el personal del equipo puede hablarte sobre cómo funciona el sistema de forma global. Las historias se transforman en objetos. Las reglas del juego de la planificación establecen que el resultado de la primera iteración deber ser un esqueleto funcional del sistema global que funcione. Sin olvidar que tenemos que crear la cosa más simple.

En la primera iteración, escoge una cosa simple, historias que esperas que te fuercen a crear la arquitectura global. Entonces estrecha tu horizonte e implementa las historias de la forma más sencilla que posiblemente pudiesen funcionar. Al final tendrás tu arquitectura. Puedes situar la arquitectura en el terreno de la especulación, o puedes situarla en el terreno de lo que necesitas ahora, y confiar que puedas poner más después. Yo me inclino a la arquitectura que necesito ahora y confío en mi capacidad para cambiarla más tarde.

 

Capítulo 18:

 

Estrategia de pruebas

Escribiremos prueba antes de codificar, minuto a minuto. Guardaremos siempre las pruebas y las ejecutaremos con frecuencia todas juntas. También obtendremos pruebas desde la perspectiva del cliente.

Las pruebas que debes escribir en XP son aisladas y automatizadas. Primero, cada prueba no interacciona con las otras pruebas que escribes. De esta forma evitas el problema de que una prueba falle y cause cientos de otros fallos. Nada desanima más en las pruebas que los "falsos negativos".

Las pruebas también son automatizadas. Las pruebas deben ser automatizadas —devolviendo una indicación aprobando o rechazando el comportamiento del sistema—.

Es imposible probar absolutamente todo. Deberías probar cosas que podrían fallar. Si el código es tan sencillo que posiblemente no puede fallar, y piensas que el código en cuestión realmente no fallará en la práctica, entonces no deberías escribir pruebas para él. Probar es una apuesta. Una forma de que una prueba tenga éxito es cuando la prueba funciona cuando no esperas que funcione. Otra forma de que la prueba tenga éxito es cuando una prueba falla cuando esperabas que funcionase. En cualquier caso, aprendes algo. Y el desarrollo del software es aprender. Cuanto más aprendas, mejor desarrollarás.

Conforme pruebes, reflexionas sobre qué clase de pruebas tienden a merecer la pena y cuáles no, y escribes más de aquellas que merezca la pena, y menos de las que no.

¿Quién escribe pruebas?

Las pruebas provienen de dos fuentes: los programadores y de los clientes.

Los programadores escriben pruebas método-a-método. Las pruebas de unidad escritas por el programador siempre funcionan al 100%. Si falla una prueba tienes un desconocimiento de la cantidad de trabajo que hay que hacer para corregirla. Puede llevar solamente un minuto. Pero puede llevar un mes. No lo sabes.

Los clientes escriben pruebas historia-a-historia La pregunta que necesitan hacerse a sí mismo es: "¿Qué tendría que probar antes de estar seguro de que esta historia se ha completado?". Cada escenario que proponen se convierte en una prueba, en este caso una prueba funcional.

No todas las pruebas funcionales funcionan necesariamente al 100% al mismo tiempo. Puesto que provienen de fuentes diferentes al código mismo. Así, aunque la medida de las pruebas de unidad es binaria la medida de las pruebas funcionales está basada, por necesidad, en porcentajes. Con el tiempo esperas que los resultados de las pruebas funcionales aumenten un valor próximo al 100%. El cliente necesitará clasificar las pruebas funcionales que fallan. Algunas serán más importantes que corregir que otras.

Los clientes no pueden escribir pruebas funcionales, necesitan la ayuda de alguien que pueda primero traducir sus datos de prueba a pruebas, y con el crear herramientas. Un equipo XP lleva incorporada al menos una persona dedicada a hacer pruebas. El trabajo del encargado de pruebas es traducir las ideas, algunas veces vagas, sobre pruebas del cliente en pruebas reales, automatizadas y aisladas. El encargado de pruebas también utiliza las pruebas ideadas por el cliente como punto de partida para las variaciones que probablemente harán que falle el software.

El encargado de pruebas hace las apuestas, esperando que una prueba tenga éxito cuando debería fallar o que falle cuando debería tener éxito. Así el encargado de pruebas también está aprendiendo con el tiempo a escribir mejor y mejor las pruebas, las pruebas que tienen más probabilidad de tener éxito.

 

Capítulo 19:

 

Adoptar XP

Adopta cada vez una práctica de XP, siempre para tratar el problema más acuciante para tu equipo. Una vez que deje de ser el problema más acuciante, continúa con el problema siguiente.

1.       Escoge tu peor problema.

2.       Resuélvelo utilizando XP.

3.       Cuando no sea tu peor problema, repite.

Los dos puntos de partida obvios son las pruebas y el juego de la planificación. En esta aproximación. Puesto que solamente aprendes una práctica cada vez, puedes hacer un trabajo minucioso de aprendizaje de cada una. Puesto que siempre estás tratando tu problema más acuciante, tienes bastante motivación para cambiar, y conseguir una realimentación positiva inmediata de tus esfuerzos.

Al resolver el problema más acuciante también tratas la siguiente objeción a XP "ajustar todo a una talla." Si no tienes un problema, no considerarás resolverlo utilizando XP.

 

Capítulo 20:

 

Reajustar XP

Los proyectos que quieren cambiar la cultura existente son mucho más comunes que los proyectos que pueden crear una nueva cultura desde el principio. Adopta poco a poco XP en proyectos en marcha comenzando con las pruebas o la  planificación. 

Adoptar XP con un equipo nuevo es un desafío. Adoptarla con un equipo y una base de código existente es incluso más duro. Tienes una presión directa de mantener la producción del software en funcionamiento. El software es improbable que se ajuste a los nuevos estándares. Es probable que sea más complejo de lo que necesita ser. Es improbable que sea probado con el grado que debiera. En un equipo nuevo, puedes seleccionar solamente a aquellas personas que estén dispuestas a intentar XP. Un equipo que ya exista es probable que sea algo escéptico.

Te llevará más tiempo reajustar XP a un proyecto que te llevaría adoptarla a un nuevo equipo similar. La buena noticia es, nunca estarás en la situación de riesgo de pensar que tienes una buena idea para el software pero que realmente no la conoces. Nunca estarás en la situación de riesgo de tomar muchas decisiones sin la realimentación directa y cruel que obtienes de los clientes reales.

¿Cómo puedes adoptar XP en un equipo que ya existe y tiene el software en producción? Tendrás que modificar la estrategia de adopción en las siguientes áreas:

• Pruebas.

• Diseño.

• Planificación.

• Gestión.

• Desarrollo.

Pruebas: El cambio del código viejo al nuevo es como la noche y el día. Tienes que resistir esta tendencia. La única forma de controlar esta situación es llevar todo el código adelante. Tendrás riesgos de magnitud desconocida. Volver hacia atrás y escribir las pruebas de todo el código existente. No hagas esto. En lugar de eso, escribe las pruebas bajo demanda. Encontrarás que el desarrollo va más lento al principio.

Diseño: La transición al diseño de XP es muy parecida a la transición a las pruebas de XP. Estarás siempre preparado para hacer primero la recodificación antes de implementar en el desarrollo XP, pero tendrás que hacer esto más a menudo conforme vayas pasando a XP. Aquellas partes del sistema que revisas muchas veces en tus actividades de desarrollo pronto se parecerán al código que estás escribiendo ahora. La sobrecarga de recodificación extra pronto se desvanecerá.

Planificación: Tendrás que convertir tu información de requisitos existente en fichas de historias. El cliente tendrá que decidir qué constituirá la próxima versión. El mayor desafío de cambiar a la planificación de XP es enseñar a tu cliente cuánto más puede conseguir del equipo.

Gestión: La gestión XP es un juego de delegar y de influir. Si eres un director de proyecto, probablemente tú mismo tomarás decisiones que deberían tomarlas los programadores o los clientes. Recuérdate a ti mismo y a todos los presentes que estás aprendiendo. Y entonces pídele a la persona apropiada que tome la decisión y que te permita conocerla. Como director de proyecto, debes ser prudente durante el período de transición, para recordarles a todos las reglas que tienen que escoger. Bajo presión, todos volverán a sus viejos patrones de comportamiento, tanto si estos patrones funcionan como si no.

Desarrollo:

La primera cosa que tienes que hacer es colocar de forma adecuada las mesas. Coloca las mesas de modo que dos personas se puedan sentar una al lado de la otra e intercambien el teclado sin tener que mover sus sillas. Cuando estés en la transición hacia XP deberías ser más rígido sobre la programación en parejas, Esfuérzate por hacerlo, incluso si no te apetece. Tómate un descanso. Vete y programa sólo durante un par de horas.

Desmenuza los problemas de pruebas y diseño. Lleva todo el código que toques a los estándares de codificación acordados.

 

Capítulo 21:

 

El ciclo de vida de un proyecto XP ideal

El proyecto XP ideal pasa por una fase corta de desarrollo inicial, seguida por años de refinamiento y mantenimiento simultáneo de la producción, y finalmente una retirada elegante cuando el proyecto no tenga más sentido.

Exploración

La preproducción es un estado no natural para un sistema y del que se debería salir de la forma más rápida posible. No estar en producción es gastar dinero sin ganarlo. Antes de entrar en producción, tienes que tener suficiente confianza en tus herramientas para creerte que puedes conseguir acabar el programa. Tienes que creerte que una vez que el código está hecho, puede funcionar día a día. Tienes que creerte que tienes (o puedes aprender) las habilidades que necesitas.

La fase de exploración es donde todo esto aparece junto. Has finalizado con la exploración cuando el cliente está seguro de que hay material suficiente en las fichas de historias para hacer una buena primera versión.

Durante la exploración los programadores están utilizando cada parte de la tecnología que ellos van a utilizar en el sistema en producción. Están explorando activamente posibilidades para la arquitectura del sistema. Si una semana no fuese suficiente para conseguir que la tecnología funcionase, deberías de considerar esa tecnología como un riesgo. Los programadores deberían experimentar con los límites de rendimiento de la tecnología que están utilizando. Deberían simular cargas reales con el hardware y la red de producción. No tienes que tener hecho todo el sistema para escribir un simulador de carga.

Los programadores también deberían experimentar con ideas sobre la arquitectura. Estas pequeñas exploraciones sobre la arquitectura son más importantes cuando te encuentras que el usuario aparece con historias que no tienes idea de cómo implementarlas.

La clave es conseguir de los clientes una realimentación rápida con las primeras historias para que puedan aprender rápidamente a especificar lo que los programadores necesitan y no especificar lo que los programadores no necesitan.

Si tienes un equipo que ya conoce su tecnología y las otras, la fase de exploración podría durar tan sólo unas pocas semanas.

Planificación

El propósito es que tanto los clientes como los programadores acuerden con seguridad la fecha en la que el conjunto más pequeño y valioso de historias estará listo. Si el plan es superior a unos pocos meses hay demasiado riesgo.

Iteraciones para la primera versión

La planificación comprometida se divide en iteraciones que duran de una a cuatro semanas. Cada iteración producirá un conjunto de casos de prueba funcionales para cada una de las historias planificadas para esa iteración.

La primera iteración pone en funcionamiento la arquitectura. Selecciona historias para la primera iteración que te fuercen a crear "el sistema global". La selección de historias para las siguientes iteraciones se hace completamente a voluntad del cliente.

Cuando detectas desviaciones del plan, entonces necesitas cambiar algo. Tal vez necesites cambiar el proceso, ves mejores formas de hacer funcionar la tecnología, o de mejorar la forma de trabajar con XP. Idealmente, al final de cada iteración, el cliente habrá completado las pruebas funcionales y funcionarán todas.  Al final de la última iteración, estás preparado para entrar en producción.

Entrar en producción

El juego final de una versión lleva a estrechar el ciclo de realimentación. Tener reuniones diarias de puesta en común para que cada uno sepa en lo que están trabajando los demás. Normalmente habrá algunos procesos para certificar que el software está preparado para entrar en producción. A menudo, en esta etapa se aplican las pruebas paralelas.

Puedes necesitar ajustar el rendimiento del sistema durante esta fase. Al final es el momento perfecto para ajustar, ya que tendrás todo el conocimiento posible embebido en el diseño del sistema, tendrás una estimación más realista de la carga de producción en el sistema, y es probable que tengas disponible el hardware de producción.

 

Mantenimiento

El mantenimiento es realmente la fase normal de un proyecto XP. Tienes que producir, de forma simultánea, una nueva funcionalidad, mantener el sistema existente en funcionamiento, incorporar nuevas personas al equipo, y despedirte de los miembros que se marchan. Cada versión comienza con una fase de exploración.

Desarrollar un sistema que está en producción no es exactamente lo mismo que desarrollar un sistema que no está todavía en producción. Eres más precavido con los cambios que haces. Tienes que estar preparado para interrumpir el desarrollo para reaccionar a los problemas de producción. Tienes datos actuales que has de tener cuidado al migrarlos cuando cambies el diseño. Si la preproducción no fuese tan peligrosa, siempre evitarías entrar en producción.

Aunque estés explorando, mide el efecto que tiene en tus actividades de desarrollo mantener la producción.

Estate preparado para cambiar la estructura del equipo al enfrentarte con la producción. Ten cuidado en rotar a todos los programadores por esa posición.

Conforme avances el software desarrollado en producción. Puedes haber partes del software que no se ejecutarán. De todos modos colócalos en el sistema en producción. En ningún caso deberías dejar código inútil más de una iteración. El tiempo depende de cuánto cuesta la verificación y la migración. Lo último es integrar una gran cantidad de código, que "posiblemente podría" estropear todo. Si guardas la base del código de producción y de desarrollo casi sincronizados, tendrás mucho antes avisos de problemas de integración.

Es tan importante comunicar la cultura sobre el proyecto como los detalles del diseño y la implementación, y que sólo se puede hacer con el contacto personal.

 

Muerte

Morir bien es tan importante como vivir bien. Esto es tan cierto para XP como para las personas. Si el cliente no puede proponer nuevas historias, entonces es el momento de pasar el sistema a la reserva. Ahora es el momento de escribir sobre el sistema, la clase de documento que desearías encontrarte cuando llegase el momento de cambiar algo dentro de cinco años.

Cuando el cliente es feliz con el sistema y no puede pensar en algo que le gustaría añadir en un futuro previsible. Es una forma de morir.

Hay también una razón no tan buena para morir —el sistema no está rindiendo—. El cliente necesita características y no puedes añadirlas de forma económica. La tasa de defectos se aproxima a valores intolerables. Ésta es la muerte entrópica contra la que has luchado durante largo tiempo.

También, la entropía con el tiempo alcanza a los proyectos XP. Esperas que esto suceda cuanto más tarde mejor.

El equipo debería ser consciente de la situación económica. Ellos, los clientes, y los directores de proyecto deberían ser capaces de aceptar que el equipo y el sistema, no pueden rendir lo que es necesario.

 

Capítulo 22:

 

Roles del personal

Ciertos roles tienen que ser cubiertos por un equipo extremo que funcione: el programador, el cliente, el preparador, el controlador.

El programador

El programador es el corazón de XP, su principal preocupación es la comunicación con otras personas. Si el programa funciona, pero hay algún componente de comunicación esencial que no se ha hecho, no ha acabado. El programador escribe pruebas que demuestren algún aspecto esencial del software. Divide el programa en partes más pequeñas o combina las partes demasiado pequeñas en una más grande, más coherente. Encuentra una forma de nombrar que refleje más exactamente tu intención.

Hay habilidades que deben poseer el programador XP que no están acentuadas en otros métodos de desarrollo. La programación en parejas, el hábito de la simplicidad, habilidades que estén orientadas a la técnica, poseer capacidad para recodificar, hacer pruebas de unidad al código, debe estar dispuesto a dejar de lado la sensación de propiedad individual de alguna parte del sistema a favor de compartir la propiedad de todo el sistema.


El cliente

El cliente conoce que hay que programar. Ser un cliente XP no es fácil, debe aprender ciertas habilidades, como escribir buenas historias y tener una actitud que lo haga triunfar, sobre todo debe conseguir estar cómodo influyendo en un proyecto sin ser capaz de controlarlo.

Los mejores clientes son los que realmente utilizarán el sistema que se está desarrollando.Tendrá que aprender cómo escribir historias, pruebas funcionales y demostrar coraje.

El encargado de pruebas

Dado que la responsabilidad de muchas pruebas recae sobre las espaldas de los programadores, el rol de encargado de pruebas en un equipo XP está realmente centrado sobre el cliente. Es responsable de ayudar al cliente a escoger y escribir pruebas funcionales.


El controlador

Es la conciencia del equipo. Hacer buenas estimaciones es una cuestión de práctica y realimentación. El controlador debe hacer muchas estimaciones, y entonces observar cómo la realidad conforma sus suposiciones. Su trabajo es cerrar el bucle de retroalimentación.

También es responsable de echarle un ojo al conjunto del sistema. A mitad de una iteración debería ser capaz de decirle al equipo que ellos lo harán, si siguen el curso actual o si necesita cambiar algo.

Es el historiador del equipo, guarda un diario de las puntuaciones de las pruebas funcionales. Guarda un diario de los defectos comunicados, quien acepta la responsabilidad para cada uno, y que casos de pruebas se añadieron a cada uno de dichos defectos.

El preparador

Es el responsable del proceso en su conjunto. Observa cuando la gente se está desviando del proceso del equipo y llama la atención del equipo sobre esto. Permanece en calma cuando todo el mundo tiene pánico.

Todo el mundo en un equipo XP es responsable de entender la aplicación de XP en algún punto. El preparador es responsable de entenderla con mucha más profundidad: que prácticas alternativas pueden ayudar al conjunto actual de problemas; cómo están utilizando otros equipos XP; que ideas subyacen en XP; y cómo relacionan con la situación actual. El rol de preparador disminuye conforme madura el equipo. De acuerdo con los principios de control distribuido y responsabilidad aceptada “el proceso” sería responsabilidad de todos. Al principio, en el cambio a XP, esto es pedirle demasiado a cualquier programador.

El consultor

Los proyectos XP no engendran muchos especialistas. Puesto que todos se emparejan con todos, y las parejas cambian tanto, y cualquiera puede aceptar la responsabilidad para una tarea si ellos quieren, hay poca posibilidad que se desarrollen agujeros negros donde solamente una o dos personas entienden el sistema. De vez en cuando el equipo necesita profundos conocimientos técnicos y por lo tanto necesita un consultor. El equipo debería ser extremadamente claro sobre el problema que necesitan resolver.


El gran jefe

Lo que más necesita el equipo del gran jefe es coraje, confianza e insistir de forma ocasional en que ellos hagan lo que ellos dicen que hacen.



Capítulo 23:

 

Regla del 80-20

El valor total de XP nunca se obtendrá hasta que todas las prácticas estén en su sitio. Muchas de las prácticas se pueden adoptar por partes, pero sus efectos se multiplicarán cuando estén todas juntas. XP pone el 20% más valioso de la funcionalidad en producción, hace el 20% más valioso del diseño, confiando en la regla del 80-20 (el 80% del beneficio proviene del 20% del trabajo) para diferir optimización. En XP las prácticas y los principios funcionan juntos recíprocamente para crear una sinergia que es mayor que la suma de las partes. Puedes conseguir ganancias significativas de partes de XP pero hay mucho más que ganar cuando pones todas las piezas en su sitio.


Capítulo 24:

 

 ¿Qué hace difícil XP?

Aunque las prácticas individuales puedan ser realizadas por programadores de cuello azul, poner y mantener todas las partes juntas es difícil. Son las emociones primarias —especialmente el temor— las que hacen difícil a XP. Digámoslo otra vez. XP es simple, ¿pero no es fácil? Exactamente. Las prácticas que componen XP pueden aprenderse por cualquiera que haya convencido a algún otro que le pague por programar. Ésta no es la parte difícil. La parte difícil es poner todas las piezas juntas, y mantenerlas en equilibrio. Las piezas tienden a apoyarse recíprocamente, pero hay muchos problemas, intereses, temores, acontecimientos, y errores que pueden desequilibrar el proceso. La razón principal para que "sacrifiquen" a un técnico con experiencia para ser preparador es porque el problema de mantener el proceso en equilibrio es muy difícil. Es difícil hacer las cosas simples, admitir que no sabes, colaborar, derribar los muros emocionales.

Capítulo 25:

 

 ¿Cuando no deberías intentar XP?

Los límites exactos de XP todavía no están claros. Pero hay algunas situaciones que, sin duda, impiden el funcionamiento de XP: grandes equipos, clientes desconfiados, tecnología que no soporta el cambio gradual. La mayor barrera para el éxito de un proyecto XP es la cultura empresarial. Cualquier empresa que ejecute proyectos intentando llevar el coche en la dirección correcta va a tener un momento difícil con un equipo que insista en dirigir. Si un cliente o director de proyecto insisten en una especificación o análisis o diseño completo antes de que empiece la pequeñez de la programación, entonces aparecerá seguro una fricción entre la cultura del equipo y la cultura del cliente o director de proyecto.

Otro problema son los clientes que gustan de grandes pilas de papel, que insisten en documentar el sistema a lo largo del proyecto.

Otra cultura que no es adecuada para XP es aquella en la que se te pide trabajar durante bastantes horas para demostrar tu “compromiso con la empresa”. No puedes llevar a cabo XP cansado.

El tamaño evidentemente es importante. Probablemente no podrás poner en marcha un proyecto XP con cien programadores.

No deberías utilizar XP si estás utilizando una tecnología con una curva de coste exponencial, otra barrera tecnológica para XP es un entorno donde necesitas mucho tiempo para obtener la realimentación.Otro problema para implementar XP es tener un entorno físico inapropiado.


Capítulo 26:

 

XP en funcionamiento

XP se puede adaptar a las formas comunes de contrato, aunque con ligeras modificaciones. Los contratos a precio fijo/ámbito fijo, en particular, se transforman en contratos a precio fijo/fecha fija/ámbito aproximadamente fijo cuando funcionan con el juego de la planificación.

A continuación algunos planes de empresa para el desarrollo de software y cómo se pueden utilizar con XP.

Precio fijo

En vez de una precio/fecha/ámbito fijo, el equipo XP ofrece algo más parecido a una suscripción. El equipo trabajará a velocidad tope para el cliente durante una cierta cantidad de tiempo. Ellos controlarán el aprendizaje del cliente. Al comienzo de cada iteración el cliente tiene una posibilidad formal para cambiar la dirección, e introducir historias completamente nuevas.

Otra diferencia que introduce XP se debe a las pequeñas versiones, la entrega incremental le da la oportunidad al cliente de terminar el contrato si el progreso es más lento de lo estimado al principio, o si las condiciones del negocio hacen que todo el proyecto no tenga sentido, y esto da al cliente puntos naturales para cambiar la dirección del proyecto.


Externalizaciòn (outsourcing)

En el típico desarrollo externo, el cliente acaba con un montón de código que no sabe cómo mantener. Tiene tres opciones:

·         Pueden hacer ellos mismos una evolución posterior del sistema de forma lenta.

·         Pueden contratar al suministrador que ha hecho el desarrollo para que continúe evolucionando el sistema (pero dicho suministrador puede cobrarles mucho).

·         Pueden contratar a otro suministrador que no conozca bien el código.

Se puede hacer esto con XP. El equipo podría instalarse con el cliente o viceversa. Ellos harían el juego de la planificación para decidir qué hacer. Cuando el contrato estuviese satisfecho, el equipo podría marcharse y dejar al cliente con el código.


Internalización (insourcing)

XP soporta la internalización haciendo una medida constante de la velocidad del equipo. Como los miembros del equipo se intercambian, el equipo como un todo está destinado a ir más rápido y más lento. Al medir constantemente la productividad alcanzada, el equipo puede ajustar qué cantidad de compromiso consiguen hacer en las iteraciones del juego de la planificación. Como los expertos dejan el equipo y son sustituidos por personal menos experimentado, el equipo puede re-estimar las historias que quedan.

 

Fecha y productos

En un contrato a una fecha y productos, el equipo XP factura por horas o días. El problema con fecha y productos es que pone los objetivos del suministrador en litigio con los objetivos del cliente por lo que el suministrador está tentado a tener trabajando al equipo horas extras para conseguir más ingresos por mes. El cliente quiere tener la máxima funcionalidad como sea posible en el plazo de tiempo más corto y con el menor número de gente posible.

Una buena relación entre suministrador y cliente puede hacer que funcione Fecha y Producto, pero la tensión subyacente siempre existirá.

Primas de terminación

Una forma excelente de alinear los intereses del suministrador y del cliente en el precio fijo o en la Fecha y Productos es dar una prima por fecha de terminación del proyecto. En cierto sentido esto es una apuesta fácil para el equipo XP. El control suministrado por el juego de la planificación hace esto muy adecuado para que ellos sean capaces de cobrarlo.  Lo malo de las primas de terminación es el castigo por el retraso. De nuevo, el juego de la planificación da al equipo de XP, una ventaja cuando acuerdan el castigo por el retraso. El equipo puede estar bastante seguro de que ellos completarán el sistema a tiempo, de modo que es improbable que tengan que pagar.

 

Terminación anticipada

En XP el cliente puede ver exactamente lo que están consiguiendo conforme ellos avanzan. Si descubren a la mitad que todo el proyecto no tiene sentido es económicamente valioso para el cliente ser capaz de desconectar lo antes posible. Se debe considerar añadir una cláusula que permita al cliente parar el proyecto y pagar una parte prorrateada del coste total, quizá con un pago adicional para compensar al suministrador por tener que encontrar un nuevo contrato en poco tiempo.


Marcos de trabajo (frameworks)

XP no es una gran técnica de "reutilización por adelantado". En un proyecto XP nunca gasta seis meses creando marcos de trabajo, y después comienzas a utilizarlos. Ni separarías el "equipo del marco de trabajo" del "equipo de la aplicación." En XP hacemos aplicaciones. Si, después de unos años de refinamiento constante, alguna de las abstracciones parecen que tienen una utilidad general, ése es el momento de comenzar a pensar sobre cómo hacerlas más ampliamente disponibles.

Sacar productos al mercado

También puedes utilizar XP para sacar productos al mercado (shrink-wrap) software. La función del negocio en el juego de la planificación la lleva a cabo el departamento de marketing. Son los que identifican qué historias quiere el mercado, cuánto de cada una de dichas historias es necesario, y en qué orden se implementarían.


Capítulo 27:

 

Conclusión

Todos los métodos están basados en el miedo. Intenta establecer hábitos que eviten que tus temores se conviertan en realidad. XP no es diferente en este aspecto a cualquier otro. La diferencia está en que los temores están incluidos en XP.

Lista de temores incluidos:

·         Hacer trabajo que no es importante.

·         Tener que cancelar el proyecto no hice el suficiente progreso técnico.

·         Tomar decisiones de negocio erróneas.

·         Tener personal de negocio que toma por mí decisiones técnicas erróneas.

·         Llegar al final de mi trayectoria profesional de constructor de sistemas y darme cuenta que tendría que haber dedicado más tiempo a mis hijos.

·         Hacer trabajo sin estar orgulloso.


Lista de las cosas a las cuales no se les teme:

·         Programación.

·         Cambio de pensamiento.

·         Proceder sin saber todo sobre el futuro.

·         Depender de otras personas.

·         Cambiar el análisis y diseño de un sistema en funcionamiento.

·         Escribir pruebas.

¡Interferencia de bloqueo de anuncios detectada!


Wikia es un sitio libre de uso que hace dinero de la publicidad. Contamos con una experiencia modificada para los visitantes que utilizan el bloqueo de anuncios

Wikia no es accesible si se han hecho aún más modificaciones. Si se quita el bloqueador de anuncios personalizado, la página cargará como se esperaba.

También en FANDOM

Wiki al azar