アジャイルキャパシティ計算 — パート2/2

最初の部分 この2部構成のブログでは、アジャイルキャパシティの計算方法を2つ紹介しました。

• 方法1： 容量を推定したり計算したりする必要はありません。これは理想的かつ最もシンプルな方法です。
• 方法2： 容量は、少数のパラメータを使用して、大まかに（時間数で）見積もられます。

2 部構成のブログ投稿の後半では、アジャイル キャパシティ計算の 3 番目で最後の方法を紹介します。

• 方法3： 容量は、非常に包括的で拡張可能かつカスタマイズ可能な一連のパラメータを使用して、正確に計算されます (時間数単位)。

各チーム メンバーの実際の実務能力は、次のようないくつかのパラメータを考慮して計算されます。

• スプリントで利用可能な週数と就業日数：例えば、4週間のスプリントの場合、就業日は20日です（週5日就業し、会社の休日による休業日がないと仮定）。スプリントが第1週の月曜日より遅く開始され、第4週の金曜日より早く終了する場合、スプリントの就業日は20日未満になります。例えば、スプリントが第1週の火曜日に開始され（月曜日は大雪で会社が休業だった場合など）、第4週の木曜日に終了する場合（金曜日はスプリントレビューと振り返りのために確保されていた場合など）、スプリントの就業日は実質的に18日になります。
• スプリント タイムボックス中に予定されている会社の休日の数: スプリント タイムボックス中に会社の休日が 2 つある場合、そのスプリントの就業日数は 2 日減少し、個人およびチームのキャパシティも減少します。
• 各チーム メンバーの個人休暇または有給休暇: たとえば、チーム メンバーが今後のスプリント タイムボックスで 3 日間の休暇を取る予定の場合、そのメンバーのキャパシティは 3 営業日分減少します (チームのキャパシティもその分減少します)。
• チームのフルタイム メンバーシップとパートタイム メンバーシップ: チーム メンバーがチームのフルタイム メンバーではなく、プロジェクトに 50% の時間のみ作業する予定の場合、そのメンバーの能力は 50% 減少します。
• 毎日のスクラムミーティングの準備と参加に必要な時間。
• 一般的な電子メールや電話のやり取り、および会社やプロジェクト以外の会議への出席に必要な時間。
• 不測の事態に備えて確保しておいた時間。
• チーム メンバーの能力を低下させる要因 (例:
  • 以前のソフトウェアリリースのサポート作業
  • 現在のスプリントが進行中に次のスプリントのバックログを準備する（いわゆる2レベルスクラムパイプライン）
  • チームの新メンバーのトレーニング
  • 多機能スキルを高めるための自己トレーニング

これはキャパシティ計算において考慮すべき要素を網羅的に列挙しているように見えますが、必ずしも網羅的なものではありません。組織のニーズに合わせて、追加、削除、修正、カスタマイズが必要になる場合があります。方法3は計算量が多すぎると思われるかもしれませんが、この計算はExcelベースのテンプレートを使用して行われるため、ほぼ瞬時にキャパシティ数値が得られます。

もしあなたのチームが、安定した速度を実証した、よくまとまったアジャイルチームであり、方法1で要求されるすべての前提が整っている場合は、方法1を次のように使用すべきである。 第1部 このブログの目的です。安定した速度を持ち、まとまりのあるチームは非常に望ましい目標です。方法1が実際に使える場合は、キャパシティを計算する必要はありません。しかし、方法1が使えない場合は、方法2または3を使用する必要があります。

方法 2 よりも方法 3 を使用することを強くお勧めします。方法 2 ではキャパシティが迅速に見積もられますが、一般的な 1 日 8 時間または 1 週間 40 時間の実作業に関する履歴データが利用できる場合にのみ、キャパシティのおおよその見積りが提供されます。

方法3は、個々のチームメンバーとチーム全体のキャパシティを正確に計算し、非常に迅速に実行できます。 仮に 演習を実施し、キャパシティ計算の透明性をチームメンバーと経営陣全員に提供します。多くのチームメンバーが予想よりも低いキャパシティ数値に驚くのを見てきましたが、この方法により、キャパシティ数値が低い理由と、現実的な方法でキャパシティを増やす方法を理解することができます。キャパシティ計算の透明性により、経営陣とチームメンバーの間で、キャパシティとワークロードのバランスをどのように取るかについて率直な話し合いが可能になります。

以下は、私がトレーニングおよび指導したチームが行ったアジャイル キャパシティ プランニングで観察した会話の例 2 つです。

• アジャイル チーム A は、キャパシティを計算し、それがプロダクト オーナーが次のスプリントでチームに提供してほしい作業負荷 (機能と欠陥の優先順位リスト) より 30% 少ないことを発見しました。チームは、チームに新しいメンバーを追加することは、次のスプリントのチーム キャパシティを上げるための現実的な選択肢ではないことを認識しています。チーム メンバーは (スクラム マスターの促進のもと)、いくつかの手順 (スプリントに対するパートタイムのチーム メンバー 2 人の時間割り当てを増やす、他のチーム メンバー 2 人の予定休暇日数を減らすなど) を実行することで、チーム キャパシティを 10% 増やす方法について話し合いました。チーム メンバーとプロダクト オーナーは、最も優先度の低い 2 つの機能と 1 つの欠陥をスプリントの範囲から外し、機能の 1 つの範囲を縮小することで、作業負荷を約 15% 削減する方法について話し合いました。これで、チーム キャパシティは計画された作業負荷より 5% 低いだけになり、チームはこの状況に満足し、スプリントを続行することを決めました。
• キャパシティとワークロードがほぼ均衡した後（互いに5％以内に収まった後）、アジャイルチームBは、個々のチームメンバーのキャパシティと個々のワークロードを次のように評価します。 Digital.ai Agility、旧称 VersionOne。シェリル（ユーザーインターフェイス開発者）は過負荷になっていることが判明していますが、ティム（Java 開発者）は余裕があります。シェリルとティムは、シェリルの作業負荷の一部（単純な UI 開発）を、シェリルの指導のもとでティムが完了する方法を話し合いました。二人とも、ティムは UI 開発が彼の主な専門分野ではないため、UI 開発作業ではシェリルほど生産的になれないだろうと認識しています。部門横断型アジャイルチームの精神にのっとり、ティムはシェリルの指導のもとで協力することを申し出ました。この負荷分散により、シェリルの作業負荷はある程度軽減されますが、それでも過負荷になっています。他の選択肢は実現できません。チームはプロダクトオーナーと話し合い、UI 集約型の機能 2 つをスプリントの範囲から外し、現在リリース バックログにある UI 集約型でない機能をスプリントの範囲に組み込んで、シェリルと他のチーム メンバーの間で適切な負荷分散を行うことに同意しました。

結論として、アジャイル チームがしっかりと連携し、方法 1 に必要なすべての前提条件が満たされている場合は方法 1 を使用し、そうでない場合は方法 3 を使用します。キャパシティ プランニングの取り組みによって、チーム メンバーとプロダクト所有者の間で会話が促進され、スプリント計画プロセスが完了します。

パート1 – アジャイルキャパシティ計算