En todo proyecto software, hay cambios. El cambio, hay que aceptarlo como lo que es, y entender su motivación y circunstancias. Hoy nos vamos a centrar en estar preparados para el cambio en el desarrollo de software, mediante 5 puntos clave que hay que conseguir. Además, otros 3 puntos clave que hay que evitar, para que no nos "hundan el chiringuito". Vamos Allá.
1. Puntos Clave a cumplir
1.1. El proyecto tiene designado un equipo/comité responsable de los cambios.
No hace falta que sea un comité sofisticado, ni pensemos en un comité como 20 personas serias y estiradas reunidas en una sala gigante durante horas. Un comité simplemente es una reunión formal o informal, en la que se revisan temas (cambios en este caso), y donde todas las partes están representadas. Una persona puede representar a varias partes. Por ejemplo, sería interesante que al menos hubiera participantes por parte de:
- Cliente (responsable que defiende los intereses del cliente).
- Equipo de desarrollo (responsable funcional/técnico)
- Dirección del proyecto (responsable económico/planificación)
Puede ser suficiente un foro, un blog, o una lista de correo (ni siquiera se tienen que reunir físicamente esas personas).
1.2. El proyecto tiene un plan o procedimiento escrito y aceptado de gestión de cambios.
Aquí, de nuevo, menos es más. Me hace gracia cuando en una reunión planteo cómo se van a gestionar los cambios. Todo el mundo asume que los cambios se van a hacer. Ese no es el tema. La gestión del cambio está para decidir qué/cuándo/cómo. De eso hablaremos en detalle otro día.
Como siempre, lo importante es aclarar el funcionamiento y acatar las decisiones tomadas en consecuencia.
1.3. Las peticiones de cambio se evalúan por todas las partes implicadas en el proyecto, antes de resolverse.
Esto es importante, si nos dejamos a alguien fuera al resolver un cambio, tenemos todas las probabilidades de que esa parte decisoria será la que nos haga echar el cambio atrás. De hecho, hay gente que lo hace por el mero placer de ejercer el poder de hacerlo.
1.4. El equipo/comité responsable de cambios, se asegura de que todas las partes implicadas están adecuadamente informadas de cómo se resuelven los cambios.
Otra vez un punto crítico: no nos dejemos a nadie fuera. ¿Te gusta que tu pareja tome una decisión o haga algo sin decírtelo? (no, ya sé que tu pareja lo hace, te estoy preguntando si te gusta!).
1.5. El equipo/comité responsable de cambios evalúa los cambios por paquetes, evitando distraer al equipo de desarrollo de forma constante.
Bastante tienen/tenemos los desarrolladores con lidiar con las complejidades técnicas, las dificultades de las distintas arquitecturas, la definición funcional, etc, etc....como para que encima nos interrumpan cada poco tiempo con cosas nuevas. Hay quien dice que es mejor interrumpir con los cambios, ya que éstos pueden afectar al trabajo en curso. MENTIRA. Déjame acabar lo que estaba haciendo, y luego ya veré cómo aplico el cambio. ¿A alguien se le pasa por la cabeza reformar su casa mientras los albañiles están levantando los pisos y poniendo ladrillos?.
2. Puntos clave a evitar.
2.1. Las decisiones del comité de cambios pueden contradecirse por la dirección, marketing o el cliente.
A ver, hay que ser serios. Respetemos los acuerdos alcanzados.
2.2. El equipo de desarrollo no tiene tiempo suficiente para seguir el plan.
De nada sirve montar un comité ni toda esta fiesta, si el equipo de trabajo está con sobreesfuerzo. Si no hay tiempo, y el plan no se puede seguir, menos aún podremos abordar cambios. Hay técnicas para eso, pero mejor lo dejamos para otro día.
2.3. Los productos del trabajo no siguen el control de cambios.
Esto que dicho así suena muy sofisticado, no es más que hacer el maldito check-in, anotar los cambios, y asociarlos a alguna tarea. Lo mismo cuando estemos preparando una versión al final de un sprint. Etiquetemos adecuadamente las versiones, su estabilidad, etc. Pocas cosas hay más divertidas que después de que nuestro equipo de sufridos testers pierda días y días probando la versión N, ahora vamos nosotros y entregamos al cliente la versión N+1. Manda huevos.
No hay comentarios:
Publicar un comentario