agile-spain.com -

EsElCambioDeInterfazRefactorizar

Wed, 19 Sep 2007 14:09:35 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

¿Es el cambio de interfaz de parte del código una refactorización?

La respuesta a esta pregunta es bastante simple - el cambio de un interfaz es una refactorización que genera un cambio en todas las llamadas. Un gran ejemplo de esto es RenombradoDeMétodo, que es una refactorización de cambio de interfaz presente en la mayoría de herramientas de refactorización.

El cambio de todas las llamadas es una parte esencial de esta refactorización. Solamente el cambio de una declaración de interfaz romperá el sistema - y consecuentemente no es un comportamiento que conserve el cambio.

Las refactorización de cambio de interfaz asumen que se puede conseguir el mantenimiento de todas las llamadas, y esto es porque se tiene que ser mucho más cuidadoso con los InterfacesPublicados. Con un interfaz publicado, el interfaz sí mismo es la parte del comportamiento observable del sistema.

Los lenguajes dinámicos pueden hacer estos cambios mucho más difíciles. La mecanografía estática realmente ayuda aquí a controlar exactamente qué interfaz es llamado en varios puntos. Las llamadas reflexivas también pueden ser más difíciles de encontrar, bien integrando nombres de método en cadenas o componiéndolas en tiempos de ejecución. Esto es otra área donde las pruebas son esenciales incluso en los entornos que tienen instrumentos de refactorización.

Planning Pocker

Fri, 27 Jul 2007 09:01:36 +0000

A la hora de hacer una estimación, se debe tener en cuenta lo siguiente:

1. Las estimaciones son estimaciones, es decir, aunque le dediques mucho tiempo, no llegaremos a una precisión del 100%
2. Las estimaciones se deciden colaborativamente, incluyendo a quienes harán la tarea ( esto último es muy importante)
3. Se deben realizar como la combinación de:
- Opinión del experto
- Analogía: comparar con otras tareas ya estimadas
- Disgregación: separar una tarea en varias

Dentro de las metodologías ágiles, una de las propuestas para estimar es jugar al Planning Pocker, que combinas las técnicas anteriores.

LecturasDSL

Thu, 26 Jul 2007 09:48:24 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

( Ver mi nota sobre LenguajeDeDominioEspecífico para una rápida introducción a este tema y a la terminología.)
Actualizado:David Laribee ha escrito un post contrastando lo que él llama interfaces fluidos ordenados o interfaces fluidos desordenados. La distinción es que los interfaces fluidos ordenados fuerzan a un flujo particular sobre cómo se compone una sentencia DSL. Él proporciona un ejemplo donde usa múltiples interfaces sobre un único ExpressionBuilder- la misma técnica que se usa por JMock.

Anders Noras ha escrito dos artículos interesantes sobre la escritura de DSLs internos en C#. El primer artículo da un ejemplo del DSL y una discusión contra la cínica lista de comprobación de Chromatic. El segundo artículo entra en detalles sobre su implementación.
Piers Cawley hacen incapié en que una característica clave de DSLs es su estrecha focalización en un dominio

ErroresDeConceptoDeLaProgramaciónPorParejas

Tue, 24 Jul 2007 13:19:14 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

Se tiene que programar por parejas si se sigue un proceso ágil.
Esto es completamente falso. 'Ágil' es un término muy amplio definido sólo en términos de valores y principios, el más notablemente en el Manifiesto para el Desarrollo de Software Ágil. El manifiesto no menciona el programar por parejas y la mayoría de los métodos ágiles no lo incluyen en su aproximación.
Ya que programar por parejas es una práctica de XP, ha tenido mucha influencia en la comunidad ágil. Por consiguiente a menudo es mencionado como una práctica ágil – tomando como práctica algo que es comúnmente usado por la gente en proyectos ágiles. Pero esto es una observación, no una prescripción..

Liberado JUnit 4.4

Mon, 23 Jul 2007 13:31:33 +0000

La nueva versión de JUnit se encuentra disponible ya en sourceforge .
En las notas de la nueva versión, los autores comentan:

JUnit is designed to efficiently capture developers' intentions about their code, and quickly check their code matches those intentions. Over the last year, we've been talking about what things developers would like to say about their code that have been difficult in the past, and how we can make them easier.

Entre los cambios de esta versión, se incluye una nueva sintaxis para las aserciones. Se puede consultar más detalle sobre esto en el blog de Joe Walnes.

AbismoParaLaMejora

Mon, 23 Jul 2007 08:20:47 +0000

Escrito por Martin Fowler
Traducido por Rafael Vacas

Si te importa lo que haces, te interesas en hacerlo cada vez mejor. Esto implica reflejar como haces las cosas y probar nuevas técnicas para ver si te hacen mejorar. Aunque otros recomienden nuevas técnicas, la única forma de saber si funcionan para ti es probándolas tú mismo y comprobar si mejoran tu rendimiento.

El problema es que la mejora, particularmente con nuevas técnicas no es lineal. A menudo hay una brecha que se abre cando intentas una nueva estrategia. La mejor ilustración que recuerdo de esto es del excelente libro de Gerald Weinberg Convertirse en un Líder Técnico. Viene de su hábito de jugar al pinball.

A medida que iba mejorando lentamente en mi nivel, empecé a sospechar que se me estaba pasando algo. Aunque mi puntuación subía rápidamente cuando tenía tres bolas en juego, de repente, al intentar mantener las tres bolas en juego, perdía las tres de golpe. Sólo pasaba una de cada cuatro veces, pero eso significaba que había perdido uno de tres preciosos turnos.

Me preguntaba que pasaría si dejaba de intentar mantener las 3 bolas en juego y me concentraba en su lugar en asegurar que una de las tres bolas se mantuviera en el campo de juego. Cuando probé esta nueva estrategia, mi puntuación cayó, inmediatamente, en el abismo. De hecho, estaba jugando contra un chiquillo al mismo tiempo, y empezó ganándome. Incapaz de afrontar la derrota, volví a mi antigua estrategia y lo puse en su lugar.

Más tarde, sin embargo, sin público observando, probé la nueva estrategia de nuevo. Y de nuevo mi puntuación bajó, pero me di cuenta de que no estaba perdiendo turno con tanta frecuencia, quizá sólo una de cada cinco veces que jugaba con tres bolas al mismo tiempo. Perseverando, con la práctica, mejoré mi habilidad para ignorar las otras dos bolas y mantener al menos una en el campo. No puntuaba mucho cuando las tres bolas estaban en juego, pero mi puntuación total aumentó. También conseguí jugar más tiempo en mi turno, lo cual es uno de los principales objetivos del juego.

HerenciaDiseñada

Mon, 23 Jul 2007 08:07:10 +0000

Escrito por Martin Fowler
Traducido por Rafael Vacas

Uno de los más largos debates en los círculos orientados a objetos es el debate entre HerenciaAbierta y HerenciaDiseñada. Josh Block ha sido probablemente quien mejor ha resumido el principio de la herencia diseñada: “Diseña y documenta para herencia o si no prohíbela”. Con este planteamiento te preocupas de decidir qué métodos pueden ser heredados y proteges los otros para evitar que sean sobrescritos.

El argumento más común para la herencia diseñada es que dado que la herencia supone una relación muy estrecha (y rompe la encapsulación) es fácil que las subclases efectivamente rompan las superclases por ejemplo, omitiendo comportamientos necesarios cuando sus métodos son invocados.

Muchos programadores, particularmente aquellos con una ActitudPermisiva, no están muy convencidos por este estilo de argumento. Otro argumento que encuentro más apetecible es el de Elliote Rusty Harold al discutir los principios de diseño de XOM. La cuestión aquí es que “las API son escritas por expertos para no expertos”. El creador de librerías debería estar debidamente versado en la tecnología con la que trabaja la librería. Deberían trabajar para simplificar esta tecnología a los usuarios de la librería. La encapsulación consiste en esconder secretos, por tanto una buena librería debería esconder toda clase de complicaciones y puntos peligrosos a los usuarios de la librería, ya usen la librería mediante invocaciones o herencia. Por tanto, con XOM puedo sobrescribir de forma segura las clases de la librería para hacer lo que quiera ya que la librería garantiza que aún así producirá XML bien formado, sin que tenga que preocupar a mi fea cabecita con todas las cosas que de otra forma podrían ir mal.

Diseño planificado y Evolutivo

Thu, 12 Jul 2007 15:23:44 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

Para este artículo voy a describir dos estilos de cómo se hace el diseño en el desarrollo de software. Quizás el más común es el diseño evolutivo. Esencialmente, el diseño evolutivo quiere decir que el diseño del sistema crece mientras se implemente el sistema. El diseño es parte de los procesos de programación y según el programa se desarrolla el diseño cambia.

En su uso habitual, el diseño evolutivo es un desastre. El diseño termina siendo la agregación de un manojo de decisiones tácticas tomadas en el momento, cada una de las cuales hace el código más difícil de cambiar. Se podría argumentar de muchas formas que esto no es diseño, de hecho esto por lo general conduce a un diseño pobre. Como Kent dijo, el diseño está ahí para permitir cambiar el software fácilmente a largo plazo. Como el diseño se deteriora, entonces se necesita la capacidad de hacer cambios con eficacia. Se tiene el estado de entropía de software, con el tiempo el diseño se pone de mal en peor.

No sólo hace esto el software más difícil de cambiar, esto también hace los errores más fácil de reproducirse y a la vez más difícil encontrar y seguramente para resolver. Esto es la pesadilla “codificar y arreglar”, donde los errores se hacen exponencialmente más caros de arreglar según el proyecto avanza.

HypótesisDeResistenciaAlDiseño

Wed, 11 Jul 2007 12:15:06 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

¿Merece la pena el esfuerzo para diseñar el software bien?

De vez en cuando tengo conversaciones indirectas sobre si el diseño de buen software es una actividad que vale la pena. Digo que estas conversaciones son indirectas porque no creo que me haya encontrado a nadie diciendo que el diseño de software no tiene importancia. Por lo general es expresado de la forma " realmente tenemos que ir rápido para cumplir nuestro objetivo el próximo año y entonces reducimos ".

Existe la noción de que el diseño es algo que se puede comerciar para conseguir una mayor velocidad. De hecho he tenido la impresión un par de veces de que el esfuerzo de diseño es aceptado para mantener a los programadores felices aun cuando esto reduzca la velocidad.

Agile-Spain empieza una nueva etapa

Tue, 10 Jul 2007 09:51:11 +0000

Despues de un periodo en el que grupo de personas de Agile-Spain ha estado tomando fuerzas, volverá la web a comenzar a publicar noticias y contenido sobre Metodologías Ágiles.

En esta nueva etapa, las metodologías ágiles ya han dejado de ser algo novedoso, para convertirse en una de las opciones que existen para afrontar la ejecución de un proyecto. Todos estos años que han pasado desde la aparición de este nuevo paradigma han servido para asentar estas metodologías y sobre todo para poder contar con gran número de experiencias en su aplicación.

Muchas entidades estan ya adoptando gran parte de las enseñanzas que han aportado las metodologías ágiles. Esta es la experiencia que queremos compartir en esta segunda etapa, donde no obstante queda todavía mucho que conocer y que aportar de la experiencia que estamos teniendo los que hemos elegido este paradigma como forma de entender los proyectos.

Desde aqui os invitamos a colaborar en el portal compartiendo estas experiencias.

Agile-Spain entra en hibernación

Sat, 12 May 2007 11:30:25 +0000

Hace ya casí tres meses de la última noticia así que creemos que es mejor ser realistas y honestos con todos los que nos habeis seguido durante estos años: Por ahora, Agile Spain dejará de tener nuevo contenido. Preferimos pensar que no es el adiós definitivo, porque nunca se sabe si el tiempo y las energías volverán o nuevos voluntarios se apuntarán al proyecto, por eso preferimos decir que hibernamos. Nos metemos en nuestra cueva (virtual) y confiamos que cuando pase el 'invierno' volvamos a salir.

Os queremos agradecer a todos cada noticia que habeis leído o mandado, cada comentario que habeis escrito y por supuesto los mensajes de ánimo. Sin vosotros Agile Spain no hubiera existido.

Pero la web no va a desaparecer. Ya tenemos pagado el hosting por bastante tiempo más, así que todo el contenido quedará disponible para el que lo quiera consultar. Simplemente no habrá más noticias o comentarios (están deshabilitados). Además la lista de correo, para intercambiar experiencias sobre metodologías ágiles seguirá estando disponible.

Por último invitaros a visitar una de nuestras webs favoritas sobre metodologías ágiles en español, y que de alguna forma sentimos que toma nuestro relevo. Hablamos de Navegapolis

Uso de DSDM en sistemas de data warehouse

Fri, 23 Feb 2007 20:27:51 +0000

dolican nos envía:
Segundo articulo en el que se narran las posibilidades de las metodologías ágiles en los sistemas de data warehouse. Esta vez el turno es para DSDM.

¿DSDM para DWH?

Desarrollo de Balas Trazadoras

Fri, 23 Feb 2007 21:07:45 +0000

Seguro que habeis oido de la practica militar de disparar con balas trazadoras cuando es de noche para poder apuntar mejor. Basicamente se basa en el hecho de que apuntar con una ametralladora es muy dificil, sobretodo por la noche. Por ese motivo se utilizan balas trazadoras que estan bañadas en fosforo y al ser disparadas dejan una estela de luz con la que el artillero se puede guiar y apuntar mejor.

El Desarollo con Balas Trazadoras (o TBD) hace exactamente lo mismo en un proyecto de software. Basicamente te deja ver a la dirección tomada dejandote apuntar continuamente mucho antes de que este terminado el proyecto.

Hoy en dia hay muchos procesos y metodologias (prefiero llamarlos ecosystemas ya que suelen fallar por eventos sociales) de las que nos podemos nutrir para sacar nuestro proyecto adelante. La mayoria de estas suelen ser o demasiado burocraticas o frustrantes. Sobretodo si vemos el espectro de ecosystemas (desde RUP a XP) todos nos imponen una serie de practicas que segun los creadores son el mejor camino a seguir y si no se practican todas ellas no estamos siguiendo su metodología. En esto estoy de acuerdo, o todo o nada (al menos si quiero decir que estoy en un equipo XP por ejemplo), ya que las metodologías suelen basar sus valores y practicas en las interrelaciones de estas.

Con DBT es diferente. El TDB no te dice como tienes que trabajar sino que mas bien complementa tu forma de trabajar. No te dice si tienes que hacer TDD (Test Driven Development) o escribir historias de usuario. Basicamente se implanta con coste cero y da unos resultados asombrosos. De hecho es posible ir añadiendo practicas al proceso ya que es un proceso muy ligero (comparable los procesos Crystal de Cockburn).

¿Sirve SCRUM para un proyecto de Data Warehouse?

Fri, 02 Feb 2007 20:20:05 +0000

Dolican nos envía: "Reflexiones sobre las posibilidades de aplicar SCRUM a proyectos de reingenieria de Data warehouses: ¿SCRUM para DWH? "

La metodología como caballo de Troya

Sun, 21 Jan 2007 17:54:48 +0000

Un usuario anónimo nos envía: "Artículo en el que se comenta como una metodología ágil puede ser usada para ir cambiando una organización que no esté lo sufiientemente madura para adoptar una metodología ágil.
La metodología como Caballo de Troya "