En uno de los artículos anteriores, escribimos sobre cómo toda la empresa cambió a un único rastreador basado en Azure DevOps (TFS). Esto nos permitió crear un conjunto unificado de reglas para la gestión de proyectos. Te contamos cómo nuestra oficina de proyectos desarrolló la lógica según la cual todos nuestros equipos están trabajando ahora.
Por sí solo, un solo rastreador no garantiza que todos los equipos funcionen de la misma manera. Para que esto suceda, la empresa debe tener una visión unificada de la gestión de proyectos, tanto en el nivel superior, donde los gerentes planifican el desarrollo del producto, como en el nivel inferior, donde los desarrolladores completan las tareas y entregan las versiones al cliente.
Esta visión unificada da continuidad a la experiencia. Todos los proyectos son similares entre sí, todos los equipos utilizan el mismo enfoque y hablan el mismo idioma. Con este fin, nuestra oficina de proyectos el año pasado se propuso crear una plantilla única que combinara nuestros términos comunes, procesos y configuraciones predeterminadas del proyecto.
El objetivo era asegurarse de que al final cada proyecto pudiera "leerse" en el rastreador y comprender claramente su estado. Además, esto puede ser realizado tanto por una persona (ajustar las métricas de un extremo a otro para todos los proyectos, comprender dónde está todo bien y dónde todo es peor), o una máquina (el servicio de formación de Notas de la versión "comprende" qué tareas estados y etiquetas para incluir en la lista de correo). Y, por supuesto, todos los proyectos recién lanzados deben crearse a la vez con las mismas reglas.
Ahora hemos logrado este objetivo. Cuando un gerente envía una solicitud a los administradores para comenzar un nuevo proyecto, no necesita explicar qué debería estar allí: qué configuraciones y tipos de tareas, a qué sistemas conectarse. Todo lo que necesita está en el proyecto desde el principio, puede iniciar sprints de inmediato, completar tareas, preparar un plan de desarrollo.
, . - , (, ..). , , .
, .
True Engineering
1. . , – .
- Epic. -, . , .
, . — « ».
– Feature, 1-3 ). Feature – -. , .
– PBI (Product Backlog Item, ), . , , – PBI. Task-, , 8 .
, , - – .
2. . PM – , , , , .
- , . , , .
, . , - .
, .
3. . :
, : , , , . .
Azure DevOps
. TFS. , , , , .
TFS Aggregator. Task- PBI. , .. Release Notes, , Release Notes.
OLAP-. , , Time-to-Market, . . , – , .
. , , .
. , , .
– -. , , TFS.
. , . , .
Otra tarea es organizar una retrospectiva de sprint. Según nuestra idea, el sistema debería poder interpretar e interpretar los resultados del sprint: qué se planificó al inicio del sprint, qué se recibió al final, cómo fue el trabajo en el proceso y si hubo dificultades, Entonces dónde. Luego, en retrospectiva, el equipo no participará en un análisis subjetivo de sus resultados, sino que los evaluará de acuerdo con datos objetivos.