Ya lo dice Martin Fowler en su artículo sobre La Nueva Metodología: Ágil no es para todo el mundo. No hay reglas predeterminadas que nos ayuden a determinar claramente cuando utilizar una metodología Ágil o, por el contrario, una metodología clásica.

En cualquier caso, ahí van unas ideas:

Dedicación del cliente.

Difícilmente podemos aplicar una metodología ágil si no contamos con la adecuada involucración del cliente. En ese caso es mejor tomar requisitos muy concienzudamente al principio.

Tamaño del proyecto.

El tamaño no es una limitación en si misma, pero a mayor tamaño más complicado es implantar una metodología Ágil.

Estabilidad de los requerimientos.

Cuando los requerimientos cambian, una metodología Ágil puede ayudar a adaptarse a ellos. Para requisitos estables, quiza una metodología clásica ayude a evitar el re-trabajo.

Criticidad.

Yo personalmente no utilizaría una metodología Ágil para diseñar y construir un sistema del que dependan vidas humanas: los sistemas de navegación de un avión, por ejemplo.

Experiencia.

Esto es obvio. No uses metodologías Ágiles con equipos sin experiencia. Estas metodologías se basan en la capacidad y madurez de los miembros del equipo.

Apetencia.

Otra obviedad. Si no te apetece usarlas, pues no las uses.

Tags: Metodología, Programación

Me he permitido copiar y traducir un pequeño fragmento del libro “Implementing and Integrating Product Data Management and Software Configuration Management” de Ivica Crnkovic, Ulf Asklund y Annita Persson Dahlqvist

Transformar [dividir] un problema grande en muchos problemas pequeños, normalmente implica que las relaciones entre las partes se hacen complejas. Las relaciones entre componentes pueden ser tan complejas que se haga casi imposible manejarlas.

Es otra forma de expresar la Ley de Tesler.

En el fondo refuerza la idea de que la complejidad de un sistema no desaparece por el método de dividirlo en subsistemas más simples. Es decir, la complejidad no se “destruye”, sino que se traslada de los componentes a las relaciones entre ellos.

Por cierto, interesante libro…

Tags: Complejidad

Últimamente se ha estado hablando mucho del principio “Menos es más”. Es uno de los los pilares de 37signals. La paradoja está en la peligrosa simplificación de ese principio: ¿Menos qué es mas qué?

Podemos pensar en:

  • Menos código.
  • Menos complejidad.
  • Menos funcionalidad.

Menos código.

Como decía en otra entrada de esta bitácora, a veces menos código consigue mejorar las características del software, ya sea en términos de flexibilidad, funcionalidad o rendimiento. Pero esto siempre implica dos pasos:

  • Eliminar la complejidad “sobrante”, es decir, limpiar y reducir hasta la complejidad intrínseca.
  • Añadir complejidad – intrínseca – que permita mejorar las características buscadas.

El saldo puede ser negativo en términos de tamaño. Pero la complejidad primordial siempre aumenta.

Menos complejidad.

Esta opción no significa que realmente el software sea menos complicado, sino que siguiendo la Ley de Tesler, hemos trasladado la complejidad a zonas del software alejadas del interfaz de usuario. Es decir, hacemos más sencillo el uso a base de complicar el funcionamiento interno. El saldo suele ser positivo en términos de complejidad total, del mismo modo que producimos calor fuera de un congelador para mantener el frio dentro.

Menos funcionalidad.

Esta es más fácil. Menos funcionalidad es menos funcionalidad. En el software Ta-Da List de 37signals no hay modo de asignar una tarea a alguien, o de indicar una fecha máxima de finalización, o clasificar tareas en categorías aunque se plantean “alternativas” imaginativas para resolver esas necesidades. La excusa es la de pretender soluciones humanas y no soluciones de software.

Pero a mi me gusta poder asignar tareas a mis colaboradores, y saber cual es la fecha de entrega máxima, o clasificar las tareas por proyectos, áreas o lo que me interese. Para mí, eso es menos. Mucho menos.

Conclusión

Creo que habría que evitar simplificar demasiado el principio “Menos es más”, y redactarlo de modo que se revele todo su significado. Mi interpretación de este principio es – y se puede no estar de acuerdo - la siguiente:

Menos funcionalidades no usadas y menos complejidad en el uso es más atractivo para el usuario pero más complejo para quien lo construye.

Tags: Complejidad

¿Como harán algunos para ponerle nombre a su software? Este es bueno: Huevos 1.1.1., un buscador adaptable para Mac Os X.

Tags: Curiosidades

Esta curiosa anécdota puede servir para ilustrar como las medidas de productividad de la Ingeniería de Software a veces nos llevan en la dirección contraria a la que quisieramos ir.

Es muy habitual medir la funcionalidad o la complejidad de un determinado software y, por tanto, la productividad de quienes lo han escrito, en número de líneas de código. Pero a veces se puede hacer más con menos.

Bill Atkinson, autor del programa QuickDraw, en el año 1982 estuvo trabajando en su optimización. Tras escribir de nuevo ciertos algoritmos para hacerlos más simples y generales, consiguió que éstos se ejecutaran 6 veces más rápido, resultando además que la nueva versión tenía dos mil líneas de código menos que la anterior.

Cuando tuvo que rellenar el parte de trabajo y llegó a la casilla de número de líneas de código producidas escribió: -2000.

Dicen que desde ese día no le hicieron rellenar el informe nunca más.

Tags: Complejidad, Programación

« Entradas anterioresEntradas siguientes »