METODOLOGIAS DE DESARROLLO DE
SOFTWARE
en ingeniería
de software es un marco de trabajo usado para estructurar,
planificar y controlar el proceso de desarrollo en sistemas de información.
Una metodología de desarrollo de
software se refiere a un framework que es usado para estructurar, planear y
controlar el proceso de desarrollo en sistemas de información.
A lo largo del tiempo, una gran cantidad
de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.
El framework para metodología de desarrollo de software consiste en:
·
Una filosofía de desarrollo de programas de
computación con el enfoque del proceso de desarrollo
de software
·
Herramientas, modelos y métodos para asistir al proceso de desarrollo de
software
Estos frameworks son a menudo vinculados a algún tipo de organización, que además
desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo
documentada en algún tipo de documentación formal.
Es una metodología cuyo fin es entregar un producto de software. Se estructura
todos los procesos y se mide la eficiencia de la organización.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado
de modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.
El RUP es un conjunto de metodologías adaptables al contexto y necesidades de
cada organización.
Describe como aplicar enfoques para el desarrollo del software, llevando a cabo
unos pasos para su realización.
Se centra en la producción y mantenimiento de modelos del sistema.
Principales características
·
Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,
cuándo y cómo)
·
Pretende implementar las mejores prácticas en Ingeniería de Software
·
Desarrollo iterativo
·
Administración de requisitos
·
Uso de arquitectura basada en componentes
·
Control de cambios
·
Modelado visual del software
·
Verificación de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e
incremental, estar centrado en la arquitectura y guiado por los casos de uso.
Incluye artefactos (que son los productos tangibles del proceso como por
ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que
desempeña una persona en un determinado momento, una persona puede desempeñar
distintos roles a lo largo del proceso).
Esfuerzo en actividades según fase del
proyecto
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue
creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida
organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en número variable según el proyecto y en las que se hace un mayor
o menor hincapié en las distintas actividades.
Fases del ciclo de vida del RUP:
1. Fase de Inicio: Esta fase tiene como
propósito definir y acordar el alcance del proyecto con los patrocinadores,
identificar los riesgos asociados al proyecto, proponer una visión muy general
de la arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.
2. Fase de elaboración: En la fase de elaboración
se seleccionan los casos de uso que permiten definir la arquitectura base del
sistema y se desarrollaran en esta fase, se realiza la especificación de los
casos de uso seleccionados y el primer análisis del dominio del problema, se
diseña la solución preliminar.
3. Fase de Desarrollo: El propósito de esta
fase es completar la funcionalidad del sistema, para ello se deben clarificar
los requerimientos pendientes, administrar los cambios de acuerdo a las
evaluaciones realizados por los usuarios y se realizan las mejoras para el
proyecto.
4. Fase de Cierre: El propósito de esta
fase es asegurar que el software esté disponible para los usuarios finales,
ajustar los errores y defectos encontrados en las pruebas de aceptación,
capacitar a los usuarios y proveer el soporte técnico necesario. Se debe
verificar que el producto cumpla con las especificaciones entregadas por las
personas involucradas en el proyecto.
La metodología RUP tiene 6 principios clave:
1. Adaptación del proceso: El proceso debe
adaptarse a las características de la organización para la que se está
desarrollando el software.
2. Balancear prioridades: Debe encontrarse un
balance que satisfaga a todos los inversores del proyecto.
3. Colaboración entre equipos: Debe haber una
comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones,
planes, resultados, entre otros.
4. Demostrar valor iterativamente: Los proyectos se
entregan, aunque sea de una forma interna, en etapas iteradas. En cada
iteración se evaluará la calidad y estabilidad del producto y analizará la
opinión y sugerencias de losinversores.
5. Elevar el nivel de abstracción: Motivar el uso de de
conceptos reutilizables.
6. Enfocarse en la calidad: La calidad del producto
debe verificarse en cada aspecto de la producción.
Disciplina de desarrollo de RUP
Determina las etapas a realizar durante el proyecto de creación del software.
·
Ingeniería o modelado del negocio: Analizar y entender las necesidades del negocio para el cual se está
desarrollando el software.
·
Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del
sistema.
·
Análisis y diseño: Trasladar los requisitos analizados anteriormente a un sistema automatizado
y desarrollar una arquitectura para el sistema.
·
Implementación: Crear software que se ajuste a la arquitectura diseñada y que tenga el
comportamiento deseado.
·
Pruebas: Asegurarse de que el comportamiento
requerido es correcto y que todo lo solicitado está presente.
·
Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.
Disciplina de soporte RUP
Determina la documentación que es necesaria realizar durante el proyecto.
·
Configuración y administración del cambio: Guardar todas las
versiones del proyecto.
·
Administración del proyecto: Administrar los
horarios y recursos que se deben de emplear.
·
Ambiente: Administrar el ambiente de desarrollo
del software.
·
Distribución: Hacer todo lo
necesario para la salida del proyecto.
Elementos del RUP
·
Actividades: Procesos que se han de
realizar en cada etapa/iteración.
·
Trabajadores: Personas involucradas
en cada actividad del proyecto.
·
Artefactos: Herramientas empleadas
para el desarrollo del proyecto. Puede ser un documento, un modelo, un elemento
del modelo.
RUP en cada una de sus fases (pertenecientes a la estructura estática)
realiza una serie de artefactos que sirven para comprender mejor tanto el
análisis como el diseño del sistema (entre otros). Estos artefactos (entre
otros) son los siguientes:
Inicio:
·
Documento Visión
·
Especificación de Requerimientos
Elaboración:
·
Diagramas de caso de uso
Construcción:
·
Documento Arquitectura que trabaja con las siguientes vistas:
VISTA LOGICA:
·
Diagrama de clases
·
Modelo E-R (Si el sistema así lo requiere)
VISTA DE IMPLEMENTACION:
·
Diagrama de Secuencia
·
Diagrama de estados
·
Diagrama de Colaboración
VISTA CONCEPTUAL
·
Modelo de dominio
VISTA FISICA
·
Mapa de comportamiento a nivel de hardware
METODOLOGÍA
SCRUM
Scrum es una metodología ágil de desarrollo, aunque
surgió como modelo para el desarrollo de productos tecnológicos, 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.
Es una
metodología de desarrollo muy simple, que requiere trabajo duro porque no se
basa en el seguimiento de un plan, sino en la adaptación continua a las
circunstancias de la evolución del proyecto.
Scrum es una metodología ágil, y como tal, Es un modo
de desarrollo de carácter adaptable más que predictivo.
Orientado a las personas más que a los procesos.
·
Emplea la estructura de desarrollo ágil:
incremental basada en iteraciones y revisiones.
Se
comienza con la visión general del producto, especificando y dando detalle a
las funcionalidades o partes que tienen mayor prioridad de desarrollo y que
pueden llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días).
Cada uno de estos periodos de desarrollo es una
iteración que finaliza con la producción de un incremento operativo del
producto.
Estas iteraciones son la base del desarrollo
ágil, y Scrum gestiona su evolución a través de reuniones breves diarias en las
que todo el equipo revisa el trabajo realizado el día anterior y el previsto
para el día siguiente.
Estructura central de Scrum
Características
·
Equipos autodirigidos
·
Utiliza reglas para crear un
entorno ágil de administración de proyectos
·
No prescribe prácticas
específicas de ingeniería
·
Los requerimientos se
capturan como ítems de la lista Product Backlog.
·
El producto se construye en
una serie de Sprints de un mes de duración.
Herramientas y Prácticas
Scrum
no requiere ni provee prácticas de Ingeniería. En lugar de eso, especifica
prácticas y herramientas de gerencia que se aplican en sus distintas fases para
evitar el caos originado
por la complejidad e imposibilidad de realizar predicciones.
Product Backlog List
Es una lista priorizada que define el
trabajo que se va a realizar en el proyecto. Cuando un proyecto comienza es muy
difícil tener claro todos los requerimientos sobre el producto. Sin embargo,
suelen surgir los más importantes que casi siempre son más que suficientes para
un Sprint.
El objetivo es asegurar que el producto
definido al terminar la lista es el más correcto, útil y competitivo posible y
para esto la lista debe acompañar los cambios en el entorno y el producto.
Existe un rol asociado con esta lista y
es el de Product Owner. Si alguien quiere realizar cualquier modificación sobre
la lista por ejemplo: agregar o incrementar la prioridad de sus elementos tiene
que convencer al Product Owner.
Sprints
Un Sprint es el procedimiento de
adaptación de las cambiantes variables del entorno (requerimientos, tiempo,
recursos, conocimiento, tecnología). Son ciclos iterativos en los cuales se
desarrolla o mejora una funcionalidad para producir nuevos incrementos. Durante
un Sprint el producto es diseñado, codificado y probado. Y su arquitectura y
diseño evolucionan durante el desarrollo.
El objetivo de un Sprint debe ser
expresado en pocas palabras para que sea fácil de recordar y esté siempre
presente en el equipo.
Burn down Chart
La burn down chart es una gráfica mostrada públicamente que mide
la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de
cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints
completados, podremos ver el progreso del proyecto. Lo normal es que esta línea
sea descendente (en casos en que todo va bien en el sentido de que los
requisitos están bien definidos desde el principio y no varían nunca) hasta
llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no
hay más requisitos pendientes de ser completados en el Backlog). Si durante el
proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en
determinados segmentos, y si se modifican algunos requisitos la pendiente
variará o incluso valdrá cero en algunos tramos.
Sprint Backlog
Es el punto de entrada de cada Sprint.
Es una lista que tiene los ítems de la Product Backlog List que van a ser
implementados en el siguiente Sprint.
Los ítems son seleccionados por el Scrum
Team, el Scrum Master y el Product Owner en la Sprint Planning Meeting a partir
de la priorización de los ítems y los objetivos que se marcaron para ese
Sprint. A partir de los objetivos a cumplir durante el Sprint el Scrum Team
determina que tareas debe desempeñar para cumplir el objetivo. De esto surge el
Sprint Backlog.
Stabilization Sprints
En estos Sprints el equipo se concentra
en encontrar defectos, no en agregar funcionalidad. Suelen aplicarse cuando se
prepara un producto para el release. Son útiles cuando se están realizando
pruebas beta, se está introduciendo a un equipo en la metodología de Scrum o
cuando la calidad de un producto no alcanza los límites esperados.
No fueron definidos por Scrum pero han
sido recomendados por su utilidad al aplicar esta metodología.
Scrum of Scrums o MetaScrum
Los equipos de Scrum suelen tener entre
5 y 10 personas, sin embargo está metodología ha sido aplicada en proyectos que
involucran más de 600 personas. Esto ha sido llevado a cabo dividiendo a los
accionistas en equipos de pequeños de hasta 10 personas aproximadamente. Y
definiendo jerárquicamente personas que pertenecen a dos equipos, es decir,
además de su rol específico dentro de un equipo tienen el rol de enlace en un
equipo superior.
Roles y responsabilidades
Scrum clasifica a todas las personas que
intervienen o tienen interés en el desarrollo del proyecto en: propietario del
producto, equipo, gestor de Scrum (también Scrum Manager o Scrum Master) y
“otros interesados”.
Los tres primeros grupos (propietario,
equipo y gestor) son los responsables del proyecto, los que según la
comparación siguiente (y sin connotaciones peyorativas) serían los “cerdos”;
mientras que el resto de interesados serían las gallinas.
Cerdos y gallinas.
Esta metáfora ilustra de forma muy
gráfica la diferencia de implicación en el proyecto entre ambos grupos:
Una gallina y un cerdo paseaban por la
carretera.
La gallina dijo al cerdo: “Quieres abrir
un restaurante conmigo”.
El cerdo consideró la propuesta y
respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”.
La gallina respondió: “Huevos con
jamón”.
El cerdo se detuvo, hizo una pausa y
contestó:
“Pensándolo mejor, creo que no voy a
abrir un restaurante contigo. Yo estaría realmente comprometido, mientras que
tú estarías sólo implicada”.
Roles
Cerdo
Los Cerdos son
los que están comprometidos con el proyecto y el proceso Scrum; ellos son los
que "ponen el jamón en el plato".
Product Owner
El Product Owner representa
la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada
desde la perspectiva del negocio. El Product Owner escribe historias de
usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
El Scrum es
facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los
obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque
ellos se auto-organizan), sino que actúa como una protección entre el equipo y
cualquier influencia que le distraiga. El ScrumMaster se asegura de que el
proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las
reglas se cumplan.
Equipo
El equipo tiene la responsabilidad de
entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades
transversales necesarias para realizar el trabajo (diseñador, desarrollador,
etc).
Roles "Gallina"
Los roles gallina en realidad no son
parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de
una aproximación ágil es la práctica de involucrar en el proceso a los
usuarios, expertos del negocio y otros interesados (stakeholders). Es
importante que esa gente participe y entregue retroalimentación con respecto a
la salida del proceso a fin de revisar y planear cada sprint.
Usuarios
Es el destinatario final del producto.
Como bien lo dice la paradoja, El árbol cae en el bosque cuando no hay nadie
¿Hace ruido? Aqui la definicion sería Si el software no es usado ¿fue alguna vez escrito?.
Stakeholders (Clientes,
Proveedores).
Se refiere a la gente que hace posible
el proyecto y para quienes el proyecto producirá el beneficio acordado que lo
justifica. Sólo participan directamente durante las revisiones del sprint.
Managers
Es la gente que establece el ambiente
para el desarrollo del producto.
Reuniones en Scrum
Daily Scrum
Cada día de un sprint, se realiza la
reunión sobre el estado de un proyecto. Esto se llama "daily
standup". El scrum tiene unas guías específicas:
·
La reunión comienza
puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para
quién llega tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina
de plástico del cuello, etc)
·
Todos son bienvenidos, pero
solo los "cerdos" pueden hablar.
·
La reunión tiene una
duración fija de 15 minutos, de forma independiente del tamaño del equipo.
·
Todos los asistentes deben
mantenerse de pie (esto ayuda a mantener la reunión corta)
·
La reunión debe ocurrir en
la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del
equipo contesta a tres preguntas:[]
·
¿Qué has hecho desde ayer?
·
¿Qué es lo que estás
planeando hacer hoy?
·
¿Has tenido algún problema
que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster
recordar estos impedimentos).
·
Scrum de Scrum
Cada día normalmente después del “Daily
Scrum”
·
Estas reuniones permiten a
los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas
de solapamiento e integración.
·
Asiste una persona asignada
por cada equipo.
La agenda será la misma como del Daily
Scrum, además de las siguientes cuatro preguntas:
·
¿Qué ha hecho tu equipo
desde nuestra última reunión?
·
¿Qué hará tu equipo antes
que nos volvamos a reunir?
·
¿Hay algo que demora o
estorba a tu equipo?
·
¿Estás a punto de poner algo
en el camino del otro equipo?
Reunión de Planificación del Sprint (Sprint Planning
Meeting)
Al inicio del ciclo Sprint (cada 15 o 30
días), una “Reunión de Planificación del Sprint” se lleva a cabo.
·
Seleccionar que trabajo se
hará
·
Preparar, con el equipo
completo, el Sprint Backlog que detalla el tiempo que tomara hacer el trabajo.
·
Identificar y comunicar
cuánto del trabajo es probable que se realice durante el actual Sprint
·
Ocho horas como limite
Al final del ciclo Sprint, dos reuniones
se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del
Sprint”
Reunión de Revisión del Sprint (Sprint Review
Meeting)
·
Revisar el trabajo que fue
completado y no completado
·
Presentar el trabajo
completado a los interesados (alias “demo”)
·
El trabajo incompleto no
puede ser demostrado
·
Cuatro horas como límite
Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se
lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del
equipo dejan sus impresiones sobre el sprint recién superado. El propósito de
la retrospectiva es realizar una mejora continua del proceso. Esta reunión
tiene un tiempo fijo de cuatro horas.
Visión general del modelo SCRUM
CUANDO APLICAR EL MODELO SCRUM
• Cuando hay intervención del cliente.
• Cuando el alcance cambia regularmente durante el proyecto.
• Cuando se requieren entregas regulares.
• Cuando el producto requiere ser implementado de
inmediato.
• Entregas incrementales.
VENTAJAS DEL MODELO SCRUM
* El cliente puede comenzar a utilizar el producto
rápidamente.
* El cliente puede decidir los nuevos objetivos a
realizar.
* Se agilIza el proceso, porque se divide el
problema en pequeñas tareas.
* Menos probabilidad de que se den sorpresas o
desarrollos inesperados porque el cliente va viendo poco a poco lo que se está
desarrollando.
DESVENTAJAS DEL MODELO SCRUM
* Existe la tendencia que si se deja una tarea
sin terminar y que por las exigencias del Dueño del Producto se deban realizar
otras nuevas. Estas tareas no terminadas puedan obstaculizar la planeación de
nuevas sprints y se deba volver al problema original.
* Alto nivel de stress de los miembros del
equipo, el desgaste puede ser excesivo y estresante lo que puede disminuir el
rendimiento.
* La necesidad de contar con equipos
multidisciplinarios puede ser un problema, porque cada integrante del equipo
debe estar en capacidad de resolver cualquier tarea y no siempre se cuenta con
este perfil en la empresa.
* El equipo puede estar tentado de tomar el
camino más corto para cumplir con un sprint, que no necesariamente puede ser el
de mejor calidad en el desarrollo del producto.
bdchEntregas pequeñas: colocan un sistema
sencillo en producción rápidamente que se actualiza de forma rápida y constante
permitiendo que el verdadero valor de negocio del producto sea evaluado en un
ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como máximo.
Entendimiento
1. Diseño simple: se basa en la
filosofía de que el mayor valor de negocio es entregado por el programa más
sencillo que cumpla los requerimientos. Simple Design se enfoca en
proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni
más ni menos. Este proceso permite eliminar redundancias y rejuvenecer los
diseños obsoletos de forma sencilla.
2. Metáfora: desarrollada por los programadores al
inicio del proyecto, define una historia de cómo funciona el sistema completo.
XP estimula historias, que son breves descripciones de un trabajo de un sistema
en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metáfora expresa la visión evolutiva
del proyecto que define el alcance y propósito del sistema. Las tarjetas CRC
(Clase, Responsabilidad y Colaboración) también ayudarán al equipo a definir
actividades durante el diseño del sistema. Cada tarjeta representa una clase en
la programación orientada a objetos y define sus responsabilidades (lo que ha
de hacer) y las colaboraciones con las otras clases (cómo se comunica con
ellas).
3. Propiedad colectiva del código: un código con
propiedad compartida. Nadie es el propietario de nada, todos son el propietario
de todo. Este método difiere en mucho a los métodos tradicionales en los que un
simple programador posee un conjunto de código. Los defensores de XP argumentan
que mientras haya más gente trabajando en una pieza, menos errores aparecerán.
4. Estándar de codificación: define la propiedad
del código compartido así como las reglas para escribir y documentar el código
y la comunicación entre diferentes piezas de código desarrolladas por
diferentes equipos. Los programadores las han de seguir de tal manera que el
código en el sistema se vea como si hubiera estado escrito por una sola
persona.
Bienestar del programador.
1. La semana de 40 horas: la programación
extrema sostiene que los programadores cansados escriben código de menor
cualidad. Minimizar las horas extras y mantener los programadores frescos,
generará código de mayor calidad. Como dice Beck, está bien trabajar
tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas
seguidas.
PROCESO DE DESARROLLO
La
programación extrema parte del caso habitual de una compañía que desarrolla
software normalmente a medida, en la que hay diferentes roles: un equipo de
gestión (o diseño), uno de desarrollo y los clientes finales. La relación entre
el equipo de diseño, los que desarrollan el software y clientes es totalmente
diferente al que se ha producido en las metodologías tradicionales, que se
basaba en una fase de captura de los requisitos previa al desarrollo, y de una
fase de validación posterior al mismo.
1. Interacción con el cliente.
En
este tipo de programación el cliente pasa a ser parte implicada en el equipo de
desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y
en efectuar las reuniones de planificación. Tiene un papel importante de
interacción con el equipo de programadores, sobre todo después de cada cambio,
y de cada posible problema localizado, mostrando las prioridades, expresando
sus sensaciones... En este tipo de programación existirán pruebas de aceptación
de la programación que ayudarán a que su labor sea lo más provechosa posible.
Al fin
y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo.
Se elimina la fase inicial de recopilación de requerimientos, y se permite que
éstos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De
esta forma se posibilita que el cliente pueda ir cambiando de opinión sobre la
marcha, pero a cambio han de estar siempre disponibles para solucionar las
dudas del equipo de desarrollo.
En
XP aparece un nuevo concepto llamado “Historia de usuario”. Se
trata de una lista de características que el cliente necesita que existan en el
producto final. Estas constan de dos fases:
o
En la primera fase, el cliente describe con sus propias palabras las
características y, es el responsable del equipo, el encargado de informarlo de
las dificultades técnicas de cada una de ellas y de su coste. A consecuencia de
este diálogo, el cliente deja por escrito un conjunto de historias y las ordena
en función de la prioridad que tienen pera él. De esta manera ya es posible
definir unas fechas aproximadas para ellos.
o
En la segunda fase, el cliente cogerá las primeras historias a implementar y
las dividirá en trabajos a realizar. El cliente también participa, pero hay más
peso por parte del equipo de desarrolladores, esto dará como resultado una
planificación más exacta. Este método se repetirá para cada historia.
A
diferencia de otras técnicas, como puede ser UML, en el caso de XP, se exige
que sea el cliente el encargado de escribir los documentos con las especificaciones
de lo que realmente quiere, como un documento de requisitos de usuario.
En
esta fase, el equipo técnico será el 'encargado de catalogar las historias del
cliente y asignarles una duración. La norma es que cada historia de usuario
tiene que poder ser realizable en un espacio entre una y tres semanas de
programación. Las que requieran menos tiempo serán agrupadas, y las que
necesiten más serán modificadas o divididas.
Finalmente
decir que las historias de los usuarios serán escritas en tarjetas, lo que
facilitará que el cliente pueda especificar la importancia relativa entre las
diferentes historias de usuario, así como el trabajo de los programadores que
podrán catalogarlas correctamente. Este formato también es muy útil en el
momento de las pruebas de aceptación.
PLANIFICACIÓN DEL PROYECTO
En
este punto se tendrá que elaborar la planificación por etapas, donde se
aplicarán diferentes iteraciones. Para hacerlo será necesaria la existencia de
reglas que se han de seguir por las partes implicadas en el proyecto para que
todas las partes tengan voz y se sientan realmente partícipes de la decisión
tomada.
Las
entregas se tienen que hacer cuanto antes mejor, y con cada iteración, el
cliente ha de recibir una nueva versión. Cuanto más tiempo se tarde en
introducir una parte esencial, menos tiempo se tendrá para trabajar con ella
después. Se aconseja muchas entregas y muy frecuentes. De esta manera un error
en la parte inicial del sistema tiene más posibilidades de detectarse
rápidamente.
Una
de las máximas a aplicar es, los cambios, no han de suponer más horas de
programación para el programador, ya que el que no se termina en un día, se
deja para el día siguiente.
Se
ha de tener asumido que en el proceso de planificación habrán errores, es más,
serán comunes, y por esto esta metodología ya los tiene previstos, por lo tanto
se establecerán mecanismos de revisión. Cada tres o cinco iteraciones es normal
revisar las historias de los usuarios, y renegociar la planificación.
Cada
iteración necesita también ser planificada, es lo que se llama planificación iterativa,
en la que se anotarán las historias de usuarios que se consideren esenciales y
las que no han pasado las pruebas de aceptación. Estas planificaciones también
se harán en tarjetas, en las que se escribirán los trabajos que durarán entre
uno y tres días.
Es
por esto que el diseño se puede clasificar como continuo. Añade agilidad al
proceso de desarrollo y evita que se mire demasiado hacia delante,
desarrollando trabajos que aún no han estado programados.
Este
tipo de planificación en iteraciones y el diseño iterativo, hace que aparezca
una práctica que no existía en la programación tradicional. Se trata de las
discusiones diarias informales, para fomentar la comunicación, y para hacer que
los desarrolladores tengan tiempo de hablar de los problemas a los que se
enfrentan y de ver cómo van con sus trabajos.
DISEÑO, DESARROLLO Y PRUEBAS
El
desarrollo es la parte más importante en el proceso de la programación extrema.
Todos los trabajos tienen como objetivo que se programen lo más rápidamente
posible, sin interrupciones y en dirección correcta.
También
es muy importante el diseño, y se establecen los mecanismos, para que éste sea
revisado y mejorado de manera continuada a lo largo del proyecto, según se van
añadiendo funcionalidades al mismo.
La
clave del proceso de desarrollar XP es la comunicación. La mayoría de los
problemas en los proyectos son por falta de comunicación en el equipo.
En
XP, aparece un nuevo concepto llamado Metáfora. Su principal objetivo es
mejorar la comunicación entre todos los integrantes del equipo, al crear una
visión global y común de lo que se quiere desarrollar. La metáfora tiene que
ser expresada en términos conocidos por los integrantes del equipo, por ejemplo
comparando el sistema que se desarrollará con alguna cosa de la vida real.
Antes
de empezar a codificar se tienen que hacer pruebas unitarias, es decir:
Cada
vez que se quiere implementar una parte de código, en XP, se tiene que escribir
una prueba sencilla, y después escribir el código para que la pase. Una vez
pasada se amplía y se continúa. En XP hay una máxima que dice "Todo el
código que puede fallar tiene que tener una prueba".
Con
estas normas se obtiene un código simple y funcional de manera bastante rápida.
Por esto es importante pasar las pruebas al 100%.
Respecto
a la integración del soft, en XP se ha de hacer una integración continua, es
decir, cada vez se tienen que ir integrando pequeños fragmentos de código, para
evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos en
la integración final. En todo buen proyecto de XP, tendría que existir una
versión al día integrada, de manera que los cambios siempre se realicen en esta
última versión.
Otra
peculiaridad de XP es que cada programador puede trabajar en cualquier parte
del programa.
De
esta manera se evita que haya partes "propietarias de cada
programador". Por esto es tan importante la integración diaria.
Para
terminar, otra peculiaridad que tiene la XP. La de fomentar la programación en
parejas, es decir, hacer que los programadores no trabajen en solitario, sino
que siempre estarán con otra persona. Una pareja de programadores ha de
compartir el teclado, el monitor y el ratón. El principio fundamental de este
hecho es realizar de manera continua y sin parar el desarrollo de código. Las
parejas tienen que ir cambiando de manera periódica, para hacer que el
conocimiento se difunda en el grupo. Está demostrado que de esta manera el
trabajo es más eficaz y también se consigue más y mejor código.
