Recientemente en nuestra empresa, la gerencia decidió implementar SAFe. Las cosas han cambiado bastante desde entonces, para bien o para mal.
Uno de los principales cambios que hemos notado como desarrolladores es la carga de realizar la recopilación de requisitos. Si bien no estamos en contra de hacer preguntas, aclarar elementos en los criterios de aceptación, pero se espera que reúna todos los requisitos para una función.
Cuando una característica se divide en varias historias de usuario y los desarrolladores seleccionan cada historia de usuario, los requisitos en ese punto son muy confusos y crean mucha confusión entre los desarrolladores. A un desarrollador se le ocurre una solución, otro con una solución diferente y así sucesivamente. Durante aproximadamente la mitad del sprint, nos obstinamos en tratar de descubrir cómo funciona realmente el proceso.
Contamos con Scrum Masters (anteriormente conocidos como Business Analysts). Con el nuevo cambio de título, los scrum masters dicen que ya no ayudan con la recopilación de requisitos. Anteriormente, los analistas comerciales solían identificar cómo funcionaba el proceso, crear diagramas de flujo cuando era necesario y los desarrolladores solían ayudarlos en el aspecto técnico para asegurarse de que todo funcionara bien.
¿Qué estamos haciendo mal aquí?
Su empresa no ha implementado SAFe; han implementado Buzzword Management™. En este caso, la interacción entre roles se ha aplicado incorrectamente. La responsabilidad central de la gestión de requisitos es una función de propiedad del producto, pero el equipo de desarrollo también tiene un papel de colaboración que desempeñar.
El rol del Scrum Master es ser el árbitro del proceso para el marco y asegurarse de que todos los demás en el equipo ágil puedan implementar sus roles de manera efectiva. Esto tampoco se está haciendo actualmente.
Si bien los equipos de desarrollo de SAFe se dedican principalmente a descomponer las características en historias de usuarios u otros tipos de elementos pendientes procesables, la responsabilidad central de la recopilación de requisitos se divide entre las funciones de gestión de productos y gestión de soluciones .
Product Management tiene la autoridad de contenido para el Program Backlog. Son responsables de identificar las necesidades del Cliente, priorizar las Funciones, guiar el trabajo a través del Programa Kanban y desarrollar la Visión y la Hoja de ruta del programa.
Solution Management tiene autoridad de contenido para Solution Backlog. Trabajan con los clientes para comprender sus necesidades, priorizar las capacidades, crear la visión y la hoja de ruta de la solución, definir los requisitos y guiar el trabajo a través de la solución Kanban.
También hay un modelo de requisitos SAFe , que dice que "los equipos ágiles emplean principalmente historias de usuarios, pruebas de aceptación de historias y NFR [requisitos no funcionales]", lo que pone la mayor parte de la responsabilidad de la propiedad del producto y la gestión de requisitos en manos de Gestión de productos y Gestión de Soluciones.
Además, tenga en cuenta los distintos niveles de funciones de gestión de productos dentro de SAFe:
SAFe ofrece una cadena de autoridad de contenido que abarca tres niveles:
- Equipo : los propietarios de productos toman decisiones rápidas sobre el contenido local en nombre del equipo ágil.
- Programa : la gestión de productos es responsable de las decisiones de contenido para Agile Release Trains (ART)
- Solución grande : Solution Management tiene autoridad de contenido para Solution Trains
Eso significa que el propietario del producto de cada equipo ágil es responsable de administrar la parte de la cartera de productos general de ese equipo. Esto incluye recopilar los requisitos de las partes interesadas/clientes y priorizar los elementos pendientes.
Habiendo dicho todo lo anterior, eso no significa que los desarrolladores del equipo Agile no estén involucrados en la comprensión o recopilación de requisitos. Las historias de usuarios y los elementos de la cartera de productos no son especificaciones. Son marcadores de posición para la colaboración con otros elementos de Agile Release Train.
El propietario del producto puede ser el principal punto de contacto, pero el equipo en su conjunto debe participar activamente con las partes interesadas que se mencionan como consumidores de valor en una historia de usuario. Si el Product Owner no está facilitando esto, o está colocando la responsabilidad únicamente en el equipo, eso es una falla de rol. Del mismo modo, si el equipo está sentado y esperando especificaciones completas del propietario del producto, el equipo ágil tampoco está cumpliendo con su función adecuada.
Los marcos ágiles, especialmente Scrum (en el que se basan varias prácticas de SAFe), requieren una colaboración activa entre roles. Si los roles están en conflicto, o si los individuos buscan "lanzar el trabajo por la borda" a otra persona, entonces el marco no se ha adoptado por completo o no se ha aplicado correctamente.
El requisito funcional debe ser proporcionado por el Product Owner o Product Manager. Los desarrolladores solo son responsables de diseñar la funcionalidad técnicamente en colaboración con el PO/PM en la perspectiva funcional y de usabilidad.
Asumiré que no tiene propietarios de productos (PO).
Pasar de Business Analyst (BA) a Scrum Master (SM) es un cambio un poco extraño. El trabajo de BA es mucho más similar al trabajo de PO que al trabajo de SM.
Existe cierto debate sobre si es o no una buena idea tener un SM dedicado o un desarrollador/SM. Sin embargo, para mí, tiene mucho más sentido elegir a algunos desarrolladores, enseñarles Scrum y convertirlos en SM que elegir a algunos desarrolladores e intentar convertirlos en PO.
Si los antiguos BA quieren permanecer como SM, entonces deberá contratar algunos PO (o capacitar a algunos desarrolladores para que cambien a PO y luego contratar nuevos desarrolladores). Si la empresa simplemente no quiere que los desarrolladores sean SM, entonces deben contratar algunos PO dedicados (o cambiar los SM para que sean PO y contratar SM dedicados).
¿Qué estamos haciendo mal aquí?
Un montón.
Por lo general, en SAFe, sus equipos de desarrollo ejecutan alguna combinación de Scrum, XP y Kanban. Sin embargo, no hay requisitos reales en cuanto a la metodología específica. Sin embargo, la idea de iteraciones e incrementos alimenta el enfoque general de SAFe.
Los requisitos tienden a fluir hacia abajo: los temas estratégicos provienen de la estrategia de la empresa; Solution Management está trabajando a nivel de programa grande en capacidades y habilitadores; La gestión de productos está trabajando en aumentar los objetivos, las características y los habilitadores; Los Product Owners están trabajando en Historias y Habilitadores. Por supuesto, estas personas no están trabajando en los requisitos de forma aislada, sino con algo de soporte técnico. Los arquitectos de soluciones admiten la gestión de soluciones, los arquitectos de sistemas admiten la gestión de productos y el equipo de desarrollo apoya a los propietarios de productos.
No todo tiene que fluir explícitamente hacia abajo desde la parte superior. Algunas cosas pueden ser trabajo técnico que se hace evidente en un nivel, pero que es demasiado complicado para el nivel superior. Pero este trabajo descompuesto y habilitador se puede detectar a medida que el trabajo por hacer se desarrolla en todos los niveles.
Para mí, parece que los Gerentes de Producto y los Propietarios de Producto no están desarrollando Incrementos de Programa , Habilitadores , Funciones e Historias sólidos . Debe haber actividades de perfeccionamiento en cada nivel que aborden estos requisitos vagos y poco claros y para garantizar que haya suficiente información para que todos estén en sintonía.
El hecho de que Business Analysts se convirtieran en Scrum Masters también es un poco preocupante. En mi experiencia, los BA (que pueden tener otros nombres en diferentes organizaciones) suelen apoyar a una organización de gestión de productos y no a una organización de desarrollo. En un equipo, el rol de Scrum Master es, de alguna manera, directamente opuesto al Dueño del producto: el Dueño del producto busca optimizar el valor entregado por el Equipo de desarrollo, mientras que el Scrum Master ayuda al equipo a optimizar su propio desempeño. A veces, optimizar el equipo significa ralentizar la entrega de un producto.
elixir