Extreme programming by 1TIyd2E

VIEWS: 17 PAGES: 8

									Fausto Alberto Paredes Villarreal                     ITC        792696
Ingeniería de Software


                             Extreme programming

A principios de 1990, un hombre llamado Kent Beck estaba pensando en
diferentes maneras para desarrollar software. Hasta que en 1996, puso en
práctica Kent su nueva metodología en el proyecto de DaimChrysler utilizó
distintas técnicas de desarrollo de software, esta nueva metodología para
desarrollar software, fue nombrada Extreme programming.

Extreme programming es una nueva disciplina del desarrollo de software que se
basa en la comunicación, simplicidad, retroalimentación y valor.

La simplicidad ayuda a que los desarrolladores de software encuentren
soluciones más simples a problemas, según el cliente lo estipula. Los
desarrolladores también crean características en el diseño que pudieran ayudar
a resolver problemas en un futuro.

La comunicación prevalece en todas las prácticas de extreme programming.
Comunicación cara a cara es la mejor forma de comunicación, entre los
desarrolladores y el cliente. Método muy ágil. Gracias a esto el equipo esta pude
realizar cambios que al cliente no le gustaron. También apoya agilidad con la
extensión del conocimiento tácito dentro del equipo del desarrollo, evitando la
necesidad de mantener la documentación escrita.

La Retroalimentación continua del cliente permite a los desarrolladores llevar y
dirigir el proyecto en una dirección correcta hacia donde el cliente quiera.

El valor requiere que los desarrolladores vayan a la par con el cambio, por que
sabemos que este cambio es inevitable, pero el estar preparado con una
metodología ayuda a ese cambio.

La metodología se diseña para entregar el software según las necesidades de
cliente y cuando sea necesaria.

Extreme programming promueve el trabajo del equipo. Cada integrante del
proyecto (cliente, desarrolladores, etc.) forman parte integral del equipo
encargado de desarrollar software de calidad.

13 prácticas incorporan estos valores y se describen así:

       El Juego de Planificación (The planning game). Son una serie de
        actividades planificadas que son llamados juegos planificados por
        extreme programming, son asumidos durante el transcurso del proyecto.
        Un juego inicial planeado se emprende durante el inicio del proyecto e
        implica una sesión con el cliente de reflexión con algunos personas claves
        como desarrolladores para determinar los requisitos iniciales y el


                                                                                1
Fausto Alberto Paredes Villarreal                      ITC        792696
Ingeniería de Software

        contorno, conocidos en la metodología como historias. Si el proyecto
        continúa, se sigue con un emprende “Planning game de lanzamiento”
        donde el cliente escribe otras historias en tarjetas y los desarrolladores
        buscan términos de Unidades Ideales de Ingeniería. El cliente también
        planea un calendario iterativo de desarrollo, cada iteración funciona entre
        dos y cuatro semanas, y subdivide historias en base a la prioridad del
        negocio. En el comienzo de cada iteración el cliente puede agregar otras
        historias, y cambiar el horario de la historia. En realidad pretende un
        permanente dialogo entre la parte empresarial y técnica del proyecto, en
        la que los empresarios deciden el alcance, la prioridad, el contenido de
        las versiones y la fecha de estas. Y la parte técnica, son los responsables
        de establecer la duración para implementar las funciones deseados por el
        cliente, de desarrollar la planificación de cada versión, entre otras.

       Desarrollo de Probar-Conducir. (Test-driven development). Esta es la
        forma de prueba de unidad y de prueba de aceptación, donde las pruebas
        se escriben antes de la implementación del código. Las pruebas de
        aceptación, son escritas por el cliente, se automatizan y prueban
        generalmente la funcionalidad del sistema. Las pruebas de unidad son
        escritas por los desarrolladores y prueba que las unidades del código
        estén a un nivel según lo esperado.

       Programación del par (Pair programming). Extreme programming
        requiere que todo el código de la producción sea producido por un par
        desarrolladores compartiendo un monitor y un teclado en una estación de
        trabajo. Uno actúa como conductor y escribe código mientras que el otro,
        el navegador, observa qué está pasando y proporciona consejos
        estratégicos para resolver los problemas de manera eficiente. El
        conductor tiene que estar explicando que es lo que esta haciendo y se
        pueden intercambiar los roles con frecuencia. Por otro lado, para facilitar
        el trabajo entre los miembros del equipo, estos pueden interactuar con
        otros individuos para realizar la tarea.

       El reorganizado sin piedad (Merciless refactoring). Los
        desarrolladores requieren mejorar el código sin que este cambie su
        función para realizar un código simple. Esto dará oportunidad a
        modificarlo cuando haya necesidad de cambiar una característica.

       Diseño simple (Simple Design). Los desarrolladores necesitan seguir el
        principio de YAGNI (You Are not Going to Need It)(usted no lo va a
        necesitar) al producir un diseño para una historia dada. El diseño no debe
        no incluir otra cosa que no sea necesaria para ejecutar la historia y pasar
        las pruebas de unidad. Y lo que en realidad busca extreme programming
        es buscar soluciones y diseñar en cada momento para las decisiones
        necesitadas en ese momento.




                                                                                 2
Fausto Alberto Paredes Villarreal                       ITC         792696
Ingeniería de Software

       Propiedad colectiva del código (Colective code ownership). Todos los
        desarrolladores son propietarios del código. Cualquier desarrollador
        puede modificar el código base en cualquier momento aunque haya sido
        hecho por otro par de desarrolladores, por ejemplo, si un desarrollador
        encuentra otra forma de hacer el código de manera mas simple lo puede
        hacer sin ningún inconveniente, claro siempre y cuando no altere su
        funcionalidad. El objetivo es quitar dependencias en individuos.

       Integración continua (Continuos Integration). Al cabo de un día el
        sistema deberá de ser integrado por una máquina, cada vez que un para
        de programadores tengan una clase ya probada unitariamente. Si al
        añadir la clase el sistema completo sigue funcionando correctamente, la
        tarea fue realizada con éxito. De lo contrario, esto permite que los
        desarrolladores detecten errores en la integración del sistema en una
        etapa antes ejecutando las pruebas de unidad del proyecto. Si después
        de esto no pueden realizar el código, lo borraran y comenzaran desde
        cero.

       Cliente en el sitio (On-site Costumer). Los desarrolladores tienen
        acceso continuo con el cliente para poner en claro las historias y discutir
        el desarrollo de ediciones y proporcionar retroalimentación. Y un cliente
        real debe permanecer junto al equipo de desarrollo, para cualquiera duda
        o aclaración.

       Lanzamientos pequeños (Small releases). Al final de cada iteración el
        sistema es lanzado y el cliente lo observa. Se lanza primero unos meses
        antes de estar completamente terminado, las otras versiones serán mas
        frecuentes entre un día y un mes. La mayoría de estos lanzamientos es
        para conseguir retroalimentación del cliente.

       Semana de 40 horas (40 hours week). Si queremos que sea un trabajo
        de calidad , los trabajadores tienen que estar bien descansados , no
        superando la regla de las 40 horas semanales y que tengan otras cosas
        que hacer y no estén obsesionados con el trabajo. El objetivo no es el
        trabajo extra, sino mantener el balance entre el trabajo y la vida. Esto está
        en los intereses del proyecto.

       Aplique los estándares de la codificación (Apply coding standards).
        El código es la forma principal de documentación y por lo tanto debe de
        estar escrito de una manera clara y constante, que pueda ser identificado
        fácilmente por cualquier programador de otro equipo.

       Metáfora del sistema (System metaphore). Un lenguaje de metáforas
        se utiliza para describir la arquitectura del sistema. Esto ayuda a la
        comunicación entre los mismos desarrolladores y entre los
        desarrolladores y el cliente.


                                                                                   3
Fausto Alberto Paredes Villarreal                     ITC         792696
Ingeniería de Software



       Reunión (Stand-up meeting). Una reunión de 15 minutos en el comienzo
        de cada día para discutir problemas encontrados el día anterior y los
        problemas que se resolverán durante el día.


Extreme programming es como un rompecabezas .Hay muchos pedazos
pequeños. Los pedazos individualmente no tienen ningún sentido, pero cuando
están combinados pueden ser considerados un cuadro completo. Esto es una
salida significativa de métodos tradicionales y del desarrollo del software en un
cambio en la manera que programamos.

Extreme programming establece cuatro variables para cualquier proyecto de
software: costo, tiempo, calidad y alcance.

También establece, que de estas cuatro variables que tenemos, solo tres de
ellas podrán ser fijadas o indicadas por el cliente o jefe del proyecto, mientras
que una variable quedará libre.

Un problema de esto es la calidad, por que muchas veces se ignora, por que
nadie es capaz de trabajar bien cuando esta sometido a mucha presión.

Las variables entre sí, no guardan una relación tan obvia. Extreme programming,
hace énfasis en equipos de desarrollo pequeños entre diez y doce personas,
que podrán ir incrementando.

El costo del proyecto se incrementa cuando se necesita máquinas más rápidas,
mas especialistas técnicos en determinadas áreas o mejores oficinas para el
equipo de desarrollo.

La calidad puede representar un cambio extraño; debido a que a mayor calidad
menor tiempo de realización del proyecto. Por lo tanto el equipo de
desarrolladores esta encargado de la tarea de hacer las pruebas con los mejores
resultados posibles para así tener una idea de cual es el problema y como lo van
a resolver de una manera simple y eficiente, para que la calidad del proyecto se
mantenga al 100% y tener una facilidad de adaptarse a los cambios del código lo
que hace este proceso más rápido.

No tener en cuenta que la gente trabaja mejor cuando la dejan hacer trabajo de
calidad y sin presión puede llegar a que el proyecto no se desarrolle a su tiempo
y con una calidad por los suelos.

La ultima variable es la que se encuentra libre y como ya mencioné no es
establecida por los directores, sino que ya que se tiene una buen idea de las
otras tres variables, se continúa a realizar el proceso de alcance del proyecto, en
la cual el equipo determina: la estimación de las tareas a realizar, que es lo que



                                                                                 4
Fausto Alberto Paredes Villarreal                     ITC       792696
Ingeniería de Software

el cliente quiere, la implementación de los requisitos mas importantes de manera
que este siempre sea funcional.

En extreme programming el costo del cambio maneja un papel muy importante,
por que comparado con otras metodologías para implementar software, es
mucho mas barato, debido a que las pruebas se van haciendo según las
versiones liberadas, no es como una metodología normal, que primero se realiza
el análisis, después el diseño, implementación, pruebas y finalmente producción,
mientras que en la extreme programming siempre estas implementando,
probando y produciendo.




*.Costo del cambio en la ingeniería de software tradicional.




*Costo del cambio en extreme programming.




                                                                              5
Fausto Alberto Paredes Villarreal                     ITC        792696
Ingeniería de Software

Los largos ciclos de desarrollo de las metodologías tradicionales son incapaces
de adaptarse al cambio, tal vez una solución puede ser ciclos de desarrollo más
cortos como la extreme programming.




*Diagrama de los ciclos de desarrollo de software


Conclusión


Y concluyó que extreme programming es una metodología de desarrollo de
software basada en la simplicidad, la comunicación, el valor y la
retroalimentación. Simplicidad en la realización de código. Valor en el desarrollo
de software y estar prevenidos para adaptarse a los cambios. Comunicación
continúa entre el cliente, los directores del proyecto y los desarrolladores. La
retroalimentación para que el cliente pueda opinar y detectar las cosas que no
sean necesarias. Trabaja al traer a todo el equipo junto para prácticas
presenciales simples, con suficiente retroalimentación para saber donde esta el
equipo y para ver que es lo que necesitan. Extreme programming ayuda a
desarrollar solo lo que se necesita desarrollar para resolver un problema. Algo
muy importante en esta metodología es que si no hay una comunicación efectiva
el proyecto no tendrá éxito. Una ventaja del extreme programming es que como
se trabaja en parejas, lo que uno lo ve muy complicado otro lo puede ver de una
manera simple y que puede ser interpretado por otra pareja de programadores.
Otra ventaja de esta metodología es la constante comunicación y
retroalimentación que no teníamos en otras metodologías. Y por último tenemos
la ventaja de que podemos detectar errores desde el principio y no hasta el
ultimo. Por eso la extreme programming es una buena metodología para usar.




                                                                                6
Fausto Alberto Paredes Villarreal   ITC   792696
Ingeniería de Software




*Diagrama del extreme programming




                                                   7
Fausto Alberto Paredes Villarreal                   ITC     792696
Ingeniería de Software


                                    Bibliografía

{Chris Loftus and Mark Ratcliffe} 2003
<http://0-delivery.acm.org.millenium.itesm.mx/10.1145/1070000/1067531/p311-
loftus.pdf?key1=1067531&key2=4928581311&coll=portal&dl=ACM&CFID=60152
549&CFTOKEN=19787734>

{Roland E. Jefrries- www} 1999- 2005.
 <http://www.extremeprogramming.org/rules/iterative.html>

{James Kewkirk y Robert C. Martin }Object Magazine, 1996
<http://0-delivery.acm.org.millenium.itesm.mx/10.1145/370000/367909/p25-
newkirk.pdf?key1=367909&key2=5218581311&coll=portal&dl=ACM&CFID=6015
2549&CFTOKEN=19787734>

{Kent Beck} Dedalous consulting Germany
<http://0-delivery.acm.org.millenium.itesm.mx/10.1145/320000/318778/p1-
beck.pdf?key1=318778&key2=9387581311&coll=portal&dl=ACM&CFID=601525
49&CFTOKEN=19787734>

{Don Wells-www}1999<http://www.xprogramming.com/xpmag/whatisxp.htm>


*{Antonio Crespo Foix-www} 2002
<http://www.ati.es/novatica/2002/156/nv156sum.html#edit>




                                                                         8

								
To top