Estudiante: Diego R.
Barrientos Jaldn
Programacin Extrema (XP)
Programacin Extrema es un proceso de desarrollo de software para grupos de dos a diez programadores, capaz de encarar el cambio de requerimientos y que implica poco riesgo de fracaso porque es predecible, porque en ste la comunicacin es primordial y porque se hace en cortas iteraciones. XP lleva, adems, el sentido comn a niveles extremos, como indica su nombre: Si es tan bueno hacer revisiones y evaluaciones al cdigo, las revisiones se hacen todo el tiempo porque se programa de a dos. Como es primordial hacer pruebas, stas se hacen siempre; sin pruebas no hay cdigo ni funcionalidad, ya que se usa TDD. Tan importante es la simplicidad que se construye lo ms sencillo que funcione. Siendo las cortas iteraciones tan buenas, se hacen iteraciones de hasta horas. Del mismo modo, XP hace 2 tipos de promesas: A los programadores les dice que van a trabajar en cosas que realmente importen, nunca van a encarar algo solos, van a tener todo a disposicin para alcanzar el xito y nunca van a tener que tomar decisiones para las que no estn facultados. Y a los clientes y encargados les avisa que el ROI es alto, siempre van a poder ver productos que funcionen y si a la mitad del proyecto quieren hacer cambios, lo podrn hacer sin incurrir en grandes gastos.
Cmo se reduce el riesgo de fracaso en XP La forma en que XP reduce el riesgo de fracasar es as: Para evitar pasarse del tiempo estipulado, se hacen iteraciones bien cortas de una a cuatro semanas que devuelven productos de valor para los clientes; dejando las de menor valor para despus. Para evitar el deterioro del software, todo el tiempo se crean tests que se ejecutan despus de cada cambio y que aseguran que el programa est funcionando y est en buenas condiciones. El poco entendimiento del negocio se elimina porque existe un contacto muy cercano con el cliente que continuamente ensea que es lo que necesita del software.
El ciclo de desarrollo XP El ciclo de desarrollo XP es de la siguiente forma: Las parejas de programadores trabajan siempre juntos. El desarrollo es dirigido por los tests, primero se hacen los tests y despus se programa. No se termina la tarea hasta que todos los tests corran y cuando ya no se puede aadir ms tests quiere decir que la funcionalidad est hecha. Las parejas no slo hacen que las pruebas corran, su misin tambin es la de aadir valor en cualquier parte que el software lo necesite. Al desarrollo siempre le sigue la integracin, incluyndose los respectivos tests de esta tarea.
Los cuatro valores de XP Comunicacin Los problemas en los proyectos se dan generalmente por una mala comunicacin; hay una persona que no habla con otra sobre algo importante. Son cosas como que un desarrollador le cuenta de alguna falla al encargado y ste lo castiga, o que el cliente le menciona algo importante a un programador y ste le resta importancia. Para eso XP hace que la comunicacin se d con frecuencia: el trabajo en parejas, las pruebas unitarias. Pero si an as se pierde la comunicacin ya sea por miedo, errores o distraccin, XP tiene un entrenador que se encarga de reincorporar a la gente que dej de comunicarse. Simplicidad XP trata de que se haga lo ms simple, pero que funcione. Es mejor hacer algo simple ahora y que despus haya que hacer algo ms, que hacer algo complicado que nunca ms va a ser usado. La comunicacin y la simplicidad estn muy ligadas: mientras haya ms comunicacin, es ms fcil darse cuenta qu cosas no deben ser hechas. Retroalimentacin La retroalimentacin trabaja a varios niveles de tiempo, por ejemplo cuando los programadores escriben sus tests y stos funcionan estn recibiendo retroalimentacin en minutos. Cuando los clientes describen caractersticas (features) se les da la retroalimentacin acerca de la calidad de stas cuando los desarrolladores estiman el tiempo. Mientras ms retroalimentacin la comunicacin se hace ms fcil. Coraje El coraje se refiere a, por ejemplo, si es que se halla una falla en el cdigo y la correccin de sta hace que los tests que estaban funcionando dejen de hacerlo, tener el valor de hacer lo correcto y arreglarlo de modo que los test vuelvan a correr o finalmente se eche todo a la basura y comenzar de nuevo.
Las prcticas de XP El Juego de Planeacin No son ms importantes las cuestiones tcnicas que las de negocio ni viceversa. Siempre hay que preguntarse entre los posible y lo deseable. Hay cosas sobre las que las personas del negocio deciden y otras sobre la que los desarrolladores deben hacerlo. Las personas del negocio deben decidir cunto del software debe ser resuelto para que tenga un valor. Tambin deben decidir sobre la prioridad de las funcionalidades y los tiempos de lanzamiento. Los desarrolladores deciden sobre las estimaciones, sobre el proceso que se llevar a cabo (cmo se va a organizar el equipo) y sobre el detalle de los tiempos de entrega. Lanzamientos Pequeos Cada lanzamiento debe ser tan pequeo como se pueda, conteniendo los requerimientos de negocio ms valiosos. El lanzamiento, adems, debe tener sentido porque no se puede implementar a medias una caracterstica slo por hacer que el tiempo de entrega ms corto, si se requiere un poco ms de tiempo no hay ningn problema. Metfora La metfora se refiere a cmo debe ser el software a desarrollar, a que debe asemejarse. Los proyectos XP son guiados por una metfora, como por ejemplo, la sitio web debe dar la impresin de ser un diario de verdad, el rea donde se escribe debe parecerse a la pgina de un diario o el mezclador de sonido debe tener semejanzas con los dispositivos que usa un dj. Las entidades tcnicas se sacan de la metfora, mientras el desarrollo avanza, la metfora madura y se encuentran nuevas cosas examinndola.
Diseo Simple 1. 2. 3. 4. Todos los tests deben correr. No debe haber duplicacin. Decir las intenciones importantes a los programadores. Se debe tener la menor cantidad posible de mtodos y clases.
Se debe quedar con slo lo necesario para que el programa funcione. Testeo Una caracterstica de programa sin test no sirve. Los desarrolladores escriben pruebas unitarias para generar confianza en el programa, as como los clientes escriben los tests con el mismo objetivo. Refactorizacin La refactorizacin es mejorar el cdigo (hacerlo ms simple), sin hacer que los tests dejen de correr. Aunque se hacen ms cosas que las que se deberan hacer para que la caracterstica funcione, con la refactorizacin se hace ms fcil el aadir nuevas caractersticas despus. Programacin en Pares Toda escritura de cdigo se hace en parejas, con una sola mquina. Hay dos roles en cada pareja: uno (el que tiene el control sobre el ratn y el teclado) que est pensando ya la mejor forma de escribir el mtodo y el otro que debe preguntarse sobre el enfoque usado, sobre tests que no se han hecho todava y sobre la manera de simplificar. Propiedad Colectiva Todos los desarrolladores tienen responsabilidad sobre todo el sistema. Esto no quiere decir que cada uno debe conocer cada parte del sistema, sino que si ve que puede hacer una mejora, la hace lo ms antes posible.
Integracin Continua Despus de que todos los tests pasan se procede inmediatamente a la integracin, haciendo los tests respectivos para ello. La mejor forma es mediante una mquina dedicada a este propsito. Si la mquina est libre, una pareja se pone a integrar su parte y una vez terminado esto, todos lo tests anteriores deben pasar. Esto ayuda a detectar al culpable del error, puesto que antes de integrarse lo ltimo todos los tests pasaban. Estndares de Codificacin Ya que va a haber una rotacin en las parejas, y stas van a tener que trabajar sobre el cdigo de otra, lo mejor es trabajar con estndares. Esto tambin har que sea muy difcil saber quien escribi que parte del cdigo. Todos los miembros del equipo deben aceptar voluntariamente los estndares.
