Metodologas de Desarrollo de Software

NDICEPROGRAMACION EXTREMA ..2CICLO DE VIDA .3VALORES ..5CARACTERSTICAS FUNDAMENTALES .7ROLES .84 ACTIVIDADES ESTRUCTURALES 9LAS DOCE PRCTICAS DE XP.11

PROGRAMACIN EXTREMALa programacin extrema o eXtreme Programming (de ahora en adelante, XP) es una metodologa de desarrollo de la ingeniera de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software.

CICLO DE VIDAEl ciclo de vida de Xp se enfatiza en el carcter interactivo e incremental del desarrollo, Segn una iteracin de desarrollo es un perodo de tiempo en el que se realiza un conjunto de funcionalidades determinadas que en el caso de Xp corresponden a un conjunto de historias de usuarios. Las iteraciones son relativamente cortas ya que se piensa que entre ms rpido se le entreguen desarrollos al cliente, ms retroalimentacin se va a obtener y esto va a representar una mejor calidad del producto a largo plazo. Existe una fase de anlisis inicial orientada a programar las iteraciones de desarrollo y cada iteracin incluye diseo, codificacin y pruebas, fases superpuestas de tal manera que no se separen en el tiempo.La siguiente figura muestra las fases en las que se subdivide el ciclo de vida Xp:

Figura No.2. Ciclo de vida de eXtreme Programming, Tomado de [1], [2][1] y [3] nos describen cada una de las fases en las que se subdivide el ciclo de vida de eXtreme Programming.

Fase de la exploracin: En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto. Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa.Fase del planeamiento: se priorizan las historias de usuario y se acuerda el alcance del release. Los programadores estiman cunto esfuerzo requiere cada historia y a partir de all se define el cronograma. La duracin del cronograma del primer release no excede normalmente dos meses. La fase de planeamiento toma un par de das. Se deben incluir varias iteraciones para lograr un release. El cronograma fijado en la etapa de planeamiento se realiza a un nmero de iteraciones, cada una toma de una a cuatro semanas en ejecucin. La primera iteracin crea un sistema con la arquitectura del sistema completo. Esto es alcanzado seleccionando las historias que harn cumplir la construccin de la estructura para el sistema completo. El cliente decide las historias que se seleccionarn para cada iteracin. Las pruebas funcionales creadas por el cliente se ejecutan al final de cada iteracin. Al final de la ltima iteracin el sistema est listo para produccin.Fase de produccin: requiere prueba y comprobacin extra del funcionamiento del sistema antes de que ste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden todava ser encontrados y debe tomarse la decisin de si se incluyen o no en el release actual. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas. Las ideas y las sugerencias pospuestas se documentan para una puesta en prctica posterior por ejemplo en la fase de mantenimiento. Despus de que se realice el primer release productivo para uso del cliente, el proyecto de Xp debe mantener el funcionamiento del sistema mientras que realiza nuevas iteraciones.Fase de mantenimiento: requiere de un mayor esfuerzo para satisfacer tambin las tareas del cliente. As, la velocidad del desarrollo puede desacelerar despus de que el sistema est en la produccin. La fase de mantenimiento puede requerir la incorporacin de nueva gente y cambiar la estructura del equipo.Fase de muerte: Es cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

VALORESMetodologas de Desarrollo de SoftwareIV

1

Los valores originales de la programacin extrema son: simplicidad, comunicacin, retroalimentacin (feedback) y coraje. Un quinto valor, respeto, fue aadido en la segunda edicin de Extreme Programming Explained. Los cinco valores se detallan a continuacin:1. 2. SIMPLICIDADLa simplicidad es la base de la programacin extrema. Se simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento. Un diseo complejo del cdigo junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente.Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de mantener el cdigo simple a medida que crece.Tambin se aplica la simplicidad en la documentacin, de esta manera el cdigo debe comentarse en su justa medida, intentando eso s que el cdigo est autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, mtodos y clases. Los nombres largos no disminuyen la eficiencia del cdigo ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorizacin que existen actualmente.Aplicando la simplicidad junto con la autora colectiva del cdigo y la programacin por parejas se asegura que cuanto ms grande se haga el proyecto, todo el equipo conocer ms y mejor el sistema completo.3. COMUNICACINLa comunicacin se realiza de diferentes formas. Para los programadores el cdigo comunica mejor cuanto ms simple sea. Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms fiable que los comentarios ya que stos ltimos pronto quedan desfasados con el cdigo a medida que es modificado. Debe comentarse slo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un mtodo.Las pruebas unitarias son otra forma de comunicacin ya que describen el diseo de las clases y los mtodos al mostrar ejemplos concretos de cmo utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programacin por parejas. La comunicacin con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qu caractersticas tienen prioridad y siempre debe estar disponible para solucionar dudas.

4. REALIMENTACIN (FEEDBACK)Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real.Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es ms importante.Considrense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El cdigo tambin es una fuente de retroalimentacin gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del cdigo. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el cdigo.5. CORAJE O VALENTAMuchas de las prcticas implican valenta. Una de ellas es siempre disear y programar para hoy y no para maana. Esto es un esfuerzo para evitar empantanarse en el diseo y requerir demasiado tiempo y trabajo para implementar el resto del proyecto. La valenta le permite a los desarrolladores que se sientan cmodos con reconstruir su cdigo cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran ms fcilmente. Otro ejemplo de valenta es saber cundo desechar un cdigo: valenta para quitar cdigo fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirti en crear ese cdigo. Adems, valenta significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un da entero, y luego lo resolver rpidamente al da siguiente, slo si es persistente.6. RESPETOEl respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compaeros. Los miembros respetan su trabajo porque siempre estn luchando por la alta calidad en el producto y buscando el diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin del cdigo. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo eleva su ritmo de produccin.

CARACTERSTICAS FUNDAMENTALESLas caractersticas fundamentales del mtodo son: Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin. Vase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres ltimas inspiradas en JUnit, la cual, a su vez, se insipir en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programacin Smalltalk. Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata. Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes. Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo. Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados. Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo. La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de programadores.

ROLESProgramador (Programmer) Responsable de decisiones tcnicas Responsable de construir el sistema Sin distincin entre analistas, diseadores o codificadores En Xp, los programadores disean, programan y realizan las pruebasCliente (Customer) Es parte del equipo Determina qu construir y cundo Escribe tests funcionales para determinar cundo est completo un determinado aspectoEntrenador (Coach) El lder del equipo - toma las decisiones importantes Principal responsable del proceso Tiende a estar en un segundo plano a medida que el equipo maduraRastreador (Tracker) Metric Man Observa sin molestar Conserva datos histricosProbador (Tester) Ayuda al cliente con las pruebas funcionales Se asegura de que los tests funcionales se ejecutanConsultor Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Ayuda al equipo a resolver un problema especfico.Gestor (Big boss) Es el dueo de la tienda y el vnculo entre clientes y programadores. Su labor esencial es la coordinacin.

Esta programacin usa un enfoque de Programacin Orientada a Objetos cmo paradigma preferido de desarrollo, y engloba un conjunto de reglas y prcticas que ocurren en el contexto de 4 actividades estructurales: planeacin, diseo, codificacin y pruebas.

4 ACTIVIDADES ESTRUCTURALESPlaneacin: o tambin llamada juego de planeacin inicia escuchando una actividad para recabar los requerimientos que permite que los miembros tcnicos del equipo xp entiendan el contexto del negocio para el software y adquieran la sensibilidad de la salida y caractersticas principales y funcionalidades que se requieren. Diseo: el diseo XP sigue rigurosamente el principio MS (mantenlo sencillo). Un diseo siempre se prefiere sobre una presentacin ms compleja. Adems el diseo gua la implementacin de una historia conforme se escribe, si el diseo de una historia se encuentra un problema de diseo difcil, XP recomienda la creacin inmediata de un prototipo de esa porcin del diseo. Entonces, se implementa y se evala el prototipo de diseo, llamado solucin en punta. El objetivo es disminuir el riesgo cundo comience la implementacin verdadera y evaluar las estimaciones originales para la historia que contiene el problema del diseo. En el rediseo el principal objetivo es controlar dichas modificaciones, sugiriendo pequeos cambios en el diseo que "son capaces de mejorarlo en forma radical". Sin embargo, debe notarse que el esfuerzo que requiere el rediseo aumenta en forma notable con el tamao de la aplicacin. Codificacin: despus de que las historias han sido desarrolladas y de que se ha hecho el trabajo de diseo preliminar, el equipo no inicia la codificacin, sino que desarrolla una serie de pruebas unitarias a cada una de las historias que se van a incluir en la entrega en curso. una vez que creamos la prueba unitaria, el desarrollador est mejor capacitado para centrarse en lo que debe implementar para pasar la prueba, No se agrega nada extrao. Una vez que el cdigo est terminado, se aplica de inmediato una prueba unitaria, con lo que se obtiene de retroalimentacin instantnea para los desarrolladores. En la codificacin un concepto muy importantes es la programacin en parejas as XP recomienda que dos personas trabajen juntas en una estacin de trabajo con el objetivo de crear cdigo para una historia. Esto da un mecanismo para la solucin de problemas en tiempo real. A medida que la pareja de programadores terminan su trabajo, el cdigo que desarrollan se integra con el trabajo de los dems. As est estrategia de integracin continua ayuda a evitar los problemas de compatibilidad e interfaces y brinda un ambiente de prueba de humo que ayuda a descubrir a tiempo los errores.Pruebas: Cmo ya se dijo de las pruebas unitarias antes de que comience la codificacin es un elemento clave del enfoque de XP. Las pruebas unitarias que se crean deben implementarse con el us de una estructura que permita automatizarlas (de modo que puedan ejecutarse en repetidas veces y con facilidad). Las pruebas de aceptacin tambin llamadas pruebas del cliente, son especificadas por el cliente y se centran en las caractersticas y funcionalidades generales del sistema que son visibles y revisables por parte del cliente. Las pruebas de aceptacin se derivan de las historias de los usuarios que se han implementado cmo parte de la liberacin del software.

LAS DOCE PRCTICAS DE XP

Jugar el Juego de la Planificacin: Rpidamente determinar el alcance del prximo release, combinando las prioridades de negocios con los estimados tcnicos. Cuando la realidad sobrepasa el Plan, adaptar el Plan.Hacer Pequeos Releases: Poner un sistema simple en produccin rpidamente, entonces liberar nuevas versiones del mismo en un ciclo de desarrollo rpido, una por semana a una por mes. Cada ciclo no debera ser ms largo.Hacer Historias y Usar Metforas: Guiar todo el desarrollo del sistema a travs de una Historia Compartida por el Equipo (o Metfora) acerca de cmo trabaja (o debera trabajar) el Sistema.Disear Simple: El Sistema debera disearse de la manera ms simple posible en cualquier momento dado. La complejidad extra es removida, tan pronto como es descubierta (ver Refactoring debajo).Probar - Testear: Los Desarrolladores continuamente escriben Testeos Unitarios, los cuales deben correr sin error para que el desarrollo pueda continuar. Cuando se detecta un error en una corrida, su reparacin pasa a ser la mxima prioridad para el Programador y/o el Equipo. Los Clientes (ayudados por Desarrolladores) escriben Tests Funcionales para probar qu funcionalidades estn terminadas de acuerdo a sus expectativas.Rearmar - Refactorizar: Los Desarrolladores reestructuran el sistema sin cambiar su comportamiento para remover duplicacin de cdigo, mejorar la comunicacin, simplificar el cdigo, o agregar flexibilidad.Programar por Pares: Todo el cdigo desarrollado es escrito por dos desarrolladores sentados frente a una nica estacin de trabajo.Propiedad Colectiva: Cualquier integrante del Equipo puede cambiar cualquier cdigo de cualquier parte del sistema en cualquier momento.Integrar Continuamente: El sistema se integra y se construye (por ejemplo, se compila), es decir, se unen sus partes, varias veces por da, hasta el extremo de integrar el sistema completo, cada vez que se termina una tarea.Semanas de 40 Horas: Trabajar no ms de cuarenta horas por semana como una regla estndar. Nunca trabajar sobre-tiempo dos semanas seguidas; si esto es necesario, hay problemas ms grandes que hay que descubrir.Cliente On-Site: Es condicin esencial la inclusin de al menos un Cliente real, vivo, como parte del Equipo. Debe estar disponible Full-Time para responder preguntas e interactuar con el resto del Equipo.Usar Estndares de Codificacin: Los Desarrolladores escribirn todo el cdigo de acuerdo a reglas predeterminadas que enfatizarn la comunicacin a travs del cdigo. Estos estndares sern simples de seguir y se seguirn a rajatabla.Muchos se preguntan cmo pueden estas prcticas seguirse La realidad es que no es recomendable seguir algunas de ellas y otras no, ya que cada Prctica soporta a las otras; XP es una unidad. Las debilidades de una son subsanadas con las fortalezas de otras.Cmo puede Funcionar este Modelo de Desarrollo?El Juego de la Planificacin: No es posible comenzar el desarrollo con slo un Plan Bsico. No es posible modificar continuamente el Plan, eso tomara demasiado y hara que los Clientes se enojen. A menos que

Los Clientes actualizan el Plan por s mismos, basados en estimados provistos por los Desarrolladores.Se tiene suficiente del Plan al comenzar, para dar a los Clientes una idea bsica de qu ser posible para el prximo ao o dos.Se hacen releases cortos de manera que cualquier error en el Plan llevara unas pocas semanas de remediar, a lo sumo.El Cliente se sienta con el Equipo y se siente parte del Equipo, Full-Time, de manera que podran identificar cambios potenciales y oportunidades para mejorar el Proyecto rpidamente, agregando valor de negocio al sistema, de manera temprana.Entonces quizs s pueda comenzarse el Desarrollo con un Plan Simple e ir refinndolo continuamente mientras se avanza en el Proyecto.Releases Cortos: No es posible poner el Sistema en Produccin despus de unos pocos meses. Ciertamente no es posible hacer Releases del Sistema que van desde un ciclo diario hasta ciclos trimestrales.A menos que

El Juego de la Planificacin haya ayudado a trabajar en las metforas ms valiosas, de manera que an un pequeo sistema pueda tener buen valor de negocio.Se integra continuamente, de manera que empaquetar un Release para instalar en Produccin, tendr un costo mnimo.El Testing continuo redujo tanto la tasa de defectos, que no es necesario ir a un lento ciclo de testeo, antes de permitir al software entrar en produccin.Puede hacerse un Diseo Simple, de manera de cumplir con los requisitos de este Release, no para cumplir todas las condiciones que pudieran surgir en un futuro lejano.Entonces quizs sea posible hacer pequeos Releases, comenzando rpidamente luego que el desarrollo empez.

Metforas:No es posible comenzar el desarrollo con slo unas Metforas, no hay suficiente detalle all, y qu pasa si la Metfora es equivocada?A menos queRpidamente se obtenga feedback concreto de cdigo real y testeos acerca de si la Metfora est trabajando en la prctica.El Cliente se siente confortable hablando del Sistema en trminos de la Metfora.Se Refactoriza continuamente, refinando la comprensin de lo que significa la Metfora y qu se entiende de ella, y haciendo de sta un mapa cada vez ms cercano a la realidad.Entonces quizs pueda comenzarse el desarrollo con slo unas Metforas.

Diseo Simple:No es posible disear slo pensando en cdigo que sea suficiente para este Release. En ese caso puede llegarse a un camino sin salida, que no permitira hacer evolucionar de manera continua el Sistema.A menos queEl Equipo se acostumbre al Refactoring, de manera que hacer cambios no producir preocupaciones.Se tiene una Metfora clara de manera que los futuros cambios de diseo tendern a seguir un camino convergente con esa Metfora.Siempre se Desarrolla con un Socio (programacin por pares) de manera que se trabaja con confianza en un diseo simple, visto y revisado por varios, no en un diseo estpido.Quizs entonces se pueda hacer avanzar el Sistema haciendo el mejor diseo para el Hoy.

Testing:No es posible escribir todos los casos de prueba necesarios. Tomara demasiado tiempo. Los Desarrolladores no escriben Tests.A menos queEl Diseo sea tan simple como puede ser, entonces escribir Tests no ser tan difcil.Siempre se Desarrolla con un Socio, de manera que si uno no puede pensar otro test, quizs su Socio pueda; y si su Socio est harto de escribir Tests, quizs uno pueda hacerse cargo del teclado otra vez.El Equipo se sentir bien viendo correr -sin cancelaciones- todos esos Tests.El Cliente se sentir bien acerca del Sistema, viendo todas sus Pruebas Funcionales corriendo y sentir confianza acerca de los plazos comprometidos.Entonces quizs los Desarrolladores y los Clientes escriban Tests. Adems si los Tests automticos no son escritos, XP no funcionar como metodologa.

Refactoring:No es posible refactorizar el diseo de un Sistema todo el tiempo. Tomara demasiado. Sera demasiado difcil de controlar, y seguramente rompera el Sistema.A menos que

El Equipo se acostumbre a la Propiedad Colectiva, de manera que ninguno se atemorizar por hacer cambios cuando y donde sea necesario.Existen Estndares de Codificacin, de manera que no es necesario traducir, ni reformatear el cdigo antes de Refactorizar.Se Programa por Pares, entonces es ms fcil tener el Coraje de tomar el toro por las astas, cuando es necesario Refactorizar, cambiar algo. As como es menos probable que al hacerlo se rompa otra cosa.El Diseo es Simple, entonces Refactorizar no ser tan complicado.Hay Tests para correr, de manera que si algo se rompe, se sabr enseguida.Hay una Integracin Continua, entonces si accidentalmente se rompe algo en otro lado, o el Refactoring produce conflictos con el trabajo de otros, se sabr en unas pocas horas.Todos estn descansados, entonces tendrn ms Coraje para Refactorizar y es menos probable que cometan errores.Quizs entonces se pueda Refactorizar cada vez que se vea la chance de hacer al Sistema ms simple, o para reducir duplicacin de Cdigo, o para comunicar el Cdigo ms claramente, o para agregarle flexibilidad.

Programacin por Pares:Es imposible escribir todo el Cdigo de un Sistema en Pares. Sera demasiado lento. Y qu pasa si dos personas no se llevan bien?A menos queLos Estndares de Codificacin reduzcan los conflictos de Estilo.Todo el mundo est fresco y descansado, reduciendo an ms la posibilidad de discusiones no-productivas.Los Pares escriben los Tests juntos, dndoles la chance de alinear su Entendimiento antes de encarar el corazn de la implementacin.Los Pares tienen la Metfora para bajar a tierra sus decisiones acerca del diseo bsico y la seleccin de nombres.Los Pares trabajan sobre un Diseo Simple, de manera que ambos pueden entender qu est pasando.Entonces quizs podra escribirse todo el cdigo de Produccin en Pares. Adems la gente que Desarrolla sola tiende a cometer ms errores, a que estos pasen in-detectados, a sobre-disear por si acaso especialmente si no entendieron la Metfora del todo. Adems tienden a no persistir en las dems prcticas y volver a viejos hbitos y maas, an si no funcionaron antes; especialmente bajo presin.

Propiedad Colectiva:Es imposible que todo el mundo est cambiando cualquier cosa en cualquier lado. La gente estara rompiendo cdigo ya probado aqu y all. Y el costo de integracin crecera dramticamente.A menos queSiempre se Integre luego de un corto lapso de tiempo (diariamente), de manera que las chances de que haya conflicto bajen.Los Tests sean escritos, y corridos continuamente, entonces la chance de romper algo accidentalmente baja.Se Desarrolla por Pares, de manera que sea menos probable romper el cdigo (por aquello de que dos cabezas piensan ms que una). Los desarrolladores aprenden rpidamente que cosa pueden cambiar que sea redituable.Hay una adherencia estricta a Estndares de Codificacin, de manera que la gente no se pone a pelear por dnde tienen que ir las llaves, o el begin y el end.Quizs entonces cualquiera podra cambiar cdigo en cualquier parte del Sistema si ve la chance de mejorarlo. Adems sin Propiedad Colectiva, la tasa de evolucin del Sistema disminuye dramticamente.

Integracin Continua:No es posible integrar luego de slo unas horas de trabajo. La integracin toma demasiado tiempo y hay siempre demasiados conflictos y posibilidades de romper algo accidentalmente.A menos queLos Tests se puedan correr rpidamente de forma que todos sepan que nada se rompi.La programacin se realice por Pares, entonces habr slo la mitad de flujos de cambio en el Equipo para Integrar.El Equipo hace Refactoring, entonces hay ms piezas ms chicas, y se reduce la posibilidad de conflictos.Entonces podra integrarse despus de unas pocas horas. Adems si no se integra seguido, la posibilidad de conflictos y la gravedad de los mismos crecern exponencialmente (y con ello el costo de la Integracin).

Semana de 40 Horas:Es imposible trabajar semanas de slo 40 horas. No es posible crear suficiente valor de negocios en 40 horas.A menos queEl Juego de la Planificacin est alimentando el Proyecto de manera de identificar el trabajo ms valioso a realizar.La combinacin del Juego de la Planificacin y el testing reduce la frecuencia de sorpresas desagradables, donde el Equipo pasara ms tiempo del que se piensa.Las Doce Prcticas de XP, vistas como un todo, ayudan a desarrollar a mxima velocidad, no hay posibilidad de ir ms rpido.Quizs entonces podra producirse suficiente valor de negocios en una semana de 40 horas. Adems, si el equipo no permanece fresco y energtico, no ejecutarn el resto de las Prcticas y comenzar la debacle.

Cliente On-Site:Es imposible tener un Cliente Real en el Equipo, sentado all todo el tiempo. Seguro puede producir mucho ms valor de negocios en otro lado.A menos quePueda producir valor para el Proyecto ayudando a escribir los Tests Funcionales.Pueda producir valor para el Proyecto tomando decisiones de prioridad y alcance en pequea escala, de manera de guiar a los Desarrolladores diariamente. Entonces quizs el Cliente pueda producir mayor valor de negocios para la Compaa contribuyendo al Proyecto. Adems, si el Equipo no incluye un Cliente, debern agregar riesgo al Proyecto planificando sin feedback y codificando sin realimentacin desde el Usuario del Sistema (sin saber exactamente qu Tests son necesarios para satisfacer los requisitos, y cules no son necesarios y pueden ser ignorados).

Estndares de Codificacin:Es imposible pedir a todo el Equipo de Desarrolladores que se adhieran a un estndar comn. Los Desarrolladores son profundamente individualistas y probablemente renuncien a participar en el Proyecto antes de dejar sus prcticas individuales.A menos queEl conjunto de Prcticas de XP los haga ms propensos a ser miembros de un Equipo ganador. Uno que lleva los Proyectos a un final feliz.

Quizs entonces ellos podrn flexibilizar un poco su posicin respecto del Estilo. Adems, sin estndares de Codificacin, fricciones adicionales salen a la luz en la Programacin por Pares, que impiden el Desarrollo y reducen significativamente la velocidad en la Programacin y el Refactoring.