UF2218 - Desarrollo de un CMS

1.1. Metodología de desarrollo

1.2. Análisis de Requerimientos

1.3. Descripción funcional

1.4.Diseño de arquitectura

1.5. Diseño Técnico

1.6. Programación

1.6.1. Pruebas Unitarias

1.7. Auditoría Funcional

1.8. Auditoría Técnica

1.8.1. Revisión de Código

1.8.2. Métricas

1.8.3. Pruebas de rendimiento

1.9. Despliegue

1.10. Liberación

1.1. Metodología de desarrollo

La primera pregunta que debemos plantearnos es qué es una metodología de desarrollo.

En primer lugar, no debemos confundir la metodología de desarrollo de software (framework) con los paradigmas o filosofías de desarrollo de software, en base a los cuales se aplica una determinada metodología.

Desde el origen de las tecnologías de la información, han surgido varios paradigmas de desarrollo de software; en términos generales son los siguientes:

–Metodologías basadas en ciclo de vida del software

–Metodologías Ágiles

En base a cada uno de estos paradigmas, han aparecido varios modelos:

Por tanto, una vez situado el contexto adecuado, podemos definir una metodología de desarrollo de software como un framework usado para estructurar, planificar y controlar el proceso de desarrollo de un sistema de información. Además de lo descrito, una metodología también puede incluir aspectos sobre el entorno de desarrollo –IDE por sus siglas en inglés: Integrated Development Environment, el desarrollo basado en modelos, y la utilización de ciertos componentes (librerías de programación u otras herramientas).

Desarrollo ágil

Las metodologías de desarrollo ágil están de moda y son populares. Todas las compañías punteras en el mercado de tecnologías de la información las utilizan: Google, Yahoo, Symantec, Microsoft, y la lista sigue.

Sabías

En 1986, [Brooks] predijo que en 1996, ninguna técnica o tecnología de gestión ofrecería un aumento de diez veces en la productividad, la fiabilidad o la simplicidad. Ninguna lo hizo. Las metodologías de desarrollo ágil tampoco.

De hecho, no es recomendable la adopción de una metodología de desarrollo ágil únicamente con el objetivo de aumentar la productividad. Sus beneficios -incluso la capacidad de liberar el software con más frecuencia- se obtienen por el hecho de trabajar de manera diferente, no trabajar más rápido. Aunque la evidencia anecdótica indica que los equipos ágiles tienen una productividad superior a la media, esa no debe ser la principal motivación de su adopción. Su equipo necesitará tiempo para aprender el desarrollo ágil. Mientras aprenden -y se necesitará un tiempo-, van a ir más lentos, no más rápidos. Además, haciendo hincapié en la productividad únicamente, podría animar a su equipo a tomar atajos y ser menos riguroso en su trabajo, lo que en realidad podría perjudicar la productividad.

El desarrollo ágil puede ser la cosa de moda que hacer en este momento, aunque no haya ninguna razón que justifique su utilización. Cuando se considera el uso de una metodología de desarrollo ágil, sólo debemos hacernos una pregunta.

¿El desarrollo ágil nos ayudará a tener más éxito?

Cuando pueda responder a esa pregunta, sabrá si el desarrollo ágil es el adecuado para su proyecto.

Entender el éxito

La idea tradicional del éxito es la entrega a tiempo, dentro del presupuesto, y de acuerdo con la especificación. A continuación, algunas definiciones clásicas:

–Exitoso: Completado a tiempo, dentro del presupuesto, con todas las características y funciones que se especifican en un principio.

–Desafiado: Completado y en funcionamiento, pero por encima del presupuesto, sobre la estimación de tiempo, [con] un menor número de características y funciones que se especifican en un principio.

–Dañado: Cancelado en algún momento durante el ciclo de desarrollo.

A pesar de su popularidad, hay algo erróneo en estas definiciones. Un proyecto puede tener éxito incluso si nunca genera un solo euro. Y también puede ser un fracaso aunque proporcione millones de euros en ingresos.

La revista CIO aportó comentarios sobre esta rareza:

"Proyectos que se ha demostrado que cumplen con todos los criterios tradicionales para el éxito -tiempo, presupuesto y especificaciones- todavía pueden fracasar al final, bien porque no despiertan interés en los usuarios previstos, bien porque en última instancia no agregan mucho valor a la

empresa.

... Del mismo modo, los proyectos considerados fracasos de acuerdo a las métricas de TI tradicionales pueden terminar siendo éxitos porque a pesar de los problemas de costes, tiempo o de especificaciones, el sistema es valorado por su público objetivo o proporciona un valor inesperado. 

Por ejemplo, en una empresa de servicios financieros, un nuevo sistema tuvo seis meses de retraso y un coste de más del doble de la estimación inicial (el coste final puede 5,7 millones de dólares). Pero el proyecto finalmente creó una organización más adaptable (después de 13 meses) y se consideró un gran éxito -la compañía tuvo una reducción de 33 millones de dólares en cuentas fallidas-, y la reducción del tiempo de generación de valor y el aumento de capacidad se tradujeron en un incremento de un 50 por ciento en el número de pruebas estratégicas de recolección concurrentes en producción."

Más allá de plazos

Tiene que haber algo más en el éxito que el simple cumplimiento de plazos... ¿pero qué?

La definición de éxito dependerá, fundamentalmente, de la visión que se utilice para definirlo.

Software.

Los programadores de software disfrutan como niños creando nuevos sistemas y aplicaciones, e independientemente de si la aplicación funciona o no, se utiliza o no, el programador se sentirá recompensado personalmente porque se habrá divertido escribiendo el código y habrá aprendido nuevas cosas.

Definición

Por tanto, desde un punto de vista individual, la definición del éxito estará centrada en recompensas personales.

Cuando el proyecto alcanza cierta envergadura a nivel técnico, las aplicaciones y sistemas a desarrollar se vuelven más complejos, y es necesario la intervención de varios programadores codificando al mismo tiempo en el mismo sistema. En este momento, la legibilidad del código y su mantenibilidad se tornan conceptos importantes.

Definición

Por tanto, desde un punto de vista tecnológico, el concepto de éxito se asociará a la excelencia técnica.

A pesar de un buen código, algunos proyectos fracasan. Incluso los proyectos ejecutados impecablemente podrían provocar bostezos de los usuarios. Normalmente, los proyectos forman parte de un ecosistema mucho mayor, en el cual participan decenas, cientos o incluso miles de personas. Los proyectos de TI deben satisfacer las necesidades de esa gente.

Definición

De hecho, desde un punto de vista económico, el valor aportado por el software debería superar su coste. En este caso, el éxito significa la entrega de valor a la organización.

Estas definiciones no son incompatibles entre sí. Los tres tipos de éxito son importantes. Sin el éxito personal, tendrá problemas para motivarse a sí mismo y al resto de miembros de la organización. Sin éxito técnico, su código fuente con el tiempo se derrumbará por su propio peso. Y sin éxito de la organización, su equipo puede encontrar que ya no es requerido en la empresa.

La importancia del éxito de la organización

El éxito de la organización es a menudo descuidado por los equipos de software a favor de los éxitos personal y técnico, más fácilmente alcanzables. Tenga la seguridad, sin embargo, que incluso si usted no está tomando la responsabilidad de éxito de la organización, el resto de la organización –a nivel global- está juzgando a su equipo en este nivel. Es probable que los directivos senior y los ejecutivos no se preocupen excesivamente de si su software es elegante, fácil de mantener, o incluso valorado por sus usuarios; ellos se preocupan por los resultados. Es decir, del retorno de la inversión en el proyecto. Si no puede conseguir este tipo de éxito, tomarán medidas para asegurarse de que lo hace. Y desafortunadamente, los altos directivos –por lo general-, no tienen el tiempo o la perspectiva de aplicar una solución matizada a cada proyecto. Esperan con razón que sus equipos de trabajo cuiden los pequeños detalles. Cuando los directivos no están contentos con los resultados de su equipo, sacan las espadas. Los costes son el objetivo más evidente. Hay dos maneras fáciles de reducir los costes: establecer plazos agresivos para reducir el tiempo de desarrollo, o enviar el trabajo a un país con un menor coste de mano de obra. O las dos cosas. Estas son técnicas torpes. Plazos agresivos terminan aumentando los horarios en lugar de reducirlos, y la deslocalización tiene costes ocultos.

¿Qué valoran las organizaciones?

Aunque el valor de algunos proyectos proviene directamente de las ventas, hay más en el valor organizacional que simplemente los ingresos.

Los proyectos proporcionan valor de muchas maneras, y no siempre se puede medir ese valor en unidades monetarias.

Aparte de los aumentos de ingresos y los ahorros de costes, las fuentes de valor incluyen:

¿Ayudarán las metodologías de desarrollo ágil a tener más éxito? Es posible. El desarrollo ágil se centra en el logro de éxitos personales, técnicos y 

organizativos.

Éxito Organizacional

Las metodologías de desarrollo ágil logran éxitos de organización, centrándose en la entrega de valor y la disminución de los costes. Esto se traduce directamente en una mayor rentabilidad de la inversión. Las metodologías de desarrollo ágiles también establecen expectativas a principios del proyecto, así que si su proyecto no será un éxito a nivel de organización, dispondrá de tiempo suficiente para llevar a cabo su cancelación con suficiente antelación antes de que su organización haya gastado mucho dinero.

En concreto, los equipos de desarrollo ágil aumentan el valor mediante la inclusión de expertos en negocios y centrando los esfuerzos de desarrollo en el valor central que el proyecto proporcionará a la organización. Los proyectos ágiles liberan sus características más valiosas primero y liberan nuevas versiones con frecuencia, lo que aumenta drásticamente el valor aportado. Cuando las necesidades del negocio cambian o cuando se descubre nueva información, los equipos ágiles cambian de dirección para responder a los nuevos requerimientos. De hecho, un equipo ágil y experimentado buscará por sí mismo oportunidades no previstas para mejorar sus planes.

Los equipos ágiles también disminuyen los costes. Hacen esto en parte por la excelencia técnica; los mejores proyectos ágiles generan sólo algunos errores al mes. También eliminan los residuos mediante la cancelación de proyectos malos al inicio y reemplazando las prácticas de desarrollo más costosas con otras más sencillas. Los equipos ágiles se comunican de forma rápida y precisa, y hacen progresos, incluso cuando las personas clave no están disponibles. Revisan regularmente sus procesos y mejoran continuamente su código, lo que hace el software sea más fácil de mantener y mejorar a lo largo del tiempo.

Éxito técnico

La metodología de desarrollo ágil que expondremos es Extreme Programming (XP). Esta metodología es particularmente recomendable para alcanzar éxitos técnicos.

Programadores XP trabajan juntos, lo que les ayuda a realizar un seguimiento de los detalles más minuciosos, necesarios para un gran trabajo y asegura que al menos dos personas revisan cada pieza de código. Los programadores integran continuamente su código, lo que permite al equipo liberar el software cada vez que tiene sentido a nivel de negocio. Todo el equipo se concentra en terminar cada función por completo antes de comenzar la siguiente, lo que evita retrasos inesperados antes de la liberación y permite al equipo cambiar de dirección a voluntad.

Además de la estructura de desarrollo, Extreme Programming incluye prácticas técnicas avanzadas que llevan a la excelencia técnica. La práctica más conocida es el desarrollo basado en pruebas, que ayuda a los programadores a escribir código que hace exactamente lo que ellos creen que hará. Equipos XP también crean diseños simples y en constante evolución que son fáciles de modificar cuando los planes cambian.

Éxito Personal

El éxito personal es, bueno, personal. El desarrollo ágil puede no satisfacer todos los requerimientos para el éxito personal. Sin embargo, una vez que se acostumbra a él, probablemente encontrará lo mucho que le gusta la metodología, con independencia del rol que se asuma:

¿Qué significa ser ágil?

La respuesta es más complicada de lo que parece. El desarrollo ágil no es un proceso específico que se pueda seguir. Ningún equipo practica el método ágil. No existe tal cosa.

El desarrollo ágil es una filosofía. Es una manera de pensar sobre el desarrollo de software. La descripción canónica de esta forma de pensar es el Manifiesto Ágil, una colección de 4 valores y 12 principios. Para «ser ágiles», hay que poner estos valores y principios en práctica.

Principios del Manifiesto Ágil

–Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

–Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

–Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

–Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

–Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 

–El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

–El software funcionando es la medida principal de progreso.

–Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

–La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

–La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

–Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

–A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Métodos Ágiles

Un método o proceso, es una forma de trabajar. Cada vez que hacemos algo, estamos siguiendo un proceso. Algunos procesos se han escrito, por ejemplo, para montar un mueble; otros son ad-hoc e informales, por ejemplo, cuando limpio mi casa.

Los métodos ágiles son procesos que apoyan la filosofía ágil; son elementos individuales llamados prácticas. Las prácticas incluyen el uso de control de versiones, el establecimiento de estándares de codificación, y demostraciones semanales a los grupos de interés. La mayoría de estas prácticas han existido desde hace años. Los métodos ágiles las combinan de una forma única, acentuando aquellas partes que apoyan la filosofía ágil, desechando el resto, y mezclándolas en algunas nuevas ideas. El resultado es una metodología ligera, poderosa, y auto-reforzada.

Extreme programming (xp)

Hay varias metodologías dentro del paradigma de desarrollo ágil (Agile Development), entre ellas las más aceptadas globalmente son Scrum y Extreme Programming (XP).

En el resto del libro nos basaremos en la metodología Extreme Programming por los siguientes motivos:

–De todos los métodos ágiles, consideramos que XP es el más completo. Pone un fuerte énfasis en las prácticas técnicas, además del trabajo en equipo y prácticas estructurales.

–XP ha sido objeto de un intenso escrutinio. Hay miles de páginas de explicaciones y relatos de experiencia y las críticas que hay. Sus capacidades y limitaciones están muy bien entendidas.

El ciclo de vida de Extreme Programming

Una de las más sorprendentes premisas de XP es que se pueden eliminar las fases de requerimientos, diseño y pruebas, así como los documentos formales asociados con ellas.

Esta premisa se encuentra tan lejos de la forma en que normalmente aprendemos a desarrollar software, que muchas personas lo descartan como una fantasía delirante. Estos locos de XP, obviamente, no saben de lo que están hablando, dicen. U otro comentario: "el mes pasado estuve en un proyecto que fracasó debido a los requisitos y el diseño inadecuados. Necesitamos más requisitos, diseño y pruebas, no menos! "

Eso es verdad. Los proyectos de software sí necesitan más requerimientos, el diseño y las pruebas; que es el motivo por el cual los equipos XP trabajan en estas actividades todos los días. Sí, todos los días.

Programación.

Como podrá comprobar, XP enfatiza la colaboración cara a cara. Esto es tremendamente eficaz en la eliminación de los retrasos de comunicación y malentendidos que el equipo ya no necesita fases distintas. Esto les permite trabajar en todas las actividades cada día -con fases simultáneas-.

Usando fases simultáneas, un equipo XP produce software desplegable cada semana. En cada iteración, el equipo analiza, diseña, codifica, prueba, e

implementa un subconjunto de características. Aunque este enfoque no necesariamente significa que el equipo es más productivo, sí significa que el equipo obtiene información con mucha más frecuencia. Como resultado, el equipo puede conectar fácilmente los éxitos y los fracasos a sus causas subyacentes.

La cantidad de trabajo no probada es muy pequeña, lo que permite al equipo corregir algunos errores sobre la marcha, como por ejemplo, si al codificar se revela un defecto de diseño, o cuando una revisión del cliente revela que un diseño de interfaz de usuario es confuso o feo.

El bucle de realimentación ajustado también permite a los equipos XP refinar sus planes rápidamente. Es mucho más fácil para un cliente refinar una idea sobre una característica si puede pedirla y empezar a explorar un prototipo de trabajo en unos pocos días.

El mismo principio se aplica para las pruebas, el diseño, y la política del equipo. Cualquier información que se aprende en una fase puede cambiar la forma de pensar sobre el resto del software. Si usted encuentra un defecto de diseño durante la codificación o la prueba, puede utilizar ese conocimiento a medida que continúe para analizar las necesidades y diseñar el sistema en posteriores iteraciones.

¿Cómo funciona XP?

Los equipos XP realizan casi todas las actividades de desarrollo de software simultáneamente. Análisis, diseño, codificación, pruebas, e incluso el despliegue se producen con una frecuencia rápida.

Eso es mucho más que hacer al mismo tiempo. XP lo hace mediante el trabajo en iteraciones: incrementos de una semana de trabajo. Cada semana, el equipo hace un poco de planificación de liberación, un poco de diseño, un poco de codificación, un poco de prueba, y así sucesivamente.

Trabajan en historias: muy pequeñas características, o partes de las características, que tienen valor para el cliente. Cada semana, el equipo se compromete a la entrega de cuatro a diez historias. Durante toda la semana, trabajan en todas las fases de desarrollo de cada historia. Al final de la semana, que despliegan su software para la revisión interna (en algunos casos, se despliegan a clientes actuales).

Los siguientes puntos muestran cómo las actividades basadas en fases tradicionales corresponden a una iteración XP.

Planificación

Todos los equipos XP incluyen varios expertos en negocios –on-site customers– que son responsables de la toma de decisiones de negocio. Los on-site customers apuntan el proyecto en la dirección correcta al aclarar la visión del proyecto, la creación de historias, la construcción de un plan de liberación, y la gestión de riesgos. Los programadores proporcionan estimaciones y sugerencias, que se mezclan con las prioridades de los clientes en un proceso llamado el juego de planificación.

Juntos, el equipo se esfuerza para crear versiones pequeñas y frecuentes que maximicen el valor.

El esfuerzo de planificación es más intenso durante las primeras semanas del proyecto. Durante el resto del proyecto, los clientes siguen para revisar y mejorar la visión y el plan de lanzamiento para dar cuenta de las nuevas oportunidades y acontecimientos inesperados.

Además del plan de liberación total, el equipo crea un plan detallado para la próxima semana en el comienzo de cada iteración. El equipo toca base todos los días en una breve reunión de pie, y su espacio de trabajo informativo mantiene informado a todos sobre el estado del proyecto.

Análisis

En lugar de utilizar una fase de análisis inicial para definir los requisitos, los on-site customers se sientan con el equipo a tiempo completo. on-site customers pueden o no ser clientes reales dependiendo del tipo de proyecto, pero son las personas mejor cualificadas para determinar lo que el software debe hacer.

on-site customers son responsables de averiguar los requisitos para el software. Para ello, utilizan su propio conocimiento como clientes combinado con técnicas tradicionales de recopilación de requerimientos.

Cuando los programadores necesitan información, simplemente pregunta. Los clientes son responsables de organizar su trabajo, por lo que están listos cuando los programadores piden información. Imaginan los requisitos generales para una historia antes de que los programadores lo estimen y los requisitos detallados antes de que los programadores lo implementan.

Algunos requisitos son complicados o difíciles de entender. Los clientes formalizan estos requisitos, con la ayuda de los probadores, mediante la creación de pruebas de clientes: ejemplos detallados y comprobados automáticamente. Los clientes y los probadores crean las pruebas de clientes de una historia al mismo tiempo que los programadores implementan la historia. Para ayudar en la comunicación, los programadores utilizan un lenguaje omnipresente en su diseño y el código.

El look & feel de la interfaz de usuario (User Interface por sus siglas en inglés) no se beneficia de las pruebas automatizadas de clientes. Para la interfaz de usuario, los clientes trabajan con el equipo para crear bocetos de las pantallas de la aplicación. En algunos casos, los clientes trabajan junto a los programadores, ya que utilizan un constructor de interfaz de usuario para crear una pantalla. Algunos equipos incluyen un diseñador de interacción, que  es responsables de la interfaz de usuario de la aplicación.

Diseño y Codificación

XP utiliza el diseño y la arquitectura progresivos para continuamente crear y mejorar el diseño en pequeños pasos. Este trabajo es impulsado por el desarrollo guiado por pruebas (TDD: test-driven development), una actividad que entrelaza inextricablemente juntos las pruebas, la codificación, el diseño y la arquitectura. Para apoyar este proceso, los programadores trabajan en parejas, lo que aumenta la cantidad de capacidad intelectual ejercida sobre cada tarea y se asegura de que una persona de cada pareja siempre tiene tiempo para pensar en los problemas de diseño más grandes.

Los programadores también son responsables de la gestión de su entorno de desarrollo. Utilizan un sistema de control de versiones para la gestión de la configuración y mantienen su propia construcción automatizada. Los programadores integran su código cada pocas horas y se aseguran de que cada integración es técnicamente capaz de desplegarse.

Para apoyar este esfuerzo, los programadores también mantienen los estándares de codificación y comparten la propiedad del código.

El equipo comparte una estética común para el código, y se espera que cualquiera pueda arreglar problemas en el código, independientemente de quién lo escribió.

Pruebas

XP incluye un conjunto sofisticado de prácticas de prueba. Cada miembro del equipo -programadores, clientes y probadores- hace su propia contribución a la calidad del software. Los equipos XP que funcionan bien producen sólo un puñado de errores al mes en el trabajo ya terminado.

Los programadores proporcionan la primera línea de defensa con desarrollo basado en pruebas. TDD produce pruebas automatizadas unitarias y de integración. En algunos casos, los programadores también pueden crear pruebas de extremo a extremo. 

Estas pruebas ayudan a asegurar que el software hace lo que pretendían los programadores. Del mismo modo, las pruebas de los clientes ayudan a asegurar que la intención de los programadores coincide con las expectativas del cliente.

Los clientes repasan el trabajo en curso para asegurar que la interfaz de usuario funciona de la manera que ellos esperan. También producen ejemplos para los programadores para automatizar, que proporcionan ejemplos de reglas de negocio difíciles.

Por último, los probadores ayudan al equipo a entender si sus esfuerzos, están produciendo realmente código de alta calidad.

Utilizan pruebas exploratorias para buscar sorpresas y lagunas en el software. Cuando los probadores encuentran un error, el equipo lleva a cabo un análisis causa-raíz y considera la forma de mejorar su proceso para evitar que errores similares vuelvan a ocurrir en el futuro. Los probadores también exploran características no funcionales del software, como el rendimiento y la estabilidad. Después, los clientes utilizan esta información para decidir si se deben crear historias adicionales.

El equipo no realiza las pruebas de regresión manual. TDD y pruebas de cliente conduce a un conjunto sofisticado de pruebas de regresión automatizadas. Cuando se encuentran los errores, los programadores crean pruebas automatizadas para demostrar que los errores han sido resueltos. Este conjunto es suficiente para prevenir regresiones. Cada vez que los programadores integran (una vez cada pocas horas), corren todo el conjunto de pruebas de regresión para comprobar si algo se ha roto.

El equipo también soporta sus esfuerzos de calidad a través de la programación en parejas, el trabajo con energía, y la estacionalidad de la iteración. Estas prácticas aumentan la capacidad intelectual que cada miembro del equipo tiene disponible para la creación de software de alta calidad.

Despliegue

Los equipos XP mantienen su software listo para implementar al final de cualquier iteración. Entregan el software a los grupos de interés internos cada

semana en preparación para la demo semanal de la iteración. 

La implementación en clientes reales se programa de acuerdo a las necesidades del negocio.

Mientras el equipo está activo, se mantiene el software que ha lanzado. Dependiendo de la organización, el equipo también puede soportar su propio software. En otros casos, un equipo de soporte diferente puede tomar el relevo. Del mismo modo, al final del proyecto, el equipo puede traspasar las responsabilidades del mantenimiento del software a otro equipo. En este caso, el equipo crea documentación y proporciona formación, según sea necesario, durante sus últimas semanas.

El equipo xp

Si quieres ampliar información sobre los diferentes roles que intervienen en un equipo de Extreme Programming, consulta en el anexo.

Conceptos xp

Como en cualquier campo especializado, XP tiene su propio vocabulario. Este vocabulario destila varios conceptos importantes en las descripciones ágiles. Cualquier discusión seria de XP (y de desarrollo ágil en general) utiliza este vocabulario. Algunas de las ideas más comunes son las siguientes.

Refactoring

Hay varias maneras de expresar el mismo concepto en el código fuente. Algunos son mejores que otros. Refactorización es el proceso de cambiar la estructura del código –reformulándolo–, sin cambiar su significado o su comportamiento. Se utiliza para mejorar la calidad del código, para luchar contra la inevitable entropía del software, y para facilitar la adición de nuevas características.

Deuda Técnica

Imagínese un cliente corriendo por el pasillo hacia su mesa de trabajo: ¡Hay un error! dice casi llorando y sin aliento. «¡Tenemos que arreglarlo ahora!". Puede pensar en dos soluciones: la manera correcta y la manera rápida. Lo que sí es seguro es que ese cliente va estar mirándole por encima del hombro hasta que lo arregle. Así que elige la manera rápida, haciendo caso omiso de esa reflexión interna que le dice que está volviendo el código un poco más desordenado.

La deuda técnica es la cantidad total de decisiones de diseño y ejecución menos que perfectos que se producen en nuestro proyecto.

Esto incluye cortes rápidos y sucios destinados sólo para conseguir algo de trabajo ¡en estos momentos! Y las decisiones de diseño que podrían haber variado debido a los cambios del negocio. La deuda técnica, incluso puede venir de las prácticas de desarrollo tales como un proceso de construcción difícil de manejar o cobertura incompleta de las pruebas. Se esconde en métodos gigantescos llenos de código comentado, y comentarios del tipo TODO: no estoy seguro de por qué esto funciona. Estos rincones oscuros de formato pobre, flujo de control ininteligible, e insuficiencia de pruebas genera errores de forma exponencial.

La factura de esta deuda a menudo se presenta en forma de mayores costes de mantenimiento. Puede que no haya una sola suma global a pagar, pero las tareas simples que debe tomar minutos pueden extenderse hasta horas o días. Puede no darse cuenta, excepto cuando se empieza a crear una sensación inminente de temor cuando se lee un nuevo informe de errores y se sospecha que se encuentra en esa parte del código.

Si no se controla, la deuda técnica crece hasta desbordar los proyectos de software. El desarrollo de sistemas de información cuesta millones de euros, e incluso los proyectos pequeños cuestan cientos de miles de euros. Es una tontería tirar esa inversión y reescribir el software, pero sucede todo el tiempo. ¿Por qué? La deuda técnica no controlada hace el software sea más caro de modificar que volver a implementar. Gran desperdicio.

XP tiene un enfoque fanático con respecto a la deuda técnica. La clave para gestionarla es estar en constante alerta. Evite los atajos, utilice un diseño sencillo, refactorice sin descanso, etc. En definitiva, aplique las prácticas de desarrollo de XP.

Timeboxing

Algunas actividades, invariablemente, se extienden hasta llenar el tiempo disponible. Siempre hay algo más pulido que se puede poner en un programa o algo más de diseño que puede comentar en una reunión. Sin embargo, en algún momento deberá tomar una decisión. En algún momento, habrá identificado tantas opciones como jamás habría imaginado.

Reconocer el punto en el que tiene suficiente información no es fácil. Si utiliza timeboxing, destinará un bloque de tiempo específico para la