¿Qué es Azure Boards?
Azure Boards es una herramienta de Azure DevOps para ayudar a los equipos a planear el trabajo que necesitan hacer. El equipo de Tailspin usará esta herramienta para hacerse una mejor idea del trabajo que necesitan hacer y cómo clasificarlo por orden de prioridad.
Mara creó su propio proyecto en Azure Boards mediante el proceso Basic. Muestra los problemas en el proceso de compilación que identificó junto con Andy. Mara reúne al equipo para hacer una demostración rápida.
Mara: —Hola todos. He configurado Azure Boards y quería mostraros algunos elementos de trabajo que he creado.
Andy: —¿Qué es un elemento de trabajo?
Mara: —Los elementos de trabajo nos ayudan a planear y administrar un proyecto. Un elemento de trabajo puede realizar un seguimiento de todo tipo de actividades. Puede ser una tarea que hay que realizar, un error que hay que corregir o cualquier otro problema. Podemos asignarlos a la gente y realizar un seguimiento de su progreso.
Quizás sea más fácil haceros una demostración. Esto es Azure Boards con el proceso Basic:
Amita: —Háblanos del proceso Basic. ¿Hay otras opciones?
Mara: Hay cuatro procesos entre los que elegir. Podemos usar:
- Integración de modelo de madurez y de capacidad (CMMI): Realmente, este es para organizaciones grandes y es bastante complicado, así que yo no lo usé.
- Scrum: Scrum depende de un facilitador o Scrum Master que dirige el equipo Scrum. El facilitador se asegura de que todo el mundo entiende la teoría, las prácticas y las reglas de Scrum. No tenemos facilitador (Scrum Master), que es alguien que, normalmente, ha recibido formación y certificación, así que tampoco he escogido ese proceso.
- Agile: Esta parecía ser la elección obvia, puesto que siempre estoy hablando de Agile, pero hay que tener en cuenta algunas otras cosas más que la opción más sencilla.
- Básico: Basic es, bueno, básico. Es sencillo, pero nos ofrece el potencial suficiente como para empezar a planear inmediatamente de forma efectiva, por eso lo he seleccionado. En el flujo de trabajo de este proceso, se mueve el trabajo de To Do (Tareas pendientes) a Doing(En curso) y a Done (Listo).
Amita: —Vale, usémoslo para empezar a trabajar. Lo podemos cambiar a otra cosa, ¿verdad?
Mara: —¡Perfecto! Bien, vamos a seleccionar algunos elementos de trabajo que creemos que podemos corregir en un par de semanas.
Andy identifica estos problemas, pero el resto del equipo tiene dudas.
Tim: —Casi todos son problemas de desarrollo. Pero mientras estamos con eso, otros equipos están hablando de vulnerabilidades de código, y se me ha pedido que demuestre que el código es seguro. ¿Hay alguna forma de agregarlos?
Mara: —Sé que la lista no está completa. Los problemas del panel son de los que Andy y yo hablábamos antes. E incluso algunos de estos problemas realmente habría que desglosarlos en tareas más pequeñas. Entiendo tus preocupaciones sobre vulnerabilidades de código. Andy, ¿qué opinas?
Andy: —En estos momentos, conseguir terminar una compilación es difícil. Empecemos con algunos de los problemas básicos. Me gusta tener una ubicación central desde donde podemos realizar un seguimiento de los problemas. Podemos agregar problemas al trabajo pendiente y asignarles una prioridad cuando estamos listos.
Mara: —Antes de incorporar ningún problema, vamos a hablar un poco más sobre el trabajo que está haciendo cada uno.
Cada miembro del equipo comparte en qué está trabajando y los problemas que tengan. Como una actividad de lluvia de ideas, agregan notas rápidas a una pizarra. La pizarra se llena rápidamente.
Al final, el equipo llega a un acuerdo sobre los siete problemas principales. Andy se ofrece para agregar las tareas a Azure Boards mientras los demás observan. El panel tiene un aspecto similar a este:
Amita: —Vaya, son un montón de problemas. ¿Cómo vamos a corregir todo eso?
Mara: —No tenemos que corregirlos todos inmediatamente. Por ahora, hemos identificado un trabajo pendiente o una lista de trabajo de la que escoger. Cuando planeemos el trabajo, podremos elegir lo que es más importante o urgente.
Después de hablar un poco más, el equipo decide hacerse cargo de los tres problemas que Mara había propuesto originariamente:
- Estabilizar el servidor de compilación
- Crear un flujo de trabajo basado en Git
- Crear pruebas unitarias
Mara: —Estos parecen los problemas más fáciles de afrontar y abordan algunos de los desafíos recientes que han surgido. Vamos a configurar un proyecto, un equipo y un sprint. Luego podemos decidir quién hace qué.
Tim: —¿Qué es un sprint?
Mara: —Buena pregunta. Un sprint es la cantidad de tiempo que tenemos para completar las tareas. Los sprints nos ayudan a mantenernos centrados. Al final, podemos tener una reunión breve retrospectiva para compartir lo que ya hemos hecho. Después, podemos planear lo siguiente.
Todo el mundo parece nervioso.
Mara: —Todavía estamos aprendiendo. Un sprint suele tener una duración de dos a cuatro semanas. Supongamos simplemente dos semanas y veamos cómo va. Estas son principalmente tareas de las que nos podemos encargar Andy y yo. Compartiremos nuestro progreso según vayamos avanzando. Luego encontraremos a forma de incluir a todo el mundo.
Mara y el equipo empiezan con buen pie. Después, se configurará el proyecto, el equipo y algunas tareas en Azure Boards.