Ingeniería del software II Metodologías ágiles eXtreme Programing

Metodologías Ágiles Las metodologías ágiles surgen como respuesta a las metodologías “pesadas” (PUD, Metrica, etc). La critica mas habitual a estas metodologías hay tanto que hacer para seguir la metodología que el ritmo entero del desarrollo se retarda. Las metodologías ágiles cambian algunos de los énfasis de las metodologías pesadas. La diferencia inmediata es que son menos orientados al documento, exigiendo una cantidad más pequeña de documentación para una tarea dada. En muchas maneras son más bien orientados al código: siguiendo un camino que dice que la parte importante de la documentación es el código fuente.

Manifiesto ágil Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de esta experiencia hemos aprendido a valorar:   Individuos e interacciones sobre procesos y herramientas Software que funciona sobre documentación exhaustiva Colaboración con el cliente sobre negociación de contratos Responder ante el cambio sobre seguimiento de un plan  Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda. (http://www.agilemanifesto.org/) Esta manifiesto esta firmado por algunos de los mas respetados expertos en ingeniería del software de la actualidad: Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Ken Schwaber etc…

Ágiles vs Pesadas Los métodos ágiles son adaptables en lugar de predictivos Los métodos pesados tienden a intentar planear una parte grande del proceso del software en gran detalle para un plazo grande de tiempo. esto funciona bien hasta que las cosas cambian. Así que su naturaleza es resistirse al cambio. Para los métodos ágiles el cambio es bienvenido. Intentan ser procesos que se adaptan y crecen en el cambio, incluso al punto de cambiarse ellos mismos.

Ágiles vs Pesadas Los métodos ágiles son orientados a la gente y no orientados al proceso: La meta de los métodos pesados es definir un proceso que funcionará bien con cualquiera que lo use. Los métodos ágiles afirman que ningún proceso podrá nunca maquillar las habilidades del equipo de desarrollo. Las metodologías ágiles afirman trabajar a favor de la naturaleza humana en lugar de en su contra y enfatizan que el desarrollo de software debe ser una actividad agradable.

Predictivo vs Adaptable: diseño y construcción La ingeniería del software tradicionalmente se ha inspirado en otras ingenierías, como por ejemplo la ingeniería civil. En estas ingenierías de desarrolla un diseño y posteriormente este es entregado a otras personas que se encargan de la construcción en base a ese diseño. Hay por tanto dos fases diferenciadas: Diseño: requiere de un equipo creativo y altamente especializado y supone en torno al 10% del tiempo del proyecto Construccion: requiere de un equipo con menos especializacion (intelectual) y supone en torno al 90% del tiempo total

Predictivo vs Adaptable: diseño y construcción Intentado aplicar este enfoque al desarrollo de software surgen muchas preguntas: ¿Es posible entregar un diseño de software, por ejemplo en UML, que especifique claramente como se debe desarrollar el código? ¿Los diseños en UML son verificables para asegurarnos de su corrección antes de entregarlos para la fase de “construcción”? ¿es la “construcción” suficientemente grande en costo y tiempo para hacer valer la pena este enfoque?

Predictivo vs Adaptable: diseño y construcción Esta clase de preguntas llevaron a Jack Reeves* a sugerir que de hecho el código fuente es un documento de diseño y que la fase de construcción está en realidad en la compilación y el ligado Estas idea lleva a las siguientes conclusiones: En software la construcción es tan barata que es casi gratis. En software todo el esfuerzo está en el diseño, de modo que requiere de personas creativas y talentosas. Los procesos creativos no se planean fácilmente, de modo que la previsibilidad bien puede ser una meta imposible. Debemos ser muy cautos al usar la metáfora de la ingeniería tradicional para construir software. Es un tipo diferente de actividad y por ende requiere un proceso diferente. (*) http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Predictivo vs Adaptable:requisitos impredecibles La idea detrás de la ingeniería de requisitos es conseguir un cuadro totalmente entendido de los requisitos antes de empezar a construir el software y conseguir la firma del cliente sobre estos requisitos. Hay que preguntarse ¿es esto posible con el software?, la respuesta es NO por varios motivos: No es fácil entender las necesidades del cliente, ni el sabe expresarlas en términos de software ni nosotros entendemos en profundidad su negocio o actividad. El valor que proporciona un software es difícil de cuantificar a priori, solo cuando se comienza a usar es posible determinar la implementación de que requisitos aporta mas valor. muchos cambios en el mundo de negocios son completamente imprevisibles y afectaran enormemente a los requisitos.

Predictivo vs Adaptable:requisitos impredecibles Aun si dispusiéramos de unos requisitos inamovibles, calcular el costo de implementación de esos requisitos puede ser complejo por varias razones: Porque los materiales básicos cambian rápidamente. Las tecnologías evolucionan rápidamente y en ocasiones son complejas de utilizar. Por lo mucho que depende el software de los individuos involucrados, y los individuos son difíciles de predecir y cuantificar.

Predictivo vs Adaptable Todo esto nos lleva a la conclusión de que la actividad de desarrollar software es imposible o muy difícil de predecir o planear. Como en tantos problemas la parte más difícil está simplemente en comprender que el problema existe. Por tanto el uso de metodologías predictivas no parece lo mas adecuado, para la gran mayoría, del desarrollo de software. Las metodologías ágiles tratan de buscar respuesta a este problema mediante la Adaptabilidad

Adaptabilidad La adaptabilidad se fundamenta en dos pilares fundamentales: Construcción iterativa del software Relación mas estrecha con el cliente

Orientados a la gente Uno de los objetivos de las metodologías tradicionales es desarrollar un proceso donde las personas involucradas sean partes reemplazables. Con tal proceso se puede tratar a las personas como recursos que están disponibles en varios tipos. Se tienen un analista, algunos programadores, algunos verificadores, un gerente. Los individuos no son tan importantes, sólo los papeles lo son. Pero realmente ¿son las personas involucradas en el desarrollo de software partes reemplazables? Uno de los rasgos importantes de los métodos ágiles es el rechazo a esta afirmación.

Orientados a la gente La creación de software es un proceso creativo y que requiere talento, ni es fácil medir el talento de las personas ni todas las personas tienen el mismo talento. La noción de la gente como recursos esta profundamente inculcado en el pensamiento de negocios, teniendo sus raíces en el impacto del enfoque de La Dirección Científica de Frederick Taylor. En la administración de una fábrica, este enfoque Taylorista tiene sentido. Pero para un trabajo altamente creativo y profesional, como es el desarrollo de software, esto no se sostiene.

Orientados a la gente Una parte clave de la noción Taylorista es que la gente que hace el trabajo no es la mejor gente para entender la mejor manera de hacer el trabajo. Cuando se quiere contratar y retener a gente capaz, hay que reconocer que son profesionales competentes. Como tales son los mejores para decidir cómo dirigir su trabajo técnico.

Orientados a la gente Los desarrolladores deben poder tomar todas las decisiones técnicas. Sólo los desarrolladores pueden estimar cuánto tiempo se va ha emplear en hacer un trabajo. Por la naturaleza creativa del desarrollo de software las diferencias entre los buenos y malos desarrolladores son enormes, retener a los buenos programadores proporcionándoles un entorno de trabajo adecuado se hace indispensable. La productividad en el desarrollo de software depende en gran medida del estado de animo del desarrollador, un equipo de desarrollo satisfecho con el trabajo que realiza será un equipo de trabajo mucho mas productivo.

Metodologías Ágiles Basándose en estos principios existen diversas metodologías: eXtreme Programming Cristal SCRUM FDD (Feature Driven Development)

eXtreme Programming eXtreme programming es un metodologia creada por Kent Beck, Ward Cunningham y Ron Jeffries durante su trabajo en el proyecto C3 de Chrysler. Actualmente es la metodología ágil mas extendida

eXtreme Programming XP es una metodología pensada para equipos de desarrollo de tamaño pequeño o medio que trabajan en proyectos donde los requisitos varían con mucha frecuencia. El “extreme” en el nombre de la metodología viene dado por que según los autores tratan de llevar al extremo practicas que consideran de “sentido común” en el desarrollo de software.

eXtreme Programming Revisar el código es bueno, XP propone revisarlo constantemente (programación en parejas). Testear el código es bueno, XP propone testear constantemente (desarrollo dirigido a test) Diseñar es bueno, XP propone que el diseño forme parte del trabajo diario (refactorizacion) La simplicidad es buena, XP propone hacer siempre lo mas sencillo “The simplest thing that could possibly work” Integrar los test en el desarrollo es importante, XP propone integrarlos incluso varias veces al dia (integracion continua)

Promesas de XP A los programadores: Promete trabajar en cuestiones importantes todos los días. No tener que afrontar problemas o situaciones difíciles solos. Tomaran las decisiones los mejores cualificados para hacerlo.

Promesas de XP A clientes y jefes de proyecto: Se conseguirá el mayor valor posible por cada semana de trabajo. Cada pocas semanas se podrán ver resultados concretos del trabajo. Se podrá cambiar la dirección del proyecto durante el desarrollo sin tener que asumir un coste exorbitante.

Valores de XP Comunicación: Muchos proyectos fracasan por errores en la comunicación. Las técnicas de XP están orientadas a fomentar la comunicación entre los distintos integrantes del proyecto. XP pretende que todos los programadores tengan un visión global proyecto, que el cliente este presente en el desarrollo y otras técnicas que sirven para fomentar esta comunicación.

Valores de XP Simplicidad XP toma la simplicidad como uno de sus valores fundamentales, los diseños y codificaciones deben ser lo mas simples posibles y mejorarlas a traves de la refactorizacion cuando sea necesario. Es Preferible hacer un diseño lo mas simple posible hoy y mejorarlo por futuras peticiones mañana que hacer un diseño muy complejo hoy y que luego no sea nunca necesario.

Valores de XP Retroalimentación (feedback) Retroalimentación del sistema: Escribiendo test unitarios que proporcionen información constante acerca del estado del sistema Retroalimentación del cliente: El cliente escribe los test funcionales y prueba el sistema proporcionando información sobre su funcionamiento.

Valores de XP Coraje Los desarrolladores tienen que tener coraje para afrontar ciertas circunstancias del desarrollo, ejemplos: Coraje para refactorizar el código constantemente. Coraje para tirar a la basura partes del codigo que se han convertido en demasiado complejas y que son un lastre en el desarrollo. Coraje para afrontar cambios profundos en el sistema que puedan proporcionar una mejora significativa del mismo.

Practicas XP Para seguir la metodología XP se deben seguir una serie de practicas. Estas practicas en su mayoría no son nada nuevo, son practicas que se llevan usando en programación durante años. La novedad en XP es incluirlas todas juntas dentro del contexto de una metodología.

Practicas XP: el juego de la planificación El desarrollo de software es a menudo un dialogo entre lo posible y lo deseable. Dentro de la planificación tendrán que intervenir tanto gente conocedora del negocio y del problema a resolver por a aplicación como la gente técnica encargada de hacer la aplicación. Los primeros hablaran de lo deseable y lo segundos de lo posible, intentando acercar los dos puntos lo máximo posible.

Practicas XP: el juego de la planificación La gente de negocios debe decidir: El alcance de la aplicación: hasta donde tiene que llegar la aplicación para poder resolver un problema real en producción. Prioridades: que tareas son más prioritarias de realizar. Composición de las entregas: que debe contener cada entrega de la aplicación para que aporte valor respecto a la anterior. Fechas de las entregas: Que fechas, desde el punto de vista del negocio, son importantes y seria deseable tener el software terminado.

Practicas XP: el juego de la planificación La gente técnica debe decidir: Estimaciones: Cuanto puede llevar implementar una característica determinada. Consecuencias: Se debe informar de las consecuencias técnicas de las decisiones de negocios. Como por ejemplo confiar en un determinado proveedor de BD para la aplicación. Planificación detallada: Dentro de cada iteración los programadores tienen la libertad de planificar que características se implementaran primero.

Practicas XP: Entregas pequeñas Las entregas deben ser lo mas pequeñas posibles, pero deben contener características que aporten valor al producto final. Una entrega debe tener sentido como conjunto, es decir, no se puede hacer una entrega que implemente características sólo a medias a fin de reducir el tiempo de entrega. Es preferible planear una entrega con un plazo de un mes a planear entregas con un año de duración.

Practicas XP: Diseño Simple Un código bien diseñado debe cumplir lo siguiente: Pasar todos los test. No tener lógica duplicada. Tener el menor número posible de clases y métodos. Esto es justo lo contrario a una recomendación clásica del desarrollo de software: “programa para hoy, diseña para mañana”. No diseñes pensando en cual será el futuro, diseña sólo pensando en la forma más sencilla de poner el sistema en funcionamiento. Si en el futuro aparecen nuevos requerimientos: modifica el diseño.

Practicas XP: Test En XP se debe utilizar el desarrollo dirigido a Test. Dentro del desarrollo dirigido a test para cada funcionalidad nueva a implementar se siguen los pasos: Primero se escribe un test unitario. Se ejecuta el test, que obviamente fallara. Se escribe el código que implementa la funcionalidad. Cuando se consigue pasar el test el trabajo ha terminado.

Practicas XP: Test Test funcionales: los test funcionales o de aceptación deben ser escritos por el cliente, que es quien sabe lo que quiere de la aplicación. Si una característica de la aplicación no tiene su correspondiente test y ha sido pasado, sencillamente esa característica no existe.

Practicas XP: Refactorización Después de añadir una nueva característica el programador se debe preguntar si existe una forma más simple de diseñar su programa. Si existe un forma más simple se debe modificar el diseño y verificar que siguen pasando los test, a esto se le llama refactorización. De este modo no se modifica el diseño por especulación o “por lo que me puedan pedir mañana”, se modifica el código en el preciso instante en que aparece la necesidad de hacerlo.

Practicas XP: Programación en parejas Todo el código de producción es escrito por dos personas en una maquina, con un teclado y un ratón. En cada pareja hay dos roles: El primero, el que maneja el teclado y el ratón, piensa y en la mejor forma de implementar. El segundo piensa de una forma más estratégica: ¿esto va ha funcionar? ¿qué nuevos test se pueden introducir? ¿hay alguna manera de simplificar el diseño?

Practicas XP: Propiedad colectiva del código Nadie es dueño de ninguna porción del código, cualquiera puede ver y modificar cualquier parte del código si lo considera necesario. Todos los programadores toman la responsabilidad del sistema completo y no solo de “su” parte del código. Los programadores se mueven y cambian de tarea frecuentemente, esto implica que todo el mundo conoce todo el código y esta capacitado para cambiar cualquier parte del sistema.

Practicas XP: Integración Continua El código se integra y testea varias al veces al día, o al menos una vez al día. Se suele dedicar una maquina exclusivamente al proceso de integración. Existen programas que permiten automatizar y programar esta tarea. Este proceso ayuda enormemente a detectar lo más pronto posible posibles errores “colaterales”.

Practicas XP: 40 horas semanales No es necesario que sean exactamente 40 horas, diferentes personas tienen diferentes tolerancias al trabajo. Pero es importante que sean unas horas razonables que permitan a los integrantes del proyecto acudir cada mañana con la cabeza despejada y dispuesta para trabajar a pleno rendimiento. La regla en XP es: no trabajar por encima de las horas estipuladas dos semanas consecutivas. Si en algún momento aparece la necesidad de trabajar mas horas durante varias semanas consecutivas eso significa que el proyecto tiene un problema que no se va ha resolver simplemente trabajando mas horas.

Practicas XP: Cliente como parte del equipo Un cliente real se tiene que sentar junto al equipo de desarrollo. Un “cliente real” significa alguien que realmente vaya a usar el sistema, no confundir con el que paga. Una objeción a esta regla suele ser que el cliente es importante en su puesto actual de trabajo. Los gestores del proyecto deben preguntarse si merece la pena perder el trabajo de esta persona para tener un mejor sistema en menos tiempo. Si consideran que la perdida de una persona durante un determinado tiempo es de mayor importancia que el sistema quizás no merezca la pena construirlo.

Practicas XP: Estándares de codificación Si asumimos que todos los programadores deben ver el código de todos y todos pueden modificarlo no puede usar cada uno sus propios estándares de codificación. Tiene que llegar un momento en el que sea imposible saber que miembro del equipo ha escrito que líneas de código. El estándar debe ser adoptado voluntariamente por todo el equipo, es decir, se debe llegar a un acuerdo con el que todo el mundo este satisfecho. Una buena practica es incluir comprobaciones de que se cumple el estándar como un test más.

El proceso XP: Proyecto

El proceso XP: Iteracion

El proceso XP: Desarrollo

El proceso XP: Propiedad Colectiva del código

Roles en XP: Programador Programadores: los programadores son el corazón de XP. Los programadores tienen la responsabilidad de tomar todas las decisiones técnicas sobre el proyecto. No hay ningún otro rol técnico en XP además de los programadores. Un programador XP tiene que desarrollar ciertas habilidades: Aprender a trabajar en parejas Convertir la simplicidad en un habito Conocer las técnicas del desarrollo orientado a test Conocer las técnicas de refactorizacion.

Roles en XP: Cliente Es la otra parte de la dualidad fundamental en XP (programador/cliente), el cliente sabe lo que hay que hacer y el programador sabe como hacerlo. Un cliente XP debe aprender también ciertas habilidades: Escribir buenas historias de usuario. Escribir buenos test funcionales.

Roles en XP: Test El papel de tester dentro de un proceso XP esta asignado al cliente, el deberá ser el encargado de ejecutar los test y verificar que el sistema funciona. ¿quién mejor que el usuario final del sistema para probarlo?. El testeador en XP no es por tanto una persona sólo dedicada a tratar de romper el sistema y humillar a los programadores.

Roles en XP: Entrenador (Coach) Es el encargado del conjunto del proceso. Tiene que responsabilizarse de que todos los participantes del proceso cumplen con su parte y realizan adecuadamente las diferentes practicas de XP. Es el encargado también de proporcionar información y asesoramiento a los participantes en el proyecto de cómo ejecutar de forma más conveniente las practicas XP.

Roles en XP: Consultor En un equipo XP no hay especialistas en áreas de conocimiento determinadas. Es posible que en ocasiones y ante problemas concretos en equipo de XP necesite la ayuda de un experto en un área determinado que pueda aportar un conocimiento técnico más profundo sobre alguno cuestión. Una vez que el consultor ha terminado su trabajo los programadores XP deben tirar a la basura el código del consultor y hacerlo por ellos mismos gracias a los conocimientos adquiridos junto al consultor.