Entradas etiquetadas con agilidad

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.

2010

No en todos los países del planeta se celebra el año 2010 en esta fechas, por ejemplo en China la llegada del nuevo año será el 14 de febrero, y en los países árabes están por el año 1432.

De todas maneras, como ni en esto existe un estándar y los que escribimos este blog tenemos como referencia el uno de enero como inicio del año, por eso decidimos hacer propósitos para marcar nuestros objetivos para el 2010:

a) Seguir informando a nuestros lectores de todo lo que ocurre sobre el Framework Scrum en español.

b) Construir una herramienta on line de gestión de Scrum para empresas u organizaciones.

c) Fomentar, apoyar y patrocinar eventos o reuniones donde la agilidad de desarrollo de proyectos sea el principal tema.

d) Participar en charlas, debates y conferencias para seguir divulgando la agilidad.

Básicamente estos son los cuatro pilares sobre los que se plantea el crecimiento de Scrum.es, el año comenzamos solo como un medio de información, pero este queremos dar el salto a poder ofrecer algunos servicios On Line y a colaborar de forma mas activa en la comunidad.
Al final del año haremos una retrospectiva para analizar los objetivos cumplidos.

Un aspecto importante para que se cumplan los objetivos, es que estos se planteen de forma natural, sin forzar las situaciones, dado que entonces se convierten en una obsesión y al final se consigue el efecto contrario, y un resultado negativo.

Tomando como principio básico la disposición al cambio por encima de seguir un plan, nunca se sabe si nos surgirán nuevos objetivos o algunos quedarán obsoletos.

Acuerdo agil Ir a una negociación cuando una de las partes no tiene conocimiento de ideas ágiles y su mente no está preparada para éstas, requiere una especial preparación previa a la reunión.

La preparación previa debe ensayarse en privado, como hacen los actores de teatro, dado que la primera parte de la reunión deberá ser una puesta en escena, una escena de cómo se desarrolla una metodología ágil donde la otra parte participará de forma activa. De esta forma se le muestra qué es una metodología ágil al mismo tiempo que participa en la simulación.

Dependiendo del tipo de cliente y de la cantidad de las personas que acudan a la negociación, se debe preparar una puesta en escena distinta, porque cuantas menos personas estén presentes, mayor será la participación de las mismas.

Supongamos que tenemos una negociación con tres personas del sector de la publicidad, la posible contratación de una campaña de publicidad esta en juego en la reunión.
Antes de comenzar la negociación se plantea que la metodología de trabajo es ágil, en este caso basada en Scrum, y que se quiere hacer una muestra gráfica de cómo se gestionan los procesos de desarrollo con los clientes.
Para esa negociación acudimos con cartas de Planning Poker para realizar una simulación de una estimación.
Repartimos las cartas a cada persona presente, con este gesto ya los invitamos a participar en la estimación de una forma natural.
Le proponemos estimar de forma ficticia la creación de un producto, por ejemplo, una silla, lo mejor es llevar fotografías de cada una de las partes de la silla.
Vamos sacando cada foto de las partes y hacemos rondas de estimación.
Al finalizar tenemos una pila de producto estimada por todos los participantes.

Con esta puesta en escena conseguimos que los asistentes se sientan mas informados sobre las metodologías ágiles, comenzamos la negociación con un ambiente más distendido, con un posible cliente más abierto a las metodologías ágiles, y que además verá cómo no tiene nada distinto a otras metodologías.

La puesta en escena de una representación de una estimación, involucrando a todas las partes en la reunión, jugando a las cartas, consigue romper las primeras reticencias de los clientes a introducir cambios en forma de trabajar con los proveedores.