Metodología ágil y problemas durante el desarrollo
El entorno, la competencia, los clientes o el propio equipo de desarrollo pueden ser los causantes de que la organización decida intentar adoptar una metodología ágil, como por ejemplo Scrum, para su siguiente proyecto. Esta decisión puede reducir drásticamente sus probabilidades de fracaso pero, al mismo tiempo, pone al Project Manager en una situación delicada, al quedar expuesto a una serie de desafíos inherentes a las primeras veces con este enfoque. Su habilidad y creatividad serán determinantes para el éxito del proyecto ya que, en la mayoría de los casos, su papel le obligará a tener que tomar decisiones rápidas... y acertadas.
Complicaciones derivadas de la falta de experiencia con la metodología ágil
Scrum es simple, fácil de entender (sólo hay que seguir las reglas) y requiere de disciplina. Con Scrum se pueden entregar proyectos a tiempo, en elevadas condiciones de calidad, sin exceder el presupuesto y con un cliente satisfecho. Pero esta metodología ágil puede suponer un reto para el Director de Proyecto y los equipos si concurren circunstancias como:
1. La falta de experiencia: la formación es importante para conocer, entre otras cosas, el lenguaje específico de esta metodología ágil, pero en lo que concierne a Scrum en la práctica, hace falta haber vivido situaciones que, si no se aprenden por la experiencia, pueden resultar difíciles de prever. Algunas de estas circunstancias tienen que ver con:
- Retrasos en la programación de proyecto.
- Distracciones ajenas al proyecto.
- Cambios en los requisitos.
Y no son las únicas. El Scrum Master tiene que ser capaz de guiar al equipo a través de las muchas decisiones del día a día, que tendrán que realizar. Scrum y cualquier otra metodología ágil son marcos de trabajo, pero en su aplicación a un proyecto hay que considerar cuidadosamente los detalles particulares. No es lo mismo liderar un equipo de desarrolladores expertos que uno en el que sus miembros nunca hayan trabajado con Scrum. Si en el primer caso, aparecerán complicaciones relacionadas con la disciplina asociada a este enfoque, en el segundo es probable que el inconveniente sea la confusión generada por los diferentes elementos de Scrum, que distraen al equipo de su trabajo, obligándoles a prestar una atención excesiva, en su afán por observar sus principios.
2. Demasiada experiencia: el problema no tiene que ver con el Project Manager, que nunca habrá reunido la suficiente, sino con los desarrolladores que, si están acostumbrados a trabajar de forma autónoma pueden encontrar que Scrum es innecesario y que ralentiza su ritmo de trabajo. No hay que olvidar que esta metodología ágil se caracteriza por su carácter colaborativo, que hace necesarias reuniones diarias y la participación del cliente, dos factores que pueden hacer saltar las reticencias de algunos miembros del equipo técnico.
En este caso, el Project Manager deberá actuar argumentando que:
- Si bien Scrum añade algo de sobrecarga al proceso de desarrollo, en comparación con el que se seguiría con otras metodologías, también ayuda a adquirir una visión significativa de la salud del proyecto y mejora la capacidad de tomar decisiones de gestión.
- Scrum proporciona información más realista sobre el proyecto que las herramientas tradicionales y, por ello, ayuda a que el equipo sea capaz de autogestionarse, por lo que es fuente de autonomía.
- Scrum es la alternativa más indicada para proyectos basados, al menos en parte, en cualquier solución existente, sobre todo si ya existen expertos en la materia. También se recomienda emplear esta metodología ágil si el número de personas que necesitan comunicarse regularmente supera las tres o cuatro. A diferencia de lo que sucedería en el escenario de desarrollo de un producto nuevo o en un proyecto con participación muy limitada, en el caso mencionado es necesario recurrir a un enfoque colaborativo.
3. Un sprint no es suficiente: podría suceder. En la práctica, el Project Manager puede darse cuenta de que algunos esfuerzos de desarrollo no encajan fácilmente en el tiempo que corresponde a un sprint. Este problema es susceptible de plantearse cuando se desarrolla una arquitectura nueva para el sistema, si el diseño para una interfaz de usuario, además de novedoso, es complejo; o si se detectan problemas de calidad de datos que obligan a aplicar procesos ETL (que pueden considerarse casi como otro proyecto en sí mismo). La misión del Director de Proyecto en cualquiera de estos casos es recurrir a la creatividad y:
- Redefinir el concepto de usuario final: si esta figura ya no es quien usará la aplicación se abre un amplio abanico de posibilidades que permite replantearse las tareas que deben asociarse a un sprint. De esta manera ya es posible fragmentar las tareas más complejas en distintas partes o capas que, al quedar divididas, permiten diseñar un calendario de entregas mucho más manejable.
- Redefinir el entorno: en vez de entregar todo el producto de inmediato, haría falta centrarse en la entrega de las piezas o partes que serán necesarias más temprano en el ciclo de desarrollo. En el caso de tomar esta decisión habría que priorizar los elementos que apoyen más capacidades o los que faciliten el programa de desarrollo inicial.
- Redefinir el sprint: ¿Hecha la ley hecha la trampa? tampoco es eso, pero, cuando se quiere seguir una metodología ágil sin excepción, ante casos como los presentados, se pueden tomar decisiones como ampliar o reducir la duración de un determinado sprint, si ello consigue garantizar el equilibrio en el conjunto del planning y, por supuesto, si no se convierte en un hábito. Permitir cierta holgura en proyectos donde la incertidumbre es un factor inherente es positivo, para el equipo y para los resultados.
