Sexo
LocalizaciónProgramación Extrema
¿Qué es?
La programación extrema es una metodología de ingeniería de software
para el desarrollo del mismo, que hace énfasis en los siguientes
aspectos: satisfacción del cliente y trabajo en equipo.
¿Cuándo se debe usar?
La programación extrema fue creada pensando en las siguientes circunstancias:
* Proyectos en los que los requisitos tienen altas
probabilidades de cambiar con el tiempo (por ejemplo, porque el cliente
no tiene claro lo que quiere, o porque el cambio de requisitos está
ligado al dominio del problema a resolver).
* Proyectos con alto riesgo (por ejemplo, proyectos con una
fecha de entrega que es indispensable cumplir, o proyectos totalmente
novedosos para la industria).
* Proyectos con un grupo pequeño de programadores (entre 2 y
12), aunque el equipo completo sea bastante más extenso (incluye a jefes
de equipo y representantes de clientes).
Aspectos destacados
Los aspectos que habitualmente se destacan cuando se habla de programación extrema son los siguientes:
* Desarrollo basado en iteraciones incrementales, usando user stories como guía.
* Muchos lanzamientos con pequeños cambios
* Simplicidad.
* Refactorización (reescritura de código/diseño para mejorar la
legibilidad y/o comprensión del mismo sin cambiar el significado).
* Constante interacción con el cliente durante todo el
desarrollo (user stories, dudas durante el desarrollo, pruebas de
aceptación...).
* Codificación en parejas.
* Propiedad colectiva de todo el código
* Pruebas unitarias codificadas antes que el propio código, que deben ser pasadas antes del lanzamiendo del mismo
* Pruebas de integración e integración del código realizadas secuencialmente y de forma frecuente
* Pruebas de aceptación realizadas frecuentemente
¿Qué prácticas engloba?
La programación extrema está compuesta por una serie de prácticas y
actividades. En la imagen podemos ver el mapa de un proyecto que usa
esta metodología:
Las prácticas que componen la programación extrema se pueden agrupar
en cuatro grandes bloques: plan, diseño, codificación y pruebas. Sin
embargo, estos bloques no deben realizarse en orden, si no que cada uno
consta de una serie de actividades, y todas ellas se irán realizando de
manera evolutiva.
Las actividades son las siguientes:
*
Planificacion
o Se escriben user stories, cuya idea principal es
describir un caso de uso en dos o tres líneas con terminología del
cliente (de hecho, se supone que deben ser escritos por el mismo), de
tal manera que se creen test de aceptación para el user storie y permita
hacer una estimación de tiempo de desarrollo del mismo.
o Se crea un plan de lanzamiento (release planning), que
debe servir para crear un calendario que todos puedan cumplir y en cuyo
desarrollo hayn participado todas las personas involucradas en el
proyecto. Se usará como base los user stories, participando el cliente
en la elección de los que se desarrollarán, y según las estimaciones de
tiempo de los mismos se crearán las iteraciones del proyecto.
o Se hacen pequeños lanzamientos con mucha frecuencia.
o El desarrollo se divide en iteraciones, cada una de las
cuales comienza con un plan de iteración para el que se eligen las user
stories a desarrollar y las tareas de desarrollo.
o Las personas cambian de área para evitar cuellos de botella y fomentar la propiedad colectiva del código.
o Se cambia el proceso lo que sea necesario para adaptarlo a tu proyecto.
*
Diseño
o Se eligen los diseños más simples que funcionen.
o Se elige una metáfora del sistema para que el nombrado
de clases, etcétera, siga una misma línea, facilitando la reutilización y
la comprensión del código.
o Se escriben tarjetas CRC
(class-responsabilities-collaboration) de
clase-responsabilidades-colaboración para cada objeto, que permiten
abstraerse el pensamiento estructurado y que el equipo de desarrollo al
completo participe en el diseño.
o Se "refactoriza sin piedad". Basicamente, consiste en no
tener miedo de cambiar un diseño o eliminar un código que ya no sirve, o
al menos que ya no es claramente la mejor solución.
*
Codificación
o El cliente está siempre disponible, a ser posible cara a
cara. La idea es que forme parte del equipo de desarrollo, y esté
presente en todas las fases de XP (escribe los user stories con la ayuda
de los desarrolladores, participa en la elección de los que entrarán en
el plan de lanzamientos, prueba pequeños lanzamientos, participa en las
pruebas de funcionalidad...). La idea es usar el tiempo del cliente
para estas tareas en vez de para que cree una detalladísima
especificación de requisitos, y evitar la entrega de un producto peor
que le hará perder tiempo.
o El código se ajustará a unos estándares de codificación,
asegurando la consistencia y facilitando la comprensión y
refactorización del código.
o Las pruebas unitarias se codifican antes que el código
en sí, haciéndo que la codificación de este último sea más rápida, y que
cuando se afronte la misma se tenga más claro qué objetivos tiene que
cumplir lo que se va a codificar.
o La programación del código se realizará en parejas, para
aumentar la calidad del mismo. En cada momento, sólo habrá una pareja
de programadores integrando código.
o Se integra código y se lanza dicha integración de manera
frecuente, evitando divergencias en el desarrollo y permitiendo que
todo el mundo trabaje con la última versión del desarrollo. De esta
manera, se evitará pasar grandes periodos de tiempo integrando el código
al final del desarrollo, ya que las incompatibilidades habrán sido
detectadas enseguida.
o Se usa la propiedad colectiva del código, lo que se
traduce en que cualquier programador puede cambiar cualquier parte del
código. El objetivo es fomentar la contribución de ideas por parte de
todo el equipo de desarrollo
o Se deja la optimización para el final
o No se hacen horas extra de trabajo
*
Pruebas
o Todo el código debe tener pruebas unitarias, y debe pasarlas antes de ser lanzado.
o Cuando se encuentra un error de codificación o bug, se desarrollan pruebas para evitar volver a caer en el mismo.
o Se realizan pruebas de aceptación frecuentemente,
publicando los resultados de las mismas. Estas pruebas son generadas a
partir de las user stories elegidas para la iteración, y son "pruebas de
caja negra", en las que el cliente verifica el correcto funcionamiento
de lo que se está probando. Cuando se pasa la prueba de aceptación, se
considera que el correspondiente user storie se ha completado.
Fuente
Pido disculpas por haber posteado sin los libros recien, pero se me
colgo todo aca y lo unico q andaba era el firefox :p asi q ahora agrego
estos 3 libros.
Requirments Architecture Extreme Programming Design Patterns (ADDISON_WESLEY-Design_Patterns_Explained)
Teach Yourself Extreme Programming In 24 Hours
Addison Wesley - Kent Beck, Martin Fowler - Planning Extreme Programming
http://rapidshare.com/files/33547244/programacion_extrema.rar.html
¿Qué es?
La programación extrema es una metodología de ingeniería de software
para el desarrollo del mismo, que hace énfasis en los siguientes
aspectos: satisfacción del cliente y trabajo en equipo.
¿Cuándo se debe usar?
La programación extrema fue creada pensando en las siguientes circunstancias:
* Proyectos en los que los requisitos tienen altas
probabilidades de cambiar con el tiempo (por ejemplo, porque el cliente
no tiene claro lo que quiere, o porque el cambio de requisitos está
ligado al dominio del problema a resolver).
* Proyectos con alto riesgo (por ejemplo, proyectos con una
fecha de entrega que es indispensable cumplir, o proyectos totalmente
novedosos para la industria).
* Proyectos con un grupo pequeño de programadores (entre 2 y
12), aunque el equipo completo sea bastante más extenso (incluye a jefes
de equipo y representantes de clientes).
Aspectos destacados
Los aspectos que habitualmente se destacan cuando se habla de programación extrema son los siguientes:
* Desarrollo basado en iteraciones incrementales, usando user stories como guía.
* Muchos lanzamientos con pequeños cambios
* Simplicidad.
* Refactorización (reescritura de código/diseño para mejorar la
legibilidad y/o comprensión del mismo sin cambiar el significado).
* Constante interacción con el cliente durante todo el
desarrollo (user stories, dudas durante el desarrollo, pruebas de
aceptación...).
* Codificación en parejas.
* Propiedad colectiva de todo el código
* Pruebas unitarias codificadas antes que el propio código, que deben ser pasadas antes del lanzamiendo del mismo
* Pruebas de integración e integración del código realizadas secuencialmente y de forma frecuente
* Pruebas de aceptación realizadas frecuentemente
¿Qué prácticas engloba?
La programación extrema está compuesta por una serie de prácticas y
actividades. En la imagen podemos ver el mapa de un proyecto que usa
esta metodología:
Las prácticas que componen la programación extrema se pueden agrupar
en cuatro grandes bloques: plan, diseño, codificación y pruebas. Sin
embargo, estos bloques no deben realizarse en orden, si no que cada uno
consta de una serie de actividades, y todas ellas se irán realizando de
manera evolutiva.
Las actividades son las siguientes:
*
Planificacion
o Se escriben user stories, cuya idea principal es
describir un caso de uso en dos o tres líneas con terminología del
cliente (de hecho, se supone que deben ser escritos por el mismo), de
tal manera que se creen test de aceptación para el user storie y permita
hacer una estimación de tiempo de desarrollo del mismo.
o Se crea un plan de lanzamiento (release planning), que
debe servir para crear un calendario que todos puedan cumplir y en cuyo
desarrollo hayn participado todas las personas involucradas en el
proyecto. Se usará como base los user stories, participando el cliente
en la elección de los que se desarrollarán, y según las estimaciones de
tiempo de los mismos se crearán las iteraciones del proyecto.
o Se hacen pequeños lanzamientos con mucha frecuencia.
o El desarrollo se divide en iteraciones, cada una de las
cuales comienza con un plan de iteración para el que se eligen las user
stories a desarrollar y las tareas de desarrollo.
o Las personas cambian de área para evitar cuellos de botella y fomentar la propiedad colectiva del código.
o Se cambia el proceso lo que sea necesario para adaptarlo a tu proyecto.
*
Diseño
o Se eligen los diseños más simples que funcionen.
o Se elige una metáfora del sistema para que el nombrado
de clases, etcétera, siga una misma línea, facilitando la reutilización y
la comprensión del código.
o Se escriben tarjetas CRC
(class-responsabilities-collaboration) de
clase-responsabilidades-colaboración para cada objeto, que permiten
abstraerse el pensamiento estructurado y que el equipo de desarrollo al
completo participe en el diseño.
o Se "refactoriza sin piedad". Basicamente, consiste en no
tener miedo de cambiar un diseño o eliminar un código que ya no sirve, o
al menos que ya no es claramente la mejor solución.
*
Codificación
o El cliente está siempre disponible, a ser posible cara a
cara. La idea es que forme parte del equipo de desarrollo, y esté
presente en todas las fases de XP (escribe los user stories con la ayuda
de los desarrolladores, participa en la elección de los que entrarán en
el plan de lanzamientos, prueba pequeños lanzamientos, participa en las
pruebas de funcionalidad...). La idea es usar el tiempo del cliente
para estas tareas en vez de para que cree una detalladísima
especificación de requisitos, y evitar la entrega de un producto peor
que le hará perder tiempo.
o El código se ajustará a unos estándares de codificación,
asegurando la consistencia y facilitando la comprensión y
refactorización del código.
o Las pruebas unitarias se codifican antes que el código
en sí, haciéndo que la codificación de este último sea más rápida, y que
cuando se afronte la misma se tenga más claro qué objetivos tiene que
cumplir lo que se va a codificar.
o La programación del código se realizará en parejas, para
aumentar la calidad del mismo. En cada momento, sólo habrá una pareja
de programadores integrando código.
o Se integra código y se lanza dicha integración de manera
frecuente, evitando divergencias en el desarrollo y permitiendo que
todo el mundo trabaje con la última versión del desarrollo. De esta
manera, se evitará pasar grandes periodos de tiempo integrando el código
al final del desarrollo, ya que las incompatibilidades habrán sido
detectadas enseguida.
o Se usa la propiedad colectiva del código, lo que se
traduce en que cualquier programador puede cambiar cualquier parte del
código. El objetivo es fomentar la contribución de ideas por parte de
todo el equipo de desarrollo
o Se deja la optimización para el final
o No se hacen horas extra de trabajo
*
Pruebas
o Todo el código debe tener pruebas unitarias, y debe pasarlas antes de ser lanzado.
o Cuando se encuentra un error de codificación o bug, se desarrollan pruebas para evitar volver a caer en el mismo.
o Se realizan pruebas de aceptación frecuentemente,
publicando los resultados de las mismas. Estas pruebas son generadas a
partir de las user stories elegidas para la iteración, y son "pruebas de
caja negra", en las que el cliente verifica el correcto funcionamiento
de lo que se está probando. Cuando se pasa la prueba de aceptación, se
considera que el correspondiente user storie se ha completado.
Fuente
Pido disculpas por haber posteado sin los libros recien, pero se me
colgo todo aca y lo unico q andaba era el firefox :p asi q ahora agrego
estos 3 libros.
Requirments Architecture Extreme Programming Design Patterns (ADDISON_WESLEY-Design_Patterns_Explained)
Teach Yourself Extreme Programming In 24 Hours
Addison Wesley - Kent Beck, Martin Fowler - Planning Extreme Programming
http://rapidshare.com/files/33547244/programacion_extrema.rar.html
