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.