05 enero 2006


eXtreme Programming

    La programación extrema (eXtreme Programming) o XP, es una disciplina de desarrollo basada en la simplicidad. XP aparece para, que equipos pequeños que necesitan desarrollar software rápidamente, puedan realizarlo en un ambiente donde los requisitos cambian rápidamente.

    La metodología de Desarrollo de Software, siempre necesitará ser modificada para adaptarla a los requisitos particulares del cliente y de las circunstancias. XP no es ninguna excepción.

Hay doce prácticas para aplicar XP:

El proceso de planteamiento o juego de la planificación

          Permite que el XP cliente defina el valor de negocio y las características deseadas, y utiliza las valoraciones de coste proporcionadas por los programadores, para elegir si necesita ser desarrollado o dejar aparcado. Con este proceso es fácil llevar el proyecto a “buen puerto”.

Entregas pequeñas

          La idea es producir rápidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad, pero constituyan un resultado de valor para el negocio.

Metáfora

          Una metáfora, es una historia compartida que describe cómo debería funcionar el sistema. El sistema es definido por una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. La metáfora consiste en formar un conjunto de nombres que actúen como vocabulario para hablar sobre el dominio del problema.

Diseño simple

          Se debe diseñar la solución más simple que puede funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el código extra debe ser removido inmediatamente.

Pruebas

          La producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación del sistema. En este desarrollo y pruebas constantes, la automatización para apoyar esta actividad es crucial.

Refactorización (Refactoring)

          La refactorización es una actividad constante de reestructuración del código con el fin de remover duplicación de código, mejorar legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. Para mantener un diseño apropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.

Programación en parejas

          Toda la producción de código debe realizarse en parejas de programadores. Muchos errores son detectados conforme son introducidos y la tasa de errores del producto final son mucho menores, los diseños son mejores y el tamaño del código menor, los problemas de programación se resuelven más rápido, se transfieren los conocimientos de programación entre los miembros del equipo, varias personas entienden las diferentes partes del sistema, mejora el flujo de información y la dinámica del equipo.

Propiedad colectiva

          Cualquier programador puede cambiar cualquier parte del código en cualquier momento. Esta práctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algún programador sea imprescindible para realizar cambios en alguna porción de código.

Integración continúa

          Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporado definitivamente. La integración continua a menudo reduce la fragmentación de los esfuerzos de los desarrolladores por falta de comunicación sobre lo que puede ser reutilizado o compartido. Esto es esencial para un proyecto controlado.

40 horas por semana

          Se debe trabajar un máximo de 40 horas por semana. No se trabajo horas extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debe corregirse. El trabajo extra desmotiva el equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificación para cambiar el ámbito del proyecto o la fecha de entrega.

Cliente in-situ

          El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del éxito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. Algunas recomendaciones propuestas para dicha situación son las siguientes: intentar conseguir un representante que pueda estar siempre disponible y que actúe de interlocutor del cliente, contar con el cliente al menos en las reuniones de planificación, establecer visitaqs frecuentes de los programadores al cliente para validar el sistema, anticiparse a los problemas aosociados estableciendo llamadas telefónicas frecuentes y conferencias, reforzando el compromiso de trabajo en equipo.

Estándares de programación

          Es indispensable que se sigan ciertos estándares de programación. Estos mantienen el código legible para los miembros del equipo, facilitando los cambios.

Todas estas prácticas, se refuerzan entre sí.

Fuente original seraKesi.com
Extreme Programming