XP - Universidad Austral

eXtreme Programming1
Parte del Trabajo de Grado “Adecuación de la metodología de desarrollo Extreme
Programming a proyectos llevados a cabo en la materia Laboratorio III de la
Facultad de Ingeniería de la Universidad Austral” de Lucila Ana Cuccaro Goggi
1
Índice General
Motivación del trabajo de grado ....................................................................................... 3
ntroducción a las metodologías Ágiles ............................................................................. 6
Historia de las metodologías Ágiles ............................................................................. 6
Manifiesto Ágil ............................................................................................................. 7
Los 12 principios ágiles ................................................................................................ 8
Distintas Metodologías ágiles ..................................................................................... 10
Introducción a eXtreme Programming ........................................................................... 14
Su creador: “Kent Beck” ............................................................................................ 14
Descripción de la Metodología: XP detallado ............................................................ 15
Actividades de Xp ...................................................................................................... 16
Escuchar.................................................................................................................. 16
Diseñar .................................................................................................................... 16
Codificar ................................................................................................................. 16
Hacer pruebas ......................................................................................................... 17
Proceso XP ................................................................................................................. 17
Prácticas XP ................................................................................................................ 18
El juego de la planificación .................................................................................... 18
Entregas pequeñas .................................................................................................. 18
Metáfora.................................................................................................................. 19
Diseño simple ......................................................................................................... 19
Pruebas ................................................................................................................... 19
Refactorización (Refactoring) ................................................................................ 19
Programación en parejas ......................................................................................... 20
Propiedad colectiva del código ............................................................................... 20
Integración continua ............................................................................................... 20
40 horas por semana ............................................................................................... 21
Cliente on-site ......................................................................................................... 21
Estándares de programación ................................................................................... 21
Artefactos XP ............................................................................................................. 23
Las Historias de Usuario ........................................................................................ 23
Task Cards .............................................................................................................. 23
CRC Card ............................................................................................................... 24
Roles XP ..................................................................................................................... 24
Programador ........................................................................................................... 24
Cliente..................................................................................................................... 25
Encargado de pruebas (Tester) ............................................................................... 25
Encargado de seguimiento (Tracker) ...................................................................... 25
Entrenador (Coach)................................................................................................. 25
Consultor ................................................................................................................ 26
Gestor (“Big boss”) ................................................................................................ 26
Casos de estudio en los que se utilizo “Extreme Programming” ............................... 26
Bibliografía ..................................................................................................................... 31
Glosario .......................................................................................................................... 33
2
Motivación del trabajo de grado
La creación de software o desarrollo de sistemas es una tarea altamente
compleja. Debido a esta complejidad con el transcurso del tiempo se han desarrollado
numerosas metodologías de desarrollo que afectan las distintas dimensiones del proceso
de desarrollo.
Por una parte podemos encontrar aquellas metodologías más tradicionales que
hacen hincapié principalmente en el control del proceso, estableciendo cuidadosamente
las actividades involucradas, los distintos artefactos que se deben producir y las
herramientas que han de ser utilizadas para producir dichos artefactos. Estas propuestas
metodológicas han demostrado ser altamente efectivas en numerosos proyectos e
inclusive, en ocasiones, necesarias; pero por desgracia también han presentado varios
problemas en muchos otros proyectos. Ante dichos problemas se han propuesto
diferentes alternativas para combatir estos inconvenientes.
Una de ellas fue la introducción de nuevas actividades en los procesos de
desarrollo. Otra alternativa fue la introducción de más artefactos y restricciones
teniendo en cuenta los puntos débiles en cada proyecto. Pero el resultado de llevar a
cabo estas acciones fue la obtención de un proceso de desarrollo más engorroso y
complejo que incluso, en algunos casos, podía llegar a limitar la habilidad del equipo a
la hora de trabajar en el desarrollo del proyecto.
Otra posible solución planteada posteriormente fue centrarse en otros aspectos
del desarrollo como por ejemplo el factor humano o equipo involucrado en el proceso
de desarrollo así como en el software a desarrollar.
A partir de esta solución que hoy en día es considerada como una filosofía,
nacen las metodologías ágiles. Esta filosofía brinda mayor valor a los individuos
involucrados, así como a la colaboración con el cliente y al desarrollo incremental del
software basado en iteraciones que constan de un corto plazo.
En la actualidad este enfoque esta mostrando una alta efectividad en proyectos
con requerimientos muy cambiantes y en aquellos casos en lo que se exige reducir
notablemente los tiempos de desarrollo pero sin descuidar la alta calidad del producto.
Apoyadas en esta filosofía nacen las metodologías ágiles, las cuales están
revolucionando la forma de producir software y a la vez generando un amplio debate
entre sus seguidores, gente innovadora en el área de desarrollo y aquellos que por
convencionalismo o escepticismo no las ven como una alternativa viable para el
desarrollo de aplicaciones.
En este marco centraremos nuestro estudio para analizar la más importante y
utilizada en el mercado laboral de estas metodologías ágiles de las software factories,
“Extreme Programming”.
En el presente trabajo se estudiará en que consiste esta metodología analizando
sus valores, estructura, artefactos y conceptos; y se realizara un estudio detallado de
como adaptar dicha metodología a la materia Laboratorio III de la Facultad de
Ingeniería de la Universidad Austral.
Junto con lo anteriormente mencionado, este trabajo tiene como objetivos
introducir a los alumnos en una metodología utilizada en la actualidad y servir de guía
de consulta a los mismos a la hora de trabajar con dicha metodología.
El trabajo comienza con la presentación de los lineamientos necesarios para
trabajar con XP y RUP; continúa con la comparación entre dichas metodologías y la
adecuación de la metodología XP a la cursada de la materia Laboratorio III y concluye
con una reflexión sobre el estudio realizado.
3
Historia de los procesos de desarrollo
El modelo más antiguo de desarrollo era el de codificar y probar. Este modelo
fue utilizado en los inicios del desarrollo de software. Dicho modelo fue el que
predominó en la década de los años 60.
Éste estaba basado en requerimientos ambiguos y sin especificaciones puntuales.
Constaba en implementar el código y, a continuación, pensar sobre los requerimientos,
el diseño y el mantenimiento.
Para sistemas pequeños este modelo resultó ser útil, pero cuando los sistemas se
presentaban con una mayor complejidad resultaba muy peligroso, ya que no
proporcionaba medios de evaluación de la calidad o de identificación de riesgos.
Su principal falla se presentaba si se estaba a punto de terminar de codificar y se
descubría que el diseño era incorrecto ya que en dichas condiciones, no había otra
solución más que desechar el trabajo realizado y comenzar de nuevo. Esto resultaba
muy elevado en costos de los recursos y tiempos de desarrollo.
Posteriormente, en la década del 70, propuesto por Winston Royce2, surgió el
denominado “modelo en cascada”. Dicho modelo sirvió como base para la formulación
del análisis estructurado, el cual fue uno de los precursores en el camino hacia la
aplicación de prácticas estandarizadas dentro de la ingeniería de software.
El modelo en cascada, buscaba ordenar el proceso de desarrollo de una forma
fácil de implementar. Este modelo tuvo una gran aceptación. La principal ventaja que
brindaba con respecto al anterior, el modelo de implementación y prueba, era que ya se
contaba con cierta disciplina en el desarrollo de sistemas; se introducen la planeación y
administración, y se deben controlar dichas actividades; es decir, debía existir alguien
que vigile que el grupo de desarrollo realmente cumpla con lo que se había planeado.
Este modelo se basaba en el desarrollo de etapas (análisis, diseño, codificación,
pruebas y mantenimiento) las cuales cuentan con una entrada y una salida predefinida.
El proceso de desarrollo toma la forma de una cascada ya que se requiere la finalización
de la etapa anterior para comenzar con la siguiente.
La principal desventaja del modelo en cascada era que no es flexible con
respecto a los cambios. Esto exigía que se tengan que especificar completamente todos
los requerimientos al comienzo del proyecto lo que puede durar meses o incluso años
antes de tener el software funcionando. Una vez que se iniciaba el desarrollo no se
permitía cambio alguno a los requerimientos, por lo que el usuario no podía ver la
aplicación hasta que ya estuviese totalmente construida. Se corría asimismo con el
riesgo de no cubrir sus necesidades.
“Conforme se fueron descubriendo las deficiencias del modelo en cascada,
fueron surgiendo diversos procesos denominados iterativos que fueron mejorando
muchas de las fallas del modelo en cascada. Como especialización de este modelo
surgen los procesos iterativos como el “modelo en espiral”, “el modelo iterativo e
incremental”, “el modelo basado en prototipo”, “el modelo MBASE” (Model-Based
Architecture and Software Engineering3) y finalmente el de mayor renombre de ellos el
“Rational Unified process”(RUP)”.4
2
http://en.wikipedia.org/wiki/Winston_W._Royce
http://en.wikipedia.org/wiki/MBASE
4
http://www.qualitrain.com.mx/index.php/Procesos-de-software/Evolucion-de-losprocesos-de-desarrollo-Primera-parrte/Page-3.html
3
4
Estos modelos hicieron un gran aporte en la historia del desarrollo al basar el
mismo en iteraciones y la construcción de la aplicación en forma progresiva, agregando
funcionalidad paulatinamente.
Las iteraciones eran tomadas de esta forma como un mini - proyecto, el cual está
compuesto por todas las fases del desarrollo (requerimientos, análisis, diseño,
implementación y pruebas). Los incrementos en la aplicación están dados por la
funcionalidad que se va agregando al software en cada una de sus iteraciones.
Los modelos iterativos fomentan el cambio en forma temprana y proponen un
control de cambio disciplinado que permite al usuario ajustar sobre el desarrollo sus
requerimientos.
A mediados de los años 90 como parte de una reacción contra los modelos muy
estructurados y estrictos, extraídos del modelo de desarrollo en cascada nacen las
metodologías ágiles.
“El proceso originado del uso del modelo en cascada era visto como burocrático,
lento, degradante e inconsistente con las formas de desarrollo de software que realmente
realizaban un trabajo eficiente. Inicialmente, los métodos ágiles fueron llamados
métodos de "peso liviano". En el año 2001, miembros prominentes de la comunidad se
reunieron en Sonwbird, Utah, y adoptaron el nombre de "Metodologías ágiles". Poco
después, algunas de estas personas formaron la "alianza ágil", una organización sin
fines de lucro que promueve el desarrollo ágil de aplicaciones.”5
Muchos métodos creados similares al ágil fueron introducidos posteriormente a
la familia “Agile” propiamente dicha y aceptada como tal en el año 2001. Entre los más
notables se encuentran: “Scrum(1986), Crystal Clear (cristal transparente),
programación extrema o XP (1996), desarrollo de software adaptativo, feature driven
development, Método de desarrollo de sistemas dinámicos(1995)”6.
A continuación se presenta un gráfico que resume e ilustra la evolución
completa de los desarrollos de software a lo largo del tiempo.
Figura 1 - Evolución histórica de las metodologías de desarrollo
5
6
http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software
http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software
5
Introducción a las metodologías Ágiles
Frente a los numerosos problemas que se presentaban en el desarrollo de software
en las últimas dos décadas, expertos enunciaron numerosas notaciones de modelado y
herramientas de soporte con la intención de que éstas actuasen como "balas de plata"
para conseguir el éxito en el desarrollo del software. No obstante, las expectativas no
fueron alcanzadas. Esto se debió en gran parte a que otro importante elemento a analizar
y mejorar, la metodología de desarrollo, había sido dejado a un lado. De nada sirvieron
las buenas notaciones y herramientas si no venían de la mano con buenas directivas para
ser aplicadas.
Así, en la década de los años 90 se comenzó a tomar un notable interés en las
metodologías de desarrollo. Hasta no hace mucho tiempo el proceso de desarrollo
llevaba asociado consigo un marcado énfasis en el control del proceso mediante una
rigurosa definición de actividades, roles y artefactos, incluyendo todo lo comprendido
en el modelado y una detallada documentación del proyecto. Este enfoque “tradicional”
para tratar el tema del desarrollo de software resultó ser efectivo y necesario en
proyectos de gran escala o tamaño en cuanto a tiempo y recursos, donde por lo general,
se exigía un alto grado de análisis en el proceso.
Sin embargo este enfoque no resultó ser el mas adecuado para muchos de los
proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige
reducir drásticamente los tiempos de desarrollo pero manteniendo un elevado nivel de
calidad. Ante las adversidades que se presentan para utilizar metodologías tradicionales,
con tantas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se
resignan a prescindir del “buen actuar” de la ingeniería del software y “robusta
documentación”, asumiendo el riesgo que esto conlleva consigo.
En dicho marco, las metodologías ágiles nacen como una respuesta posible para
resolver este problema y llenar así ese vacío metodológico presente. Estas metodologías
especialmente orientadas para proyectos pequeños, constituyen una solución a medida
para entornos con dichas condiciones (proyectos pequeños), aportando una elevada
simplificación que sin embargo, no renuncia a las buenas prácticas esenciales que
aseguran la buena calidad del producto.
Las metodologías “Agile” constituyen, sin duda alguna, uno de los principales
temas mas novedosos en la industria del software, que día a día van acaparando gran
interés en el mercado. Esto se ve reflejado en que están ganando mucho espacio en la
mayoría de los workshops y conferencias de los últimos años.
También cabe destacar que las metodologías Ágiles fueron especialmente
pensadas para proyectos con distintas características que se ajustan a un amplio rango
de proyectos de distintas industrias de desarrollo de software.
Historia de las metodologías Ágiles
En el mes de febrero del año 2001, 17 expertos reconocidos de la industria del
software, incluyendo algunos de los creadores o impulsores de metodologías de
software, se reunieron en Utah-EEUU para discutir varias cuestiones relacionados con
el desarrollo de aplicaciones informáticas. En dicha reunión nace el término “ágil” que
abarcaba una serie de principios y valores que serán explicados con mayor detalle a
continuación.
6
El objetivo de dicha reunión fue esbozar los valores y principios que deberían
permitir a los equipos involucrados en un proyecto desarrollar sus tareas de forma
rápida y respondiendo a los cambios que puedan surgir a lo largo de todo el ciclo de
vida del proyecto.
Pretendían brindar una alternativa a los procesos de desarrollo de software
tradicionales, que se caracterizaban por ser rígidos y dirigidos por la documentación que
se genera en cada una de las actividades desarrolladas.
Tras esta reunión se creó “The Agile Alliance”, una organización, sin fines de
lucro que se dedica a promover los conceptos relacionados con el desarrollo ágil de
software y ayuda a las organizaciones para que adopten dichos conceptos en sus
procesos. El punto de partida de dichos valores y principios fue el Manifiesto Ágil. Este
documento resume la filosofía “ágil”7.
Manifiesto Ágil
Los creadores del manifiesto Ágil son:
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
El manifiesto Ágil establece que se valora:
- Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas.
- Desarrollar software que funciona más que conseguir una buena documentación.
- La colaboración con el cliente más que la negociación de un contrato.
- Responder a los cambios más que seguir estrictamente un plan.
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas.
Este principio es probablemente el más importante de todos los principios del
manifiesto. Sabemos que los procesos constituyen una gran ayuda al trabajo de
desarrollo junto con las herramientas a la hora de mejorar la eficiencia. Sin embargo,
son las personas con una correcta actitud y conocimiento técnicos quienes hacen posible
junto con dichos procesos y herramientas, alcanzar los resultados esperados. La gente
constituye el factor clave de éxito en un proyecto de desarrollo de software. Es más
importante construir un buen equipo que construir el entorno adecuado. Lo ideal es que
una vez que se cuente con el quipo adecuado de desarrollo, éste sea quien establezca el
7
www.willydev.net/descargas/prev/TodoAgil.pdf
7
entorno necesario para desarrollarse cómodamente.
Desarrollar software
documentación.
que
funciona
más
que
conseguir
una
buena
Si es posible, se aconseja desarrollar un prototipo o módulos del sistema final
desarrollados para poder ver sobre ellos como han de comportarse las funcionalidades
esperadas. Esto brinda una retroalimentación muy rica que estimula la generación de
ideas que no habrían sido posibles de concebir en una primera instancia. Difícilmente se
podrá conseguir un documento que contenga requisitos detallados antes de comenzar el
proyecto. Los documentos deben ser un soporte que permita la transferencia del
conocimiento, registre información histórica, y que cubra las cuestiones legales o
normativas en aquellos casos que esto sea necesario; pero son menos importantes que
los productos finales en buen funcionamiento. Los documentos no pueden sustituir, ni
pueden ofrecer la riqueza y generación de valor que se logra con la comunicación
directa entre las personas y a través de la interacción con los prototipos. Por eso,
siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de
documentación que genera trabajo que no aporta un valor directo al producto final. Los
documentos deben ser de poco tamaño y no ir más allá de lo fundamental. Deben ser
claros y concisos.
La colaboración con el cliente más que la negociación de un contrato.
Como hemos dicho anteriormente, las metodologías ágiles están principalmente
enfocadas en proyectos en los que los requerimientos del producto son muy difíciles de
definir con detalle en los inicios del proyecto o se cree que los mismos irán cambiando
por la velocidad del entorno de desarrollo y del mismo negocio sobre el cual están
pensados. Los contratos con el cliente no son mas que una formalidad que establece
lineamientos sobre como deben comportarse las distintas partes que lo integran. El
desarrollo ágil ve al cliente como un miembro más del equipo, que se integra y colabora
en el grupo de trabajo. Se propone que exista una interacción constante entre el cliente y
el equipo de desarrollo ya que es precisamente esta colaboración la que asegure el éxito
del proyecto y determine la velocidad con el cual el mismo será desarrollado.
Responder a los cambios más que seguir estrictamente un plan.
Aquí se nos está diciendo que debemos valorar más la capacidad de respuesta
frente a los cambios que puedan surgir por encima de la capacidad de seguimiento y
aseguramiento de planes establecidos con anterioridad. En la actualidad es muy común
encontrarse con entornos inestables, que tienen como factor inherente al cambio y la
evolución rápida y continua. Es importante analizar como el quipo responde en dicho
entorno y la preparación con la que cuenta para responder a los cambios que se
presenten. La planificación en un proyecto no debe ser estricta sino flexible y abierta ya
que la habilidad de responder a estos cambios, ya sean cambios de requerimientos, de
tecnología, o en el equipo a cargo del proyecto, son los que determinarán también el
éxito o fracaso del proyecto.
Los 12 principios ágiles
Basados en los valores anteriores enunciados se han formulado los doce principios
que componen el manifiesto ágil. Estos son características comunes que deben tener
8
todos los procesos ágiles y que los diferencian de los procesos tradicionales.
1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas
de software que le aporte un valor.
Este principio establece que se deben realizar pequeñas entregas al cliente para
que éste vaya viendo el estado del proyecto y pueda comunicar su satisfacción o
descontento frente a las expectativas sobre el sistema. Las entregas realizadas a las
pocas semanas de empezado el proyecto, facilitan la comprensión de los requerimientos
del cliente. El cliente luego decide si pone en marcha dicho software con la
funcionalidad que ahora éste le proporciona o simplemente lo revisa e informa los
posibles cambios que desea que se realicen.
2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente
tenga una ventaja competitiva.
Los cambios de requerimientos son algo inevitable en todo proyecto de desarrollo.
Dichos cambios deben ser vistos como algo positivo por parte del equipo. Esta actitud
lleva al equipo a adquirir nuevos conocimientos, y a la vez, a lograr una mayor
satisfacción por parte del cliente. Este principio implica además que la estructura del
software debe ser flexible para poder incorporar los cambios sin demasiado costo
añadido y sin que estos cambios corrompan el software o partes del mismo ya
producidas. Hace que las componentes de software se vuelvan reutilizables y mas
independientes entre sí.
3. Entregar frecuentemente software que funcione desde un par de semanas a
un par de meses, con el menor intervalo de tiempo posible entre entregas.
Este principio nos dice que debemos tratar de hacer entregas pequeñas en cortos
plazos y no dejar pasar grandes intervalos de tiempo entre una entrega y la siguiente.
Este principio hace énfasis en la entrega de componentes de software en lugar de
componentes de planificación o documentación, ya sea de análisis o de diseño.
4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del
proyecto.
La interacción con el cliente constituye una pieza clave del desarrollo del
proyecto. Este principio nos dice que tanto cliente como equipo deben trabajar
conjuntamente para facilitar la comunicación y asegurar así el éxito del proyecto.
5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el
apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
Las mitologías ágiles establecen que las personas asignadas al proyecto
constituyen el principal factor de éxito. Todo los demás (proceso, entorno, gestión, etc.)
pasan a estar en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los
individuos debe ser cambiado. Es muy importante que las personas se encuentren en un
ambiente cómodo ya que esto contribuirá a que desarrollen sus tareas correctamente
obteniendo un mayor rendimiento.
6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.
Los miembros del equipo deben hablar entre ellos y con el cliente constantemente.
Si bien pueden existir otras formas de comunicación como los documentos, no toda la
información necesaria estará comprendida en ellos. Es por esto que la comunicación
oral debe ser la principal forma de comunicación.
9
7. El software que funciona es la medida principal de progreso.
El estado de un proyecto no se puede medir por la documentación generada o la
fase en la que el mismo se encuentre. Sólo el código generado y en funcionamiento
serán los que dirán efectivamente en que estado se encuentra el proyecto.
8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz
constante.
Este principio nos dice que debe mantenerse un ritmo constante de desarrollo
durante todo el proyecto en lugar de tratar de desarrollar lo más rápido posible. Esto
asegurará una mayor calidad en el producto final.
9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
Un buen diseño nos llevará a la producción de un código más claro y robusto, lo
cual constituye la clave para avanzar más rápidamente en el proyecto.
10. La simplicidad es esencial.
Un código simple y de alta calidad siempre es más sencillo de leer y adaptar a los
cambios que puedan surgir. Siempre debe intentarse tomar el camino más simples que
consistente con los objetivos perseguidos.
11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos
organizados por sí mismos.
Los requerimientos son entregados al equipo quedando todos sus miembros al
tanto de los mismos. El equipo es quien decide la mejor forma de organizarse, de
acuerdo a los objetivos que se persigan asignando a cada miembro la tarea que mejor se
adapte a su perfil.
12. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser
más efectivo, y según esto ajusta su comportamiento.
Debido a los constantes cambios del entorno, el equipo también debe adaptarse al
nuevo escenario de forma continua para poder realizar las modificaciones necesarias
para poder trabajar correctamente y conseguir buenos resultados. Puede realizar
cambios en su organización, sus reglas, sus convenciones, sus relaciones, etc., y de ésta
forma seguir siendo ágil.
Distintas Metodologías ágiles
Aunque los creadores e impulsores de las metodologías ágiles más populares han
suscrito el manifiesto ágil y coinciden con los principios enunciados anteriormente,
cada metodología tiene características propias y hace hincapié en algunos aspectos más
específicos. A continuación se resumen dichas metodologías ágiles, dejando el análisis
más detallado de XP para la siguiente sección.
10
Extreme Programming: “XP”
Es el proceso ágil más popular y utilizado de todas las metodologías ágiles. Esta
metodología pone mayor énfasis en la colaboración, en la rápida y temprana entrega de
componentes de software y en prácticas de desarrollo simples. Sus prácticas
establecidas “core” son: un equipo trabajando en un mismo ambiente, pair programming
(programación de a pares), uso constante de y la promoción del desarrollo orientado al
testing (realizar pruebas antes de programar). Hablaremos de xp con mayor detalle a lo
largo del trabajo.
Scrum
Metodología desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. La
misma establece un marco para el “management” o gestión de proyectos, que ha sido
empleado con éxito durante los últimos 10 años. Se encuentra principalmente dirigida
para proyectos que cuentan con un rápido cambio de requerimientos o requerimientos
inestables que presentan difícultades a la hora de ser definidos. Sus principales
características son el desarrollo de software iterativo y las reuniones diarias. El
desarrollo iterativo establece que el desarrollo de software se debe realizar mediante
iteraciones, denominadas sprints, que son de corta duración, aproximadamente de unos
30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al
cliente junto con el resto de los stakeholders. Las reuniones diarias se realizan a lo largo
de todo el proyecto se realizan reuniones diarias que poseen una duración de
aproximadamente 15 minutos. En ellas participa todo el equipo de desarrollo junto con
el cliente o un representante del mismo quienes conjuntamente coordinan e integran el
proyecto.
Crystal Methodologies
Las metodologías “Crystal” para el desarrollo de software se caracterizan por
estar focalizadas en las personas que componen el equipo de desarrollo, de quienes
depende el verdadero éxito del proyecto; así como en la reducción al máximo del
número de artefactos producidos en un tiempo determinado. Las mismas fueron
desarrolladas por Alistair Cockburn. Esta metodología ve al desarrollo de software
como “un juego cooperativo de invención y comunicación, limitado por los recursos a
utilizar”8. El equipo de desarrollo constituye una pieza clave en el proceso, por lo que
han de ser invertidos grandes esfuerzos en mejorar sus habilidades y destrezas (tanto
conocimientos técnicos como aptitudes personales); así como tener políticas bien
definidas de trabajo grupal. Estas políticas dependerán del tamaño del equipo,
estableciéndose una clasificación por colores, por ejemplo Crystal Clear en el caso que
el equipo cuente con un número de entre 3 y 8 miembros; y Crystal Orange en el caso
que este compuesto por un número de entre 25 y 50 miembros.
8
http://www.willydev.net/descargas/prev/TodoAgil.pdf
11
Dynamic Systems Development Method: “DSDM”
Define el marco para desarrollar un proceso de producción de software. Nace en
1994 con el objetivo de crear una metodología RAD unificada. Sus principales
características son: es un proceso iterativo e incremental y el equipo de desarrollo y el
usuario trabajan juntos. Propone cinco fases: estudio de viabilidad, estudio del negocio,
modelado funcional, diseño y construcción, y finalmente implementación. Las tres
últimas son iterativas, además de existir realimentación a todas las fases.
Adaptive Software Development: “ASD”
Esta metodología fue impulsada por Jim Highsmith. Se encuentra inspirada en
sistemas de alta complejidad que cuenta con una fuerte adaptabilidad y métodos de
desarrollo con rápida aplicación. Sus principales características son que es iterativo,
orientado a las componentes de software más que a las tareas y tolerante a los cambios.
El ciclo de vida que propone esta formado por tres fases principales: especulación,
colaboración y aprendizaje. En la primera de ellas el proyecto es iniciado y se planifican
las funcionalidades o características que tendrá el software; en la segunda se desarrollan
dichas funcionalidades y finalmente en la tercera se revisa la calidad de lo
implementado, y se lo entrega al cliente. La revisión de las componentes sirve para
aprender de los errores y volver a iniciar el ciclo de desarrollo contando con un mayor
conocimiento por parte de todos los integrantes del equipo.
Feature-Driven Development: “FDD”
Esta metodología creada por Jeff De Luca y Peter Coad establece que el
desarrollo debe originarse a partir del domino o modelo de negocio. Define un proceso
iterativo que consta de 5 pasos: desarrollar un modelo general, crear la lista de
características o funcionalidades que debe tener el sistema, realizar un plan de
desarrollo acorde a la lista de funcionalidades, realizar el diseño para dichas
funcionalidades, y finalmente, implementar dichas funcionalidades.
Las iteraciones son cortas, de una plazo de hasta 2 semanas. Se concentra en las fases de
diseño e implementación del sistema, partiendo de una lista de requerimientos
principales que debe reunir el software.
Lean Development : “LD”
“Lean Development” es un metodología pensada por Bob Charette’s a partir de
su trabajo realizado en proyectos relacionados con la industria automotriz japonesa en la
década de los 80. Fue utilizada en numerosos proyectos del área de telecomunicaciones
en toda Europa. En ella, los cambios se consideran riesgos, pero si se manejan
adecuadamente se pueden convertir en oportunidades que mejoren la productividad del
equipo así como la calidad del producto. Su principal característica es introducir un
mecanismo para implementar dichos cambios sin que impacte de forma negativa en las
componentes previamente desarrolladas del sistema.
A continuación se presenta una tabla en la que se compara las distintas
aproximaciones ágiles en base a tres parámetros: vista del sistema como algo cambiante,
12
tener en cuenta la colaboración entre los miembros del equipo y características más
específicas de la propia metodología (CM) como son los resultados, la simplicidad, la
excelencia técnica, adaptabilidad, etc.
También incorpora como referencia no ágil el Capability Madurity Model
(“CMM”).
Los valores más altos representan una mayor agilidad.
9
Figura 3 – Tabla de Ranking de agilidad
Como se puede observar en la Figura 3, todas las metodologías ágiles tienen una
significativa diferencia del índice de agilidad respecto a CMM y entre ellas destacan
ASD, Scrum y XP como las más ágiles a nivel general. Asimismo se puede observar
que XP, ASD y Scrum presentan los mayores valores con respecto a la adaptación de
los cambios dentro del sistema. Lo mismo ocurre con la colaboración y los resultados
obtenidos en donde se les suma a la lista Crystal.
Ahora bien, si observamos la grilla verticalmente, podremos notar que XP y ASD
son las metodologías con mayor nivel de agilidad de todas ya que poseen cinco de los
sietes aspectos analizados con el mayor valor posible de agilidad. Luego con un nivel
inferior pero aún así elevado de agilidad les siguen Cristal y Scrum.
Como podemos ver XP presenta notables ventajas con respecto a las otras
metodologías de desarrollo y son estas ventajas las que precisamente lo posesionan
fuertemente dentro de la familia Agile así como en el actual mercado de la informática.
9
http://www.cyta.com.ar/ta0502/v5n2a1.htm
13
Introducción a eXtreme Programming
A continuación realizaremos un detallado estudio de la metodología Extreme
Programming. La misma constituye el más destacado de los procesos ágiles de
desarrollo de software, es la metodología más utilizada en el mercado laboral y cuenta
con una notable adaptación y flexibilidad frente a los distintos tipos de proyecto.
Su creador: “Kent Beck”
10
Figura 4 - Kent Beck, Autor de XP
Aunque la creación de la metodología “XP” es atribuida tanto a Kent Beck como
a Ron Jeffries y Ward Cinningham, se hable de Beck como el padre y mayor
influenciador de la misma. Kent Beck también creó, junto con Erich Gamma el
framework de pruebas unitarias para Java conocido como “JUnit”. Es el fundador y
director de “Three Rivers Institute” (TRI). Su carrera combina la práctica de desarrollo
de software con reflexión, innovación y comunicación.
Es el author/co-author de numerosos libros como: “Implementation Patterns”11,
“Extreme Programming Explained: Embrace Change 2nd Edition”12, “Contributing to
Eclipse”13, “Test-Driven Development: By Example”14, “Planning Extreme
Programming”15, “Smalltalk Best Practice Patterns”16, and the “JUnit Pocket Guide”17.
10
http://images.google.com.ar
2008. Implementation Patterns. Addison-Wesley.
12
1999. Extreme Programming Explained: Embrace Change. Addison-Wesley.
13
2003. Contributing to Eclipse: Principles, Patterns, and Plugins. With Erich Gamma.
Addison-Wesley.
14
2002. Test-Driven Development: By Example. Addison-Wesley. Winner of the Jolt
Productivity Award.
15
2000. Planning Extreme Programming. With Martin Fowler. Addison-Wesley.
16 1996. Smalltalk Best Practice Patterns. Prentice Hall.
17
2004. JUnit Pocket Guide. O'Reilly.
11
14
Obtuvo sus títulos en Computer Science (Ciencias de la computación) en la
Universidad de Oregon. Sus actividades de negocio incluyen: contract programming
utilizando Java/Eclipse, writing, consulting y presentación de workshops con su
compañera Cynthia Andres.
En la actualidad Beck divide su tiempo entre la escritura, la programación y el
entrenamiento.
Su contribución al desarrollo de software incluye patrones, el redescubrimiento
de:
Test-first programming
Es una metodología basada en las pruebas unitarias como parte vital y buena
práctica del desarrollo de software. La misma establece que previamente a realizar la
implementación del sistema deben realizarse dichas pruebas y sólo teniendo la totalidad
de ellas aprobadas podrá comenzarse entonces a desarrollar el código fuente.
Esta metodología cuenta con la particularidad de ser a su vez parte de otras
metodologías (XP y TDD “Test driven Development”).
xUnit
Es un framework de pruebas conducido por código que ha llegado a conocerse
colectivamente y tomado gran importancia en los últimos tiempos. Dicho framework
esta basado en un diseño de Kent Beck, implementado originalmente para Smalltalk.
Actualmente, se encuentra disponible para muchos lenguajes de programación y
plataformas de desarrollo.
Finalmente, su mayor aporte al mundo de la informática: “Extreme
Programming”, metodología de la cual hablaremos con mayor detalle posteriormente.
Descripción de la Metodología: XP detallado
Extreme Programming es una metodología ágil basada en cuatro principios:
simplicidad, comunicación, retroalimentación y valor.
Al hablar de simplicidad, nos referimos a la simplicidad aplicada a todos los
aspectos del proyecto, desde la forma de trabajar en sí, plasmada en los procesos y las
prácticas aplicadas al implementar las soluciones, así como a la simplicidad del código
que facilita su lectura, corrección y extensión entre los distintos programadores.
En cuanto a la comunicación, XP plantea que debe existir una comunicación
fluida entre todos los participantes del proyecto lo cual mejorará tantos los tiempos del
proyecto así como la calidad del producto.
Con respecto a la retroalimentación, XP nos dice que debe existir una
retroalimentación continua entre el cliente y el equipo de desarrollo, lo cual facilitará en
forma notable el trabajo y desarrollo del proyecto.
Extreme Programming es una metodología centrada en potenciar las relaciones
interpersonales como clave para el éxito en desarrollo de software, promoviendo el
trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y
propiciando un buen clima de trabajo.
15
XP se define como una metodología especialmente adecuada para proyectos en
donde los requisitos aún son muy ambiguos o imprecisos, cambian rápidamente, o
donde existe un alto riesgo técnico.
Los principios y prácticas son principios y prácticas de sentido común,
usualmente aplicados en numerosas metodologías, pero aquí se diferencian en que son
llevados al extremo, de ahí proviene su nombre “Extreme Programming”.
A continuación presentaremos las características esenciales de XP.
Actividades de Xp
La metodología cuenta con cuatro actividades básicas y esenciales: escuchar,
diseñar, codificar y hacer pruebas. A continuación se describen las mismas.
Escuchar
Beck menciona en una frase que los programadores no lo conocen todo, y sobre
todo desconocen muchas cosas que las personas de negocios piensan que son
interesantes.
Al realizar las pruebas sobre el sistema es necesario preguntar si los resultados
obtenidos son los deseados, es decir, se debe preguntar al cliente si era precisamente lo
obtenido lo que él estaba buscando por parte del software. Es necesario escuchar por
parte de los clientes cuáles son los problemas que presenta su negocio. Se debe tener
una escucha activa, explicando lo que es fácil y lo que es difícil de obtener a la hora de
desarrollar el sistema. La retroalimentación entre ambas partes (cliente y equipo de
desarrollo) será la que brindará la mayor ayuda a todos a la hora de entender los
problemas existentes a resolver. Es por ello que el equipo del proyecto debe estar
continuamente atento a lo que el cliente esta diciendo y debe hacerse escuchar por parte
del mismo a la hora de proponer nuevas soluciones.
Diseñar
El diseño moldea la estructura que ordenará la lógica de la aplicación. Un correcto
diseño brinda la posibilidad de que el sistema crezca con cambios en un solo lugar, lo
hace extensible y reutilizable. Los diseños deben de ser sencillos, si alguna parte del
sistema es de desarrollo complejo, lo apropiado es dividirla en varias partes. Si hay
fallas en el diseño o malos diseños, estas deben ser corregidas cuanto antes porque de lo
contrario se verán plasmadas en el producto disminuyendo su calidad o en ocasiones, no
cumpliendo los requerimientos para los cuales ha sido creado el producto.
Codificar
El proceso de codificación se basa en plasmar las ideas y funcionalidades del
16
sistema a través del código. En programación, el código expresa la interpretación del
problema en término de los programadores. De esta forma podemos utilizar el código
para comunicar, para hacer comunes las ideas y también para aprender y mejorar el
nivel de los mismos recursos involucrados en el desarrollo del proyecto. El código es el
idioma de comunicación de los programadores. Es por ellos que se recomienda que el
mismo sea sencillo y legible para todos los integrantes del equipo.
Hacer pruebas
Todas las características del software que muestran su correcto funcionamiento
deben ser demostradas mediante pruebas. Las pruebas brindan la oportunidad de saber
si lo implementado es lo que en verdad se tenía en mente por parte del cliente. Las
pruebas son las que nos indican que el trabajo, es decir el propio sistema se encuentra
funcionando en perfectas condiciones. Cuando no es posible pensar en ninguna prueba
que pueda originar una falla en el sistema, entonces se da por finalizado el proceso de
testing o prueba del sistema. Es importante destacar que a la hora de realizar las pruebas
es importante la objetividad de dichas pruebas y que las mismas sean realizadas desde el
punto de vista del usuario. Es por ello que es recomendable que no sean realizadas por
los mismos programadores. Recordemos que al hablar de pruebas en este apartado
hacemos referencia a pruebas de testeo posterior al desarrollo del código y no a las
pruebas unitarias realizadas previamente al desarrollo.
Resumiendo las actividades de Xp: Debe codificarse porque sin código no hay
programas, se deben hacer pruebas de testeo porque sin pruebas no es posible
determinar si se ha acabado de codificar, se debe escuchar, porque si no hay escucha no
existe forma de saber que codificar ni probar, y finalmente se tiene que diseñar para
poder codificar, probar y prestar una mejor atención para poder focalizar la escucha en
los puntos críticos o poco definidos del proyecto.
Proceso XP
Un proyecto XP tiene éxito cuando el equipo de desarrollo cumple con todos las
expectativas del cliente, es decir el producto final realiza todo aquello para lo que fue
pensado. Para poder llevar a cabo esto, el cliente debe seleccionar el valor de negocio a
implementar (funcionalidad) basándose en la habilidad del equipo para medir la
funcionalidad que puede entregar dentro de un determinado período de tiempo. Es decir,
el cliente prioriza las funcionalidades y las agrupa acorde a la capacidad del equipo y la
importancia que éstas poseen para él.
El ciclo de desarrollo de una iteración consiste (a grandes rasgos) en los siguientes
pasos:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las
restricciones de tiempo que presenta el equipo junto con el entorno de desarrollo.
4. El programador construye ese valor de negocio.
17
5. Se vuelve al paso 1.
En todos los “release” o iteraciones tanto el programador como el cliente
aprenden de sus errores. El desarrollador no debe ser presionado para hacer una mayor
cantidad de trabajo que la estimada previamente, ya que no sólo se perderá calidad en el
software o no se cumplirán los plazos; sino que también podría haber una
desmotivación en el mismo y su rendimiento en las próximas iteraciones podría llegar a
disminuir. De la misma forma el cliente tiene la obligación de manejar el ámbito de
entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio
posible con cada iteración.
Prácticas XP
Uno de los principales análisis que se realiza en XP es el estudio de la reducción
de los costos que acarrean los cambios a lo largo de todo el proyecto. Se trata de
llevarlos a valores de forma tal que el diseño evolutivo funcione óptimamente. XP
apuesta por un crecimiento lento del costo del cambio con un comportamiento
asintótico; es decir, trata de reducir los costos de la mayor forma posible hasta llevarlos
a su valor mínimo y que estos permanezcan constantes en dicho valor. Esto es posible
de conseguir gracias a las tecnologías disponibles para ayudar en el desarrollo de
software y a la aplicación disciplinada de las prácticas que describiremos a
continuación.
El juego de la planificación
Es un espacio frecuente de comunicación entre el cliente y los programadores. El
equipo técnico realiza una estimación del esfuerzo requerido para la implementación de
las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y
de cada iteración. Esta práctica se puede ilustrar como un juego, donde existen dos tipos
de jugadores: Cliente y Programador. El cliente establece la prioridad de cada historia
de usuario, de acuerdo con el valor que aporta para el negocio. Los programadores
estiman el esfuerzo asociado a cada historia de usuario. Se ordenan las historias de
usuario según prioridad y esfuerzo, y se define el contenido de la entrega y/o iteración,
apostando por enfrentar lo de más valor y riesgo cuanto antes. Este juego se realiza
durante la planificación de la entrega, en la planificación de cada iteración y cuando sea
necesario reconducir el proyecto.
Entregas pequeñas
La idea es producir rápidamente versiones del sistema que sean operativas,
aunque obviamente no cuenten con toda la funcionalidad pretendida para el sistema
pero si que constituyan un resultado de valor para el negocio. Una entrega no debería
tardar más 3 meses.
18
Metáfora
En XP no se enfatiza la definición temprana de una arquitectura estable para el
sistema. Dicha arquitectura se asume en forma evolutiva. Los posibles inconvenientes
que se generarán por no contar con ella explícitamente en el comienzo del proyecto se
solventan con la existencia de una metáfora. El sistema es definido mediante una
metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de
desarrollo. Una metáfora es una historia compartida que describe cómo debería
funcionar el sistema. Martín Fowler18 explica que la práctica de la metáfora consiste en
formar un conjunto de nombres que actúen como vocabulario para hablar sobre el
dominio del problema. Este conjunto de nombres ayuda a la nomenclatura de clases y
métodos del sistema. Esta práctica simplemente nos dice que a la hora de abordar un
problema complejo, debemos atacar al mismo estableciendo una analogía entre dicha
problemática y una historia o situación que nos permita visualizarla y resolverla con una
mayor facilidad.
Diseño simple
“Se debe diseñar la solución más simple que pueda funcionar y ser implementada
en un momento determinado del proyecto. La complejidad innecesaria y el código extra
debe ser removido inmediatamente. Kent Beck dice que en cualquier momento el diseño
adecuado para el software es aquel que: supera con éxito todas las pruebas, no tiene
lógica duplicada, refleja claramente la intención de implementación de los
programadores y tiene el menor número posible de clases y métodos”. 19
Pruebas
La producción de código está dirigida por las pruebas unitarias. Las pruebas
unitarias son establecidas antes de escribir el código y son ejecutadas constantemente
ante cada modificación del sistema. Los clientes escriben las pruebas funcionales para
cada historia de usuario que deba validarse. En este contexto de desarrollo evolutivo y
de énfasis en pruebas constantes, la automatización para apoyar esta actividad es
crucial.
Refactorización (Refactoring)
La refactorización es una actividad constante de reestructuración del código con el
objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y
hacerlo más flexible para facilitar los posteriores cambios. La refactorización mejora la
estructura interna del código sin alterar su comportamiento externo. Robert Martín20
señala que el diseño del sistema de software es una cosa viviente. No se puede imponer
todo en un inicio, pero en el transcurso del tiempo este diseño evoluciona conforme
18
http://martinfowler.com/
http://www.cyta.com.ar/ta0502/v5n2a1.htm
20
http://www.objectmentor.com/omTeam/martin_r.html
19
19
cambia la funcionalidad del sistema. Para mantener un diseño apropiado, es necesario
realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.
De hecho, este cuidado continuo sobre el diseño es incluso más importante que el
diseño inicial. Un concepto pobre al inicio puede ser corregido con esta actividad
continua, pero sin ella, un buen diseño inicial se degradará.
Programación en parejas
Toda la producción de código debe realizarse con trabajo en parejas de
programadores.
Las principales ventajas de introducir este estilo de programación son:
- Una gran cantidad de errores son detectados conforme son introducidos los
distintos módulos desarrollados. Se realizan inspecciones de código continuas,
por consiguiente la tasa de errores del producto final es más baja.
- Los diseños son mejores y el tamaño del código es menor (continua discusión de
ideas de los programadores).
- Los problemas de programación se resuelven más rápidamente.
- Se posibilita la transferencia de conocimientos de programación entre los
miembros del equipo.
- Varias personas entienden las diferentes partes sistema
- Los programadores conversan mejorando así el flujo de la información y la
dinámica del equipo.
- Los programadores disfrutan más su trabajo.
Dichos beneficios se consiguen después de varios meses de practicar la
programación en parejas. Se estima que este lapso de tiempo varía de 3 a 4 meses.
Propiedad colectiva del código
Esta práctica establece que cualquier programador puede tener acceso y cambiar
cualquier parte del código en cualquier momento que así lo desee. Esta práctica motiva
a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la
vez que algún programador sea imprescindible para realizar cambios en alguna porción
de código.
Integración continua
Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el
sistema puede llegar a ser integrado y construido varias veces en un mismo día. Todas
las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea
incorporado definitivamente. La integración continua a menudo reduce la
fragmentación de los esfuerzos de los desarrolladores por falta de comunicación sobre
lo que puede ser reutilizado o compartido. Varios expertos de la informática afirman
que el desarrollo de un proceso disciplinado y automatizado es esencial para un
proyecto controlado. De esta forma, el equipo de desarrollo está más preparado para
20
modificar el código cuando sea necesario debido a la confianza en la identificación y
corrección de los errores de integración.
40 horas por semana
Esta práctica establece que se debe trabajar un máximo de 40 horas por semana.
No se deben asimismo trabajar horas extras en dos semanas seguidas. Si esto ocurre,
probablemente está ocurriendo un problema que debe corregirse. El trabajo extra
desmotiva al equipo. Los proyectos que requieren trabajo extra para intentar cumplir
con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede
realizar el juego de la planificación para cambiar el ámbito del proyecto o la fecha de
entrega.
Cliente on-site
En esta práctica se establece que el cliente debe estar presente y disponible en
todo momento para el equipo de desarrollo. Gran parte del éxito del proyecto XP se
debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportará
mayor valor de negocio y de esta forma, los programadores pueden resolver de manera
inmediata cualquier duda asociada. La comunicación oral es más efectiva que la escrita,
ya que esta última toma mucho tiempo en generarse y puede tener más riesgo de ser mal
interpretada. En caso de que el cliente no cuente con dicha disponibilidad necesaria, se
recomienda lo siguiente: intentar conseguir un representante que pueda estar siempre
disponible y que actúe como interlocutor del cliente, contar con el cliente al menos en
las reuniones de planificación, establecer visitas frecuentes de los programadores al
cliente para validar el sistema, anticiparse a los problemas asociados estableciendo
llamadas telefónicas frecuentes y conferencias reforzando el compromiso de trabajo en
equipo.
Estándares de programación
XP enfatiza la comunicación de los programadores a través del código, con lo cual
es indispensable que se sigan ciertos estándares de programación (del equipo, de la
organización u otros estándares reconocidos para los lenguajes de programación
utilizados). Los estándares de programación mantienen el código legible para los
miembros del equipo, facilitando los cambios.
Comentarios respecto de las prácticas
El mayor beneficio de las prácticas se consigue con su aplicación conjunta y
equilibrada puesto que se apoyan unas en otras.
La mayoría de las prácticas propuestas por XP no son novedosas sino que en
alguna forma ya habían sido propuestas en ingeniería del software e incluso demostrado
su valor en la práctica. El mérito de XP es integrarlas de una forma efectiva y
complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos
21
y el trabajo en equipo.
A continuación se presenta un gráfico que muestra como funciona el circuito de
una iteración así como el refuerzo que ejercen las prácticas entre sí.
21
Figura 5 - Interacción entre las prácticas de XP
Inicialmente se realiza un “Release Plan” el cual esta determinado por la
cantidad de “User stories” que integrarán la iteración. Éste junto con las fallas
encontradas y el proyecto de velocidad de la próxima iteración se integran para
confeccionar el Plan de Iteración. Recordemos que en el caso de la primera iteración las
fallas encontradas y el plan de la próxima iteración serán vacíos. Una vez finalizado el
plan de iteración se procede a desarrollar las funcionalidades o “user stories”
establecidas para dicha iteración. Así se obtiene la primera versión de la aplicación.
Luego se testea el trabajo realizado y se documentan las fallas encontradas y se reinicia
el proceso entero con los problemas a resolver (Bugs), nuevas funcionalidades y se
guardan las tareas no completadas para la instancia de la planificación de Plan.
21
http://www.extremeprogramming.org/
22
Artefactos XP
Las Historias de Usuario
Las historias de usuario son la técnica utilizada en XP para especificar los
requisitos del software. Estas constituyen el artefacto más importante de XP. Se trata de
tarjetas de papel en las cuales el cliente describe brevemente las características que el
sistema debe poseer, sean requisitos funcionales o no funcionales.
El tratamiento de las historias de usuario es muy dinámico y flexible, en cualquier
momento del proyecto las historias de usuario pueden romperse en varias historias de
usuario, reemplazarse por otras más específicas o generales, añadirse nuevas o ser
modificadas. Cada historia de usuario es lo suficientemente comprensible y delimitada
para que los programadores puedan implementarla en solo unas semanas.
Respecto de la información contenida en la historia de usuario, existen varias
plantillas sugeridas pero no existe un consenso al respecto. En muchos casos sólo se
propone utilizar un nombre y una descripción o sólo una descripción, más quizás una
estimación de esfuerzo en días. Beck en su libro presenta un ejemplo de ficha (customer
story and task card) en la cual pueden reconocerse los siguientes contenidos: fecha, tipo
de actividad (nueva, corrección, mejora), prueba funcional, número de historia,
prioridad técnica y del cliente, referencia a otra historia previa, riesgo, estimación
técnica, descripción, notas y una lista de seguimiento con la fecha, estado de cosas por
terminar y comentarios.
Una de los interrogantes (que también se presenta cuando se utilizan casos de uso)
es: ¿Cuál es el nivel de granularidad adecuado para una historia de usuario?
Desafortunadamente no existe una respuesta tajante a este interrogante. Jeffries dice que
depende de la complejidad del sistema aunque establece que debe haber al menos una
historia por cada característica importante del mismo, y propone realizar una o dos
historias por programador en un período de un mes. Si se tienen menos, probablemente
sea conveniente dividir las historias en varias; si se tienen más, por el contrario, lo
mejor es disminuir el detalle y agruparlas. Para efectos de planificación, las historias
pueden ser de una a tres semanas en tiempo de programación (para no superar el
tamaño de una iteración, recordemos que en XP las iteraciones son de corta duración).
No hay que preocuparse si en un principio no se identifican todas las historias de
usuario. Al comienzo de cada iteración estarán registrados los cambios en las historias
de usuario y según eso se planificará la siguiente iteración.
Las historias de usuario son descompuestas en tareas de programación y asignadas
a los programadores para ser implementadas durante una iteración.
Task Cards
Como hemos mencionado anteriormente las historias de usuario se encuentran
compuestas por distintas tareas. Para brindar información acerca de las mismas, se
utilizan las denominadas “Task Cards”.Si bien tampoco existe una plantilla o template
específico para las mismas se recomiendan que contengan la siguiente información: el
numero de tarea, la historia de usuario a la que hacen referencia, el nombre de la tarea,
el tipo de tarea (si es de desarrollo, de corrección, de mejora, o algún otro tipo de tarea
específico), los puntos estimados, una fecha de inicio, una fecha de finalización, el
23
programador responsable de ella, y una breve descripción de la tarea (en que consiste la
misma).
CRC Card
Estas tarjetas pueden ser también denominadas: tarjetas de clase-responsabilidadcolaboración. Estas tarjetas se dividen en tres secciones que contienen la información
del nombre de la clase, sus responsabilidades y sus colaboradores.
Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las
responsabilidades de una clase son las cosas que conoce y las que realiza, 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 siguiente
pregunta: ¿Qué sabe la clase? y ¿Qué hace o como queremos que se comporte la clase?
Finalmente se buscan los colaboradores dentro de la lista de clases que se tenga es decir
quienes queremos que interactúen con cada clase.
Roles XP
Según Kent Beck existen los siguientes distintos roles involucrados en un
desarrollo basado en la metodología extreme programming:
Programador
El programador es el encargado de escribir las pruebas unitarias y producir el
código de la aplicación. El código debe ser legible por los distintos programadores del
equipo y es recomendable una buena comunicación, coordinación y colaboración entre
24
los distintos programadores y los otros miembros del equipo.
Cliente
El cliente es el encargado de escribir las historias de usuario y las pruebas
funcionales para validar su implementación. Además, es quien prioriza las historias de
usuario y decide cuáles han de ser implementadas en cada una de las iteraciones
centrándose en el mayor valor que éstas le brindan al negocio. Al hablar de cliente
hacemos referencia al cliente propiamente dicho o a su representante en aquellos casos
que el propio cliente no pueda realizar dichas tareas.
Encargado de pruebas (Tester)
Los “testers” son aquellos que colaboran con el cliente para escribir las pruebas
funcionales, ejecuta las pruebas regularmente, difunde los resultados obtenidos por
dichas pruebas con el equipo y en ocasiones toma las decisiones de las herramientas que
se utilizarán para realizar las pruebas de la aplicación.
Encargado de seguimiento (Tracker)
El tracker es el encargado de verificar el cumplimiento o grado de acierto entre las
estimaciones realizadas y el tiempo real dedicado al proyecto. Él es quien comunica los
resultados al resto del equipo para que luego los mismos puedan mejorar las futuras
estimaciones. También realiza el seguimiento del progreso de cada iteración y evalúa si
los objetivos son alcanzables con las restricciones de tiempo y recursos con los que se
cuenta. El es el que estará a cargo de la determinación de si es necesario realizar algún
cambio general en el ambiente para lograr los objetivos planteados de cada iteración por
parte el equipo.
Entrenador (Coach)
Es “coach” es el responsable del proceso global. Es quien posee mayores
conocimientos sobre el proceso de la metodología (extreme programming) y quien
provee las guías a los miembros del equipo de forma que se apliquen correctamente
todas las prácticas XP y se siga el proceso adecuadamente.
25
Consultor
El consultor es un miembro externo del equipo con un conocimiento específico en
algún tema necesario para el proyecto. Guía al equipo para resolver un problema
específico. Los consultores son llamados en ocasiones especiales donde existe alguna
problemática (ya sea técnica o de lógica del negocio) que el equipo no puede resolver.
Gestor (“Big boss”)
El “Big boss” es el intermediario entre el cliente y los programadores, ayuda a que
el equipo trabaje efectivamente creando las condiciones adecuadas para esto. Su labor
esencial es de coordinación.
Casos de estudio en los que se utilizo “Extreme Programming”
A continuación se presentan algunos casos de estudio en los que se ha utilizado la
metodología. Los mismos atacan distintas problemáticas que se dan normalmente en un
proyecto de desarrollo de software. Estos artículos han sido seleccionados por la
magnitud de la problemática que atacaban y por la importancia que aportaban para el
análisis de la implementación de la metodología XP a la materia Laboratorio III de la
universidad.
The impact of Agile Methods on Software Project Management
(El impacto de los métodos ágiles en la gestión de proyectos)
Tema principal: Este artículo trata sobre el estudio de los distintos factores:
personas, proyecto y proceso, para evaluar la conveniencia de la utilización de XP como
metodología de desarrollo considerando el impacto que la misma metodología podría
provocar en el management o gestión de un proyecto.
Para realizar dicho estudio se han tenido en cuenta también los requerimientos,
staff y factores externos (propios del negocio) para evaluar estas cuestiones.
Que nos dice: En este artículo se establece que con respecto al personal
involucrado en el proyecto:
Desarrolladores: Pueden no adaptarse al ambiente agile lo cual influye notablemente en
su rendimiento a la hora de desempeñar sus tareas. Esto se debe a que la falta
documentación complica el trabajo.
Testers: El testing debe ser automatizado entonces requiere de una skill o habilidad
nueva por parte del tester(un conocimiento mínimo en lo que es codificación).
Poject leaders: Los líderes del proyecto deben integrar al equipo en la toma de
decisiones.
Managers: Tener una mayor relación con el cliente, indicar el avance del proyecto.
Customers: El cliente debe tener un mayor compromiso con el proyecto y su desarrollo.
Debe tener compromiso, conocimiento, colaborar, debe ser representativo y con poder
26
suficiente.
Excecutive Management: La estimación de costos es compleja, no se puede garantizar
las fechas de entrega, y en ocasiones las funcionalidades.
Con respecto a los procesos estable:
Planning: Es muy complejo planear, suele hacerse ligeramente y en el momento Ej.:
reuniones de scrum.
Documentación: Escasa para ahorrar esfuerzo. Información es comunicada
informalmente. Luego se complica también el mantenimiento.
Development Process: Principios ágiles fuerzan a cambiar varios procesos
(refactorización, reviews, etc.)
Con respecto al proyecto, establece que la metodología está orientada a proyectos con
requerimientos “ligeros” es recomendable utilizar la metodología.
Conclusiones: En conclusión, las metodologías ágiles ofrecen un razonable ajuste
para el alto nivel de cambio que posee todo proyecto, mas precisamente para la
incertidumbre que puede presentarse en el mismo. Existen algunos principios que
utilizados en las correctas circunstancias, reducen notablemente el riesgo en el proyecto
y brindan una mayor productividad y calidad al mismo tiempo. Sin embargo las
metodologías ágiles no son apropiadas para todo tipo de proyectos. Un líder de proyecto
debe tener en cuenta las características del mismo para asegurar que una metodología
ágil sea indicada para el mismo. Los impactos de la utilización de la misma en la gente,
los procesos y el proyecto deben ser considerados y analizados de antemano.
On the effectiveness of pair programming
(Sobre la efectividad de la programación en parejas)
Tema principal: En este artículo se estudia la efectividad de la programación de a
pares desde el punto de vista de la duración del proyecto, el tiempo, el esfuerzo y la
calidad del producto.
Que nos dice: El estudio muestra que gracias a la programación de a pares, en
varios casos, se alcanza a producir más en la mitad del tiempo. También muestra que los
programadores están más contentos, y mejora el trabajo en equipo, el conocimiento del
equipo es mayor y la transferencia de conocimientos crece notablemente.
Conclusión: Como conclusión, el caso de estudio muestra que a la hora de
analizar si la programación de a pares es indicada o no, la respuesta es “Depende”.
Debe tenerse en cuenta la experiencia de los programadores tanto como la
complejidad del sistema y las tareas a desarrollar.
Investigating the impact of Personality Types on Comunnication and
collaboration viability in Pair Programming - an empirical study
(Investigando el impacto de los tipos de personalidad en la comunicación y colaboración en la
Programación de a pares – Un caso de estudio empírico)
Tema principal: El articulo trata de 2 experimentos controlados que investigan
el impacto de la personalidad y el temperamento de los desarrolladores en la
27
comunicación, colaboración, y efectividad de un par dentro de un equipo.
El estudio esta basado en experimentos que cuenta con dos pares de
programadores: uno de personalidades diferentes y otro con personalidades similares.
Lo que se evaluara es la efectividad en cuanto a performance medida con
comunicación, velocidad, productividad y satisfacción del cliente y la elaboración
medida por la satisfacción de los desarrolladores, conocimientos adquiridos y
participación.
Se plantea la hipótesis de que la personalidad no afectará el rendimiento de las
parejas.
Que nos dice: Las estadísticas mostraron que el rendimiento no solo es
afectado por la formación de las parejas sino que el rendimiento del equipo formado por
desarrolladores de personalidades con más diferencias, era mayor al equipo compuesto
por programadores con personalidades similares.
La comunicación es mayor y por ende el intercambio de información también.
Esto acarrea como consecuencia un mayor rendimiento y comprensión entre los
desarrolladores que se ve plasmado en el producto final y la calidad del mismo.
Conclusión: Basándonos en los resultados obtenidos, podemos decir que una
buena práctica para las compañías sería la de evaluar la personalidad de los
desarrolladores a la hora de formar un equipo para aumentar su productividad y de esta
forma tener un revenuew (o beneficio) mayor formando parejas con recursos de
personalidades distintas entre sí.
Introducing Agile Methods: Three years of experience
(Introduciendo los métodos ágiles: Tres años de experiencia)
Tema principal: Este artículo trata de un estudio de 3 años de experiencia
trabajando con metodologías ágiles en ámbitos académicos. Su objetivo es evaluar cual
es el punto de vista de los estudiantes y como éste varía acorde al curso al que ellos
asisten. Se evalúan estudiantes de distintos niveles y cursos diferentes de distintas
universidades.
Se les realiza una encuesta de 20 preguntas entre otras acerca de si se han sentido
cómodos utilizando xp como metodología de desarrollo, si lo recomendarían a su
compañía en el caso de aquellos alumnos que poseen un trabajo, si consideran que la
utilización de xp mejora la productividad y otros aspectos del proceso de desarrollo del
proyecto.
Estas preguntas son realizadas al finalizar el curso y con ellas se sacan
posteriormente las estadísticas que permiten así alcanzar una conclusión.
Que nos dice: El estudio concluye con la observación de que los estudiantes se
han mostrado no solo interesados en la metodología, sino que con un alto agrado al
introducir metodologías ágiles a los cursos y no se observaron notables diferencias entre
lo percibido por los estudiantes de distintos niveles. Asimismo se recomienda
capacitarse y utilizar metodologías ágiles en los cursos para una mejor incorporación de
los estudiantes universitarios en la industria del software.
Conclusión: Según lo visto en este artículo podemos animarnos a decir que
sería una buena práctica la introducción de xp en el ámbito académico ya que los
28
alumnos se mostrarían contentos ante dicho suceso y a la vez contarían con
conocimientos sobre una metodología que de a poco va tomando un importante espacio
en la industria laboral en la que el día de mañana formarán parte.
Extreme Programming from a CMM perspective
(Extreme programming desde una perspective CMM)
Tema principal: El articulo resume la mitología entre XP y SW-CMM
(Software capability maturity model), muestra como XP puede ayudar a las
organizaciones a alcanzar las metas de SW-CMM y luego critica XP desde la
perspectiva CMM.
Que nos dice: El artículo comienza detallando las distintas prácticas y
conceptos de ambos metodologías: XP y CMM. Luego de un detallado análisis
concluye con la señalización de que XP se centra mas en el trabajo técnico y no tanto en
el management, diseño, arquitectura y los riesgos del sistema a nivel general como lo
hace CMM.
Conclusión: Teniendo en cuenta lo señalado por el artículo puede decirse que
extreme programming y SW-CMM se complementan ya que resumiendo, CMM le dice
a la organización que es lo que necesita hacer y XP le dice la forma en la que debe
llevar a cabo aquello que debe hacer, es decir el “como”, siempre teniendo siempre en
cuenta los entornos en los que se trabajará durante el desarrollo del proyecto.
Extreme programming in reducing the rework of requirement change
(Extreme Programming en la reducción del retrabajo de cambio de requerimientos)
Tema principal: Este artículo trata sobre un estudio basado en el análisis de la
reducción del retrabajo o “rework” que los cambios de requerimientos acarean consigo
teniendo siempre en cuenta que estos son inevitables en todo proyecto.
Que nos dice: Una de las principales cláusulas de xp sugiere que se trabaje con
un cliente on-site, lo cual brinda la ventaja de poder reducir el trabajo de los cambios de
requerimientos notablemente.
Este cliente on-site puede predecir a grandes rasgos cuales podrían llegar a ser los
cambios de requerimientos y el trabajo que ellos traerían desde una perspectiva basada
en la lógica del negocio
Los costos de los cambios de requerimientos tienden a incrementarse a lo largo
del ciclo de vida del proyecto (de manera exponencial).
Conclusión: Teniendo en cuenta lo expuesto en el artículo podemos decir que
como el cambio de requerimientos es inevitable, es muy importante tenerlo en cuenta.
La utilización de XP y sus practicas reducen notablemente la cantidad de rework y es
por ello que deben ser consideradas como buenas practicas de desarrollo porque están
enfocadas principalmente en la satisfacción del cliente y poseen una notable flexibilidad
para los cambios que dicho cliente plantea a lo largo del proyecto.
Extreme Programming ha demostrado ser una metodología eficiente, flexible y
desafiante no por sus prácticas, sino por la integración que propone entre ellas. Es una
29
metodología relativamente joven que va ganando mercado día a día y es por ello que
debe ser tenida en cuenta no sólo en la industria laboral sino también en el ámbito
académico. Como toda metodología “nueva” debe ser manejada con cuidado ya que,
como es natural, siempre existirán aquellos que se resistirán al cambio y aquellos que lo
acogerán con gran entusiasmo.
Sin embargo, teniendo en cuenta los artículos analizados, deben considerarse
varios factores a la hora de decidir si es correcto o no implementar xp como
metodología de desarrollo en un proyecto. Deben analizarse los aspectos técnicos como
la naturaleza, complejidad y extensión del proyecto así como los recursos o personas
que integrarán el equipo de desarrollo.
30
Bibliografía
Agile Alliance website: http://www.agilealliance.org
http://c2.com/cgi/wiki?ExtremeProgramming
http://www.extremeprogramming.org/rules/iterative.html
Kent Beck.Extreme Programming Explained. Embrace Change.pdf
Kent Beck and Martin Fowler. Planning Extreme Programming.pdf
Patricio Letelier, Departamento de Sistemas Informáticos y Computación, Universidad
Politécnica de Valencia, letelier[arroba]dsic.upv.es
Manifiesto para el Desarrollo de Software Ágil, http://www.agilemanifesto.org
Martín Fowler. La Nueva Metodología: http://www.programacion.net
Alistair, Desarrollo de Software Ágil,
http://www.amazon.com/exec/obidos/ASIN/0201699699/programacione-20
Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El Proceso Unificado de Desarrollo
de Software.
http://es.wikipedia.org/wiki/Proceso_Unificado
http://www.dybox.cl/metodologia/rup.html. (2/5/05)
Anónimo. Seminario sobre RUP en un entorno empresarial de desarrollo. http://www5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)/RUPS1ES. (2/5/05)
Kruchten, Philippe. The Rational Unified Process: An Introduction, 3rd edition.
Addison Wesley. December 2003.
Larman, Craig. Agile and Iterative Development: A Manager’s guide. Addison Wesley,
2003.
http://www.cyta.com.ar/ta0502/v5n2a1.htm
http://www.slideshare.net/fmmeson/metogologias-de-desarrollo-de-softwaretradicionales-vs-agiles
http://www.qualitrain.com.mx/index.php/Procesos-de-software/Evolucion-de-losprocesos-de-desarrollo-Primera-parrte.html
31
Michael Coram and Shawn Bohner. The Impact of Agile Methods on Software Project
Management. Department of Computer Science , Virginia Polytechnical Institute and
State University ,Blacksburg, Virginia 24061.
Tore Dyba, Erik Arisholm, Dag I.K. Sjoberg, Jo E. Hannay, and Forrest Shull. On the
Effectiveness of Pair Programming.
Panagiotis Sfetsos, Ioannis Stamelos, Lefteris Angelis and Ignatios Deligiannis.
Investigating the impact of Personality Types on Comunnication and collaboration
viability in Pair Programming - an empirical study. Department of Information
Technology, Thessaloniki, Greece.
Grigori Melnik, Frank Maurer .Introducing Agile Methods: Three Years of Experience.
Department of Computer Science,University of Calgary 2500 University Dr. N.W.,
Calgary, Alberta, T2N 1N4, Canada.
Mark C. Paulk. Extreme Programming from a CMM Perspectiva. Software Engineering
Institute.
Xu Bin, Yang Xiaohu, He Zhijun. EXTREME PROGRAMMING IN REDUCING THE
REWORK OF REQUIREMENT CHANGE. College of Computer Science &
Technology, Zhejiang Univ. 310027 Hangzhou, P. R. China
32
Glosario
Proceso de desarrollo: Es el conjunto de técnicas y procedimientos que nos permiten
conocer los elementos necesarios para definir un proyecto de software.
Release / iteración: Es una versión del producto que cumple con determinados
requerimientos.
Software: Es el conjunto de los programas de cómputo, procedimientos, reglas,
documentación y datos asociados que forman parte de las operaciones de un sistema de
computación.
Seniority: Nivel de experiencia y conocimientos de un recurso en un proyecto de
desarrollo. La misma puede ser Junior, Semi Sr. o Senior.
Refactorización: es una técnica de la ingeniería de software para reestructurar un código
fuente, alterando su estructura interna sin cambiar su comportamiento externo.
Rework: (o “retrabado”) es el trabajo excedente que debe realizarse en un proceso de
desarrollo.
Artefacto: producto tangible resultante del proceso de desarrollo de software. Algunos
artefactos como los casos de uso, diagrama de clases u otros modelos UML ayudan a la
descripción de la función, la arquitectura o el diseño del software.
Ad hoc: locución latina que significa literalmente «para esto». Generalmente se refiere a
una solución elaborada específicamente para un problema o fin preciso y, por tanto, no
es generalizable ni utilizable para otros propósitos.
Metodología RAD: (Desarrollo rápido de aplicaciones) Proceso de desarrollo de
software que permite construir sistemas utilizables en poco tiempo.
Model-Based Architecture and Software Engineering: Proceso de desarrollo ideado por
Barry Boehm y Dan Port en la década del 90. El mismo se enfoca principalmente en el
aseguramiento de la consistencia y el refuerzo de los modelos de producto, procesos,
propiedades y éxito del proyecto.
Método de desarrollo de sistemas dinámicos (DSDM): es un método que provee un
framework para el desarrollo ágil de software, apoyado por su continua implicación del
usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos
cambiantes, para desarrollar un sistema que reúna las necesidades de la empresa en
tiempo y presupuesto. Es uno de los tantos métodos de desarrollo ágil de software y
forma parte de la conocida alianza ágil.
33