Cualquier marco de partida ha de basarse en los 5 niveles de planificación que contempla la gestión ágil, cuyos tres niveles superiores, visión, hoja de ruta y planificación de release son parte de la fase de definición que deberá liderar el cliente. La fase de ejecución, que incluye la planificación de sprint y la diaria, se suele hacer con Scrum, y en caso de incluir un proveedor externo estará supervisada por un coordinador del cliente que hará de nexo y será responsable del seguimiento del proyecto. Por último un departamento de seguridad y calidad, generalmente una PMO (oficina de proyectos), se encargará de asegurar el cumplimiento con el nivel de calidad definido por los criterios de hecho y las políticas definidas.
Niveles de planificación y aproximaciones |
Definición
La fase de definición permitirá obtener los siguientes 5 outputs:
- Visión del producto
- Pila de producto inicial
- Planificación de la primera release
- Hoja de ruta del producto
- Valoración económica y plazo
Marco general que sintetiza como algunas compañías tradicionales inician su transformación ágil |
- Quién es el público: ¿Quién va a utilizar tu producto?
- Qué problema tiene: ¿Qué problema o necesidad latente se va a satisfacer?
- Qué solución se ofrece: ¿Cómo se va a satisfacer?
Organización del equipo de trabajo: Obtenida la aprobación del proyecto se deberá de constituir la organización del equipo que liderará el proyecto, se identificaran:
- Propietario del Producto: que liderará la macrogestión del proyecto dándole misión y propósito.
- Coordinador: que apoyará la microgestión y la maestría del equipo de desarrollo por venir y actuará de enlace con sistemas, arquitectura y calidad del cliente.
- Scrum Master: que se ocupará de la gestión del modelo operativo de Agilidad y su mejora continua así como de la gestión de las personas (formación, entrenamiento y asentamiento del modelo).
- Interesados: se identificaran todos los interesados en el proyecto, todos aquellos que pueden influenciarlo y que son usuarios del software a construir.
Taller funcional: En este taller se pretende obtener la parte funcional de la pila de producto inicial a través de un User Story Mapping sobre cada uno de los procesos, desde los diferentes puntos de vista de quienes interactúan con el sistema.
Asistirán a este evento, liderado por el Propietario del Producto, quienes conocen el negocio, entre ellos usuarios, así como parte o todo el equipo de desarrollo. Las actividades y conversaciones que se producirán tienen un gran beneficio porque abren canales de comunicación entre las personas de negocio y tecnología.
Todos los requisitos identificados se estimarán en valor de negocio y se trasladarán a un tablero con la hoja de ruta, priorizando las historias de usuario en función de la release de la que se pretende que formen parte. Se dará especial foco a la primera release que constituirá el Mínimo Producto Viable (MPV).
Taller técnico: consiste en la añadidura de historias técnicas por parte del equipo de sistemas y del equipo de desarrollo si este último ya estuviera constituido. Muy posiblemente la primera release requiera preparar un entorno de producción, arquitectura... historias sin las que sería imposible que funcionara el software construido. Estas historias técnicas se estimarán en esfuerzo y se refinará la priorización de la pila de producto sobre la hoja de ruta.
Valoración económica y plazo: finalmente el coordinador elaborará junto con el Propietario del Producto el contenido inicial del proyecto. En función del presupuesto disponible realizarán un corte en la pila de producto con aquello que el presupuesto permita abarcar en total de esfuerzo y plazo. Esta valoración servirá de base para el pliego y la contratación del equipo de desarrollo de proveedor.
En este modelo tiene especial importancia al sprint 0 ya que en él se establece el entorno de colaboración entre cliente y el proveedor.
- Visión del producto: coincidimos todos en ello como una de las cosas más importantes. Visión de lo que hay que hacer y además que esté compartida. Saber qué es y que no es el producto.
- Equipo: formado, motivado y con actitud proactiva.
- Intervinientes y contactos: quien tiene algo que hacer y qué.
- Fases de aceptación: proceso para conseguirlo, acuerdos de trabajo. Definición de hecho (Done).
- Expectativas de Calidad.
- Detección de dependencias.
- Restricciones o limitaciones: de seguridad, de rendimiento, de disponibilidad, …
- Pila de riesgos del proyecto: se pueden intercalar con la pila de producto, para dar respuesta temprana a cualquier riesgo.
- Métricas que se seguirán en el proyecto.
- Entorno tecnológico disponible.
- Spikes de arquitectura.
Cuadro sinóptico con el marco de Scrum - Cortesía de Scrum Manager |
Quiero resaltar que este post trata de una síntesis en forma de marco de lo que he observado en algunos de los clientes más tradicionales a los que he acompañado. Este "marco" no es un marco ágil ya que no está alineado con todos los valores y principios del Manifiesto Ágil.
Mis agradecimientos a Ramón y a Lorenzo que han trabajado a fondo parte de lo que expongo
¡Has juntado Scrum, PMO, Ágil, Proyecto, Release y Planificación en un sólo Post! ¡Sacrilegio! :)
ResponderEliminarJajajaja, absolutamente, ¡¡¡las sombras eclipsan la luz!!!
EliminarHay compañías alineadas con Agilidad en las que disfruto totalmente mi profesión, me dan fuerzas y considero que es un privilegio poder participar en su transformación ágil.
Luego hay otras a las que también he acompañado los últimos 3 años, son esas las que necesitan un marco como este, y funciona... tiene sus beneficios. Cada compañía es una realidad distinta y creo que las compañías que pueden ser ágiles en España ya lo son, las demás las podemos acercar, pero poco a poco y con mucho tiempo. A estas compañías las suelo "sobrecargar" con mis ideas incomprensibles, jajaja, creo en un mundo mejor y que los más necesitados también merecen ayuda :-P
Gracias José por dejarte caer por aquí una y otra vez. Un abrazo :-)