VICTOR PINELA BRIONES ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS

TRABAJO DE INVESTIGACIÓN

TEMA:

METODOLOGÍA DE DESARROLLO DE
SOTFWARE XP EXTREME PROGRAMMING

PERTENECIENTE A:

VICTOR PINELA BRIONES

MATERIA:

ADMINISTRACIÓN DE PROYECTOS
INFORMÁTICOS

LICENCIADO:
RICHARD RAMIREZ A.

ESPECIALIDAD:
INGENIERIA EN SISTEMAS
2010 - 2011
1
VICTOR PINELA BRIONES ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS
INDICE

PAG.

PROGRAMACIÓN EXTREMA O EXTREME PROGRAMMING (XP) 3

ASPECTOS INTERESANTES DE XP

VALORES 4

CARACTERÍSTICAS FUNDAMENTALES 5

CONCUSIÓN

ANEXOS 6

BIBLIOGRAFÌA 7

2
VICTOR PINELA BRIONES ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS
PROGRAMACIÓN EXTREMA O EXTREME PROGRAMMING (XP)

Nació en 1996, es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro
sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los
procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las
metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la
previsibilidad. Los defensores de 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 aproximación mejor
y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después
en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo
de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el
ciclo de vida del software.

Alguna de las situaciones en las que XP es adecuada son:

Los requerimientos no están claros o cambian mucho: el cliente no tiene una idea clara de lo
que el sistema debería hacer. Nuestro proyecto requería la reescritura de una plataforma existente,
pero modificando la concepción original de trabajo orientándola hacia las redes sociales y la web 2.0
Los riesgos son altos: si el cliente tiene una fecha tope o si el proyecto representa una novedad
para el equipo de desarrollo. La aplicación a pesar de no ser innovadora en cuanto a sus
herramientas, sí era una novedad para los desarrolladores el uso de estándares del área de
educación. Así mismo, el nuevo enfoque que se le daba representaba una novedad para todo el
equipo. (Realmente es y será novedad para toda la comunidad).
se trabaja con un equipo de desarrollo pequeño: se recomienda equipos de entre 2 y 12
programadores.
Se dispone de un equipo multidisciplinario: el equipo debe no solo ser de desarrolladores, sino
también los gerentes y clientes, todos trabajando en conjunto.
El equipo de soporte ofrecido constaba de gente con conocimientos en las áreas de diseño,
computación y pedagogía.
El código debe poder ser probado: debe ser posible automatizar las pruebas unitarias y
funcionales. Partíamos de la idea de usar CakePHP como framework de desarrollo. Este nos ofrecía
una suite de pruebas automatizadas.

Aspectos Interesantes de XP

La documentación

XP no hace previsiones para la documentación, sin embargo es lógico que sea necesaria para que
cualquier persona fuera del proyecto se ponga en contexto. Al final todo dependerá del proyecto y del
equipo.

Para este proyecto la documentación es necesaria por una par de razones: al finalizar el proyecto serán
otras personas quienes se encarguen del mantenimiento; y por otro lado, al ser un proyecto de grado es
necesaria mucho más la documentación para convencer a los jurados

La propiedad compartida del código

Extreme programming aboga porque ninguna parte del código sea propiedad exclusiva de alguno de los
desarrolladores, esto con la intensión de disminuir la necesidad de documentación hacia adentro del equipo
de programadores. Adicionalmente esto permite evitar cuellos de botella que entorpecen el avance.

Para lograrlo, XP exige dos cosas: mover a los desarrolladores de sus asignaciones a otras y desarrollar en
parejas de modo que la toma de decisiones y el conocimiento sobre ellas no sea un secreto.
Adicionalmente, cada día las reuniones permiten notificar estas decisiones al resto del grupo. En este
apartado, puedo decir que en gran parte se ha logrado. El desarrollo en parejas puede ser perjudicial si no
se mantiene la disciplina necesaria para concentrarse en el código y no en la cháchara.

3
VICTOR PINELA BRIONES ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS
Valores

Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación

(feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming
Explained. Los cinco valores se detallan a continuación:

Simplicidad: Es la base de la programación extrema. Se simplifica el diseño para agilizar el

desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas
modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente
exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es
la manera de mantener el código simple a medida que crece. También se aplica la simplicidad en la
documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí
que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las
variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el
tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen
actualmente. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por
parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y
mejor el sistema completo.

Comunicación: La comunicación se realiza de diferentes formas. Para los programadores el código

comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo
inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos
pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo
aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método.
Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y
los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad. Los programadores se
comunican constantemente gracias a la programación por parejas. La comunicación con el cliente
es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que características
tienen prioridad y siempre debe estar disponible para solucionar dudas.

Retroalimentación (feedback): Al estar el cliente integrado en el proyecto, su opinión 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 más importante. Considérense 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 código
también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo,
las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias
frecuentemente permite descubrir fallos debidos a cambios recientes en el código.

Coraje o valentía: Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje?.
Para los gerentes la programación en parejas puede ser difícil de aceptar, porque les parece como
si la productividad se fuese a reducir a la mitad ya que solo la mitad de los programadores está
escribiendo código. Hay que ser valiente para confiar en que la programación por parejas beneficia
la calidad del código sin repercutir negativamente en la productividad. La simplicidad es uno de los
principios más difíciles de adoptar. Se requiere coraje para implementar las características que el
cliente quiere ahora sin caer en la tentación de optar por un enfoque más flexible que permita
futuras modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo
(frameworks) mientras el cliente espera. En ese tiempo el cliente no recibe noticias sobre los
avances del proyecto y el equipo de desarrollo no recibe retroalimentación para saber si va en la
dirección correcta. La forma de construir marcos de trabajo es mediante la refactorización del código
en sucesivas aproximaciones.

Respeto: El 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 compañeros. Los miembros respetan su trabajo
porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o
más eficiente para la solución a través de la refactorización del código. Los miembros del equipo
respetan el trabajo del resto no haciendo menos a otros, si no orientándolos a realizarlo mejor,
obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de producción en
el equipo.
4
VICTOR PINELA BRIONES ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS
Características fundamentales

XP resuelve volver a lo básico. Al adherirnos a este modelo haremos todo lo que debemos para tener un
desarrollo de software predecible, estable, pero no tendremos tiempo para hacer nada extra. Las cuatro
actividades que guiarán el desarrollo serán: Codificar, Testear, Atender y Diseñar.

A continuación mencionamos las Doce Prácticas de XP que nos permiten realizar desarrollos de Alta
Calidad, en Tiempo y Costo razonables:

1. Jugar el Juego de la Planificación: Rápidamente determinar el alcance del próximo release,

combinando las prioridades de negocios con los estimados técnicos. Cuando la realidad sobrepasa
el Plan, adaptar el Plan.
2. Hacer Pequeños Releases: Poner un sistema simple en producción rápidamente, entonces liberar
nuevas versiones del mismo en un ciclo de desarrollo rápido, una por semana a una por mes. Cada
ciclo no debería ser más largo.
3. Hacer Historias y Usar Metáforas: Guiar todo el desarrollo del sistema a través de una Historia
Compartida por el Equipo (o Metáfora) acerca de cómo trabaja (o debería trabajar) el Sistema.
4. Diseñar Simple: El Sistema debería diseñarse de la manera más simple posible en cualquier
momento dado. La complejidad extra es removida, tan pronto como es descubierta (ver Refactoring
debajo).
5. 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 reparación pasa a ser la máxima prioridad para el Programador y/o el Equipo. Los Clientes
(ayudados por Desarrolladores) escriben Tests Funcionales para probar qué funcionalidades están
terminadas de acuerdo a sus expectativas.
6. Rearmar - Refactorizar: Los Desarrolladores reestructuran el sistema sin cambiar su
comportamiento para remover duplicación de código, mejorar la comunicación, simplificar el código,
o agregar flexibilidad.
7. Programar por Pares: Todo el código desarrollado es escrito por dos desarrolladores sentados
frente a una única estación de trabajo.
8. Propiedad Colectiva: Cualquier integrante del Equipo puede cambiar cualquier código de cualquier
parte del sistema en cualquier momento.
9. Integrar Continuamente: El sistema se integra y se construye (por ejemplo, se compila), es decir,
se unen sus partes, varias veces por día, hasta el extremo de integrar el sistema completo, cada
vez que se termina una tarea.
10. Semanas de 40 Horas: Trabajar no más de cuarenta horas por semana como una regla estándar.
Nunca trabajar sobre-tiempo dos semanas seguidas; si esto es necesario, hay problemas más
grandes que hay que descubrir.
11. Cliente On-Line: Es condición esencial la inclusión 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.
12. Usar Estándares de Codificación: Los Desarrolladores escribirán todo el código de acuerdo a
reglas predeterminadas que enfatizarán la comunicación a través del código. Estos estándares
serán simples de seguir y se seguirán a rajatabla.

Muchos se preguntan cómo pueden estas prácticas seguirse… La realidad es que no es recomendable
seguir algunas de ellas y otras no, ya que cada Práctica soporta a las otras; XP es una unidad. Las
debilidades de una son subsanadas con las fortalezas de otras.

CONCLUSIÓN

XP se adapta muy bien a un proyecto que requiere un código de calidad, probado y confiable. No hace
énfasis en la documentación (al contrario de RUP) lo cual nos ha ayudado a concentrarnos en lo importante
para el cliente: la funcionalidad.
Disponer del cliente/asesor realmente dedicado y concentrado es importante para acelerar el desarrollo y
evitar pasos en falso.
La planificación semanal y la planificación de las entregas es importante para mantener metas claras.

5
VICTOR PINELA BRIONES ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS
ANEXOS

6
VICTOR PINELA BRIONES ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS
BIBLIOGRAFÍA

Segmentos del Libro “Extreme Programming Explained” – Kent Beck