Metodologia Agil En Una Organizacion En Cascada - Historial de revisiones

Admin en 01:43 8 sep 2009

2009-09-08T01:43:32Z

Leito en 20:25 31 ago 2008

2008-08-31T20:25:18Z

200.125.124.96: /* Resistencia del Management */

2008-08-09T14:30:39Z

‎Resistencia del Management

200.125.124.96: /* Administración de recursos */

2008-08-09T14:30:31Z

‎Administración de recursos

200.125.124.96: /* Resistencia del Equipo */

2008-08-09T14:30:22Z

‎Resistencia del Equipo

200.125.124.96: /* Costos y Presupuesto */

2008-08-09T14:30:11Z

‎Costos y Presupuesto

190.172.86.173: /* 10 consejos para integrar Ágil y Cascada */

2008-07-26T17:40:48Z

‎10 consejos para integrar Ágil y Cascada

190.172.86.173: Página nueva: Es posible aplicar una metodologia ágil dentro de una organizacion que utiliza Cascada como proceso. Ambos mundos pueden coexistir: es necesario crear un "puente" entre ambos. De hec...

2008-07-26T17:38:57Z

Página nueva: Es posible aplicar una metodologia ágil dentro de una organizacion que utiliza Cascada como proceso. Ambos mundos pueden coexistir: es necesario crear un "puente" entre ambos. De hec...

Página nueva

Es posible aplicar una metodologia ágil dentro de una organizacion que utiliza Cascada como proceso. Ambos mundos pueden coexistir: es necesario crear un "puente" entre ambos. De hecho, esta es una situación común, y este "puente" suele ser el primer paso para una transformación más profunda.

Es posible entonces, por ejemplo, llevar un proceso ágil de desarrollo por más que los extremos no lo sean. Sin embargo, hay que tener en cuenta algunos obstáculos que puedan ocurrir en el camino, y cómo sortearlos.

==Obstáculos==
===Resistencia===
La resistencia al cambio es normal, y no será una excepción al intentar aplicar una nueva metodología. Es importante que la actitud a tomar deberá ser la de "vender" la metodología ágil, y no transformarse en un actor defensor de la misma (por sentirnos atacados).

====Resistencia del Management====
Lo más más recomendable es no intentar venderle el cambio: de todas formas, no saben lo que se está haciendo ahora tampoco.

Por otro lado, es importante comunicarse en su mundo e idioma: explicar los beneficios de una metodología ágil, el incremento del ROI, entregas más tempranas, mayor calidad, reducción de costos, etc. Evitar términos como Scrum, Sprint, Backlog, XP, etc, que no aportan al objetivo final.

Por último, es bueno recopilar historias de éxito para compartir con el management: esto les puede transmitir experiencias reales, y brindarles más seguridad sobre el cambio que se está llevando adelante.

====Resistencia del negocio====
Es importante involucrar al [[Dueño Del Producto]] y demás participantes desde el principio: tienen que sentirse parte del proceso, y comprender el mismo.

Sirve mucho destacar el bajo riesgo: "Satisfacción garantizada, o le devolvemos el dinero". Es decir, explicar que el Dueño del Producto puede realizar cambios frecuentes (cada 1 Sprint!), revisando qué cosas no le gustó del proceso y ver cómo cambiarlas. Más aún, puede cancelar el proyecto temprananmente si consigue la funcionalidad requerida, o el proyecto deja de tener sentido para el negocio.

Por último, una buena práctica es comenzar a adoptar herramientas y prácticas ágiles al proceso de desarrollo, por más que la metodología todavía no se implemente. Técnicas como [[Integracion Continua]], [[Automatizacion De Pruebas Unitarias]], programación de pares, etc, pueden ir "preparando el terreno" entre las personas.

====Resistencia del Equipo====
No hacerse problema por los integrantes escépticos: de hecho, es su trabajo diario el cuestionar y revisar. Es necesario responder y aclarar todas sus inquietudes, con sinceridad. Si no se sabe una respuesta, o plantean una situación que no se había previsto, integrarlos para hallar juntos una solución.

Es bueno también que el Equipo cuente con un "guía" (un Coach ágil), el cual los pueda asistir y guiar en el proceso de implementar un proceso ágil de desarrollo.

===Administración de recursos===
Muchas veces las empresas necesitan asignar personal por adelantado. Puede ayudar en estos casos presentar un Release Plan, para poder ir calculando qué personas serán necesarias en distintas fechas.

No es un requesito obligatorio que todos los integrantes del equipo se encuentren físicamente ubicados en el mismo lugar (si bien es una condición deseable). En el caso de que los equipos no pueden co-habitar el mismo espacio, será necesario contar con herramientas que faciliten su interacción.

===Vendors y Contrataciones===
Los Vendors proveen al equipo con algún servicio o producto necesario para el proyecto. Si la relación con el Vendor es a corto plazo, no vale la pena intentar explicarles el proceso ágil: simplemente tomar su resultado y seguir avanzando. Por otro lado, en el caso de relaciones a largo plazo (por ejemplo, integrantes tercerizados del equipo) será necesario realizar una capacitación y explicar el proceso de desarrollo ágil.

Cuando el proyecto sea para un cliente que no es ágil, será importante explicarles el proceso, haciendo incapié en los beneficios que se dará. Remarcar que pueden cancelar el proyecto cuando lo deseen, de manera de brindarles seguridad.

===Facilidades y Herramientas===
Todos los equipos y lugares de trabajo son diferentes, por lo que las soluciones van a variar de acuerdo al lugar. Involucrar siempre al equipo para encontrar soluciones al acondicionamiento del lugar: cómo ubicarse, dónde reunirse, qué salas usar, dónde pegar los gráficos, etc.

Es importante destacar que los equipos físicamente separados van a necesitar comunicarse diariamente, comunicar su avance a los stakeholders, poder planificar y colaborar entre ellos, y registrar decisiones que realicen.

Como requerimientos técnicos generales se pueden mencionar la necesidad de automatizar las prueba, integración continua y repositorios de código.

===Costos y Presupuesto===
Cuando sea necesario calcular el costo del proyecto, puede servir acotar el problema y calcular el costo de cada iteración. De hecho, con este dato se puede incluso calcular el costo por cada punto de historia, y el costo por "hacer nada".

En todo caso, conviene evitar la documentación innecesaria: quizás sea posible arreglar el envio de una foto por email del Burndown chart como muestra del avance.

==10 consejos para integrar Ágil y Cascada==
# __Establecer un ritmo de Inspección y Adaptacion__: Llevar adelante todas las reuniones de RevisionDelSprint y RetrospectivaDelSprint, haciendo incapié en aplicar las lecciones aprendidas de experiencias pasadas.
# __Encontrar un ejecutivo involucrado__: Es siempre deseable contar con un sponsor interesado en la aplicación del proceos ágil.
# __Socializar, no evangelizar__: Tener buenas relaciones, hablar con todas las personas posibles de la empresa, y explicar los beneficios es mucho más efectivo que transformarse en un evangelizador.
# __Usar el poder del Backlog__: Agregar problemas de la organización al backlog, para hacerlos evidentes pero también mostrar que se resuelven. Recordar que las tareas del Backlog no tienen que ser exclusivas del producto.
# __Tirarse a la pileta__: Lo más dificil es comenzar: no hay que esperar al "momento perfecto", simplemente lanzarse y empezar.
# __Usar el principio de "lo mínimo requerido"__: Ser eficientes y efectivos; no hacer tareas "demás". Recordar preguntarse siempre: ¿qué es lo mínimo que sirve para satisfacer el requerimiento?
# __Invitar a todos los no-agiles a las reuniones de planificación__: Compatir la reunión de planificación con personas no-ágiles, para que vayan viendo el proceso.
# __Enviar el feedback "hacia arriba"__: Ir informando el avance y el desarrollo del proyecto ágil "hacia arriba" en la jerarquia de la organización.
# __Prestar atención al comportamiento__: En momentos de crisis se suele volver a "la forma anterior". Prestar atención si, ante problemas, se tiende a volver a la forma anterior de resolver las situaciones, y corregir.
# __Invitar a todo el mundo a las Retrospectivas__: En estas reuniones el equipo y todos los interesados pueden opinar sobre cómo mejorar el proceso. Esto es importante ya que no sólo se mejora el proceso del propio equipo, sino su implementación en toda la organización.

==Ver también==
* [[Desarrollo Agil De Software]]
* [[Scrum]]

==Más información==
* [http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger Agile in the Waterfall Enterprise by Michele Sliger (video)]

← Revisión anterior		Revisión del 01:43 8 sep 2009
Línea 65:		Línea 65:
	* [http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger Agile in the Waterfall Enterprise by Michele Sliger (video)]		* [http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger Agile in the Waterfall Enterprise by Michele Sliger (video)]
	* [http://www.infoq.com/presentations/Introduction-Agile-Stacia-Broderick Agile for traditional Project Managers]		* [http://www.infoq.com/presentations/Introduction-Agile-Stacia-Broderick Agile for traditional Project Managers]
		+
		+	[[Category: Ágil]]

← Revisión anterior		Revisión del 14:30 9 ago 2008
Línea 13:		Línea 13:

	Por último, es bueno recopilar historias de éxito para compartir con el management: esto les puede transmitir experiencias reales, y brindarles más seguridad sobre el cambio que se está llevando adelante.		Por último, es bueno recopilar historias de éxito para compartir con el management: esto les puede transmitir experiencias reales, y brindarles más seguridad sobre el cambio que se está llevando adelante.
−

	====Resistencia del negocio====		====Resistencia del negocio====

← Revisión anterior		Revisión del 14:30 9 ago 2008
Línea 31:		Línea 31:

	No es un requesito obligatorio que todos los integrantes del equipo se encuentren físicamente ubicados en el mismo lugar (si bien es una condición deseable). En el caso de que los equipos no pueden co-habitar el mismo espacio, será necesario contar con herramientas que faciliten su interacción.		No es un requesito obligatorio que todos los integrantes del equipo se encuentren físicamente ubicados en el mismo lugar (si bien es una condición deseable). En el caso de que los equipos no pueden co-habitar el mismo espacio, será necesario contar con herramientas que faciliten su interacción.
−

	===Vendors y Contrataciones===		===Vendors y Contrataciones===

← Revisión anterior		Revisión del 14:30 9 ago 2008
Línea 26:		Línea 26:

	Es bueno también que el Equipo cuente con un "guía" (un Coach ágil), el cual los pueda asistir y guiar en el proceso de implementar un proceso ágil de desarrollo.		Es bueno también que el Equipo cuente con un "guía" (un Coach ágil), el cual los pueda asistir y guiar en el proceso de implementar un proceso ágil de desarrollo.
−

	===Administración de recursos===		===Administración de recursos===

← Revisión anterior		Revisión del 14:30 9 ago 2008
Línea 50:		Línea 50:

	En todo caso, conviene evitar la documentación innecesaria: quizás sea posible arreglar el envio de una foto por email del Burndown chart como muestra del avance.		En todo caso, conviene evitar la documentación innecesaria: quizás sea posible arreglar el envio de una foto por email del Burndown chart como muestra del avance.
−
−
−

	==10 consejos para integrar Ágil y Cascada==		==10 consejos para integrar Ágil y Cascada==

@@ Línea 63: / Línea 63: @@
 * [[Desarrollo Agil De Software]]
 * [[Scrum]]
 * [http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger Agile in the Waterfall Enterprise by Michele Sliger (video)]

@@ Línea 55: / Línea 55: @@
 ==10 consejos para integrar Ágil y Cascada==
-# __Establecer un ritmo de Inspección y Adaptacion__: Llevar adelante todas las reuniones de RevisionDelSprint y RetrospectivaDelSprint, haciendo incapié en aplicar las lecciones aprendidas de experiencias pasadas.
+# '''Establecer un ritmo de Inspección y Adaptacion''': Llevar adelante todas las reuniones de [[Revision Del Sprint]] y [[Retrospectiva Del Sprint]], haciendo incapié en aplicar las lecciones aprendidas de experiencias pasadas.
-# __Encontrar un ejecutivo involucrado__: Es siempre deseable contar con un sponsor interesado en la aplicación del proceos ágil.
+# '''Encontrar un ejecutivo involucrado''': Es siempre deseable contar con un sponsor interesado en la aplicación del proceos ágil.
-# __Socializar, no evangelizar__: Tener buenas relaciones, hablar con todas las personas posibles de la empresa, y explicar los beneficios es mucho más efectivo que transformarse en un evangelizador.
+# '''Socializar, no evangelizar''': Tener buenas relaciones, hablar con todas las personas posibles de la empresa, y explicar los beneficios es mucho más efectivo que transformarse en un evangelizador.
-# __Usar el poder del Backlog__: Agregar problemas de la organización al backlog, para hacerlos evidentes pero también mostrar que se resuelven. Recordar que las tareas del Backlog no tienen que ser exclusivas del producto.
+# '''Usar el poder del Backlog''': Agregar problemas de la organización al backlog, para hacerlos evidentes pero también mostrar que se resuelven. Recordar que las tareas del Backlog no tienen que ser exclusivas del producto.
-# __Tirarse a la pileta__: Lo más dificil es comenzar: no hay que esperar al "momento perfecto", simplemente lanzarse y empezar.
+# '''Tirarse a la pileta''': Lo más dificil es comenzar: no hay que esperar al "momento perfecto", simplemente lanzarse y empezar.
-# __Usar el principio de "lo mínimo requerido"__: Ser eficientes y efectivos; no hacer tareas "demás". Recordar preguntarse siempre: ¿qué es lo mínimo que sirve para satisfacer el requerimiento?
+# '''Usar el principio de "lo mínimo requerido"''': Ser eficientes y efectivos; no hacer tareas "demás". Recordar preguntarse siempre: ¿qué es lo mínimo que sirve para satisfacer el requerimiento?
-# __Invitar a todos los no-agiles a las reuniones de planificación__: Compatir la reunión de planificación con personas no-ágiles, para que vayan viendo el proceso.
+# '''Invitar a todos los no-agiles a las reuniones de planificación''': Compatir la reunión de planificación con personas no-ágiles, para que vayan viendo el proceso.
-# __Enviar el feedback "hacia arriba"__: Ir informando el avance y el desarrollo del proyecto ágil "hacia arriba" en la jerarquia de la organización.
+# '''Enviar el feedback "hacia arriba"''': Ir informando el avance y el desarrollo del proyecto ágil "hacia arriba" en la jerarquia de la organización.
-# __Prestar atención al comportamiento__: En momentos de crisis se suele volver a "la forma anterior". Prestar atención si, ante problemas, se tiende a volver a la forma anterior de resolver las situaciones, y corregir.
+# '''Prestar atención al comportamiento''': En momentos de crisis se suele volver a "la forma anterior". Prestar atención si, ante problemas, se tiende a volver a la forma anterior de resolver las situaciones, y corregir.
-# __Invitar a todo el mundo a las Retrospectivas__: En estas reuniones el equipo y todos los interesados pueden opinar sobre cómo mejorar el proceso. Esto es importante ya que no sólo se mejora el proceso del propio equipo, sino su implementación en toda la organización.
+# '''Invitar a todo el mundo a las Retrospectivas''': En estas reuniones el equipo y todos los interesados pueden opinar sobre cómo mejorar el proceso. Esto es importante ya que no sólo se mejora el proceso del propio equipo, sino su implementación en toda la organización.
 ==Ver también==