Resistencia a los cambios

Escrito por Diego Gomez

Miércoles 01 de Octubre de 2008 16:51

Las metodologías ágiles enfrentan resistencia en muchos mercados. A menudo, la resistencia está en nosotros mismos!

Ciertamente, esta metodología es un quiebre al paradigma. Y para entender bien un nuevo paradigma a veces es preciso que vaciemos algunos conceptos de nuestra cabeza para absorber otros. Muchas empresas todavía ofrecen resistencia a estos frameworks de procesos ágiles a causa de algunos puntos. Vamos a mencionar algunos:

Puro desconocimiento (ignorancia?). No se conoce la metodología ágil y los beneficios que trae.
Prejuicios. Alguien ha dicho que no funciona y, por tanto, se convierte en una creencia.
Se cree que funciona para otras empresas, pero que es imposible de aplicar en el propio lugar de trabajo.
Interpretaciones erróneas y extremistas de conceptos ágiles.

Podemos adoptar una metodología ágil repentinamente aplicando todas las prácticas o adoptarla poco a poco comenzando con una o dos técnicas y avanzar por etapas. Podemos trabajar con agilidad tanto en las pequeñas como en las grandes empresas. En las grandes empresas existe una gestión y cuestiones culturales, pero no debemos ver esto como barreras, sino más bien para examinar la manera en que la agilidad se puede aplicar sin causar fricciones innecesarias.

Para hablar de la mala interpretación es clásico el ejemplo de Pair Programming. Muchas personas piensan que esta técnica puede interferir, pero ignora el hecho de que el código está en proceso de revisión en cualquier momento. Cualquier buena práctica ágil puede no funcionar si no se aplica correctamente, es por eso que tenemos papeles importantes para prevenir esos desvíos, como el entrenador (coach) de Extreme Programming y el ScrumMaster de Scrum.

Quién mira el lado extremo es el que dice que lo ágil no hace ninguna documentación, pero ninguna metodología dice eso. Lo que dice el Manifiesto ágil es que los individuos y las interacciones son más importantes que los procesos y herramientas. Como dice Felipe Rodrigues, "La documentación buena es aquella que es estrictamente necesaria. El resto es resto".

Muchas preguntas pasan por nuestra cabeza cuando nos enfrentamos a nuevos paradigmas, es normal! Sin embargo, una opinión debe ser formada cuando se conocen bien los opuestos.

¿Como estimar plazos en una metodología ágil? ¿Cómo es el contrato? Cómo asegurar implementar funcionalidades dentro del alcance?

Uno de los grandes logros de la metodología ágil seguramente es la estimación de plazos. Scrum tiene varias técnicas para estimar un plazo conciso. Sin embargo, como estimar? Scrum propone la planificación de Poker.

Y si la estimación falla? Es más difícil que esto suceda porque los Sprints (iteraciones) deben ser cortos, y si sucede, existe en Scrum la Retrospectiva de Sprint, y la Revisión del Sprint para poder cambiar y mejorar para la próxima iteración.

¿Cómo aprender de los errores? Backlog del Producto actualizada. Cómo mantener el equipo motivado? Scrum diario. ¿Cómo hacer mejor código? Pair Programmig, Integración Continua, Chequeo Estático de Código, TDD, Cobertura.

Alguien ya pensó en los problemas que la gente endrenta. Siempre escuchamos la frase "No reinventar la rueda".

Una metodología ágil debe decir que el cliente ha de estar siempre cerca del equipo, y cuantos mas desarrolladores participen de las reuniones, sobre los requisitos, por ejemplo, mejor. En Scrum existe en el papel de dueño del producto (PO) (se puede pensar en el cliente del ejemplo citado), el Equipo y el ScrumMaster. Esto es a menudo suficiente.

Podemos tener analistas de negocios? Sí, siempre que no se trata de un intermediario.

Espero sus comentarios.

Desde VisionAgil

Comentarios

Añadir nuevo

Buscar