Diferencia entre revisiones de «Metodologia Agil En Una Organizacion En Cascada»
(→Administración de recursos) |
m |
||
| (No se muestran 2 ediciones intermedias de 2 usuarios) | |||
| 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==== | ||
| Línea 64: | Línea 63: | ||
* [[Desarrollo Agil De Software]] | * [[Desarrollo Agil De Software]] | ||
* [[Scrum]] | * [[Scrum]] | ||
| + | * [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] | ||
| − | + | [[Category: Ágil]] | |
| − | |||
Revisión actual del 01:43 8 sep 2009
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.
Contenido
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 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.
- 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.
