MANUAL TE GP AGILES

MANUAL GESTIÓN DE PROYECTOS ÁGILES

Aunque existirán casos donde esto sea posible, es importante realizar un nuevo trabajo de análisis previo (una nueva iteración) en el que se incluirá dentro del estudio el aprendizaje obtenido por la experiencia con el proyecto piloto. Hay que tener en cuenta el esfuerzo invertido en formar, motivar, guiar y resolver dudas a un pequeño equipo y dimensionarlo en su justa medida al trabajo que queda por delante. Que se haya podido formar un equipo en un tiempo concreto no significa que en ese mismo tiempo se pueda formar un equipo de dimensión mucho mayor. Tampoco significa que si se han empleado X meses con el equipo piloto, se necesiten x * 4 para formar 4 equipos. La experiencia ha de ser tenida en cuenta y una práctica muy útil es introducir al menos un miembro del equipo piloto en cada nuevo equipo a formar. De esta manera, ya existirá otra persona con conocimiento que puede guiar a sus compañeros de equipo (al fin y al cabo el equipo se auto gestiona y cada miembro acaba encontrando su rol).

2.4.3. EXPERIENCIA POSITIVA (COMENZANDO POR EL EQUIPO)



Antecedentes

Este caso trata de la experiencia vivida por una empresa de desarrollo de software a la hora de implantar scrum.

La empresa buscaba una nueva forma de trabajar, ya que se habían dado cuenta de que cada vez más contaban con perfiles muy especializados en determinadas áreas y productos de los cuales una sola persona era experta. Esto llevaba a que la ausencia de un miembro del equipo de desarrollo penalizaba enormemente el desarrollo de nuevos proyectos y ni que decir cabe del mantenimiento de proyectos en producción. Así mismo, la propia metodología de trabajo había derivado en un ciclo vicioso en que lo único que se hacía era resolver crisis inmediatas, ya que todos los clientes con los que trabajaban solicitaban nuevos desarrollos y cambios en los productos ya entregados, sin ningún tipo de control y siempre con prioridad alta. Esto derivaba en que, por un lado, el equipo de desarrollo se antojase infradimensionado, asignando finalmente una sola persona a varios proyectos sin ningún tipo de comunicación o intercambio de información con sus compañeros, y, por otro, a que los miembros del mismo no tuviesen manera de planificar y dimensionar su trabajo de manera coherente. La paralelización del desarrollo de funcionalidades e incluso entre proyectos hacía que las peticiones de los clientes se comenzasen nada más ser solicitadas, dejando paradas

164

European Open Business School