新しい機能を開発するチームが実装を開始すると、ライフサイクルは次のようになります。
- チームは、ソースのメインブランチに基づいて新しいブランチを作成し、行われた変更を分離します。 したがって、新しい作業は既存の作業と混合されず、他のチームによる変更から隔離されます。
- 新しい機能の開発が進行中であるため、開発者には2つの重要なマイルストーンがあります。 これらのポイントは、管理者が実行された作業を認識しているだけでなく、階層の上位の情報を転送できるようにするために、プロジェクト管理に必要です。 マイルストーン1は設計に関連しています。チームは特定の問題をどのように解決するかを示します。
- チェックポイント番号2は、機能の実装に関連しています。 ここで、チームは問題を解決するために実際に行われたことを示します。
- 宣言された機能の実行が終了するとすぐに、チームはメインブランチからのすべての変更を独自のブランチに統合します。
- メインブランチへの変更を「アップロード」する前に、チームは品質特性を満たし、話し合う必要があります。 このような特性は、「パフォーマンスを低下させることなく」、「コードの70％を自動テストでカバーする必要がある」などです。
- チームが確立された品質特性を達成したことを確認した後、メインブランチに変更を「アップロード」できます。 品質機能はコアコードを保護し、常に最高の状態にあることを保証します。
注：目標は、指定された機能を4〜6週間で完了することです（常に可能であるとは限りませんが、この期間をできるだけ正確に維持する必要があります）。
「完了」と言う前に満たす必要があった16の異なる品質要件を使用しました。 最も重要なものを以下にリストします：
品質要件の設定は、3,000人以上がベースコードの700を超える新しい関数で作業するときに使用する方法です。これには、* line ards（実際のサイズはわかりませんが、自分で想像できます）が含まれます。分散化された作業が必要な品質で実行されることを保証できます。
すべてのチームが独自のタスクを実行している間、ユニット全体が反復管理に従事していました。 覚えている限りでは、約14回の反復がありました。 次の図は、メインブランチから分離された新しい機能のブランチを示しています。メインブランチは後で統合されました。 反復と同様に、開発チームも重複しています。
ユニットレベルで統合レビューを実施し、すべてのチームが次のイテレーションで達成する計画と過去に実際に起こったことを上司に報告しました。
次の章：TFSを使用したプロセスの実装。