Introducción
Cuando hablamos de desarrollo de software, muchas veces nos enfocamos en el resultado final, en el producto que se entrega al cliente, pero no en el proceso que se lleva cabo para llegar a ese resultado. Al no tener bien definido que proceso se llevará a cabo durante el proyecto nos estamos exponiendo a una serie de riesgos y desafíos que pueden dificultar la entrega oportuna al cliente.
Los retrasos en la entrega, la falta de comunicación entre equipos, la incapacidad para adaptarse a los cambios repentinos en los requisitos del cliente y el propio agotamiento de los recursos son solo algunos de los peligros que acechan cualquier desarrollo.
Para evitar estos problemas, se han desarrollado una serie de metodologías que nos ayudan a gestionar el desarrollo de software de una manera más eficiente. Estas metodologías se conocen como metodologías ágiles y dado que esta semana tengo una exposición acerca de este mismo tema, aprovecharé la investigación que realicé y escribo este artículo sobre una de las metodologías que considero de mis favoritas.
Origen
Podría comenzar a hablar directamente sobre la metodología en sí, pero creo que es importante conocer un poco sobre el contexto en el que surge, ya que esto nos ayudará a entender mejor el porqué de algunas de las prácticas que se llevan a cabo en ella.
De acuerdo a Letelier & Penades (2006) en un proceso de software existen numerosas propuestas metodológicas que inciden en distintas dimensiones del transcurso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros.
Manifiesto Ágil
Voy a ir de viaje ¿me acompañan? Específicamente iré a Utah EE.UU. en el año 2001 donde se llevó a cabo una reunión de 17 expertos en desarrollo de software, los cuales se reunieron para discutir sobre los problemas que se presentaban en el desarrollo de software y las posibles soluciones a estos problemas. De esta reunión surgió el Manifiesto Ágil, este manifiesto ágil comienza enumerando los principales valores del desarrollo ágil, como lo son:
- Individuos e interacciones sobre procesos y herramientas.
- Software funcionando sobre documentación extensiva.
- Colaboración con el cliente sobre negociación contractual.
- Respuesta ante el cambio sobre seguir un plan.
Es decir, aunque los elementos de la derecha tienen valor, valoramos más los de la izquierda.
Los valores anteriores inspiran los 12 principios del desarrollo ágil, los cuales son:
- 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.
Estos principios son algo así como los 10 mandamientos del desarrollo ágil, solo que ni son 10, ni son mandamientos, pero bueno, creo que se entiende la idea. Son como los 12 10 mandamientos, ¿buena, no?.
Programación Extrema
La programación extrema o XP (eXtreme Programming) es una metodología ágil que se centra en la mejora de la calidad del software y la calidad de vida del equipo de desarrollo, se considera como el más destacado de los procesos ágiles de desarrollo de software.
Al igual que los demás procesos ágiles, XP se basa en la premisa de que el cambio es inevitable en el desarrollo de software, por lo que se le da mayor énfasis a la adaptabilidad que a la previsibilidad. NO SE HACEN COSAS QUE NO SE NECESITEN EN EL MOMENTO.
Origen
Nace de la mano de Kent Beck, Ron Jeffries y Ward Cunningham en el año 1996, cuando trabajaban en el desarrollo de un proyecto para la empresa Chrysler. Él tenía varias ideas de metodologías para la realización de programas que eran cruciales para el buen desarrollo de cualquier sistema.
Estas ideas las presentó en una revista llamada C++ Report, en la que se publicó un artículo llamado “Programación extrema”. En este artículo se presentaban las ideas que Beck tenía sobre la programación extrema, y que se basaban en la simplicidad, la comunicación, el feedback, el coraje y el respeto.
Usando Wayback Machine podemos acceder a la página que en su momento se utilizaba para divulgar la metodología, aquí
Objetivos
La programación extrema cuenta varios objetivos principales, los cuales son:
- La satisfacción del cliente.
- Potenciar el trabajo en grupo.
- Minimizar el riesgo actuando sobre las variables del proyecto: costo, tiempo, calidad, alcance. Por ejemplo, si se quiere reducir el tiempo de desarrollo, se debe aumentar el costo o reducir el alcance.
Características
La programación extrema se caracteriza por:
- Metodología basada en prueba y error para obtener un software que funcione realmente. Es decir, se va construyendo el software a medida que se va probando.
- Fundamentada en principios. Es decir, se basa en una serie de principios que se deben cumplir para que la metodología funcione.
- Está orientada hacia quien produce y usa software (el cliente participa muy activamente). Es decir, es necesario que el cliente participe activamente en el desarrollo del software.
- Reduce el coste del cambio en todas las etapas del ciclo de vida del sistema. Se busca que el cambio sea lo más económico posible.
- Combina las que han demostrado ser las mejores prácticas para desarrollar software, y las lleva al extremo. Toma las mejores prácticas de otras metodologías y las lleva al extremo.
- Cliente bien definido. Por cliente definido se entiende que el cliente debe tener claro lo que quiere y debe estar dispuesto a participar activamente en el desarrollo del software.
- Los requisitos pueden cambiar. Habilidad para adaptarse a los cambios.
- Grupo pequeño y muy integrado (2-12). Menos es más.
- Equipo con formación elevada y capacidad de aprender. El equipo debe tener la capacidad de aprender y adaptarse a los cambios.
Herramientas
Para poder hacer un uso correcto de la metodología, es necesario hacer uso de una serie de herramientas que nos ayudarán a llevar a cabo las prácticas que se llevan a cabo en la metodología. Estas herramientas son las siguientes:
Historias de usuario
Las historias de usuario son una técnica para capturar requisitos de un sistema desde el punto de vista del usuario. Se trata de una descripción corta y sencilla de una característica nueva que se desea implementar en el sistema. Las historias de usuario se escriben en lenguaje natural, utilizando frases cortas y sencillas, y se escriben en tarjetas de papel o en notas adhesivas.
Cada historia de usuario debe ser lo suficientemente comprensible y delimitada para que los programadores puedan implementarlas en unas semanas.
Tareas de ingeniería
También conocidas como Task Cards son una técnica para capturar las tareas que se deben realizar para implementar una historia de usuario. Una historia de usuario se descompone en varias tareas de ingeniería, las cuales describen las actividades que se realizarán en cada historia de usuario, así mismo las tareas de ingeniería se vinculan más al desarrollador, ya que permite tener un acercamiento con el código. Por lo general se escriben en tarjetas de papel o en notas adhesivas.
Pruebas de aceptación
Según Chiluisa Pallo & Loarte Cajamarca, las pruebas de aceptación son de vital importancia para el éxito de una iteración y el comienzo de la siguiente, con lo cual el cliente puede conocer el avance den el desarrollo del sistema y a los programadores lo que les resta por hacer. Además permite una retroalimentación para el desarrollo de las próximas historias de usuarios a ser entregadas. Estas son comúnmente llamadas pruebas del cliente, por lo que son realizadas por el encargado de verificar si las historias de usuarios de cada iteración cumplen con la funcionalidad esperada.
Tarjetas CRC
Las tarjetas CRC (Clase, Responsabilidad, Colaboración) son una técnica para capturar las clases que se deben implementar para una historia de usuario. Las tarjetas CRC, permiten conocer que clases componen el sistema y cuales interactúan entre sí. Se dividen en tres secciones:
- Nombre de la clase
- Responsabilidades
- Colaboradores
Roles
La programación extrema cuenta con una serie de roles que se deben cumplir para que la metodología funcione correctamente, estos roles son:
- PROGRAMADOR: Es el responsable de implementar las historias de usuario por el cliente. Además, estima el tiempo de desarrollo de cada historia de usuario para que el cliente pueda asignarle prioridad dentro de la iteración. Cada iteración incorpora nueva funcionalidad de acuerdo a las prioridades establecidas por el cliente. El Programador también es responsable de diseñar y ejecutar los test de unidad del código que ha implementado o modificado.
- CLIENTE: Determina la funcionalidad que se pretende en cada iteración y define las prioridades de implementación según el valor de negocio que aporta cada historia. El Cliente también es responsable de diseñar y ejecutar los test de aceptación.
- TESTER: Es el encargado de ejecutar las pruebas regularmente, difunde los resultados dentro del equipo y es también el responsable de las herramientas de soporte para pruebas.
- TRACKER: Una de las tareas más importantes del tracker, consiste en seguir la evolución de las estimaciones realizadas por los programadores y compararlas con el tiempo real de desarrollo. De esta forma, puede brindar información estadística en lo que refiere a la calidad de las estimaciones para que puedan ser mejoradas.
- ENTRENADOR: Es responsable del proceso en general. Se encarga de iniciar y de guiar a las personas del equipo en poner en marcha cada una de las prácticas de la metodología XP.
- 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.
- GESTOR(BIG BOSS): Es el vínculo entre el cliente y programadores. Experto en tecnología y labores de gestión. Construye el plantel del equipo, obtiene los recursos necesarios y maneja los problemas que se generan. Administra a su vez las reuniones (planes de iteración, agenda de compromisos, etc).
Fases de la metodología
La programación extrema se divide en 4 fases, las cuales son:
Planificación
En esta fase se determina mediante comunicación activa con el cliente, cuales son las historias de usuario que se van a implementar en la iteración. Para ello se debe tener en cuenta la prioridad de cada historia de usuario, el tiempo de desarrollo de cada historia de usuario y la capacidad del equipo de desarrollo.
Los conceptos básicos de la planificación son:
- Historias de usuario: Son las funcionalidades que se van a implementar en la iteración.
- El plan de entregas: Establece que las historias de usuarios serán agrupadas para conformar una entrega y el orden de las mismas. Este cronograma será el resultado de una reunión entre todos los actores del proyecto.
- Plan de iteraciones: Las historias de usuarios seleccionadas para cada entrega son desarrolladas y probadas en un ciclo de iteración, de acuerdo al orden preestablecido.
- Reuniones diarias: Se realizan reuniones diarias de 15 minutos para que el equipo de desarrollo pueda comunicar el estado de las tareas que se están llevando a cabo.
Diseño
Hace especial énfasis en los diseños simples y claros. Los conceptos básicos del diseño son:
- Simplicidad: El diseño debe ser lo más simple posible, ya que esto permite que el equipo se adapte a los cambios de una manera más rápida y eficiente.
- Soluciones "Spikes": Se trata de una solución temporal que se utiliza para resolver un problema complejo, de esta forma se puede avanzar en el desarrollo del software mientras se busca una solución definitiva.
- Refactorización: Es el proceso de reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo. El objetivo de la refactorización es mejorar la legibilidad del código o cambiar su estructura interna, para facilitar el mantenimiento del código, reducir su complejidad, mejorar su rendimiento, o facilitar la comprensión del código fuente.
- Metáfora: Es una forma de describir el sistema de una manera simple y clara, de esta forma se puede entender mejor el sistema y se puede adaptar a los cambios de una manera más rápida y eficiente.
Codificación
Disponibilidad del cliente. Uno de los requerimientos de XP es tener al cliente disponible durante todo el proyecto. No solamente como apoyo a los desarrolladores, sino formando parte del grupo. El involucramiento del cliente es fundamental para que pueda desarrollarse un proyecto con la metodología XP. Al comienzo del proyecto, debe proporcionar las historias de usuarios. Pero, dado que estas historias son expresamente cortas y de "alto nivel", no contienen los detalles necesarios para realizar el desarrollo del código. Estos detalles deben ser proporcionados por el cliente, y discutidos con los desarrolladores, durante la etapa de desarrollo.
Uso de estándares. XP promueve la programación basada en estándares, de manera que sea fácilmente entendible por todo el equipo, y que facilite la re codificación.
Programación dirigida por las pruebas. En las metodologías tradicionales, la fase de pruebas, incluyendo la definición de los test, es usualmente realizada sobre el final del proyecto, o el final del desarrollo de cada módulo. La metodología XP propone un modelo inverso, primero se escribe los test que el sistema debe pasar. Luego, el desarrollo debe ser el mínimo necesario para pasar las pruebas previamente definidas. Las pruebas a los que se refiere esta práctica, son las pruebas unitarias, realizado por los desarrolladores. Programación en pares. XP propone que se desarrolle en pares de programadores, ambos trabajando juntos en un mismo ordenador. Si bien parece que esta práctica duplica el tiempo asignado al proyecto (y por ende, los costos en recursos humanos), al trabajr en pares se minimizan los errores y se logran mejores diseños, compensado la inversión en horas. El producto obtenido es por lo general de mejor calidad que cuando el desarrollo se realiza por programadores individuales.
Integraciones permanentes. Todos los desarrolladores necesitan trabajar siempre con la "última versión". Realizar cambios o mejoras sobre versiones antiguas causan graves problemas, y retrasan al proyecto. Es por eso que en XP promueve publicar lo antes posible las nuevas versiones, aunque no seas las últimas, siempre que estén libres de errores. Idealmente, todos los días deben existir nuevas versiones publicadas. Para evitar errores, solo una pareja de desarrolladores puede integrar su código a la vez.
Propiedad colectiva del código. En un proyecto XP, todo el equipo puede contribuir con nuevas ideas que apliquen a cualquier parte del proyecto. Asimismo, una pareja de programadores puede cambiar el código que necesario para corregir problemas, agregar funciones o re codificar.
Ritmo sostenido. Indica que debe llevarse un ritmo sostenido de trabajo. El concepto que se desea establecer con esta práctica es planificar el trabajo de forma a mantener un ritmo constante y razonable, sin sobrecargar al equipo.
Pruebas
Pruebas unitarias. Todos los módulos deben de pasar las pruebas unitarias antes de ser liberados o publicados. Por otra parte, como se mencionó anteriormente, las pruebas deben ser definidas antes de realizar el código. Todo código liberado debe pasar correctamente las pruebas unitarias, es lo que habilita que funcione la propiedad colectiva del código.
Detección y corrección de errores. Cuando se encuentra un error (BUG), este debe ser corregido inmediatamente, y se deben tener precauciones para que errores similares no vuelvan a ocurrir. Asimismo se generan nuevas pruebas para verificar que el error haya sido resuelto.
Pruebas de aceptación. Son creadas en base a las historias de usuarios, en cada ciclo de la iteración del desarrollo. El cliente debe especificar uno o diversos escenarios para comprobar que una historia de usuario ha sido correctamente implementada. Asimismo, en caso de que fallen varias pruebas, deben indicar el orden de prioridad de resolución. Una historia de usuario no se puede considerar terminada hasta que pase correctamente todas las pruebas de aceptación.
Prácticas de la metodología
La metodología XP está orientada al desarrollo de software cuando los requerimientos son ambiguos o rápidamente cambiantes asumiéndolos como algo natural, por lo que los programadores deben responder a estos cambios cuando el cliente lo solicite.
Esta metodología esta principalmente orientada para pequeños y medianos equipos, basándose en la comunicación continúa entre todos los participantes, la simplicidad en las soluciones implementadas y coraje para enfrentar los cambios.
Recomienda seguir las siguientes prácticas:
- Comunicación: Conversación continua entre el equipo de desarrollo y el cliente, para implementar cambios lo antes posible.
- Entregas pequeñas: Entrega en versiones operativas.
- Diseño simple: Diseñar lo antes posible, pero con la funcionalidad requerida.
- Pruebas: Se realizan pruebas unitarias por parte de los programadores y pruebas de aceptación por parte del cliente.
- Refactorización: Remover código duplicado para facilitar los posteriores cambios.
- Programación en parejas: Se realiza para contar con menor tasa de errores, mejor diseño y mayor satisfacción de los programadores.
- Integración continua: Cuando un fragmento de código esté listo, puede ser integrado al sistema.
- Cliente in-situ: El cliente debe de estar presente y disponible para el equipo de desarrollo.
- Estándares de programación: Normas definidas por los desarrolladores para tener un código legible.
- Juego de la planificación: Es importante que desde el comienzo tanto el equipo de desarrollo y el cliente tengan una visión general del proyecto. Se realizan reuniones con el fin de organizar las tareas e ideas que surgen tanto por parte del cliente como del equipo.
- Propiedad colectiva del código: El código no es conocido por una sola persona del grupo del trabajo, esto facilita implementar cambios al programa por parte de otros integrantes del grupo.
- Utilización de metáforas del sistema: Para mejorar el entendimineto de los elementos del sistema por parte del equipo de desarrollo se acude a la utilización de metáforas, como una forma de universalizar el lenguaje del sistema.
- Test del cliente: El cliente con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.
- 40 horas por semana: Se debe de trabajar un máximo de 40 horas por semana.
Ventajas y desventajas de XP
| Ventajas | Desventajas |
|---|---|
| Contacto cercano con el cliente | Trabajo adicional |
| Sin trabajo de programación innecesario | El cliente debe participar en el proceso |
| Software estable mediante pruebas continuas | Inversión de tiempo relativamente grande |
| Menor errores debido a la programación en parejas | Costes relativamente elevados |
| No hay horas extras, los equipos trabajan a su ritmo | Requiere gestión de versiones |
| Se pueden hacer cambios con poca antelación | Requiere autodisciplina para practicar |
| El código es claro y comprensible en todo momento | --- |
Conclusión
Podemos decir que la metodología XP es una metodología de desarrollo ágil que se centra en la satisfacción del cliente, la simplicidad, la comunicación y la retroalimentación. Es una metodología que se adapta a los cambios, ya que los cambios son algo natural en el desarrollo de software, por lo que se debe de estar preparado para afrontarlos.
En La Cueva del NeanderTech nos gusta mucho esta metodología, ya que es una metodología que se adapta a los cambios, y que se centra en la satisfacción del cliente, que es lo que más nos importa. Además, es una metodología que se centra en la comunicación, y en la comunicación continua con el cliente, algo que nos parece muy importante. Por último, nos gusta mucho que se centra en la simplicidad, ya que creemos que es algo muy importante en el desarrollo de software. Como siempre, espero que esto haya sido útil para al menos una persona, cualquier comentario siéntete libre de colocarlo en la caja de comentarios. ¡Hasta la próxima!
El problema es que, en el diseño de software, a menudo las consecuencias de tus decisiones no se hacen evidentes hasta pasados años.
— Kent Beck