XP

La programacin extrema o eXtreme Programming, es una metodologa de desarrollo de

la ingeniera de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme
Programming Explained: Embrace Change (1999). Es el ms destacado de los procesos giles de
desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las
metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la
previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son
un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz
de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto
e invertir esfuerzos despus en controlar los cambios en los requisitos.

Caractersticas fundamentales

Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la
codificacin. Vase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit
orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres ltimas
inspiradas en JUnit, la cual, a su vez, se insipir en SUnit, el primer framework orientado a
realizar tests, realizado para el lenguaje de programacin Smalltalk.
Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por
dos personas en un mismo puesto. La mayor calidad del cdigo escrito de esta manera -el
cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida
de productividad inmediata.
Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda
que un representante del cliente trabaje junto al equipo de desarrollo.
Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas
frecuentes.
Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su
legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de
garantizar que en la refactorizacin no se ha introducido ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de
cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal
pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de
regresin garantizan que los posibles errores sern detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo
funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta
que es ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se
requiere, que realizar algo complicado y quizs nunca utilizarlo.

Roles

Programador
Escribe las pruebas unitarias y produce el cdigo del sistema. Es la esencia del equipo.

Cliente

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

Tester

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

Tracke

Es el encargado de seguimiento. Proporciona realimentacin 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.

Consultor

Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para
el proyecto. Ayuda al equipo a resolver un problema especfico. Adems este tiene que investigar
segn los requerimientos.

Gestor (Big boss)

Es el dueo de la tienda y el vnculo entre clientes y programadores. Su labor esencial es la

coordinacin.

Procesos
LEAN

Lean es un modelo de Gestin diseado por la compaa TOYOTA para sus plantas de fabricacin de
automviles, durante la dcada de los aos 70.
El objetivo de Lean es desarrollar una cultura hacia una organizacin ms eficiente mediante unos
cambios en los procesos del negocio con el fin de incrementar la velocidad de respuesta por medio
de reduccin de desperdicios, costes y tiempos.
En la actualidad, las empresas ms competitivas de todos los sectores de la industria emplean este
sistema de gestin y sus herramientas asociadas para conseguir ser los mejores.
Esta optimizacin tiene un alto impacto cuando se integran los sistemas de Lean Manufacturing y 6
sigma.
Principios:

Especificar el Valor para los clientes (eliminar desperdicios). No debemos pensar por los
clientes. El cliente paga por las cosas que cree que tienen valor y no por las cosas que
pensamos que son valiosas. Las actividades de valor a&ntildeadido son aquellas que el
cliente est dispuesto a pagar por ellas. Todas las otras son desperdicios (MUDA).
Identificar el mapa de la cadena de valor (VSM) para cada producto/servicio. La secuencia
de actividades que permite responder a una necesidad del cliente representa un flujo de
valor. Creando un "mapa" de la corriente de valor, es posible identificar aquellas actividades
que no agregan valor, desde el punto de vista del cliente, a fin de poder eliminarlas.
Favorecer el flujo (sin interrupcin). Debemos lograr un movimiento continuo del
producto/servicio a travs de la corriente de valor. Por ello, tenemos que reducir los tiempos
de demora en el flujo de valor quitando los obstculos en el proceso.
Dejar que los clientes tiren la produccin (sistema PULL). La aplicacin del Flujo y del Pull
generan una respuesta ms rpida y exacta con un menor esfuerzo y menores desperdicios.
Permite producir slo lo que el cliente pide y evita la generacin de un stock innecesario.
Perseguir la perfeccin (mejora continua). Hay que seguir trabajando constantemente para
conseguir unos ciclos de produccin mas cortos, obtener la produccin ideal (calidad y
cantidad), focalizar los esfuerzos en el valor para el cliente. "Ninguna mquina o proceso
llegar a un punto a partir del cual no se puede seguir mejorando" (Sakichi Toyoda - 1890).

Herramientas utilizadas:

Anlisis de Valor de los Procesos (Mapeo e identificacin de desperdicios)

Indicadores (OEE, Lead time, WIP, Takt Time...)
Mapa de la cadena de valor (Value Stream Mapping)
Bsqueda del flujo continuo (Gestin de las colas,...)
Integracin eficiente de las personas en la empresa
Sistema "PULL" arrastre
Desarrollos KANBAN y sistemas de "supermercado"
KANBAN
Kanban es una palabra japonesa que significa algo as como tarjetas visuales (kan significa visual,
y ban tarjeta). Esta tcnica se cre en Toyota, y se utiliza para controlar el avance del trabajo, en el
contexto de una lnea de produccin. El Kanban est dentro de la estrategia, es decir, la mejora
continua y continuada.

Aunque esta tcnica la explicamos en el libro de gestin gil de proyectos, me ha parecido

interesante hacer un resumen de la misma en este post.

Todo surgi en una metodologa llamada Lean, creada por Toyota para mejorar su produccin
usando tcnicas just-in-time (JIT).

Kanban no es una tcnica especfica del desarrollo software, su objetivo es gestionar de manera
general como se van completando tareas, pero en los ltimos aos se ha utilizado en la gestin de
proyectos de desarrollo software, a menudo con Scrum (lo que se conoce como Scrumban).

Las principales reglas de Kanban son las tres siguientes:

Visualizar el trabajo y las fases del ciclo de produccin o flujo de trabajo

determinar el lmite de trabajo en curso (o Work In Progress)
medir el tiempo en completar una tarea (lo que se conoce como lead time). Vemos que
significa cada uno de los anteriores.
FDD
Si no encuentras manera de encajar Scrum a tu proyecto, pero necesitas algo gil, pero tu equipo
es grande, utilizas personal externo, no tienes claro que tu equipo sea auto-organizado, sigues
pensando que debe haber un jefe de proyecto y arquitecto, que hay que tener un diseo /
arquitectura antes de empezar a desarrollar puede que en FDD encuentres la respuesta a tus
problemas.

La metodologa gil FDD est orientada a equipos ms grandes, con ms personas que aquellos a
los que normalmente se aplican otras metodologas giles como Scrum. La metodologa gil
FDD contempla la figura del jefe de proyecto y una fase de arquitectura.

Como sabis, las populares Scrum y XP suelen usarse, y recomendarse, para equipos pequeos y
auto-organizados y en estas metodologas no queda claro que haya una fase de diseo. Y ah
es donde muchas empresas tienen grandes problemas; bien porque han intentado aplicar Scrum a
equipos numerosos, y no han sabido cmo, o les fall la arquitectura o el equipo no era del todo
auto-organizado.

Por lo anterior, para m, en muchos casos, metodologa gil FDD es una metodologa ms
pragmtica, mas con los pies en el suelo, es decir, ms cercana a lo que son los equipos de desarrollo
reales que te encuentras en las empresas, aquellos que necesitan hacer una arquitectura, un diseo,
y que tienen jefes de proyecto y arquitectos.

En esta serie de dos post te dejo un breve resumen de la metodologa gil FDD. En el post de hoy
veremos algunos datos importantes a conocer de FDD y una introduccin a sus procesos. En el post
de maana veremos los cinco procesos de la metodologa gil FDD.
CRYSTAL
Las metodologas Crystal son una familia de metodologas giles, donde cada una de ellas est
adecuada para un tipo de proyecto. Su creador es el popular Cockburn uno de los firmantes del
manifiesto gil.

La metodologa Crystal tambin sirve para gestionar proyectos giles, con la diferencia de que es
menos extrema y est pensada para ms tipologas de proyectos y organizaciones, destacando
especialmente proyectos y empresas grandes.

El nombre de metodologas Crystal viene de que cada proyecto software puede caracterizarse
segn dos dimensiones, tamao y criticidad, al igual que los minerales se caracterizan por dos
dimensiones, color y dureza. Y esta es una de las bases de las metodologas Crystal: hay una
metodologa para cada proyecto, o la escala de Cockburn.

La otra gran clave de metodologas Crystal, comn a casi todas las metodologas giles, es que lo
ms determinante para el xito, o fracaso, de un proyecto son las persona. Una de las claves que
determinan el xito (o fracaso) de un proyecto software.

El que veis en la foto de este post es el libro ms destacado sobre las metodologas Crystal

Las metodologas Crystal: Una familia de metodologas giles segn sea tu proyecto

En las metodologas Crystal, proyectos grandes, que necesitan ms coordinacin y comunicacin,

se asocian con colores ms oscuros. Proyectos en los que un fallo pueda causar mayores
problemas, tambin se asocian con colores ms oscuros.

As, aparece una familia de metodologas:

Clear, para equipos de hasta 8 personas o menos.

Amarillo, de entre 10 y 20 personas.
Naranja, para equipos entre 20 y 50 personas.
Roja, entre 50 y 100 personas.
etc.

A ms personas en el proyecto, ms coordinacin. A ms criticidad en el software, ms rigurosidad

en el proceso. El factor ms determinante en cualquier caso, la comunicacin entre los
participantes en el proyecto.

Las 7 propiedades de las metodologas Crystal

Las metodologas Crystal cumplen todas ellas con 7 propiedades esenciales, las siguientes:

1 Entregas frecuentes, en base a un ciclo de vida iterativo e incremental. En funcin del proyecto
puede haber desde entregas semanales hasta trimestrales. Para los que conozcan Scrum: en Scrum
las entregas son, mximo, cada 4 semanas, en las Crystal se contemplan muchas ms opciones.

2 Mejora reflexiva. Que viene a ser mejora continua. Las iteraciones ayudan a ir ajustando el
proyecto, a ir mejorndolo.
3 Comunicacin osmtica. Traducido al castellano, que el equipo est en una misma ubicacin
fsica, para lograr la comunicacin cara a cara.

4 Seguridad personal. Todo el mundo puede expresar su opinin sin miedos, tenindosele en
cuenta, considerndose su opinin, etc.

5- Enfoque. Perodos de no interrupcin al equipo (2h horas), objetivos y prioridades claros,

definiendo as tareas concretas. Si llevas desde hace tiempo pasando por este blog, recordars ya
comentbamos, tiempo a, aquello de que el entorno fsico afecta al rendimiento del desarrollador
software (te dejo aquel post).

6 Fcil acceso a usuarios expertos. Las Crystal (a diferencia de otras como XP) no exigen que los
usuarios estn continuamente junto al equipo de proyecto (no todas las organizaciones pueden
hacerlo), s que, como mnimo, semanalmente debe haber reuniones y los usuarios deben estar
accesibles.

7 Entorno tcnico con pruebas automatizadas, gestin de la configuracin e integracin

continua.Prcticas comunes en casi todas las metodologas giles, te dejo un post sobre la
integracin continua y el smoke test.
BIBLIOGRAFIA

http://www.caletec.com/consultoria/lean/

http://www.javiergarzas.com/2012/09/metodologia-gil-fdd-1.html
NOMBRE: ORIHUELA SEGALES SAIRA
MATERIA: ANALISIS DE SISTEMAS II
SEMESTRE: QUINTO
TURNO: MAANA