archivo

Archivos diarios: abril 14, 2011

Chris Guillebeau es escritor, emprendedor y una persona que decide vivir sus sueños. Os recomiendo que visitéis su blog y comprenderéis por qué .

Una de sus citas más conocidas es la siguiente (traducción libre): “El mejor momento para empezar fue el año pasado. Si no fue así, hoy lo será”.

Es una frase que invita a la reflexión. Nada nos limita más que nosotros mismos, nuestros miedos, nuestros temores, nuestro afán por conservar algo que no tiene valor en comparación con lo que está tras la pared que nos separa de nuestros sueños.

A los principios indicados en el artículo anterior sobre DSDM, hay que asumar otros, que se denominan asunciones (assumptions) y que se van a describir a continuación.

Considero importante indicar los principios y asunciones antes que la metodología en sí, ya que son la base no solo de la misma, sino de prácticamente cualquier metodología de desarrollo que tenga una orientación iterativa e incremental.

Si no se cree en ellos, no se creerá en este tipo de metodologías. Como ya sabéis por los artículos que llevo escritos sobre la materia, considero que proyectos desarrollados de esta manera tienen un porcentaje de éxito mayor que otros desarrollados con metodologías más tradicionales como las basadas en el ciclo de vida clásico o cascada.

Las asunciones son las siguientes:

– Los sistemas no se construyen perfectamente en una solo intento. Sin embargo siguiendo el Principio de Pareto, el 80% de los objetivos de una solución perfecta se puede desarrollar en el 20% del esfuerzo que se requeriría para obtenerlos. Por tanto, la realización de un desarrollo rápido debería centrarse en priorizar funcionalidades importantes para la cobertura de las funcionalidades de negocio dejando con las mismas satisfechos al conjunto de usuarios. Esto debería ser posible ya que la metodología requiere una implicación real de los usuarios.

Intentar construir un sistema perfecto es una utopía e intentar aproximarse demasiado pronto a esa idea de sistema es una pérdida de energía que además pone en riesgo al propio sistema de información, ya que como consecuencia de ello muchos de los inconvenientes de la crisis del software habrán impactado en el proyecto. Si intentamos subir una cuesta a máximo rendimiento desde el principio probablemente tardemos más en alcanzar la cima (si es que llegamos a ella).

– No se puede quitar la vista del objetivo de conseguir proyectos con calidad y dentro de los plazos y presupuestos.

Y añado yo, que satisfaga al usuario (eso debería estar ya implícito en el concepto de calidad, pero nunca está de más tener siempre presente que los proyectos y que nuestro trabajo (en la mayoría de los casos) está orientado a informatizar procesos que utilizan personas y que si las mismas no se sientes cómodas y no le sacan rendimiento no serán eficientes en el uso de la aplicación y se resentirá la productividad y la calidad de los datos que se graban.

– Pueden desarrollarse simultáneamente varios incrementos siempre y cuando no se entorpezcan entre sí.

– La metodología es válida más allá de desarrollos que comiencen desde cero. Es igualmente aplicable para mantenimientos incluso de proyectos no desarrollados siguiendo esta metodología o una similar.

¿Por qué no iba a serlo? La clave está en definir adecuadamente los incrementos (aunque sea más o menos difícil). Si estamos ante el mantenimiento de un sistema gigantesco que tiene incendios por todos lados resultará más complicado priorizar y se tardarán bastantes iteraciones en conseguir una cierta estabilidad.

Las bases de la metodología o la metodología en sí no constituyen una piedra filosofal para que todos los proyectos tengan éxito. Esta forma de entender los proyectos de desarrollo de software marcan un camino que desde mi punto de vista es el adecuado, pero generalmente la vía es tan ancha y hay tantas nubes que es fácil perderse.