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
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
