Ingeniera del software II

Metodologas giles eXtreme Programing

Metodologas giles

Las metodologas giles surgen como respuesta a las metodologas pesadas (PUD, Metrica, etc). La critica mas habitual a estas metodologas hay tanto que

hacer para seguir la metodologa que el ritmo entero del desarrollo se retarda.

Las metodologas giles cambian algunos de los nfasis de las metodologas pesadas. La diferencia inmediata es que son menos orientados al documento, exigiendo una cantidad ms pequea de documentacin para una tarea dada. En muchas maneras son ms bien orientados al cdigo: siguiendo un camino que dice que la parte importante de la documentacin es el cdigo fuente.

Manifiesto gil

Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A travs de esta experiencia hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas Software que funciona sobre documentacin exhaustiva Colaboracin con el cliente sobre negociacin 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 estn a la izquierda. (http://www.agilemanifesto.org/) Esta manifiesto esta firmado por algunos de los mas respetados expertos en ingeniera del software de la actualidad: Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Ken Schwaber etc

giles vs Pesadas

Los mtodos giles son adaptables en lugar de predictivos

Los mtodos 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 mtodos 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 mtodos giles son orientados a la gente y no orientados al proceso:

La meta de los mtodos pesados es definir un proceso que funcionar bien con cualquiera que lo use. Los mtodos giles afirman que ningn proceso podr nunca maquillar las habilidades del equipo de desarrollo. Las metodologas 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: diseo y construccin

La ingeniera del software tradicionalmente se ha inspirado en otras ingenieras, como por ejemplo la ingeniera civil. En estas ingenieras de desarrolla un diseo y posteriormente este es entregado a otras personas que se encargan de la construccin en base a ese diseo. Hay por tanto dos fases diferenciadas:

Diseo: 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: diseo y construccin

Intentado aplicar este enfoque al desarrollo de software surgen muchas preguntas:

Es posible entregar un diseo de software, por ejemplo en UML, que especifique claramente como se debe desarrollar el cdigo? Los diseos en UML son verificables para asegurarnos de su correccin antes de entregarlos para la fase de construccin? es la construccin suficientemente grande en costo y tiempo para hacer valer la pena este enfoque?

Predictivo vs Adaptable: diseo y construccin

Esta clase de preguntas llevaron a Jack Reeves* a sugerir que de hecho el cdigo fuente es un documento de diseo y que la fase de construccin est en realidad en la compilacin y el ligado Estas idea lleva a las siguientes conclusiones:

En software la construccin es tan barata que es casi gratis. En software todo el esfuerzo est en el diseo, de modo que requiere de personas creativas y talentosas. Los procesos creativos no se planean fcilmente, de modo que la previsibilidad bien puede ser una meta imposible. Debemos ser muy cautos al usar la metfora de la ingeniera 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 detrs de la ingeniera 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 fcil entender las necesidades del cliente, ni el sabe expresarlas en trminos de software ni nosotros entendemos en profundidad su negocio o actividad. El valor que proporciona un software es difcil de cuantificar a priori, solo cuando se comienza a usar es posible determinar la implementacin 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 dispusiramos de unos requisitos inamovibles, calcular el costo de implementacin de esos requisitos puede ser complejo por varias razones:

Porque los materiales bsicos cambian rpidamente. Las tecnologas evolucionan rpidamente y en ocasiones son complejas de utilizar. Por lo mucho que depende el software de los individuos involucrados, y los individuos son difciles de predecir y cuantificar.

Predictivo vs Adaptable

Todo esto nos lleva a la conclusin de que la actividad de desarrollar software es imposible o muy difcil de predecir o planear. Como en tantos problemas la parte ms difcil est simplemente en comprender que el problema existe. Por tanto el uso de metodologas predictivas no parece lo mas adecuado, para la gran mayora, del desarrollo de software. Las metodologas giles tratan de buscar respuesta a este problema mediante la Adaptabilidad

Adaptabilidad

La adaptabilidad se fundamenta en dos pilares fundamentales:

Construccin iterativa del software Relacin mas estrecha con el cliente

Orientados a la gente

Uno de los objetivos de las metodologas tradicionales es desarrollar un proceso donde las personas involucradas sean partes reemplazables. Con tal proceso se puede tratar a las personas como recursos que estn disponibles en varios tipos. Se tienen un analista, algunos programadores, algunos verificadores, un gerente. Los individuos no son tan importantes, slo los papeles lo son. Pero realmente son las personas involucradas en el desarrollo de software partes reemplazables? Uno de los rasgos importantes de los mtodos giles es el rechazo a esta afirmacin.

Orientados a la gente

La creacin de software es un proceso creativo y que requiere talento, ni es fcil medir el talento de las personas ni todas las personas tienen el mismo talento. La nocin de la gente como recursos esta profundamente inculcado en el pensamiento de negocios, teniendo sus races en el impacto del enfoque de La Direccin Cientfica de Frederick Taylor. En la administracin de una fbrica, 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 nocin 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 cmo dirigir su trabajo tcnico.

Orientados a la gente

Los desarrolladores deben poder tomar todas las decisiones tcnicas. Slo los desarrolladores pueden estimar cunto 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 proporcionndoles 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.

Metodologas giles

Basndose en estos principios existen diversas metodologas:

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 metodologa gil mas extendida

eXtreme Programming

XP es una metodologa pensada para equipos de desarrollo de tamao pequeo o medio que trabajan en proyectos donde los requisitos varan con mucha frecuencia. El extreme en el nombre de la metodologa viene dado por que segn los autores tratan de llevar al extremo practicas que consideran de sentido comn en el desarrollo de software.

eXtreme Programming

Revisar el cdigo es bueno, XP propone revisarlo constantemente (programacin en parejas). Testear el cdigo es bueno, XP propone testear constantemente (desarrollo dirigido a test) Disear es bueno, XP propone que el diseo 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 das. No tener que afrontar problemas o situaciones difciles 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 podrn ver resultados concretos del trabajo. Se podr cambiar la direccin del proyecto durante el desarrollo sin tener que asumir un coste exorbitante.

Valores de XP

Comunicacin:

Muchos proyectos fracasan por errores en la comunicacin. Las tcnicas de XP estn orientadas a fomentar la comunicacin entre los distintos integrantes del proyecto. XP pretende que todos los programadores tengan un visin global proyecto, que el cliente este presente en el desarrollo y otras tcnicas que sirven para fomentar esta comunicacin.

Valores de XP

Simplicidad

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

Valores de XP

Retroalimentacin (feedback)

Retroalimentacin del sistema: Escribiendo test unitarios que proporcionen informacin constante acerca del estado del sistema Retroalimentacin del cliente: El cliente escribe los test funcionales y prueba el sistema proporcionando informacin sobre su funcionamiento.

Valores de XP

Coraje

Los desarrolladores tienen que tener coraje para afrontar ciertas circunstancias del desarrollo, ejemplos:

Coraje para refactorizar el cdigo 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 metodologa XP se deben seguir una serie de practicas. Estas practicas en su mayora no son nada nuevo, son practicas que se llevan usando en programacin durante aos. La novedad en XP es incluirlas todas juntas dentro del contexto de una metodologa.

Practicas XP: el juego de la planificacin

El desarrollo de software es a menudo un dialogo entre lo posible y lo deseable. Dentro de la planificacin tendrn que intervenir tanto gente conocedora del negocio y del problema a resolver por a aplicacin como la gente tcnica encargada de hacer la aplicacin. Los primeros hablaran de lo deseable y lo segundos de lo posible, intentando acercar los dos puntos lo mximo posible.

Practicas XP: el juego de la planificacin

La gente de negocios debe decidir:

El alcance de la aplicacin: hasta donde tiene que llegar la aplicacin para poder resolver un problema real en produccin. Prioridades: que tareas son ms prioritarias de realizar. Composicin de las entregas: que debe contener cada entrega de la aplicacin 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 planificacin

La gente tcnica debe decidir:

Estimaciones: Cuanto puede llevar implementar una caracterstica determinada. Consecuencias: Se debe informar de las consecuencias tcnicas de las decisiones de negocios. Como por ejemplo confiar en un determinado proveedor de BD para la aplicacin. Planificacin detallada: Dentro de cada iteracin los programadores tienen la libertad de planificar que caractersticas se implementaran primero.

Practicas XP: Entregas pequeas

Las entregas deben ser lo mas pequeas posibles, pero deben contener caractersticas que aporten valor al producto final. Una entrega debe tener sentido como conjunto, es decir, no se puede hacer una entrega que implemente caractersticas slo 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 ao de duracin.

Practicas XP: Diseo Simple

Un cdigo bien diseado debe cumplir lo siguiente: Pasar todos los test. No tener lgica duplicada. Tener el menor nmero posible de clases y mtodos. Esto es justo lo contrario a una recomendacin clsica del desarrollo de software: programa para hoy, disea para maana. No disees pensando en cual ser el futuro, disea slo pensando en la forma ms sencilla de poner el sistema en funcionamiento. Si en el futuro aparecen nuevos requerimientos: modifica el diseo.

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 cdigo que implementa la funcionalidad. Cuando se consigue pasar el test el trabajo ha terminado.

Practicas XP: Test

Test funcionales: los test funcionales o de aceptacin deben ser escritos por el cliente, que es quien sabe lo que quiere de la aplicacin. Si una caracterstica de la aplicacin no tiene su correspondiente test y ha sido pasado, sencillamente esa caracterstica no existe.

Practicas XP: Refactorizacin

Despus de aadir una nueva caracterstica el programador se debe preguntar si existe una forma ms simple de disear su programa. Si existe un forma ms simple se debe modificar el diseo y verificar que siguen pasando los test, a esto se le llama refactorizacin. De este modo no se modifica el diseo por especulacin o por lo que me puedan pedir maana, se modifica el cdigo en el preciso instante en que aparece la necesidad de hacerlo.

Practicas XP: Programacin en parejas

Todo el cdigo de produccin es escrito por dos personas en una maquina, con un teclado y un ratn. En cada pareja hay dos roles:

El primero, el que maneja el teclado y el ratn, piensa y en la mejor forma de implementar. El segundo piensa de una forma ms estratgica:

esto va ha funcionar? qu nuevos test se pueden introducir? hay alguna manera de simplificar el diseo?

Practicas XP: Propiedad colectiva del cdigo

Nadie es dueo de ninguna porcin del cdigo, cualquiera puede ver y modificar cualquier parte del cdigo si lo considera necesario. Todos los programadores toman la responsabilidad del sistema completo y no solo de su parte del cdigo. Los programadores se mueven y cambian de tarea frecuentemente, esto implica que todo el mundo conoce todo el cdigo y esta capacitado para cambiar cualquier parte del sistema.

Practicas XP: Integracin Continua

El cdigo se integra y testea varias al veces al da, o al menos una vez al da. Se suele dedicar una maquina exclusivamente al proceso de integracin. Existen programas que permiten automatizar y programar esta tarea. Este proceso ayuda enormemente a detectar lo ms 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 maana 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 algn 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 objecin 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 quizs no merezca la pena construirlo.

Practicas XP: Estndares de codificacin

Si asumimos que todos los programadores deben ver el cdigo de todos y todos pueden modificarlo no puede usar cada uno sus propios estndares de codificacin. Tiene que llegar un momento en el que sea imposible saber que miembro del equipo ha escrito que lneas de cdigo. El estndar 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 estndar como un test ms.

El proceso XP: Proyecto

El proceso XP: Iteracion

El proceso XP: Desarrollo

El proceso XP: Propiedad Colectiva del cdigo

Roles en XP: Programador

Programadores: los programadores son el corazn de XP. Los programadores tienen la responsabilidad de tomar todas las decisiones tcnicas sobre el proyecto. No hay ningn otro rol tcnico en XP adems de los programadores. Un programador XP tiene que desarrollar ciertas habilidades: Aprender a trabajar en parejas Convertir la simplicidad en un habito Conocer las tcnicas del desarrollo orientado a test Conocer las tcnicas 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 tambin 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. quin mejor que el usuario final del sistema para probarlo?. El testeador en XP no es por tanto una persona slo 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 tambin de proporcionar informacin y asesoramiento a los participantes en el proyecto de cmo ejecutar de forma ms 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 tcnico ms profundo sobre alguno cuestin. Una vez que el consultor ha terminado su trabajo los programadores XP deben tirar a la basura el cdigo del consultor y hacerlo por ellos mismos gracias a los conocimientos adquiridos junto al consultor.