Embed Size (px)
Citation preview
METODOLOGÍA XP (EXTREME PROGRAMMING)QUÉ ES LA METODOLOGÍA XPSegún Kent Beck
La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de
la ingeniería de software formulada 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.
Kent Beck, Creador de la Metodología XP
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.
Según Ian Sommerville
La Programación Extrema (XP) es posiblemente el método ágil más conocido y ampliamente
utilizado. El nombre fue acuñado por Beck (Beck 2000) debido a que el enfoque fue
desarrollado utilizando buenas prácticas reconocidas, como el desarrollo iterativo, y con la
participación del cliente en niveles extremos.
En la programación extrema todos los requerimientos se expresan como escenarios
llamados historias de usuario los cuales se implementan directamente como una serie de
tareas. Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes
de escribir el código. Todas las pruebas se deben ejecutar satisfactoriamente cuando el
código nuevo se integre al sistema. Existe un pequeño espacio de tiempo entre las entregas
del sistema.
La programación extrema implica varias prácticas que se ajustan a los principios de los
métodos agiles:
El desarrollo incremental se lleva a cabo a través de entregas del sistema pequeñas y
frecuentes y por medio de un enfoque para la descripción de requerimientos basados en
las historias de cliente o escenarios que pueden ser la base para el proceso de
planificación.
La participación del cliente se lleva a cabo a través del compromiso a tiempo completo
del cliente en el equipo de desarrollo. Los representantes de los clientes participan en el
desarrollo y son los responsables de definir las pruebas de aceptación del sistema.
El interés en las personas, en vez de en los procesos, se lleva a cabo a través de la
programación en parejas, la propiedad colectiva del código del sistema, y un proceso de
desarrollo sostenible que no implique excesivas jornadas de trabajo.
El cambio se lleva a cabo a través de las entregas regulares del sistema, un desarrollo
previamente probado y la integración continua.
El mantenimiento de la simplicidad se lleva a cabo a través de la refactorización
constante para mejorar la calidad del código y la utilización de diseños sencillos que no
prevén cambios futuros en el sistema.
CARACTERÍSTICAS DE LA METODOLOGÍA XP
Se diferencia de las metodologías tradicionales principalmente en que pone más énfasis
en la adaptabilidad que en la previsibilidad.
Se aplica de manera dinámica durante el ciclo de vida del software.
Es capaz de adaptarse a los cambios de requisitos.
Los individuos e interacciones son más importantes que los procesos y herramientas.
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas.
La gente es el principal factor de éxito de un proyecto software. Es más importante construir
un buen equipo que construir el entorno. Muchas veces se comete el error de construir
primero el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el
equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.
Software que funcione es más importante que documentación exhaustiva.
Desarrollar software que funciona más que conseguir una buena documentación.
La regla a seguir es no producir documentos a menos que sean necesarios de forma
inmediata para tomar un decisión importante. Estos documentos deben ser cortos y
centrarse en lo fundamental.
La colaboración con el cliente es más importante que la negociación de contratos.
La colaboración con el cliente más que la negociación de un contrato.
Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo.
Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su
éxito.
La respuesta ante el cambio es más importante que el seguimiento de un plan.
VALORES DE LA METODOLOGÍA XPLos 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:
La 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é auto-
documentado.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 como
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 qué 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 programador esa
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:
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para
hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir
demasiado tiempo y trabajo para implementar todo lo demás del proyecto. La valentía le
permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea
necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios
futuros se implementaran mas fácilmente. Otro ejemplo de valentía es saber cuando
desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo
y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un
programador puede permanecer sin avanzar en un problema complejo por un día entero, y
luego lo resolverá rápidamente al día siguiente, sólo si es persistente.
PERSONAS QUE INTERVIENEN EN LA METODOLOGÍA XPSegún Kent Beck
La metodología XP se encuentra en una frecuente integración del equipo de programación
con el cliente o usuario: se recomienda que un representante del cliente trabaje junto al
equipo de desarrollo. 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 qué características tienen prioridad y
siempre debe estar disponible para solucionar dudas.
Según Ian Sommerville
En un proceso XP, los clientes están fuertemente implicados en la especificación y
establecimiento de prioridades de los requerimientos del sistema.
Los requerimientos no se especifican como una lista de funciones requeridas del sistema.
Más bien, los clientes del sistema son parte del equipo de desarrollo y discuten escenarios
con otros miembros del equipo. Desarrollan conjuntamente una tarjeta de historia que recoge
las necesidades del cliente. El equipo de desarrollo intentara entonces implementar ese
escenario en una entrega futura del software.
La participación del cliente se lleva a cabo a través del compromiso a tiempo completo del
cliente en el equipo de desarrollo. Los representantes de los clientes participan en el
desarrollo y son los responsables de definir las pruebas de aceptación del sistema.
LOS PASOS DE LA METODOLOGÍA XPSegún Kent Beck
Los Pasos fundamentales inmersos en las fases del método son:
Desarrollo iterativo e incremental: Pequeñas mejoras, unas tras otras.
Pruebas unitarias continuas: Son frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la
codificación.
Véase, 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 programación Smalltalk.
Programación en parejas: Se recomienda que las tareas de desarrollo se lleven a cabo
por dos personas en un mismo puesto. Se supone que la mayor calidad del código
escrito de esta manera -el código es revisado y discutido mientras se escribe- es más
importante que la posible pérdida de productividad inmediata.
Frecuente integración del equipo de programación con el cliente o usuario: Se
recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas
frecuentes.
Refactorizacion del código: Es decir, reescribir ciertas partes del código para aumentar
su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han
de garantizar que en la refactorización no se ha introducido ningún fallo.
Propiedad del código compartido: en vez de dividir la responsabilidad en el desarrollo
de cada módulo en grupos de trabajo distintos, este método promueve el que todo el
personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas
de regresión garantizan que los posibles errores serán detectados.
Simplicidad del codigo: es la mejor manera de que las cosas funcionen. Cuando todo
funcione se podrá añadir funcionalidad si es necesario. La programación extrema
apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para
cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más
comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más
simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una
comunicación más completa, especialmente si se puede reducir el equipo de
programadores.
Según Ian Sommerville
Planificación Incremental: Los requerimientos se registran en tarjetas de historias y las
historias a incluir en una entrega se determinan según el tiempo disponible y su prioridad
relativa.
Los desarrolladores dividen estas historias en tareas de desarrollo.
Entregas Pequeñas: El mismo conjunto útil de funcionalidad que proporcione valor de
negocio se desarrolla primero. Las entregas del sistema son frecuentes e
incrementalmente añaden funcionalidad a la primera entrega.
Diseño Sencillo: Solo se lleva a cabo el diseño necesario para cumplir los
requerimientos actuales.
Desarrollo previamente probado: Se utiliza un sistema de pruebas de unidad
automatizado para escribir pruebas para nuevas funcionalidades antes de que estas se
implementen.
Refactorizacion: Se espera que todos los desarrolladores refactoricen el código
continuamente tan pronto como encuentren posibles mejoras en el código.
Esto conserva el código sencillo y mantenible.
Programación en Parejas: Los desarrolladores trabajan en parejas, verificando cada
uno el trabajo del otro proporcionando la ayuda necesaria para hacer siempre un buen
trabajo.
Propiedad Colectiva: Las parejas de desarrolladores trabajan en todas las áreas del
sistema, de modo que no desarrollen islas de conocimiento y todos los desarrolladores
posean todo el código. Cualquiera puede cambiar cualquier cosa.
Integración Continua: En cuanto acaba el trabajo en una tarea, se integra en el sistema
entero.
Después de la integración, se deben pasar al sistema todas las pruebas de unidad.
Ritmo Sostenible: No se consideran aceptables grandes cantidades de horas extras, ya
que a menudo el efecto que tienen es que se reduce la cantidad del código y la
productividad a medio plazo.
Cliente Presente: Debe estar disponible al equipo de la XP un representante de los
usuarios finales del sistema (el cliente) a tiempo completo. En un proceso de la
programación externa, el cliente es miembro del equipo de desarrollo y es responsable
de formular al equipo los requerimientos del sistema para su implementación.
FASES DE LA METODOLOGÍA XPSegún Kent Beck
1ª FASE: Planificación del proyecto.
Historias de usuario:
El primer paso de cualquier proyecto que siga la metodología X.P es definir las historias de
usuario con el cliente. Las historias de usuario tienen la misma finalidad que los casos de
uso pero con algunas diferencias: Constan de 3 ó 4 líneas escritas por el cliente en un
lenguajeno técnico sin hacer mucho hincapié en los detalles; no se debe hablar ni de
posibles algoritmos para su implementación ni de diseños de base de datos adecuados,etc.
Son usadas para estimar tiempos de desarrollo de la parte de la aplicación que
describen.También se utilizan en la fase de pruebas, para verificar si el programa cumple
con lo que especifica la historia de usuario. Cuando llega la hora de implementar una historia
de usuario, el cliente y los desarrolladores se reúnen para concretar y detallar lo que tiene
que hacer dicha historia. El tiempo de desarrollo ideal para una historia de usuario es entre 1
y 3 semanas.
Release Planning: .Después de tener ya definidas las historias de usuario es necesario
crear un plan de publicaciones, en inglés "Release plan", donde seindiquen las historias de
usuario que se crearán para cada versión del programa y las fechas en las que se publicarán
estas versiones. Un "Release plan" es una planificación donde los desarrolladores y clientes
establecen los tiempos de implementación ideales de las historias de usuario, la prioridad
con la que serán implementadas y las historias que serán implementadas en cada versión
del programa. Después de un "Release plan" tienen que estar claros estos cuatro factores:
los objetivos que se deben cumplir (que son principalmente las historias que se deben
desarrollar en cada versión), el tiempo que tardarán en desarrollarse y publicarse las
versiones del programa, el número de personas que trabajarán en el desarrollo y cómo se
evaluará la calidad del trabajo realizado. (*Release plan: Planificación de publicaciones).
Iteraciones: Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones de
aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes deben
seleccionar las historias de usuario definidas en el "Release planning" que serán
implementadas. También se seleccionan las historias de usuario que no pasaron el test de
aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario son
divididas en tareas de entre 1 y 3 días de duración que se asignarán a los programadores.
La Velocidad del Proyecto: es una medida que representa la rapidez con la que se
desarrolla el proyecto; estimarla es muy sencillo, basta con contar el número de historias de
usuario que se pueden implementar en una iteración; de esta forma, se sabrá el cupo de
historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del
proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que
dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se
aprecia que no es adecuada hay que negociar con el cliente un nuevo "Release Plan".
Programación en Parejas: La metodología X.P. aconseja la programación en parejas pues
incrementa la productividad y la calidad del software desarrollado.
El trabajo en pareja involucra a dos programadores trabajando en el mismo equipo; mientras
uno codifica haciendo hincapié en la calidad de la función o método que está
implementando,el otro analiza si ese método o función es adecuado y está bien diseñado.
De esta forma se consigue un código y diseño con gran calidad.
Reuniones Diarias:. Es necesario que los desarrolladores se reúnan diariamente y
expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que
ser fluidas y todo el mundo tiene que tener voz y voto.
2ª FASE: Diseño.
Diseños Simples: La metodología X.P sugiere que hay que conseguir diseños simples y
sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un
diseño fácilmente entendible e impleméntable que a la larga costará menos tiempo y
esfuerzo desarrollar.
Glosarios de Términos: Usar glosarios de términos y un correcta especificación de los
nombres de métodos y clases ayudará a comprender el diseño y facilitará sus posteriores
ampliaciones y la reutilización del código.
Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una pareja
de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese
problema.
Funcionabilidad extra: Nunca se debe añadir funcionalidad extra al programa aunque se
piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica
que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.
Refactorizar: Refactorizar es mejorar y modificar la estructura y codificación de códigos ya
creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos
para procurar optimizar su funcionamiento. Es muy común rehusar códigos ya creados que
contienen funcionalidades que no serán usadas y diseños obsoletos.
3ª FASE: Codificación.
Como ya se dijo en la introducción, el cliente es una parte más del equipo de desarrollo; su
presencia es indispensable en las distintas fases de X.P. A la hora de codificar una historia
de usuario su presencia es aún más necesaria. No olvidemos que los clientes son los que
crean las historias de usuario y negocian los tiempos en los que serán implementadas. Antes
del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que
ésta hará y también tendrá que estar presente cuando se realicen los test que verifiquen que
la historia implementada cumple la funcionalidad especificada. La codificación debe hacerse
ateniendo a estándares de codificación ya creados. Programar bajo estándares mantiene el
código consistente y facilita su comprensión y escalabilidad.
4ª FASE: Pruebas.
Uno de los pilares de la metodología X.P es el uso de test para comprobar el funcionamiento
de los códigos que vayamos implementando. El uso de los test en X.P es el siguiente:
Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo
específico para test.
Hay que someter a tests las distintas clases del sistema omitiendo los métodos más
triviales.
Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado
anterior se explicó la importancia de crear antes los test que el código.
Un punto importante es crear test que no tengan ninguna dependencia del código que en
un futuro evaluará.
Como se comentó anteriormente los distintos test se deben subir al repositorio de código
acompañados del código que verifican.
Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas
tareas en las que ha sido dividida una historia de usuario.
Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se
harán test que analicen partes de las mismas, sino que las pruebas se realizarán para
las funcionalidades generales que debe cumplir el programa especificado en la
descripción de requisitos.
Fases de la Metodología XP
Según Ian Sommerville
Fases de la Metodología XP
VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA XPVENTAJAS:
Programación organizada.
Menor taza de errores.
Satisfacción del programador.
DESVENTAJAS:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.
COMPARATIVAS DE LAS METODOLOGÍAS SCRUM y XPSEMEJANZAS
Es un Agile Manifiesto.
Existen una Interacción de Usuario a Usuario.
Realizan los Proyectos en un Corto Periodo de Tiempo.
Trabajan en Equipo.
DIFERENCIAS
SCRUM XP (EXTREME PROGRAMMING)
Las iteraciones de entregas son de 2 a 4 semanas. Las iteraciones de entrega son a 1 a 3 semanas.
Lo que se termina, funciona y este bien, se aparta y ya no se toca.
Las tareas q se van entregando a los diferentes clientes son susceptibles a las modificaciones.
Cada miembro del Scrum Team trabaja de forma individual.
Los miembros del programan en pareja en un proyecto XP.
El Scrum Team trata de seguir el orden de prioridad q marca el Product Owner en el Sprint Backlog pueden ser modificadas.
El equipo de desarrollo sigue estrictamente el orden de prioridad de las tareas definidas por el cliente.
Esta basada en la administración del proyecto.Se centra mas en la propia programación o creación del producto.
PROCESO DE LA METODOLOGÍAS XP
CONCLUSIÓNMediante la realización de esta investigación se pudo llegar a las siguientes conclusiones:
• El SCRUM es usado como modelo para el desarrollo de productos tecnológicos, aunque
también se emplea en entornos que trabajan con requisitos inestables y que requieren
rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de
software, mientras que el XP se usa de una forma adaptable a cualquier punto de la vida de
cualquier proyecto, considerándose capaz de obtener resultados mas realistas y efectivos.
• Tanto el SCRUM como el XP, toman en cuenta los cambios que puedan ir ocurriendo a
medida que se vaya desarrollando el proyecto para de esta manera mejorar u optimizar la
arquitectura del mismo a medida que este se va llevando a cabo.
• El SCRUM y el XP trabajan de forma iterativa, de manera que en cada una se vaya
mejorando la arquitectura del proyecto y se acerque más al resultado esperado.
• Estos procesos ágiles requieren de una persistente comunicación y retroalimentación entre
los integrantes desarrolladores del proyecto para que de esta manera se realicen los
cambios y se mejore el producto final.
METODOLOGIA XP{}
METODOLOGÍA EXTREME PROGRAMMING (XP)
La programación extrema es una metodología de desarrollo ligero (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el
objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programación se basa en una serie de metodologías de
desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programación.
Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en cómo se refuerzan los unos con los otros. El resultado de esta
selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de
software. El objetivo que se perseguía en el momento de crear esta metodología era la
búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común.
CARACTERÍSTICAS FUNDAMENTALES
Las características fundamentales del método son:
Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, 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 programación Smalltalk.
Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.
ACTIVIDADES DE XP
Codificar
Es necesario codificar y plasmar nuestras ideas a través del código. En programación, el código expresa la interpretación del problema, así podemos utilizar el código para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar.
Hacer pruebas
Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema, entonces habremos acabado por completo.
Escuchar
En una frase, "Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿para qué nos querrían?".
Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuáles son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.
Diseñar
El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.
Resumiendo las actividades de Xp: Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.
PRÁCTICAS BÁSICAS DE XP
De forma aislada, cualquier práctica individual de Xp tiene poco sentido, pero en conjunto, unas compensan las carencias que las otras puedan tener.
El juego de la Planificación - (Planning Game)
El alcance de la siguiente versión esta definido por las consideraciones de negocios (prioridad de los módulos, fechas de entrega) y estimaciones técnicas (estimaciones de funciones, consecuencias).
El objetivo del juego es maximizar el valor del software producido, La estrategia es poner en producción las características más importantes lo antes posible, Las Piezas clave son las Story Cards, Los Jugadores son los desarrolladores y el cliente y las Movidas son Exploración, Selección y Actualización.
Versiones Pequeñas (Short Releases)
Un sistema simple se pone rápidamente en producción. Periódicamente, se producen nuevas versiones agregando en cada iteración aquellas funciones consideradas valiosas para el cliente
Metáfora del Sistema (Metaphor)
Cada Proyecto es guiado por una historia simple de cómo funciona el sistema en general, reemplaza a la arquitectura y debe estar en lenguaje común, entendible para todos (Cliente y Desarrolladores), esta puede cambiar permanentemente.
Diseño Simple (Simple Designs)
El sistema se diseña con la máxima simplicidad posible (YAGNY - "No vas a necesitarlo"), Se plasma el diseño en tarjetas CRC (Clase – Responsabilidad- Colaboración), no se implementan características que no son necesarias, con esta técnica, las clases descubiertas durante el análisis pueden ser filtradas para determinar qué clases son realmente necesarias para el sistema.
Pruebas Continuas (Testing)
Los casos de prueba se escriben antes que el código. Los desarrolladores escriben pruebas unitarias y los clientes especifican pruebas funcionales.
Refactorización (Refactoring)
Es posible reestructurar el sistema sin cambiar su comportamiento, por ejemplo eliminando código duplicado, simplificando funciones, Mejorando el código constantemente, si el código se esta volviendo complicado se debería modificar el diseño y volver a uno más simple. Refactoring (Modificar la forma del código sin cambiar su funcionamiento).
Programación por parejas (Pair Programming)
El código es escrito por dos personas trabajando en el mismo computador. "Una sola maquina con un teclado y un mouse"
Posesión Colectiva del Código (Collective Code Ownership)
Nadie es dueño de un modulo. Cualquier programador puede cambiar cualquier parte del sistema en cualquier momento, siempre se utilizan estándares y se excluyen los comentarios, Los test siempre deben funcionar al 100% para realizar integraciones con todo el código permanentemente.
Integración continua (Continuous Integration)
Los cambios se integran en el código base varias veces por día. Todos lo casos de prueba se deben pasar antes y después de la integración, se dispone de una maquina para la integración y se realizan test funcionales en donde participa el cliente.
Semana laboral de 40 horas (40-Hour Week)
Cada Trabajador trabaja no más de 40 Horas por semana. Si fuera necesario hacer horas extra, esto no debería hacerse dos semanas consecutivas. Sin héroes, esto hace que se reduzca la rotación del personal y mejora la calidad del producto.
Cliente en el Sitio (On Site Customer)
El equipo de desarrollo tiene acceso todo el tiempo al cliente, el cual esta disponible para responder preguntas, fijar prioridades, etc. Esto no siempre se consigue; Un cliente muy Junior no sirve y un cliente muy Sénior no es disponible. "Lo ideal es un cliente Analista".
Estándares de Codificación (Coding Standard)
Todo el código debe estar escrito de acuerdo a un estándar de codificación
CICLO DE VIDA
El ciclo de vida de Xp se enfatiza en el carácter interactivo e incremental del desarrollo.
Las iteraciones son relativamente cortas ya que se piensa que entre más rápido se le entreguen desarrollos al cliente, más retroalimentación se va a obtener y esto va a representar una mejor calidad del producto a largo plazo. Existe una fase de análisis inicial orientada a programar las iteraciones de desarrollo y cada iteración incluye diseño, codificación 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:
Ciclo de vida de eXtreme Programming
Fase de la exploración
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto.
Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.
Fase del planeamiento
Se priorizan las historias de usuario y se acuerda el alcance del release. Los programadores estiman cuánto esfuerzo requiere cada historia y a partir de allí se define el cronograma. La duración del cronograma del primer release no excede normalmente dos meses. La fase de planeamiento toma un par de días. Se deben incluir varias iteraciones para lograr un release. El cronograma fijado en la etapa de planeamiento se realiza a un número de iteraciones, cada una toma de una a cuatro semanas en ejecución. La primera iteración crea un sistema con la arquitectura del sistema completo. Esto es alcanzado seleccionando las historias que harán cumplir la construcción de la estructura para el sistema completo. El cliente decide las historias que se seleccionarán para cada iteración. Las pruebas funcionales creadas por el cliente se ejecutan al final de cada iteración. Al final de la última iteración el sistema esta listo para producción.
Fase de producción
Requiere prueba y comprobación extra del funcionamiento del sistema antes de que éste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden todavía ser encontrados y debe tomarse la decisión 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 práctica posterior por ejemplo en la fase de mantenimiento. Después 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 también las tareas del cliente. Así, la velocidad del desarrollo puede desacelerar después de que el sistema esté en la producción. La fase de mantenimiento puede requerir la incorporación de nueva gente y cambiar la estructura del equipo.
Fase de muerte
Es cuando el cliente no tiene más 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 documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.
ACTORES Y RESPONSABILIDADES DE XP
Existen diferentes roles (actores) y responsabilidades en Xp para diferentes tareas y propósitos durante el proceso:
Programador (Programmer)
Responsable de decisiones técnicas Responsable de construir el sistema Sin distinción entre analistas, diseñadores o codificadores En Xp, los programadores diseñan, programan y realizan las pruebas
Cliente (Customer)
Es parte del equipo Determina qué construir y cuándo Escribe tests funcionales para determinar cuándo está completo un
determinado aspecto
Entrenador (Coach)
El líder del equipo - toma las decisiones importantes Principal responsable del proceso Tiende a estar en un segundo plano a medida que el equipo madura
Rastreador (Tracker)
Metric Man Observa sin molestar Conserva datos históricos
Probador (Tester)
Ayuda al cliente con las pruebas funcionales Se asegura de que los tests funcionales se ejecutan
ARTEFACTOS XP
A continuación describimos los artefactos de Xp, entre los que se encuentran: Historias de Usuario, Tareas de Ingeniería y Tarjetas CRC.
Historias de Usuario
Representan una breve descripción del comportamiento del sistema, emplea terminología del cliente sin lenguaje técnico, se realiza una por cada característica principal del sistema, se emplean para hacer estimaciones de tiempo y para el plan de lanzamientos, reemplazan un gran documento de requisitos y presiden la creación de las pruebas de aceptación.
Historia de UsuarioNúmero: Nombre Historia de Usuario:Modificación (o extensión) de Historia de Usuario (Nro. y Nombre):Usuario: Iteración Asignada:Prioridad en Negocio:
(Alta / Media / Baja)Puntos Estimados:
Riesgo en Desarrollo:
(Alto / Medio / Bajo)Puntos Reales:
Descripción:
Observaciones:
Modelo propuesto para una historia de usuario
Estas deben proporcionar sólo el detalle suficiente como para poder hacer razonable la estimación de cuánto tiempo requiere la implementación de la historia, difiere de los casos de uso porque son escritos por el cliente, no por los programadores, empleando terminología del cliente. "Las historias de usuario son más "amigables" que los casos de uso formales".
Las Historias de Usuario tienen tres aspectos:
Tarjeta: en ella se almacena suficiente información para identificar y detallar la historia.
Conversación: cliente y programadores discuten la historia para ampliar los detalles (verbalmente cuando sea posible, pero documentada cuando se requiera confirmación)
Pruebas de Aceptación: permite confirmar que la historia ha sido implementada correctamente.
Caso de Prueba de Aceptación
Código:Historia de Usuario (Nro. y Nombre):
Nombre:Descripción:
Condiciones de Ejecución:
Entrada / Pasos de ejecución:
Resultado Esperado:
Evaluación de la Prueba:
Modelo propuesto para una prueba de aceptación
Task Card
Tarea de IngenieríaNúmero Tarea: Historia de Usuario (Nro. y Nombre):Nombre Tarea:Tipo de Tarea :
Desarrollo / Corrección / Mejora / Otra (especificar)
Puntos Estimados:
Fecha Inicio: Fecha Fin:Programador Responsable:Descripción:
Modelo propuesto para una tarea de ingeniería
Tarjetas CRC (Clase - Responsabilidad – Colaborador).
Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la clase, sus responsabilidades y sus colaboradores. En la siguiente figura se muestra cómo se distribuye esta información.
Modelo de tarjeta CRC
Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las responsabilidades de una clase son las cosas que conoce y las que realizan, sus atributos y métodos. Los colaboradores de una clase son las demás clases con las que trabaja en conjunto para llevar a cabo sus responsabilidades.
En la práctica conviene tener pequeñas tarjetas de cartón, que se llenarán y que son mostradas al cliente, de manera que se pueda llegar a un acuerdo sobre la validez de las abstracciones propuestas.
Los pasos a seguir para llenar las tarjetas son los siguientes:
Encontrar clases Encontrar responsabilidades Definir colaboradores Disponer las tarjetas
Para encontrar las clases debemos pensar qué cosas interactúan con el sistema (en nuestro caso el usuario), y qué cosas son parte del sistema, así como las pantallas útiles a la aplicación (un despliegue de datos, una entrada de parámetros y una pantalla general, entre otros). Una vez que las clases principales han sido encontradas se procede a buscar los atributos y las responsabilidades, para esto se puede formular la pregunta ¿Qué sabe la clase? y ¿Qué hace la clase? Finalmente se buscan los colaboradores dentro de la lista de clases que se tenga.
