República Bolivariana De Venezuela Ministerio del Poder Popular para la Educación Superior Instituto Universitario Politécnico “Santiago Mariño”. Extensión Valencia.
METODOLOGIAS AGILES PARA EL DESARROLLO DE SOFTWARE. (EXTREME PROGRAMMING)
Erwing Subero C.I. 21.0021.347
Metodologías Ágiles Teóricamente, la agilidad se puede aplicar a cualquier proceso de software, sin embargo han surgido modelos de proceso propios con esta filosofía. Es este tipo de modelos, según el Manifiesto Ágil publicado en 2001, se valora lo siguiente:
A los individuos sobre los procesos y herramientas. Pues nada sustituye a las personas a pesar de todas las ayudas que existen para desarrollar software. Toda la importancia hay que dársela a las personas, que deben permanecer en un primer plano.
Al software funcionando sobre la documentación exhaustiva. Esto se debe a que había llegado un punto en el que la documentación de un trabajo había alcanzado tanta importancia como el objeto de trabajo en sí mismo, el producto. Cuando realmente la mayor atención debe estar puesta siempre en lo que queremos construir, y lo demás debería ser secundario.
La colaboración del cliente sobre la negociación de un contrato. A la hora de sacar un proyecto adelante, la forma más productiva siempre será estableciendo un marco de colaboración y confianza con quien nos lo encarga. Lo que estaba cobrando mayor importancia antaño era cerrar un contrato atado que sirviese por encima de todo como una herramienta de protección, de manera que el cliente y el equipo parecían partes enfrentadas, cuando en realidad comparten objetivos e intereses.
La respuesta al cambio sobre seguir un plan. Se trata de apreciar la incertidumbre como un componente básico del trabajo, de tal manera que la adaptabilidad y la flexibilidad se convierten en virtudes y no en defectos de la manera de trabajar del equipo. Por norma general, el seguimiento ciego de un plan suele llevar al fracaso si no se puede corregir la dirección ante los inevitables cambios que van surgiendo.
Además, para responder a los supuestos clave señalados previamente, los modelos de desarrollo ágiles deben cumplir con lo siguiente:
Ser adaptables de forma incremental
Tener abundante retroalimentación del cliente
Basarse en la entrega continua de incrementos
Equipo de desarrollo El proceso ágil requiere una serie de características sobre el equipo de desarrollo:
Competencia técnica
Enfoque común: entregar al cliente un incremento dentro del plazo
Colaboración entre todos los participantes
Autonomía para la toma de decisiones
Capacidad de resolución de problemas confusos
Confianza y respeto mutuo en el equipo
Organización propia
12 Principios de Agilidad 1. Satisfacer al cliente con entregas tempranas y continuas de software valioso. 2. Los requisitos cambiantes son bienvenidos, incluso en fases tardías del desarrollo. 3. Entregar con frecuencia software funcionando, -de dos semanas a dos meses,- cuanto antes se haga mejor. 4. El cliente y los desarrolladores deben trabajar juntos a diario a lo largo del proyecto. 5. Individuos motivados. Darles el ambiente y el soporte que necesitan, y confiar en ellos para obtener el trabajo realizado. 6. El método más eficiente y efectivo de transmitir información hacia y dentro del equipo es la conversación cara a cara. 7. El software en funcionamiento es la medida principal de progreso. 8. El desarrollo debe ser sostenible. Los participantes deben ser capaces de mantener un paso constante de manera indefinida. 9. Atención continua a la excelencia técnica y a un buen diseño.
10. La simplicidad es esencial, maximizando el avance del trabajo no realizado. 11. Las mejores arquitecturas, los mejores requisitos y los mejores diseños emergen de equipos auto-organizados. 12. A intervalos regulares el equipo refleja la forma en que se puede volver más efectivo, entonces su comportamiento se ajusta y adecua en concordancia. Metodologías Ágiles más comunes. SCRUM Scrum (Melé en español) es un modelo de desarrollo ágil que propone una técnica de desarrollo incremental mediante sprints. Para ello, no se cuenta con una planificación como tal, sino con un listado de características deseables para el producto que se deberán abordar durante los sprints de trabajo. Sus principios se basan en:
Mantener equipos de trabajo bien organizados en los que se maximice la comunicación.
Utilizar un proceso flexible susceptible a cambios para asegurar una máxima calidad del producto.
Dividir el trabajo en paquetes poco acoplados. Roles
Product Owner: Es el miembro que recibe toda la información del producto y la plasma en el documento de requisitos del producto de forma priorizada (Product Backlog).
Scrum Master: Es un miembro del equipo encargado de que el sprint se realice de forma correcta, coordinando a los miembros y solucionando los problemas que pudieran retrasar al equipo.
Equipo: Formado por unas 4-8 personas deben tener conocimientos generales de todas las fases del desarrollo y se encargarán de realizar las tareas planificadas para el sprint.
Idealmente pueden participar todos los 'stakeholders' o participantes del proyecto, como el cliente o los administradores de la organización. Fases Product backlog Durante esta fase se escribirán los requisitos en el documento de forma priorizada. Dicho documento puede ser actualizado en cualquier punto del desarrollo salvo durante los sprint. Sprint
Duración: 1 a 4 semanas.
Durante el sprint el equipo realizará una serie de tareas previamente identificadas. Cada miembro deberá elegir la tarea que más le motive hacer para lograr que se realice de manera rápida y obtener una mejor calidad. Reunión de planificación de Sprint
Este Sprint planning meeting tiene una duración: máx. 8 horas.
Antes de comenzar el sprint se realiza una reunión en la que se escogen los requisitos que se abordarán. Para planificar o estimar la duración que deberá tener el sprint es común realizar sesiones de 'scrum póker'. Despues de esta fase se deberá generar un documento con todas las tareas a realizar así como los tiempos en los que se deberán completar, conocido como 'sprint backlog'. Reunión diaria de Scrum
Este Daily Scrum tiene una duración aproximada de 15 minutos. Cada día, al comenzar la jornada, se dedicarán 15 minutos para realizar una
reunión en la que se deberán poner al día los miembros del equipo exponiendo:
¿Qué hiciste desde la última reunión?
¿Hay algún obstáculo en tu tarea?
¿Qué tienes planificado hacer hoy?
Revisión del Scrum y retrospectiva
Este Scrum Review & Retrospective tiene una duración de 4 horas (cada una) Al finalizar el sprint se realizan dos reuniones. La Scrum review está orientada
a valorar el trabajo realizado y a anotar qué quedó por hacer. Por otro lado la Scrum restrospective pretende analizar y valorar el transcurso del sprint con el objetivo de mejorar el proceso. Dynamic Systems Development Method El método DSDM es un método de desarrollo ágil que se apoya en una continua interacción con el usuario, consiguiendo una gran implicación. Esto produce un sistema sensible a los requisitos cambiantes del usuario, y que será capaz de adaptarse mucho mejor a las necesidades de la empresa. Fué creado para ser un sistema de resolución sencilla de tareas complejas, para ello se utilizan una serie de principios y valores, junto a una organización de equipo específica y con roles, y una serie de fases y etapas a seguir durante el desarrollo del software. Los métodos de desarrollo ágiles tienen una serie de valores como son dar más valor a los individuos en lugar de a las herramientas, o valorar mejor un software que funciona bien en lugar de una buena documentación. El método DSDM utiliza 9 principios para aplicar estos valores. 1.- La obligación del usuario de implicarse: Es considerado el más importante de los principios. Esto es debido a que la implicación del usuario en el desarrollo reduce en gran parte el número de errores y, por consiguiente, el dinero y tiempo utilizado para corregir los mismos. Por lo general, se trabaja con un pequeño número de usuarios selectos, haciendo pequeñas revisiones periódicas. Estos usuarios se mantendrán durante el desarrollo del Software consiguiendo así una imagen más fiel del software deseado. La continuidad, por otra parte, es uno de los valores que se aplican en los principios.
2.- Los equipos deben de tener el poder de tomar decisiones. Para poder proceder de la manera más rápida posible y sin depender de otras
personas,
todos
deben
de
tener
poder
para
tomar
decisiones
independientemente de los demás integrantes del equipo. Requerir la autorización de otras personas para poder proceder a actuar según decisiones tomadas ralentiza el proceso de creación del software, por ello, a todos los trabajadores se les da permiso para tomar decisiones que afectan a: Requisitos en desarrollo. Requisitos cuya funcionalidad se necesita en futuras interacciones. Priorización de requisitos y características. Detalles técnicos. 3.- Realización de entregas tempranas. Las entregas tempranas garantizan la detección rápida de errores para que sean corregidos y revertidos rápidamente antes de que el coste de reparación sea demasiado elevado. Estas entregas afectarán tanto al software como a la documentación que se entregará junto al software terminado. 4.- Las entregas que se acepten han de ser adaptadas a la empresa. El software que entreguemos ha de ser capaz de satisfacer las necesidades de la empresa. Por lo general, la Refactorización, el diseño y la mejora de las funciones son tareas que en los sistemas de modelado de software solo realizan una vez, al comienzo como es el diseño, o al final como es la refactorización o mejora de las funciones. Sin embargo, el DSDM sostiene que estas tareas han de formar parte del ciclo de vida del software y han de ser tareas que se deben de repetir una vez con cada una de las entregas que la empresa haya aceptado para así conseguir una mayor adaptación a la empresa y, como hemos dicho antes, que los errores no se hagan mucho más grandes y su coste de reparación no se eleve demasiado. Por otra parte, repitiendo estas fases una y otra vez se consigue una mucho mejor aproximación al software que desea la empresa. 5.- El desarrollo es Iterativo e Incremental. El desarrollo Iterativo e Incremental es el que mejor se adapta a todos los principios anteriores, y además facilita la división de las tareas para una mejor y más fácil organización del trabajo. En este desarrollo el software se va haciendo más grande con cada iteración hasta conseguir con la última que el software se
haya adaptado completamente a lo que la empresa necesitaba. Este principio se basa en el concepto de que todo software está sujeto a cambios. Por último, cuanto más pequeñas sean las iteraciones, más fácil será identificar y realizar los cambios que hay que realizar. 6.- Todos los cambios que se hagan durante el desarrollo han de ser reversibles. Como el propio título indica, cualquier cambio que nosotros realicemos debe de poder ser revertido con facilidad y sin suponer excesivos costes. Esto es debido a que los principios anteriores hacen que los cambios surjan continuamente y si no se tiene un control sobre ellos puede que el tiempo que tardemos en realizarlos sea excesivo. Por ello todos los cambios que se realicen han de ser escritos ideando que sean sencillos de eliminar o revertir. Es cierto que este principio pueda hacer que realicemos trabajo para nada si nuestros cambios se revierten al final, pero sin ello, los principios que sigue el método DSDM no sería aplicable dado que generaría trabajo muy grande procedente de la continua comunicación con usuario y cliente. 7.- Los requisitos se describen en alto nivel y tendrán una línea base. El DSDM hasta el momento propone que haya una gran libertad a la hora de cambiar los requisitos. Para limitarlos se establecen una serie de requisitos en alto nivel al comenzar el proyecto, formando una Linea Base sobre la que desarrollar. Así se forma una idea del alcance que deben tener los requisitos y nos aseguramos que los cambios no alteran demasiado la funcionalidad del ECS. 8.-Las pruebas se integran a lo largo del ciclo de vida. Por lo general, las pruebas es una de las últimas fases que forman proceso de ingeniería del software, siendo estas las que se realizan después de la codificación. Sin embargo, el modelo DSDM defiende que para conseguir una rápida corrección de los errores, las pruebas deben integrarse dentro de las fases más tempranas de la elaboración y repetirse en múltiples ocasiones durante el ciclo de vida del software.
9.- Enfoque cooperativo y colaborativo . La programación cooperativa es comúnmente utilizada en métodos de desarrollo ágil. Estas técnicas aceleran la resolución de problemas y la construcción de un software más eficiente y con menos errores. La más común es la programación por parejas en la que, mientras una de las dos personas codifica, la otra piensa y resuelve como realizar el algoritmo o la clase que hay que escribir a continuación además de revisar y ayudar a su compañero y viceversa.
Roles En todo equipo de modelado de software existen diferentes roles que adoptan los integrantes del equipo. El DSDM identifica un total de 12 roles, aunque, estos son variantes según las necesidades del equipo de desarrollo en función del software que se desarrolle:
Patrocinador ejecutivo: Es el rol más alto que adopta la organización. Es la fuente que proporciona fondos y recursos al proyecto. Es la posición más alta que toma decisiones. Visionario: Es el que tiene la responsabilidad de iniciar el proyecto. El visionario es el que proporciona las necesidades que tiene la empresa del software. El visionario tiene también la tarea de supervisar que el proyecto se desarrolla correctamente. Usuario “Embajador”: Proporciona al proyecto la información proveniente de la comunidad de usuarios. Tiene la obligación de asegurar que los desarrolladores reciben suficiente información de la comunidad de usuarios durante la fase de desarrollo. Usuario “Consejero”: Es cualquier usuario que proporcione al proyecto un buen punto de vista de la aplicación. Jefe de Proyecto: Es la persona encargada de gestionar el proyecto en general. Coordinador Técnico: Es el responsable de organizar la arquitectura del proyecto y controlar la calidad del software generado. Lider de Equipo: Se asegura de que el equipo funciona correctamente. Desarrollador: Interpreta los requisitos de sistema y los modela y desarrolla el código. Probador “Tester”. Es el encargado de comprobar que el software funciona correctamente así como de generar la documentación. Escriba: Toma nota de todos los requisitos, acuerdos y cambios que se realizan.
Facilitator: Es la persona que se encarga de controlar el progreso facilitar y potenciar la comunicación y el desarrollo.
Roles especiales: Business Architect, Quality Manager, System Integrator, etc. Fases Como todo modelo de proceso de Ingeniería de software, el DSDM está dividido en fases y etapas para organizar mejor las tareas a realizar en el desarrollo del software. El modelo DSDM consta de 3 grandes fases, El preproyecto, Ciclo de vida del software, y Post-Proyecto.
1.- El Pre-Proyecto: En esta fase se producen varias sugerencias de proyectos candidato, entre las cuales se elige una candidata. Además en esta fase se realiza una estimación de los fondos necesarios para desarrollar el proyecto y se decide si el proyecto se va a realizar o no. 2.- El Ciclo de vida del Software: El objetivo de esta fase es la construcción del proyecto planteado en la fase de Pre-Proyecto. Esta fase está subdividida en fases: 2.1- Estudio de Viabilidad y de Negocio. Los estudios que se plantean a continuación han de ser lo más cortos y esquemáticos posibles pero con la mayor completitud posible, dado que la creación de un documento demasiado complejo retrasaría el proyecto, pero unos buenos estudios nos ayudarán a enfocarlo mejor. 2.1.1- Estudio de Viabilidad: En esta fase se realizan reuniones para determinar aquellas ideas que no tienen que ver con el proyecto en sí, sino con la gestión del proyecto. Las respuestas ayudarán a direccionar el desarrollo del proyecto determinando sus costes, la adaptación de este al modelo DSDM, los riesgos que existen, etc... Produciendo un documento de Viabilidad.
2.1.2- Estudio de negocio: Es un documento que extiende al estudio de flexibilidad y que se realiza únicamente se haya decidido que el proyecto se puede desarrollar mediante DSDM. En esta fase se intentarán definir características del proyecto, así como las necesidades que esperan los usuarios de el. Al final del estudio se determinará una lista de requisitos, que se priorizarán según su necesidad para el desarrollo de el resto de requisitos. 2.2- Iteración de Modelo Funcional (Functional Model Iteration) En esta fase se recogen los requisitos identificados en fases anteriores y se transforman en Modelos Funcionales. Para ello se crean prototipos funcionales de los requisitos que dan una idea al usuario de cómo va a funcionar la aplicación y así satisfacer el principio número 1. Los prototipos funcionales son revisados por diferentes grupos de usuarios que valoran y certifican la calidad del prototipo. 2.3- Iteración de diseño y desarrollo (Design & Build Iteration) La principal tarea de esta fase es transformar los Modelos funcionales obtenidos de la fase anterior y completarlos para que satisfagan totalmente las necesidades del usuario. Para ello, crearemos Prototipos de diseño, y al igual que en la fase anterior, los verificaremos con los usuarios. 2.4- Implementación Por último, en la fase de implementación, los usuarios verifican que los prototipos cumplen con lo deseado y se realiza la implementación de los mismos, así como el entrenamiento de los futuros usuarios para que sepan utilizar la aplicación. 3.- El Post-Proyecto. Esta fase se utiliza para comprobar que el producto funciona correcta y eficientemente. En esta fase se realizan tareas de mantenimiento, y de mejora del software si son requeridas. Por lo general esta fase se produce durante los 6 meses siguientes a la entrega del proyecto al cliente.
DESARROLLO ADAPTATIVO DE SOFTWARE El método ágil ASD significa Desarrollo Adaptable de Software, es un modelo de implementación de patrones ágiles para desarrollo de software. Al igual que otras metodologías ágiles, su funcionamiento es cíclico y reconoce que en cada iteración se producirán cambios e incluso errores. El desarrollo de software adaptable (ASD) es una metodología de desarrollo que hace énfasis en aplicar las ideas que se originaron en el mundo de los sistemas complejos, adaptación continua del proceso al trabajo. CARACTERÍSTICAS: Sus principales características del ASD son:
Iterativo.
Orientado a los componentes de software más que a las tareas en las que se va a alcanzar dicho objetivo.
Tolerante a los cambios.
Guiado por los riesgos.
La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.
Estudiaremos a profundidad:
Metodología Extreme Programming (XP) La programación extrema o eXtreme Programming (de ahora en adelante, XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de
adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.
Valores de XP Los valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación: Simplicidad La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del
código
junto
a
sucesivas
modificaciones
por
parte
de
diferentes
desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente.
Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo. Comunicación La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas. Retroalimentación (feedback) Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.
Coraje o valentía Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar el resto del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran más fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo si es persistente. Respeto El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo eleva su ritmo de producción.
Características de XP
Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la
plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.
Roles Programador Escribe las pruebas unitarias y produce el código del sistema. Es la esencia del equipo. Cliente Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio. Tester Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Tracker Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. Entrenador (coach) Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente. Consultor
Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Ayuda al equipo a resolver un problema específico. Además este tiene que investigar según los requerimientos. Gestor (Big boss) Es el dueño de la tienda y el vínculo entre clientes y programadores. Su labor esencial es la coordinación. Fases
1ª Fase: Planificación del proyecto. Historias de usuario: El primer paso de cualquier proyecto que siga la metodología X.P es definir las historias de usuario con el cliente. Las historias de usuario tienen la misma finalidad que los casos de uso pero con algunas diferencias: Constan de 3 ó 4 líneas escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles; no se debe hablar ni de posibles algoritmos para su implementación ni de diseños de base de datos adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte de la aplicación que describen. También se utilizan en la fase de pruebas, para verificar si el programa cumple con lo que especifica la historia de usuario. Cuando llega la hora de implementar una historia de usuario, el cliente y los desarrolladores se reúnen para concretar y detallar lo que tiene que hacer dicha historia. El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3 semanas.
Release planning*: .Después de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en inglés "Release plan", donde se indiquen las historias de usuario que se crearán para cada versión del programa y las fechas en las que se publicarán estas versiones. Un "Release plan" es una planificación donde los desarrolladores y clientes establecen los tiempos de implementación ideales de las historias de usuario, la prioridad con la que serán implementadas y las historias que serán implementadas en cada versión del
programa. Después de un "Release plan" tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que son principalmente las historias que se deben desarrollar en cada versión), el tiempo que tardarán en desarrollarse y publicarse las versiones del programa, el número de personas que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo realizado. (*Release plan: Planificación de publicaciones). Iteraciones Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones de aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que serán implementadas. También se seleccionan las historias de usuario que no pasaron el test de aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los programadores. Velocidad del proyecto: La velocidad del proyecto es una medida que representa la rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con contar el número de historias de usuario que se pueden implementar en una iteración; de esta forma, se sabrá el cupo de historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente un nuevo "Release Plan".
Programación en pareja: La metodología X.P. aconseja la programación en parejas pues incrementa la productividad y la calidad del software desarrollado. El trabajo en pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica haciendo hincapié en la calidad de la función o método que está implementando, el otro analiza si ese método o función es
adecuado y está bien diseñado. De esta forma se consigue un código y diseño con gran calidad. Reuniones diarias. Es necesario que los desarrolladores se reúnan diariamente y expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y todo el mundo tiene que tener voz y voto. 2ª Fase: Diseño. Diseños simples: La metodología X.P sugiere que hay que conseguir diseños simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseño fácilmente entendible e impleméntable que a la larga costará menos tiempo y esfuerzo desarrollar. Glosarios de términos: Usar glosarios de términos y un correcta especificación de los nombres de métodos y clases ayudará a comprender el diseño y facilitará sus posteriores ampliaciones y la reutilización del código. .Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese problema. Funcionalidad extra: Nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos. Refactorizar. Refactorizar
es
mejorar
y
modificar
la
estructura
y
codificación de códigos ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos para procurar optimizar su funcionamiento. Es muy común rehusar códigos ya creados que contienen funcionalidades que no serán usadas y diseños obsoletos. Esto es un error porque puede generar código completamente inestable y muy mal diseñado; por este motivo, es necesario refactorizar cuando se va a utilizar código ya creado.
Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and Collaboration) permiten al programador centrarse y apreciar el desarrollo orientado a objetos olvidándose de los malos hábitos de la programación procedural clásica.Las tarjetas C.R.C representan objetos; la clase a la que pertenece el objeto se puede escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se pueden escribir las responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las clases que colaboran con cada responsabilidad.
3ª Fase: Codificación. Como ya se dijo en la introducción, el cliente es una parte más del equipo de desarrollo; su presencia es indispensable en las distintas fases de X.P. A la hora de codificar una historia de usuario su presencia es aún más necesaria. No olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos en los que serán implementadas. Antes del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que ésta hará y también tendrá que estar presente cuando se realicen los test que verifiquen que la historia implementada cumple la funcionalidad especificada.
La codificación debe hacerse ateniendo a estándares de codificación ya creados. Programar bajo estándares mantiene el código consistente y facilita su comprensión y escalabilidad.
Crear test que prueben el funcionamiento de los distintos códigos implementados nos ayudará a desarrollar dicho código. Crear estos test antes nos ayuda a saber qué es exactamente lo que tiene que hacer el código a implementar y sabremos que una vez implementado pasará dichos test sin problemas ya que dicho código ha sido diseñado para ese fin. Se puede dividir la funcionalidad que debe cumplir una tarea a programar en pequeñas unidades, de esta forma se crearán primero los test para cada unidad y a continuación se desarrollará dicha
unidad, así poco a poco conseguiremos un desarrollo que cumpla todos los requisitos especificados.
Como ya se comentó anteriormente, X.P opta por la programación en pareja ya que permite un código más eficiente y con una gran calidad. X.P sugiere un modelo de trabajo usando repositorios de código dónde las parejas de programadores publican cada pocas horas sus códigos implementados y corregidos junto a los test que deben pasar. De esta forma el resto de programadores que necesiten códigos ajenos trabajarán siempre con las últimas versiones. Para mantener un código consistente, publicar un código en un repositorio es una acción exclusiva para cada pareja de programadores. X.P también propone un modelo de desarrollo colectivo en el que todos los programadores están implicados en todas las tareas; cualquiera puede modificar o ampliar una clase o método de otro programador si es necesario y subirla al repositorio de código. El permitir al resto de los programadores modificar códigos que no son suyos no supone ningún riesgo ya que para que un código pueda ser publicado en el repositorio tiene que pasar los test de funcionamiento definidos para el mismo. La optimización del código siempre se debe dejar para el final. Hay que hacer que funcione y que sea correcto, más tarde se puede optimizar. X.P afirma que la mayoría de los proyectos que necesiten más tiempo extra que el planificado para ser finalizados no podrán ser terminados a tiempo se haga lo que se haga, aunque se añadan más desarrolladores y se incrementen los recursos. La solución que plantea X.P es realizar un nuevo "Release plan" para concretar los
nuevos
tiempos
de
publicación
y
de
velocidad
del
proyecto.
A la hora de codificar no seguimos la regla de X.P que aconseja crear test de funcionamiento con entornos de desarrollo antes de programar. Nuestros test los obtendremos de la especificación de requisitos ya que en ella se especifican las pruebas que deben pasar las distintas funcionalidades del programa, procurando
codificar pensando en las pruebas que debe pasar cada funcionalidad. 4ª Fase: Pruebas. .......Uno de los pilares de la metodología X.P es el uso de test para comprobar el funcionamiento de los códigos que vayamos implementando. El uso de los test en X.P es el siguiente: Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo específico para test. Hay que someter a tests las distintas clases del sistema omitiendo los métodos más triviales. Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado anterior se explicó la importancia de crear antes los test que el código. Un punto importante es crear test que no tengan ninguna dependencia del código que en un futuro evaluará. Hay que crear los test abstrayéndose del futuro código, de esta forma aseguraremos la independencia del test respecto al código que evalúa. Como se comentó anteriormente los distintos test se deben subir al repositorio de código acompañados del código que verifican. Ningún código puede ser publicado en el repositorio sin que haya pasado su test de funcionamiento, de esta forma, aseguramos el uso colectivo del código (explicado en el apartado anterior). El uso de los test es adecuado para observar la refactorización. Los test permiten verificar que un cambio en la estructura de un código no tiene porqué cambiar su funcionamiento.
Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas tareas en las que ha sido dividida una historia de usuario. Para asegurar el funcionamiento final de una determinada historia de usuario se deben crear "Test de aceptación"; estos test son creados y usados por los clientes para comprobar que las distintas historias de usuario cumplen su cometido. Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se harán test que analicen partes de las mismas, sino que las pruebas se realizarán para las funcionalidades generales que debe cumplir el programa especificado en la descripción de requisitos.