Metodologia ciclo de vida de desarrollo de software xp

7/24/2019 Metodologia ciclo de vida de desarrollo de software xp

1/20

Programacin ExtremaXP (eXtreme Programing)

Autor: Ken Beck

Prof Miguel Angel PueblaTaller de Metodologas IUTVAL 2008


2/20


3/20

Que es la programacin extrema (XP)?

XP (eXtreme Programing) nace como nueva disciplina de desarrollo desoftware hace aproximadamente unos seis aos, y ha causado un gran

revuelo entre el colectivo de ro ramadores del mundo. Kent Beck, su

autor, es un programador que ha trabajado en mltiples empresas y

que actualmente lo hace como programador en la conocida empresa .

respaldo de gran parte de la industria del software y el rechazo de otra

parte.

La programacin extrema se basa en la simplicidad, la

comunicacin y el reciclado continuo de cdigo, paraalgunos no es mas que aplicar una pura lgica.


4/20

Problemas del desarrollo de software. Cuales son los principales problemas a la hora de desarrollar nuestrosoftware ?

RetrasosSistemas deterioradosTasa de defectosRequisitos mal comprendidos

Falsa riqueza

XP trata de evitar estos riesgos en nuestro desarrollo de software.


5/20

4.1- Planificacin.XP plantea la planificacin como un permanente dialogo entre las partes la

.

Las personas del negocio necesitan determinar:

mbito: Qu es lo que el software debe de resolver para que estegenere va or

Prioridad: Qu debe ser hecho en primer lugar ?Composicin de versiones: Cunto es necesario hacer para saber si el

negocio va mejor con software que sin el ?.

Fechas de versiones: Cules son las fechas en la resencia delsoftware o parte del mismo pudiese marcar la diferencia ?

El personal del negocio no puede tomar en vaci estas decisiones, y el

metera prima para las decisiones del negocio.


6/20

Estimaciones: Cuanto tiempo lleva implementar una caracterstica ?Consecuencias: Informar sobre las consecuencias de la toma de

.

datos a Oracle.

Procesos: Cmo se organiza el trabajo y el equipo ?resolvern primero ?

4.1.1.- Pequeas versiones.a a vers n e e e ser an peque a como uera pos e, con en en o

los requisitos de negocios ms importantes, las versiones tiene que tener

sentido como un todo.

Es mucho mejor planificar para 1 mes o 2 que para seis meses y un ao,

las compaas que entregan software muy voluminoso no son capaces dehacerlo con mucha frecuencia.


7/20

. .- se o4.2.1.- Metfora.Una metfora es una historia que todo el mundo puede contar a cerca de

cmo funciona el sistema. Algunas veces podremos encontrar metforas

sencillas Programa de gestin de compras, ventas, con gestin de cartera

y almacn. Las metforas ayudan a cualquier persona a entender el

objeto del programa.

4.2.2. Diseo sencil lo. El diseo adecuado ar el software es a uel ue:

1.Funciona con todas las pruebas.2.No tiene lgica duplicada.

.

4.Tiene el menor nmero de clases y mtodos. Haz el diseo lo mas

simple posible borra todo lo que puedas sin violar las reglas 1,2 y 3. ,

para maana , no es del todo correcto si piensas que el futuro es

incierto.


8/20

4.3.- Desarrollo.

. . .- .Cuando implementamos nuevas caractersticas en nuestros programasnos planteamos la manera de hacerlo lo mas simple posible, despus

e mp emen ar es a carac er s ca, nos pregun amos como acer e

programa mas simple sin perder funcionalidad, este proceso se le

denomina recodificar o refactorizar (refactoring).

4.3.2.- Programacin por parejas.Todo el cdi o de roduccin lo escriben dos ersonas frente al

ordenador, con un slo ratn y un slo teclado. Cada miembro de lapareja juega su papel: uno codifica en el ordenador y piensa la mejor

, ,

funcionar ?, Puede haber pruebas donde no funcione ?, Hay forma

de simplificar el sistema global para que el problema desaparezca ?. El

,

con una persona y por la tarde con otra, si tienes un trabajo sobre un

rea que no conoces muy bien puedes emparejarte con otra persona

que s conozca ese rea. ua qu er m em ro e equ po se pue e

emparejar con cualquiera.


9/20

4.3.3.- Propiedad colectiva.

parcela puede hacerlo, ningn miembro del equipo es propietario del

cdigo. Si alguien quiere hacer cambios en el cdigo puede hacerlo. si

..

4.3.4.- Integracin contina.El cdigo se debe integrar como mnimo una vez al da, y realizar las

pruebas sobre la totalidad del sistema. Una pareja de programadores se

encargara de integrar todo el cdigo en una maquina y realizar todas las

pruebas hasta que estas funcionen al 100%.

4.3.5.- 40 Horas semanales.Si queremos estar frescos y motivados cada maana y cansado y

satisfecho cada noche. Esto requiere que trabajemos 40 horas a la

,

proyecto, la regla de XP dice nunca 2 semanas seguidas realizando

horas extras.


10/20

. . .- en e n-s u.Un cliente real debe sentarse con el equipo de programadores, estardisponible para responder a sus preguntas, resolver discusiones y fijar

las prioridades. Lo difcil es que el cliente nos ceda una persona que

conozca el negocio para que se integre en el equipo normalmente

estos elementos son muy valiosos, pero debemos de hacerles ver queser mejor para su negocio tener un software pronto en

funcionamiento, y esto no implica que el cliente no pueda realizar

cual uier otro traba o.

4.3.7.- Estndares de codificacin. ,

intercambiando compaeros, haciendo refactoring, debemos de

establecer un estndar de codificacin aceptado e implantado por todo.


11/20

4.4.- Pruebas4.4.1.- Hacer pruebas.

o e e ex s r n nguna carac er s ca en e programa que no aya s o

probada, los programadores escriben pruebas para chequear el correcto

funcionamiento del programa, los clientes realizan pruebas funcionales.

El resultado un programa mas seguro que conforme pasa el tiempo es

ca az de ace tar nuevos cambios.


12/20

XP supone:

Las personas son claves en los procesos de desarrollo.

Los programadores son profesionales no necesitan supervisin. , .

Desarrolladores y gerentes comparten el liderazgo del proyecto.

El trabajo de los desarrolladores con las personas que conocen

, .

Y conviene recordar que:

ninguna metodologa hace el trabajo por

, .


13/20

5.- Como hacemos funcionar esto?

amos a ra ar e exp car como se ponen en marc a o as es aspracticas se apoyan entre si y toman valor, veremos como todo esta

historia de XP puede funcionar.

5.1.- PlanificacinEn principio no podramos comenzar el programa con tan slo un

lan a roximando no odramos estar actualizando este lan

constantemente a no ser que:

Los propios clientes hiciesen su planificacin con las estimaciones

.

Le diramos a los clientes un plan para hacerles una idea de lo queseria posible en los prximos meses.

error en el plan.

Tu cliente est incorporado al equipo, para observar rpidamente lospos es cam os.


14/20

5.2.- Versiones reducidas

En principio no podamos tener una produccin despus de unos pocosmeses, a no ser que:

,

de tal forma que un pequeo tuviese valor para el negocio.

Estuvieses integrando constantemente de tal forma que el coste de la.

Tus pruebas redujesen los defectos lo suficiente, para evitar los largos

ciclos de testeo.

c ramos se os senc os necesar os n camen e para es a vers n.

5.3.- Metfora.No podramos comenzar a desarrollar con tan solo una metfora a no

ser que:

Tengas rpidamente retroalimentacin a partir del cdigo real y de las

ruebas, sobre si esta metfora esta funcionando en la rctica.Tus clientes estn a gusto hablando sobre el sistema en trminos de

metfora.

conocimiento de lo que la metfora significa en la prctica.


15/20

5.4.- Diseo sencillo.

n pr nc p o no en r amos as an e se a o para co car oy, a noser que:

Utilizramos la Recodificacin, haciendo cambios que no fuesen

preocupantes.

Tuvisemos una metfora global clara, de tal forma que los cambios del

diseotenderan a seguir caminos convergentes.

Estuvisemos codificando con un compaero, de tal forma que tuvieses

5.5.- Hacer pruebas.En principio escribir pruebas nos llevara mucho tiempo, a menos que:

pruebas no sea difcil.

Estemos programando con un compaero, as no puedes pensar en

pero tu compaero si puede.

Te sientas bien cuando veas las pruebas funcionando.

Tus clientes se sientan bien cuando vean todas las pruebas

funcionando.


16/20

5.6.- Recodif icacin.En principio no podramos hacer Recodificacin del sistema durantetodo el tiempo, nos llevara mucho tiempo y sera difcil de controlar, a

menos que:

Estemos habituados a la propiedad colectiva y no tengamos

inconvenientes en hacer cambios necesarios.

Trabajemos sobre estndares de codificacin, para que no tengamos

que cambiar el formato del cdigo antes de recodificar.

mejoras difciles en el cdigo.Tengamos diseos sencillos donde recodificar sea ms fcil.

algo lo sepamos en cuestin de horas.

Estemos descansados y as tengamos ms valenta y sea masimprobable que cometamos errores.


17/20

5.7.- Programacin en parejas. ,

Los estndares de codificacin reduzcan las disputas.

Cada uno este fresco y descansado y as evitar las discusiones absurdas.

,

comprensin antes de afrontar el meollo de la implementacin.

Las parejas tengan la metfora para fundamentar sus discusiones sobre losnombres y el diseo bsico.

Las parejas estn trabajando sobre diseos sencillos.

5.8.- Propiedad colectiva.

En principio no podrs dejar a todo el mundo cambiar todo lo que deseen.Las personas estropean cosas a diestro y siniestro, a menos que:

Inte remos des us de un corto eriodo de tiem o.

Escribamos y hagamos pruebas, as la posibilidad de daar las cosas

accidentalmente disminuye.

,

los programadores aprendan mas rpido lo que pueden cambiar con

beneficio.

,

espantosas Guerras de los Corchetes


18/20

5.9.- Integracin contina.

Posiblemente no podremos integrar tras unas pocas horas de trabajo, ano ser que:

Podamos e ecutar ruebas r idamente ara saber ue no hemos

perdido nada.

Codifiques en parejas, as hay la mitad de cambios a integrar.

, ,

de conflicto.

5.10.- 40 Horas semanales.

daramos el suficientevalor a nuestro negocio, a menos que:

a p an cac n nos es e an o mas ra a o va oso que acer.

La combinacin de planificacin reduzca la frecuencia de malas

sorpresas, donde tienes que hacer ms de lo que piensas.Las practicas como un todo te ayudaran a programar a gran velocidad.


19/20

- -. . .En principio no podremos tener a un cliente in-situ ya que este produce

ms valor en otra parte, a menos que: .

Puedan producir valor para el proyecto priorizando el a pequea escala y

tomando decisiones junto a los programadores.

5.12. Estndares de codificacin.En principio no podemos pedirle al equipo que codifique bajo un estndar

comn, los programadores somos individualistas. A menos que:

Toda XP le de la posibilidad de sentirse dentro de un equipo ganador.


20/20

Metodologia ciclo de vida de desarrollo de software xp

Documents

Transcript of Metodologia ciclo de vida de desarrollo de software xp