Para la entrega anterior, vaya aquí: ¿Qué es la práctica ágil en su proyecto? (Parte 1)
Debo decir que disfruté muchísimo trabajando en ese proyecto, ¡aunque el proyecto era una pesadilla todos los días! (Por favor no
Empresa B – Proyecto B
La necesidad de negocio del Proyecto B en la Empresa B es implementar un nuevo sistema para
Dominio empresarial y la complejidad
Financiero – Banca de Empresas. Diría que el dominio comercial es bastante complejo.
Tamaño del equipo
El equipo estaba formado por un gerente de proyecto, un gerente de iteración, un arquitecto de soluciones, analistas de negocios (yo era uno de esos dos BA), un especialista en UX/UI, un equipo de desarrollo y un equipo de pruebas. El equipo de desarrollo y pruebas se apresuró tanto en el sitio como en el extranjero (fuera de Australia). En total, había entre 35 y 40 miembros del equipo en el proyecto, tanto en el sitio como en alta mar.
Práctica ágil
Comencemos con las actividades de preparación del sprint. Como había múltiples partes interesadas comerciales involucradas en el proyecto, la situación era intensa la mayor parte del tiempo, ya que cada parte interesada comercial intentaba poner sobre la mesa sus requisitos. Sin embargo, siempre era el Product Owner y su Boss quienes decidían la prioridad de la canalización de requisitos. Nosotros, los BA, no nos involucramos en esas discusiones y estábamos muy contentos con eso, siempre que se nos informara a tiempo sobre la lista acordada de prioridades comerciales en trámite. La lista priorizada y acordada de iniciativas comerciales siempre estaba en la pared para que todos pudieran ver lo que venía después. Tener la tubería de requisitos visible para todos fue muy importante, especialmente para los BA, ya que pudimos trabajar en múltiples iniciativas en paralelo.
Luego, los especialistas en BA y UI comenzaron a trabajar en la iniciativa comercial y como parte de la elaboración de requisitos; llevamos a cabo el primer conjunto de sesiones de elicitación de requisitos con las partes interesadas comerciales relevantes y el propietario del producto para recopilar suficientes detalles para realizar la estimación de la historia con el equipo.
Nota: Aunque el negocio ha decidido sus prioridades, las estimaciones de esfuerzo siempre deciden si el trabajo se implementará o no. Entonces, antes de comenzar cualquier otra cosa sobre la iniciativa, se tomaron puntos de la historia de alto nivel de la iniciativa de los líderes del equipo de desarrollo y prueba.
Junto con la estimación de la historia, se llevó a cabo un mapeo de la historia que explicaría el escenario de extremo a extremo con la ayuda de las maquetas de la interfaz de usuario proporcionadas por el especialista en interfaz de usuario. El resultado de estas sesiones fue la lista de historias de usuarios y la estimación de alto nivel para esas historias. (Los puntos de la historia estaban en 1, 2, 3, 5, 8, 13, 21 puntos, etc.). Tenga en cuenta que esas sesiones de mapeo y estimación de historias de usuario no fueron sencillas en la mayor parte del tiempo, ya que se descubrieron muchos requisitos ocultos y mal considerados durante esas sesiones, lo que provocó que se revisaran los requisitos de un lado a otro con la empresa. Sin embargo, digamos que obtuvimos la lista de historias y los puntos totales de la historia. Luego se lo presentamos a la empresa. Y allí esperamos y enviamos “recordatorios amables” varias veces a las empresas para obtener su decisión de Go/No Go según el conjunto de requisitos de MVP.
El escenario más posible fue que Business dijo que estaba por encima del presupuesto -> BA’s, UX Specialist y el equipo revisaron nuevamente la lista de historias e intentaron llegar a la ‘versión mínima’ de los requisitos de MVP con soluciones alternativas y puntos de historia -> Lo mismo fue presentado a la Empresa -> Esperó su respuesta.
Digamos de nuevo que recibimos la respuesta de ellos…
¿Han pedido proceder con esto? NO -> Aceptar. Simplemente olvídese de eso y pase a la siguiente prioridad comercial y comience el mismo conjunto de actividades nuevamente para la nueva iniciativa.
¿Han pedido proceder con esto? Sí -> Uf….
Luego, los BA comenzaron a elaborar más requisitos y comenzaron a escribir historias. Lo bueno de ese enfoque era que los BA siempre trabajarían solo en las piezas de trabajo priorizadas y no perderían tiempo en la documentación de requisitos y la preparación de ningún trabajo dado que tuviera el potencial de ser despriorizado. (Gracias a los Line Managers de BA que siempre insistieron en que siguiéramos ese enfoque)
Una vez que se completaron las historias de los usuarios, las mismas fueron revisadas por pares y luego las sesiones Story Refinement / Story Time fueron realizadas por
Comenzando desde el mapeo de historias de usuario y las sesiones de estimación hasta obtener la aprobación comercial para el proceso de historias de usuario.
Durante la sesión de planificación del sprint, el propietario del producto priorizó las historias de usuario Ready para el próximo sprint. Cada sprint tenía una Capacidad de Sprint. Entonces, al final de la sesión de planificación del sprint, todos sabían lo que se entregaría al final del sprint.
Aquí empezó el nuevo sprint….
Los stand-ups diarios se llevaron a cabo como de costumbre. Y cuando hubo historias listas para UAT, se llevó a cabo el proceso de UAT. Se suponía que los defectos de UAT se arreglarían dentro del sprint y se considerarían mejoras/sugerencias de UAT para los sprints futuros. Una vez que la UAT se completó sin defectos en esas funciones, la historia de usuario relevante se considera “Terminada”. es decir, hemos terminado con la historia de usuario y no hay más trabajo por hacer en función del requisito original.
Al final del sprint, se llevaría a cabo Sprint Showcase, donde todas las partes comerciales relevantes y todo el equipo tienen la oportunidad de ver nuevas funciones y brindar sus comentarios.
Y luego la Retrospectiva del Sprint -> Nosotros, como equipo, no esperamos hasta la reunión de la Retrospectiva del Sprint para dar nuestra opinión sobre lo que salió bien, lo que salió mal y las mejoras que sugerimos. Tenemos una bandeja de entrada retrospectiva… una caja física guardada el área del proyecto. Cada vez que queramos gritar sobre el infierno por el que estábamos pasando o las cosas iban muy bien, podíamos escribir eso en pequeños pedazos de papel y ponerlos en la caja. De lo contrario, ¿quién recordaría todas esas cosas hasta la reunión de Retro?
Eso es más o menos sobre la práctica ágil que se siguió en ese proyecto. Mi sensación personal es que la práctica ágil se había personalizado bien en función de la naturaleza del proyecto, excepto que BA y el administrador de iteración tuvieron que luchar mucho para evitar los cambios de requisitos solicitados por la empresa justo antes del inicio del sprint. La empresa ha malinterpretado el significado de la palabra “ÁGIL” y pensó que los cambios en los requisitos SIEMPRE (siempre significa en cualquier momento antes de que el requisito entre en producción) se aceptan en los proyectos Ágiles. Excepto por ese desafío, creo que los principios ágiles se han personalizado y practicado bien en ese proyecto.
Espero que los dos ejemplos anteriores le den una idea de cuán diferentes los proyectos usan principios ágiles basados en la naturaleza del proyecto. Y creo que esto le daría algunos consejos si también desea ajustar la práctica ágil existente en su proyecto. Entonces, los BA que no han trabajado antes en proyectos ágiles, ahora saben cómo son los proyectos ágiles del mundo real….
Además, me gustaría saber de usted cuán diferente su proyecto también usa principios ágiles.
Autor: Dhanu Gunathissa, CBAP
