programacion extrema

5
PROGRAMACIÓN EXTREMA (XTREME PROGRAMING (XP)) Es una metodología de desarrollo de software formulado hace un poco mas de 10 años por Kent Beck, autor del primer libro sobre esta materia, "Extreme Programming Explained: Embrace Change (Una explicación de la Programación extrema: aceptar el cambio)(1999) ". Es el método más destacado de los procesos ágiles de desarrollo de software. Pasa por alto la utilización de elaborados casos de uso, la exhuberante definicion de requerimientos y una extensa documentación. La programación extrema es una opción a considerar cuando se debe entregar el software en lapsos menores de tiempo y con exigencias de costos reducidos y altos estándares de calidad. También XP es una metodología interesante para pequeños y medianos proyectos, donde los equipos de programadores sean menores a 10 y mayores a 1. Los objetivos de la programación extrema son muy sencillos: la satisfacción del cliente. Esta metodología concuerda dar al cliente lo que el necesita y cuando lo necesita, por lo tanto se debe responder rápidamente las necesidades del cliente aún cuando los cambios sean al final del ciclo de la programación. La programación está en constantes "riesgos", por ejemplo, el riesgo de entrega tardía del proyecto al cliente, la cancelación del proyecto por altos costos de mantenimiento, cambios en los requerimientos originales, desintegración del equipo, las espectativas del cliente no son cubiertas por el producto, etc. Y por lo tanto la programación extrema trata de evitar estos riesgos en el desarrollo del software. VALORES La Programación Extrema se fundamenta en cuatro valores escenciales: simplicidad, comunicación, retroalimentación y coraje. Un quinto valor fue añadido en la segunda edición de Extreme Programming Explained y este fue el respeto. Simplicidad: La programación extrema hace que los desarrolladores intenten producir el código más simple que realice la funcionalidad requerida. Ninguna función debe ser agregada si no se requiere en ese momento, esto hace al programa muy simple en todo momento. Comunicación: La programación no puede ser llevada a cabo si no es llevado a cabo un nivel adecuado de comunicación entre los

Upload: skabeche-deskabechado

Post on 11-Nov-2015

220 views

Category:

Documents


0 download

DESCRIPTION

Descripcion de programacion extrema

TRANSCRIPT

PROGRAMACIN EXTREMA (XTREME PROGRAMING (XP))

Es una metodologa de desarrollo de software formulado hace un poco mas de 10 aos por Kent Beck, autor del primer libro sobre esta materia, "Extreme Programming Explained: Embrace Change (Una explicacin de la Programacin extrema: aceptar el cambio)(1999)". Es el mtodo ms destacado de los procesos giles de desarrollo de software. Pasa por alto la utilizacin de elaborados casos de uso, la exhuberante definicion de requerimientos y una extensa documentacin.La programacin extrema es una opcin a considerar cuando se debe entregar el software en lapsos menores de tiempo y con exigencias de costos reducidos y altos estndares de calidad. Tambin XP es una metodologa interesante para pequeos y medianos proyectos, donde los equipos de programadores sean menores a 10 y mayores a 1.Los objetivos de la programacin extrema son muy sencillos: la satisfaccin del cliente. Esta metodologa concuerda dar al cliente lo que el necesita y cuando lo necesita, por lo tanto se debe responder rpidamente las necesidades del cliente an cuando los cambios sean al final del ciclo de la programacin. La programacin est en constantes "riesgos", por ejemplo, el riesgo de entrega tarda del proyecto al cliente, la cancelacin del proyecto por altos costos de mantenimiento, cambios en los requerimientos originales, desintegracin del equipo, las espectativas del cliente no son cubiertas por el producto, etc. Y por lo tanto la programacin extrema trata de evitar estos riesgos en el desarrollo del software.

VALORESLa Programacin Extrema se fundamenta en cuatro valores escenciales: simplicidad, comunicacin, retroalimentacin y coraje. Un quinto valor fue aadido en la segunda edicin de Extreme Programming Explained y este fue el respeto.Simplicidad: La programacin extrema hace que los desarrolladores intenten producir el cdigo ms simple que realice la funcionalidad requerida. Ninguna funcin debe ser agregada si no se requiere en ese momento, esto hace al programa muy simple en todo momento.Comunicacin: La programacin no puede ser llevada a cabo si no es llevado a cabo un nivel adecuado de comunicacin entre los programadores, administradores y el cliente. Retroalimentacin: Al estar el cliente integrando y supervisando el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real y de esa manera los programadores pueden tener una mejor manera de llevarlo a cabo.Coraje: Este valor hace referencia a la actitud del equipo frente a la programacin a mxima velocidad, a estar dispuestos a desechar el cdigo que o funciona, sin importar la cantidad de este, o a codificar diferentes alternativas para compararlas y seleccionar la mejor.Respeto: Se deben respetar los miembros del equipo unos a los otros y sobre todo deben respetar su trabajo, porque siempre se debe estar luchando por la alta calidad del producto y buscando el diseo mas eficiente para la solucin a travs de la refactorizacin del cdigo. Los miembros del equipo no deben hacer menos a otros.

PRACTICASLa programacin extrema especifica ciertas prcticas que deben llevarse a cabo al implementar este modelo:1. La planeacin, en la cual la opinin del cliente y del equipo de desarrollo deben fusionarse como un todo coherente. 2. Entregas en iteraciones pequeas, que permitan al cliente utilizar el sistema con las funcionalidades mnimas lo antes posible, e irlo complementando por etapas y continuamente. 3. Manejo de metforas, donde la metfora ayuda a que todo el equipo de desarrollo entienda los elementos bsicos del sistema y las relaciones entre ellos sin la necesidad de una arquitectura muy compleja. 4. Diseo simple, donde siempre se intenta tener el cdigo ms simple, menos redundante y con las funcionalidades estrictamente necesarias en el presente. 5. Pruebas continuas, donde es imperativo que los programadores escriban pruebas por cada unidad de cdigo y que el cliente participe en el diseo de pruebas funcionales. 6. Refactorizacin, donde este concepto se refiere a mantener una depuracin y simplificacin constante del sistema. Una vez que se ha aadido alguna funcionalidad, es necesario revisar y ser crticos para encontrar puntos de simplificacin del cdigo. 7. Programacin en pares, donde toda la codificacin debe hacerse en parejas de programadores, cada pareja compartiendo un mismo monitor y teclado. El que utiliza el teclado piensa en la mejor manera de implementar alguna funcionalidad, el otro piensa estratgicamente, cuestionando si se puede simplificar, anticipando pruebas, o preguntndose si el enfoque es el adecuado o si debe descartarse cdigo y replantear el problema. Se alienta la rotacin continua de programadores en los pares, combinando diferentes niveles de experiencia y de conocimiento del cdigo. 8. Propiedad colectiva del cdigo. Aqu se dice que el cdigo puede ser modificado por cualquier elemento del equipo de programacin, esto es, que no hay propiedad individual de algn programador sobre alguna parte de cdigo. Se asume que al seguir las prcticas de la programacin extrema, despus de un tiempo razonable, cualquier programador conoce todo el cdigo, principalmente por el hecho de la programacin en pares. 9. Integracin continua (mantener una sola revisin para todo el equipo de programacin), tan pronto como pequeos saltos en la versin actual sean concluidos. Se recomiendan lapsos entre integraciones de pocas horas a no ms de un da. 10. Semana de 40 horas. La programacin extrema afirma que las condiciones de trabajo ptimas para programar a mxima velocidad es solo en un turno normal (8 horas). En este sentido las horas extras o fines de semana trabajados solo desgastan al equipo de programacin, afectan el rendimiento y generan un ambiente apto para cometer errores, ser desordenados en el apego a las normas y producir software de mediocre calidad. 11. El cliente debe estar disponible localmente, donde un representante del cliente debe permanecer por turnos completos en el sitio de programacin para contestar cualquier pregunta y ayudar en el desarrollo de pruebas funcionales. 12. Mantener estndares de codificacin entre los programadores. Esto es esencial para la programacin en pares y para la propiedad colectiva del cdigo

CONTROVERSIASLa programacin extrema ha causado un gran revuelo en la comunidad de la ingenieria de software. Aqu muestro una grfca realizada por IBM:

XP tiene muchas controversias especialmente con la programcin en parejas, ya que muchos programadores se sienten poseedores del cdigo, creen que ellos son los mejores conocedores de las herramientas y leguajes que utilizan y que si no los entienden es porque los dems no saben lo suficiente.Tambin se critica el mito de las 40 horas semanales, y que es un lujo para las exigiencias del mercado. La programacin extrema supone:

Las personas son claves en los procesos de desarrollo. Los programadores son profesionales no necesitan supervisin.Los procesos se aceptan y se acuerdan, no se imponen. Desarrolladores y gerentes comparten el liderazgo del proyecto. El trabajo de los desarrolladores con las personas que conocen el negocio es regular, no puntual.

ROLESAunque en otras fuentes de informacin aparecen algunas variaciones y extensiones de roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original de Beck. ProgramadorEscribe las pruebas unitarias y produce el cdigo del sistema.ClienteEscribe las historias de usuario y las pruebas funcionales para validar su implementacin. Asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar el mayor valor de negocio.TesterAyuda 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 retroalimentacin 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. Gua a los miembros del equipo para seguir el proceso correctamente.ConsultorEs un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Ayuda al equipo a resolver un problema especfico.Gestor (Big boss)Es el dueo de la tienda y el vinculo entre clientes y programadores. Su labor esencial es la coordinacin.