Es difícil hacer un resumen para que se entienda fácilmente la diferencia entre ambos planteamientos, por ello, hemos dibujado dos gráficos que unidos ayudan a explicar mejor la diferencia entre las estas dos opciones de metodologías.

En el planteamiento en cascada se realiza un plan estimando la documentación de seguimiento de un programa y el coste de ejecutarlo. Como resultado se tienen que dar una características y sobre ella se van desarrollando el plan y el resultado.

En la metodologías ágiles el planteamiento es distinto.

Se realiza una estimación sobre las características, lo cual da como resultado una visión, no un plan de ejecución, como ocurre en la planificación en cascada, y luego se trabaja sobre el programa y el coste.

La gran diferencia entre las dos formas es el corazón, lo que se encuentra dentro del triángulo, en la planificación en cascada es el “plan”, en la metodología ágiles es la “Visión”. La otra diferencia  es que en una el coste esta totalmente cerrado, sobre el mismo se ha realizado un programa y se ejecuta, y en la otra como se abrigan los cambios, no hay un coste cerrado.

Que no exista un coste cerrado no significa que sea malo para el proyecto ni perjudicial para terceros, normalmente se tiende a pensar en que va a costar mas de lo que se planificó, pero puede ocurrir lo contrario, que la visión lleve a ejecutarse un producto mas sencillo de hacer y con unos costes menores de los previamente previstos. Los costes se irán definiendo mejor cuanto mas se acerque uno al final del proyecto, es muy difícil en muchas ocasiones saber al 100%  el coste total, y si además, el proyecto se atañe a unas cantidades fijadas, perderá eficiencia y eficacia, dado que estos valores se colocarán por debajo en importancia del cumplimiento de unos costes ya firmados.

Las metodologías ágiles, lo que ponen sobre la mesa es que se trabajaba sobre una estimación de las características que se quieren crear en un producto, con una visión que va enfocando el camino, una visión que crece y se enriquece con el paso del proyecto y que, la mejor definición de la misma puede hacer variar el coste y el programa cuando se reciben los primeros resultados de las entregas parciales del producto.

Ya se ha anunciado la primera conferencia nacional sobre metodologías ágiles en España. Será el 10 y 11 de junio de 2010 en Madrid, en el Campus de la E.U. Informática de la U.P.M.

Toda la información sobre la misma se encuentra en la web de Agile Spain de la conferencia 2010.

Como invitado principal estará Henrik Kniberg autor de “Scrum y XP desde las trincheras” y de “Kanban vs. Scrum – Obteniendo lo mejor de ambos”.

Es una gran noticia la organización de este evento, por primera vez todos los profesionales que emplean metodologías ágiles tendrán una cita ineludible en España.

Todos podemos ayudar a que el evento sea un éxito, la mejor manera es participar activamente y para ello puedes hacerlo de tres maneras distintas:

Desde este blog apoyamos esta iniciativa activamente, iremos comunicando todas las novedades sobre el evento, ni que decir tiene que ya hemos enviado nuestras propuestas de conferencias.

Unas de las cuestiones que se plantean los gerentes o directivos de empresas es cuando integrar las metodologías ágiles en sus organizaciones.

Para responder a esta pegunta hay que realizar un análisis de la situación actual de cada empresa, para ello se deben de tener en cuenta los requisitos y la tecnología que se está empelando.

En la gráfica podemos ver que si disponemos de una tecnología conocida y unos requisitos específicos , el problema a solucionar es bastante sencillo, por lo que cualquier sistema es válido para sacar el trabajo adelante. En el caso contrario ocurre lo mismo, cualquier trabajo sobre una tecnología desconocida y unos requisitos muy vagos, lo único que consigue es una anarquía que no puede solucionar ninguna metodología de trabajo, ni las ágiles, ni ninguna otras.

Integrar una metodología ágil en una organización o empresa, debe de tener como objetivo principal gestionar proyectos que estén dentro de la zona compleja.

Si la mayoría de los proyectos de una empresa se encuentran en la zona azul, es cuando se recomienda a los gestores de la misma el uso de metodologías ágiles. Esta recomendación viene avalada por que es justamente donde se puede sacar el máximo beneficio de Scrum y de sus procedimientos.

El framework Scrum está preparado y es efectivo para manejarse en las situaciones complejas, e incluso las que rocen la anarquía. En las otras zonas se comporta igual que cualquier otra metodología.

Cuando un cliente nos escribe en un documento las necesidades que tiene para alcanzar sus objetivos, nos esta dando una información muy amplia y normalmente poco precisa en bastantes aspectos. El cliente suele tener claro el objetivo, pero muy poco los detalles peque´ños, que al final son los garantizan poder tener éxito.

Tomemos como ejemplo un cliente que nos plantea el objetivo de tener una web de comercio electrónico para la venta de productos naturales de cultivo ecológico. Tiene muy claro el objetivo principal, y nos transmite este objetivo en un extenso documento, pero normalmente olvida traducir este documento en tareas a desarrollar.

La primera misión del Product Owner es exprimir toda la información que recibimos para convertirla en un documento donde se escriban los pequeños objetivos que tenemos que alcanzar, la pila de producto.

Como es bastante difícil poder desfragmentar en pequeñas tareas todos los objetivos intermedios del cliente, lo mejor es dividir los mismos en varios niveles de precisión. Básicamente, podemos precisar de forma mas exhaustiva las primeras tareas a realizar, sin saber como serán las que realizaremos dentro de unos meses u años, dado que no podemos adivinar al cien por cien el futuro.

La mejor manera de manejar la incertidumbre del futuro es crear distintos niveles de tareas en la pila de producto.

  • Épicas: Son todas las grandes ideas del cliente. Todas se pueden hacer, no se dice no a nada. Las estimaciones suelen ser altas, al tener un alto grado de incertidumbre.
  • Temas: Las ideas generales ya diseccionadas en áreas de trabajo distintas.
  • Historias: Detalles concretos de cada tema
  • Tareas: Si una historia dura mas de dos días de trabajo, debería dividirse en tareas, no es recomendable que se trabaje en una historia que dure mas de dos días.

Pongamos un ejemplo:

  • Épica: Meter sistema de pago On Line
  • Tema: Pago Por Tarjeta, Transferencia o PayPal
  • Historia: Conexión con un banco en concreto.
  • Tareas: Test, XML, etc.

En el ejemplo anterior no parece muy difícil disgregar las épica hasta llegar a las tareas. Esto por que es el primer objetivo del cliente que hemos analizado. Pero supongamos que el proyecto de desarrollo del portal se estima en un año. Al momento del inicio, no sabemos con que nos vamos a encontrar en un futuro, por lo que lo mejor es redactar una épica.

  • Épica: Meter sistema de pago On Line
  • Tema: Pago Por Tarjeta, Transferencia, PayPal, Iphone, Android, o algún nuevo sistema que salga, por ejemplo si lo lanza Google.
  • Historia: Conexión con un banco, no tenemos ni idea de con que banco, dado que esta negociando als condiciones.
  • Tareas: No existen tareas, dado que no hay historias concretas.

Como podemos comprobar, predecir el futuro es imposible, e incluso puede que el cliente al final no llegue a ningún acuerdo con ningún banco y solo acepte PayPal. Es por esto que para tener un rango del coste se crean dentro de la pila de producto distintos niveles de detalles, el cliente puede tener una idea aproximada, pero no se puede concretar hasta que llegue el momento de abordarla.

Perder el tiempo en querer redactar de forma detalla el futuro es una pérdida de tiempo y dinero, y casi siempre genera un gran conflicto entre el cliente y la empresa contratada. La recomendación es muy clara, emplear distintos niveles de detalles en la pila de producto.

Un equipo de Scrum es mas que la suma de sus individualidades. La foto que empleamos para ilustrar este artículo es el fiel reflejo de la relación de un equipo de Scrum.

Deben divertirse como niños, el trabajo que realizan, aún asumiendo su cuota de responsabilidad, les debe permitir divertirse, jugar en equipo. Esa es la principal cualidad que debe tener un equipo de Scrum.

Estamos acostumbrados a que las personas vean el trabajo como una carga, un mal menor. Esa es la opinión o pensamiento general que suelen tener los gerentes o directores de empresas. Que los miembros de su equipo hacen las cosas por obligación, buscando solo el beneficio económico.

Este planteamiento es un error muy común, como podemos ver en la pirámide de Maslow:

El nivel económico es una necesidad que se puede considerar que cubre los dos primeros escalones de la pirámide, pero no es la principal que hace que una persona cualificada se mantenga en su puesto de trabajo.

Hay que diferenciar, entre personas cualificadas y personas no cualificadas. Estás últimas tienen mas difícil el acceso al mercado de trabajo y un ascenso en el mismo, por lo que normalmente se conformarán con cubrir sus necesidades básicas.

Las personas cualificadas buscaran seguir escalando en la pirámide lo mas alto posible. En un equipo de Scrum se puede progresar, y seguir avanzando escalones de la pirámide.

En un equipo, si se les deja ser como niños, tener ilusiones, poder gestionar y solucionar problemas, ayudarles y estimular la participación global, por encima de una competición individual, al final se consigue que los miembros del equipo, alcances los siguientes niveles sin necesidad de hundir o desprestigiar a otros compañeros de trabajos.

Trabajando en equipos autogestionados las personas alcanzan: La afiliación, el reconocimiento y la autorealización.

El principal valor que tiene que tener un equipo es ser como un niño: Tener la mente abierta todo, poner ilusión en lo que hace, no mentir y sobre todo, disfrutar mucho de los que se está haciendo, compartir los éxitos y fracasos entre todos y ser feliz.

Es muy raro no ver a un niño feliz cuando juega a algún deporte con amigos en un equipo. En caso de no serlo, hay que educarle a pensar en el equipo por encima del egoísmo personal.