PDF de programación - eXtreme Programming

18/03/2010

XP

Creo que fue a finales del año 2000 cuando oí por primera vez, en boca de un colega, el

término eXtreme Programming. Con mi mentalidad cinematográfica lo primero que

imaginé al escuchar semejantes palabros, fue a unos cuantos programadores, cada uno

con un portátil en el regazo, trabajando mientras hacían puénting.

Como a veces no me gusta que mi imaginación pueda más que mi ignorancia, dos años

después intenté aclararme y aproveché para ello la edición en español del libro “Una

explicación de la Programación Extrema: aceptar el cambio”, escrito por Kent Beck y

prologado por Erich Gamma. La edición española es prácticamente inencontrable pero

la inglesa (reseñada al pie de este artículo) es de fácil acceso.

Y bueno: ¿qué viene a decir este libro? Pues a lo largo de 190 páginas explicar que “XP

toma principios y prácticas de sentido común a niveles extremos.”

Me gusta: sentido común. Common sense que dicen los sajones. Una muestra: “No

puedes obtener software más rápidamente, gastando más dinero.” Una máxima que se

incumple demasiadas veces.

Otra frase que no es tan evidente: “Para el desarrollo de software, el ámbito(alcance)

es la variable más importante a tener en cuenta.”

Y otra que va contra la práctica habitual: “Deberías de tomar las grandes decisiones lo

más tarde posible.” Cuando se reflexiona en ella se encuentra su sentido: cuanto más

tiempo pase, más conocimiento tienes del problema a resolver. Esto hace disminuir la

incertidumbre acerca del ámbito y, por lo tanto, será más fácil tomar entonces esas

grandes decisiones.

¿Esto es obvio? ¿De sentido común? Vamos entonces por el buen camino, por el

camino extremo…

Otra sentencia, ésta con tintes zen: “El cambio es la única constante.” ¿Cómo lo

gestionamos entonces?

Teniendo en cuenta estos cuatro valores:

 Comunicación

 Sencillez

 Realimentación

 Valentía

Y algunos apuntes acerca de ellos: “La mala comunicación no sucede por casualidad.”

“La sencillez no es fácil.” “La sencillez y la comunicación se apoyan mutuamente.” “Un

acto de valentía es tirar el código que no funciona.”

Pero “hay un valor más profundo que está bajo la superficie de los otros cuatro: el

respeto. Si los miembros de un equipo no se preocupan de los otros y de lo que están

haciendo, XP está muerta.”

Estos valores se concretan en estos principios:

 Realimentación rápida

 Asumir la sencillez

 Cambio incremental

 Aceptar el cambio

 Trabajar con calidad

XP incide mucho en el equipo que está desarrollando el trabajo y al equipo hay que

cuidarlo, con lo que ¡ojo! con esto: “Ninguna acción quita la vida a un equipo o a una

persona más que decirle lo que tiene que hacer, especialmente si el trabajo es

realmente imposible.”

Valores que se concretan en principios pero ¿cuáles son las actividades básica del

desarrollo de software?

 Codificar

 Probar

 Escuchar

 Diseñar

¿Y cuándo se considera que el trabajo ha terminado? “Cuando no puedas pensar en

ninguna prueba que pudiese generar un fallo, has acabado por completo.”

¿Pruebas? “¡Oh, puaf! Nadie quiere hablar de pruebas. Es el hijastro feo del desarrollo

de software.” Aun así, ten en cuenta que “programar y probar a la vez, es también más

rápido que solamente programar.”

Y que “cuando el sistema requiere que dupliques código, te está pidiendo

que recodifiques.”

Uno de los temas que siempre surge en los proyectos es el de quién toma las decisiones.

Beck indica que “el personal técnico decide sobre:

 Estimaciones

 Consecuencias

 Procesos

 Programación detallada”

Antes hemos indicado que no por mucho dinero que se inyecte en un desarrollo, éste no

acelera su ritmo. Entonces ¿podemos inyectar más tiempo? Hmmm: “Las horas extras

son un síntoma de un problema serio en el proyecto. La regla de XP es sencilla: no

puedes trabajar una segunda semana de horas extraordinarias. Una semana, bien,

arrancas y metes alguna hora extra. Si llegas el lunes y dices ‘para conseguir los

objetivos, tendremos que trabajar aún más’ entonces tienes ya un problema que no se

puede resolver trabajando más horas.”

XP no es equivalente a la anarquía: “Las estrategias de gestión que se inclinan hacia el

control centralizado son difíciles de llevar a cabo puesto que requiere mucho coste por

parte de aquellos que están siendo gestionados. Por otra parte, la estrategia opuesta no

funciona: no puedes dejar que cada uno vaya y haga lo que quiera sin ninguna

supervisión.”

Ahora bien esa supervisión tiene como regla de oro “la humildad”.

Sigamos con las directrices de los proyectos: “El proyecto debe ser dirigido por

decisiones de negocio pero las decisiones de negocio deben basarse en decisiones

técnicas sobre el coste y el riesgo.”

Decisiones técnicas, decisiones de negocio… “Aunque la elección de la tecnología

puede parecer al principio que es una decisión puramente técnica, es en realidad una

decisión de negocio, pero que debe contar con Desarrollo.” Tesis, antítesis, síntesis.

Por otro lado, nada de la consabida “parálisis por análisis”: “No quieras dedicar mucho

tiempo a la planificación puesto que la realidad nunca consentirá que ejecutes

exactamente el plan.”

Una de las prácticas que más llaman la atención de XP es la programación en parejas.

Se justifica porque el autor dice que, en su experiencia: “La programación en parejas es

más productiva que la división del trabajo entre dos programadores y la posterior

integración de los resultados.”

Para acabar este artículo y, como siempre, animándoos a que leáis el libro, dos

observaciones sobre el hecho de que el código desarrollado es propiedad del equipo no

de una persona sola: “La propiedad colectiva tiende a prevenir que sea introducido

código complejo al sistema desde el primer momento. También tiende a diseminar el

conocimiento del sistema sobre todo el equipo.”

El hecho de escribir este artículo ahora no es casual: es también una invitación a que

acudáis al itinerario que hemos preparado en Metodologías Ágiles. Os esperamos.



Extreme Programming Explained: Embrace Change (2nd Edition)



http://twitter.com/CESNavarra

http://twitter.com/curtasun



Expuesta a las 13:58 por Carlos Urtasun



16/03/2010

Implementar R.I.A. Services a tu web con Silverlight 4

Cada vez más se tiende a enriquecer nuestras aplicaciones, de forma que deseamos tener todas aplicaciones de negocio en el mundo

web. Para lograr una experiencia de usuario enriquecedora a la par que productiva vamos a utilizar Silverlight 4 y los servicios R.I.A

que esta plataforma nos ofrece.

Pero para empezar a trabajar con estos elementos lo mejor es que comencemos por comprender el terminoR.I.A de Silverlight 4.

Que mejor forma de comenzar el aprendizaje que saber el significado de R.I.A. (Rich Internet Application) en definitiva

aplicaciones enriquecidas de internet. Pero nos nos vamos a quedar en el termino de la parte visible y bonita de este concepto, si no

que vamos a entrar en la parte funcional y productiva del mismo.

El siguiente paso es la visualización de la estructura de las webs tradicionales y las web que utilizan R.I.A Services:

Web tradicionales

Las webs tradicionales por un lado tenían el navegador basado exclusivamente en HTML alojado en el navegador y por el otro las

diferentes capas de la aplicación( Presentación, lógica y de Acceso a Datos). Lo que conlleva pesados desarrollos del lado del

servidor, además del retardo en el tiempo de respuesta a la hora de trabajar con los datos contenidos en el servidor.



Aplicaciones R.I.A

Las aplicaciones R.I.A lo que hacen es separar la capa de presentación al lado del cliente, consiguiendo con ello un cliente mucho



más versátil, eso si, también más pesado. La mayor dificultad la encontramos en que las comunicaciones con las fuentes de datos no

se realizan de manera directa y ¿cómo resolvemos este problema?



En Silverlight 4 se introducen dos nuevos elementos (Domain Context y el Data Services) que nos ayudan a resolver el problema

mencionado con anterioridad, convirtiendo nuestra aplicación en una web tradicional pero aprovechando todas posibilidades que nos

ofrecen los servicios RIA.

Vamos a entrar en detalles, el elemento Data Services está situado del lado del servidor y nos va servir de nexo entre el cliente y la

fuente de datos. El elemento Domain Context está situado del lado del cliente. Nos permite trabajar con los datos del servidor y

utilizarlos en la capa de presentación. Estos dos elementos se asemejan a los conocidos DataSources de ASP.Net. Pudiendo realizar

inserciones, actualizaciones, borrados, filtros, etc.

Una vez que hemos comprendido el concepto de los servicios R.I.A vamos aplicarlos en un proyecto de Silverlight 4. Para este

ejemplo hemos utilizado Visual Studio 2010 Beta 2 y Silverlight 4 Beta.

Abrimos Visual Studio 2010 para crear un nuevo proyecto Silverlight 4 eligiendo como plantilla “Silverlight Business

Application”como podemos observar en la siguiente imagen:

Ahora vamos a implementar los servicios R.I.A para poder disfrutar trabajando con ellos. Lo primero es agregar la fuente de datos

con la que vamos a trabajar, para ello nos situamos del lado del servidor (nombre del proyecto.Web) y presionando con el botón

derecho sobre la carpeta Models elegimosAñadir->Nuevo Elemento.



En mi caso voy a utilizar como modelo de obtención de datos ADO:NET Entity Data Model pero podríais utilizar el modelo que

más se adapte a vuestras necesidades.



Una vez seleccionado el elemento, elegimos un nombre representativo y presionamos aceptar. En la siguiente ventana emergente

elegimos Generar desde una base de datos, ya que esta va ser el tipo de fuente de datos.



En la siguiente ventana emergente, seleccionamos Nueva Conexión, nos aparecerá u