Prioriza tu Backlog
Con ALM Octane
ALM Octane es una herramienta para el control del ciclo de vida de software certificada por SAFe, que cumple los estándares de las metodologías ágiles. ALM Octane, puede configurarse de tres modos, dependiendo de la metodología de trabajo que se esté utilizando: Metodología Agile, Waterfall o Híbrida. En este post, y en los siguientes, hablaremos de cómo ALM Octane puede ayudarnos si trabajamos con una metodología Agile en nuestros proyectos.
Como ya vimos en nuestro AfterWork del pasado 7 de marzo en el que estuvimos hablando de cómo NO Deberíamos gestionar nuestros proyectos para obtener Calidad, (si te lo perdiste, puedes seguirnos en Linkedin para estar al día) la especificación de un alcance claro y comprensible por todos los miembros del equipo es una parte muy importante del camino para que nuestro proyecto cumpla con unos mínimos de calidad.
Nuestro objetivo de hoy es conocer cómo se trabaja con el Backlog y cómo nos puede ayudar ALM Octane a gestionar nuestro día a día.
Trabajando con Backlogs
Actores que intervienen
Por norma general en nuestros proyectos intervienen diferentes actores con diferentes funciones e intereses.
- Por un lado, podríamos tener a nuestro Business Analyst (BA) o nuestro Product Owner (PO), el cual se encargaría de proveer al equipo las diferentes funcionalidades necesarias para llevar a cabo dentro de nuestro Sprint, normalmente, en las compañías o proyectos, este role suele ser una persona no técnica, cercana al área de negocio de la compañía.
- A su vez, el equipo de desarrollo también participa en el objetivo común, proveer una solución para las funcionalidades indicadas por el Product Owner, estos perfiles suelen ser muy técnicos.
- Y, por último, pero no menos importante, tenemos al QA, Agile QA, o facilitador de QA, que serán los encargados de verificar y comprobar que lo entregado por el equipo de desarrollo cumple con las necesidades planteadas por el Product Owner.
Comenzando desde los cimientos
Nuestra historia siempre comienza con una necesidad identificada por el Product Owner.
En el mejor de los casos, nuestra organización, dispondrá de una herramienta que nos sirva de repositorio de las diferentes necesidades identificadas, de las cuales, el Product Owner, es el responsable de trasladarlas de la forma más clara y concisa que le sea posible, con el fin de que puedan ser entendidas y solventadas por el equipo técnico. En el peor de los casos, nuestros Product Owners utilizarán documentos Word o Excel para plasmar estas necesidades y quedarán almacenas en una herramienta que sirva de repositorio de documentación como puede ser Sharepoint o Box, quedando sin trazabilidad desde que es priorizado hasta su puesta a producción en un mismo sitio.
Para poder tener una trazabilidad y un seguimiento continuo de nuestros requerimientos podemos utilizar la herramienta ALM Octane, la cual nos facilita y agiliza el trámite quedando todo trazado de principio a fin, incluidas las pruebas llevadas a cabo y su resultado, así como los posibles defectos identificados durante la ejecución de pruebas o ya una vez liberado el software en producción. ALM Octane es una solución integradora ideal para resolver los gaps entre herramientas, que solemos encontrar habitualmente dentro de nuestra organización.
Backlog en ALM Octane
En ALM Octane podemos aplicar diferentes filtros a nuestro Backlog según nuestras necesidades. Aplicando un filtro u otro, podemos ver nuestro Backlog priorizado por releases o Sprints.
En el Backlog, el Product Owner va registrando las diferentes necesidades identificadas o requeridas, pudiendo o no, otorgarles una prioridad para que posteriormente pueda ser más fácil priorizarlas en nuestras reuniones antes de comenzar el Sprint. De esta manera ALM Octane se convierte en nuestro repositorio de funcionalidades, el cual albergará toda la historia de nuestro producto, sirviéndonos como parte de la documentación del producto construido, así como permitiéndonos conocer cómo ha sido cubierta la necesidad detectada.
Como podemos ver en la imagen, ALM Octane, nos facilita la visión y evolución de nuestro proyecto, y gracias a los filtros podremos ver que funcionalidades están pendientes de ser priorizadas, y cuáles ya fueron priorizadas en una determinada release/Sprint, ayudando en esta misión a los Product Owners y a los actores que intervienen en la priorización.
En el Backlog, podremos ver también en detalle las distintas entidades: los Epics, Features, User Stories y defectos, así como la cobertura de test a la que son sometidos los ítems. Esto, podemos hacerlo a través de la estructura lateral de la herramienta.
Desde esta estructura de árbol, se pueden crear fácilmente relaciones y ordenarlas dentro del Backlog. En particular, desde el Backlog se tiene la capacidad de crear la trazabilidad entre los elementos del Backlog, independientemente de dónde se encuentren en el árbol de directorios.
Como Product Manager, se podrán crear las User Stories, asignarlas a una release o Sprint, y asignar los Storie Points a las User Stories (incluidas Epics / Features). Estos Storie Points se administran como tareas y se miden por horas para reflejar el esfuerzo actual del desarrollador realizado. El Product Manager puede agregar tareas a medida que crea sus User Stories, para agilizar el proceso de planificación de la release. Las tareas pueden ser creadas en cualquier momento por alguien a quien se le ha asignado la User Storie o el trabajo utilizando las capacidades de planificación completas de ALM Octane.
Se puede seleccionar una entidad, para ver todo lo que se planea en el contexto de ese elemento. A medida que se selecciona una Feature, se podrán ver las User Stories /defectos/Test relacionados con la funcionalidad específica. Las diferentes pestañas permiten una fácil navegación, y cada entidad tiene su propia visión general o métricas para informar en el contexto del trabajo planificado.
¿Cómo nos ayuda todo esto?
A medida que nuestro Sprint Backlog dentro de una determina release va avanzando, los diferentes gráficos dentro del módulo Backlog, nos ayudará a comprender la cantidad de trabajo planificado, o no y la capacidad específica del equipo para cada Sprint. Esta visibilidad permite optimizar la planificación del Sprint, actualizando la información en tiempo real permitiendo, de esta manera, tomar decisiones rápidamente en caso de ser necesario.
