MANUAL TE GP AGILES

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Muchas veces el intento de no asumir ese retraso hacía que se instalasen productos con deficiencias detectadas en producción y se tratasen como bugs de mantenimiento. Esto no beneficiaba en absoluto a la empresa, ya que dejaba en entredicho uno de los valores de nuestra empresa más importantes en el mercado: la calidad. Por tanto, lo que se hizo fue fundir todos esos distintos departamentos en uno solo y dividir a la gente en equipos multidisciplinares. No era una idea descabellada. Scrum abogaba por equipos heterogéneos con expertos en todas las áreas necesarias y eso precisamente es lo que teníamos. Así, nuestros equipos estarían formados mínimo por un miembro de cada departamento (siempre había más desarrolladores que otros perfiles). Lo mejor de todo es que los productos empezarían a trabajarse de manera que todos sus diferentes aspectos (diseño, implementación, pruebas, etc.) se paralelizarían. La definición de “hecho” implicaba que todos los miembros hubiesen realizado su trabajo en el producto y, por tanto, este se ajustase a lo esperado en diseño, implementación, experiencia de usuario y calidad entre otros requisitos. Las entregas a cliente serían desde entonces de un producto realmente acabado. Lo que resultó más difícil de llevar todo esto a cabo fue sacar a los miembros del equipo con más antigüedad de la comodidad que suponía para ellos hacer “el trabajo de siempre” y comenzar a realizar labores que hasta entonces realizaba gente de otro departamento ajeno, ya que, lógicamente, ni el tester podía estar de brazos cruzados hasta que el resto del equipo desarrollase algo que poder probar, ni el desarrollador podía quedarse parado mientras el tester probaba su trabajo. Poco a poco, aunque con más resistencia al principio, todos los miembros del equipo sabían hacer de todo, aunque por supuesto cada uno tenía su especialidad y la explotaba siempre que le era posible, en beneficio no solo propio, sino del equipo entero. De esta manera, ningún equipo se sentiría desatendido, ya que al hacer un cambio tan grande y no progresivo (recordad que al principio de la clase hemos visto que lo recomendable es empezar por un pequeño proyecto piloto y después escalarlo al resto de proyectos) un solo Scrum Master tenía altas probabilidades de sentirse desbordado. Para el rol de Product Owner se barajó la posibilidad de contratar a una nueva persona con experiencia de Business Analyst, pero como una de las grandes preocupaciones iniciales era los posibles problemas de comunicación entre equipo y Product Owner, la decisión final fue que el jefe de proyecto precursor del cambio ocuparía ese rol de inicio y más adelante se irían incluyendo nuevos Product Owners. Al existir varios equipos, se vio necesaria también la figura de múltiples Scrum Master, que, como antes se comentó, ya se tenía pensado que fuesen los distintos jefes de proyecto.

170

European Open Business School