以前の記事の1つで、会社全体がAzure DevOps（TFS）に基づく単一のトラッカーにどのように切り替えたかについて書きました。これにより、プロジェクト管理のための統一されたルールセットを作成することができました。プロジェクトオフィスが、現在すべてのチームが取り組んでいるロジックをどのように開発したかを説明します。
単一のトラッカー自体は、すべてのチームが同じように機能することを保証するものではありません。これを実現するには、会社はプロジェクト管理の統一されたビューを持っている必要があります-マネージャーが製品開発を計画するトップレベルと、開発者がタスクを完了して顧客にリリースを提供する下位レベルの両方で。
そのような統一された見方は、経験の継続性を与えます。すべてのプロジェクトは互いに類似しており、すべてのチームが同じアプローチを使用し、同じ言語を話します。この目的のために、私たちのプロジェクトオフィスは昨年、私たちの共通の用語、プロセス、およびデフォルトのプロジェクト設定を組み合わせた単一のテンプレートの作成に着手しました。
目標は、最終的に各プロジェクトがトラッカーで「読み取られ」、その状態を明確に理解できるようにすることでした。さらに、これは、人（すべてのプロジェクトのエンドツーエンドのメトリックを調整し、すべてが良い場所と悪い場所を理解する）、またはマシン（リリースノート形成サービスがどのタスクを使用するかを「理解」する）の両方で実行できます。メーリングリストに含めるステータスとタグ）。そしてもちろん、新しく立ち上げられたすべてのプロジェクトは、同じルールで一度に作成する必要があります。
私たちは今、この目標を達成しました。マネージャーが新しいプロジェクトを開始するように管理者に要求を送信するとき、マネージャーはそこに何があるべきか、どの設定とタスクのタイプ、どのシステムに接続するかを説明する必要はありません。必要なものはすべて最初からプロジェクトにあり、すぐにスプリントを開始し、タスクを実行し、開発計画を準備することができます。
, . - , (, ..). , , .
, .
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.
. , . , .
もう1つのタスクは、スプリントの回顧展を開催することです。私たちの考えによれば、システムはスプリントの結果を解釈および解釈できる必要があります：スプリントの最初に計画されたもの、最後に受け取られたもの、作業がどのように進行したか、そして問題があった場合は、さて、どこ。その後、振り返ってみると、チームは結果の主観的な分析に従事するのではなく、客観的なデータに従ってそれらを評価します。