viernes, diciembre 22, 2006

Feliz Navidad (un clásico)





Os deseo a todos una Ágil Navidad y que en este Metodológico 2007 tomeis buenas decisiones ;-D

¡¡¡¡FELIZ NAVIDAD Y PRÓSPERO AÑO 2007!!!!

viernes, diciembre 01, 2006

La metodología como caballo de troya

Uno de los problemas que nos podemos encontrar en las organizaciones es que no estén lo suficientemente maduras para la agilidad como ya comenté en ¿Cuando puedo aplicar una metodología ágil? y en 7 Paradigmas a romper para ser ágiles

Si a esto le unimos la semiestructuración de los procesos decisionales, nos encontramos que para aplicar una metodología ágil en un proyecto de Business Intelligence, tenemos que tener muy claro a que nos estamos enfrentando. Para ello el primer proyecto que se haga de estas características en la organización tiene que tener no solo el caracter de una metodología rigurosa y seria, sino también la característica de "evangelizar", de ser un caballo de Troya que infecte a todos los ambitos de desarrollo de la organización.

Un metodología (que desgraciadamente su autor no ha seguido desarrollando) es el Adaptative Software Development, esta metodología parte de la idea de que las necesidades del cliente son siempre cambiantes durante el desarrollo del proyecto (y posteriormente a su entrega). Cosa que nos viene que ni pintada para los sistemas decisionales

Su impulsor es Jim Highsmith, la novedad de esta metodología es que en realidad no es una metodología de desarrollo de software, sino un método (como un caballo de troya) a través del cual inculcar una cultura adaptativa a la empresa ya que su velocidad de adaptación a los cambios marcará la diferencia entre una empresa próspera y una en declive.

La incertidumbre y el cambio continuo son el estado natural de los sistemas de información, pero parece ser que muchas organizaciones aún no son conscientes de ellos. La idea de “finalizar” un proyecto carece de sentido porque debe seguir adaptándose y con mas razón si se trata de un sistema decisional. Siempre estamos cambiando nuestros puntos de vista.


Así pues tenemos una metodología (mas bien un metodito) con 4 objetivos claros (independientemente de que el proyecto sea un éxito)

  1. Concienciar a la organización de que debe esperar cambio e incertidumbre y no orden y estabilidad.
  2. Desarrollar procesos iterativos de gestión del cambio.
  3. Facilitar la colaboración y la interacción de las personas a nivel interpersonal, cultural y estructural.
  4. Marcar una estrategia de desarrollo rápido de aplicaciones pero con rigor y disciplina.El ciclo de vida que propone se basa en tres fases

El ciclo de vida que propone se basa en tres fases

Fase 1: Especulación. Se inicia el proyecto y se planifican las características del aplicativo a desarrollar.

Fase 2: Colaboración. en esta el equipo de desarrollo se encarga de implementar las características

Fase 3: Aprendizaje. En ella se revisa su calidad, se aprende de los errores y se vuelve a iniciar el ciclo de desarrollo y/o se entrega al cliente.

Pero lo importante no son las fases ni nada por el estilo, lo realmente importante es que cambia la semántica de la creación de sistemas de información:

En lugar de analizar, diseñar, implementar, etc.. que es el lenguaje habitual con una semántica de infalibilidad y definitud (creo que me he inventado esta palabra) algo jactante, pasamos a especular, colaborar y aprender juntos y eso creo que es una buena característica para una metodología, sea cual sea su ámbito de actuación.


Por favor no me pongais ningún comentario a esta entrada (estoy probando la psicología inversa a ver si consigo mas colaboración) :-D