最初のイテレーションを完了する前にスクラムチームの初期ベロシティを見積もるための簡単なガイドラインがいくつかあります（下記のFAQを参照）。しかし、それ以降は、機能の計画には実績のある指標を用いるべきです。ベロシティは通常、短期間で安定し、アジャイルプロジェクトの短期および長期計画の精度と信頼性を向上させるための大きな基盤となります。 アジャイルデリバリー サイクルは非常に小さいため、速度がすぐに現れ、プロジェクトの非常に早い段階で検証することができ、その後、プロジェクトの予測可能性を向上させるために頼ることができます。
速度は本当にそんなに単純なのでしょうか?
はい、そうです速度を複雑にしすぎないようにしましょう。速度は実に分かりやすい概念であり、その価値の多くはその本質的なシンプルさにあります。多くのマネージャーやチームは、 アジャイルメソッド 速度の概念を過度に分析し、複雑に捉えすぎる傾向があります。アジャイルプロジェクトを数ヶ月経験すると、ほとんどの人が速度について「なるほど！」という瞬間を経験し、速度にまつわるあらゆる固定観念を捨て去り、そのシンプルさと本質的な価値を理解するようになります。
速度チャート
リリースおよびイテレーションのバーンダウンチャートに加え、アジャイルチームのベロシティ測定は、プロジェクトの進捗状況とステータスに関する優れた洞察と可視性を提供することが実証されています。ベロシティチャートは、すべてのイテレーションで達成された作業量の見積りの合計を示します。通常、プロジェクトチームの構成が大きく変化したり、イテレーションの長さが変更されたりしない限り、ベロシティはプロジェクトの存続期間を通じて安定します。そのため、ベロシティは将来の計画にも活用できます。ベロシティは通常、数イテレーション先までは信頼できるものですが、優先順位、目標、チームが時間の経過とともに変化し、その結果、遠い将来のイテレーションの信頼度が変化する可能性があることを前提とすれば、ベロシティははるかに先のリリース計画にも活用できます。
アジャイルソフトウェア開発に初めて取り組むチームは、まずは利用可能なガイドラインと情報を参考に、初期ベロシティを設定することから始めましょう。ベロシティは、非常に迅速に（次のイテレーションと同じ速さで）測定・調整できます。ベロシティに加え、粒度の高いデータ（ユーザーストーリー、バックログ、要件など）や、大まかな見積もりや相対的な見積もり（ポイント、理想的な日数、さらには時間単位）を組み合わせることで、プロジェクトの計画、見積もり、ステータス追跡、そしてレポート作成のプロセス全体が大幅に簡素化・加速されます。
アジャイルスクラムに関するよくある質問
速度は アジャイル開発 チームは計算しましたか?
速度は、反復ごとに配信された（つまり、受け入れられた）機能の見積りの合計です。
速度を測定するのに使用される単位は何ですか?
速度は、ストーリー ポイント、日数、理想的な日数、スクラム チームが提供する時間など、機能の見積もりと同じ単位で測定されます。これらはすべて許容範囲内とみなされます。
最初の反復の速度はどのように推定されますか?
アジャイル チームの最初のイテレーションでは、一般的なガイドラインとして、初期ベロシティを利用可能な時間の 3 分の 1 で計画します。理想的なプログラマ時間を見積もる場合、これには会議、メール、設計、ドキュメント作成、やり直し、コラボレーション、調査などが含まれます。たとえば、プログラマが 6 人でイテレーションが 2 週間の場合、合計 60 プログラマ日 (プログラマ 6 人 x10 日) を使用できます。この状況では、イテレーションで 20 理想的な日数分の作業を計画するのが良いスタートです。実際の時間を使用する場合は、標準的なプロジェクトの 1) オーバーヘッドと 2) 見積りの不正確さを考慮して十分なバッファーを含めます。また、ベロシティは最初のイテレーションですぐに現れることを覚えておいてください。ベロシティを過小評価すると、新しい機能が追加されるにつれて最初のイテレーションのベロシティが上がり、過大評価すると、機能が削除されるにつれてベロシティが低下します。2 回目のイテレーションでは、スクラム チームは最初のイテレーションをガイドラインとして使用する必要があります。
会議、電話、電子メールは速度に含まれますか?
これは、これらの項目が推定され、 反復計画これらは通常含まれません。速度の目標は、アジャイル チームの成果を出す能力の観点から、反復全体にわたる相対的な一貫性と予測可能性です。
すべてのアジャイル開発チームまたはプロジェクトにわたって速度を累積する必要がありますか?
ベロシティは非常に局所的な指標です。チームメンバーごとに「個性」が異なるだけでなく、プロジェクトは通常、見積もり手法、詳細なプロセス、テクノロジー、顧客の関与などにおいて独自の特徴を持っています。その結果、組織全体の分析は非常に不正確になる可能性があります。一方、もしすべてのチームが全く同じ見積もりを行い、全く同じ開発を行い、全く同じテストを行い、全く同じ進捗状況を追跡しているのであれば、間違いなくあなたは例外と言えるでしょう。
速度が変動するとどうなるでしょうか?
速度は通常、妥当な範囲内で変動しますが、これは全く問題ありません。速度が1～2イテレーションを超えて大きく変動する場合は、スクラムチームは再見積もりや再交渉が必要になる場合があります。 リリース計画.
速度が安定するまでにどれくらいの時間がかかりますか?
ほとんどのアジャイル開発チームでは、通常、速度は 3 ～ 6 回の反復で安定します。
将来の反復をどのように見積もればよいでしょうか?
今後のイテレーションでは、チームの実績に基づいて、チームがどれだけの成果を上げられるかを判断します。したがって、ベロシティは今後のイテレーションを計画する際に適切な指標となります。
プロジェクト チームの規模が変更された場合、速度をどのように見積もればよいでしょうか?
ベロシティを最大限活用するには、チームの一貫性が不可欠です。アジャイルチームに変更があった場合は、今後のイテレーションを計画する際には常識的な判断を下してください。チームの20%が数イテレーションで対応できない場合は、計画されているベロシティを20%程度削減します。これに複数の主要メンバー、特に対応が難しくなる可能性のある顧客が含まれる場合は、見積り額をさらに下げてください。チームが何を実現できるか、そして新たなベロシティをより深く理解するには、次のイテレーションの期間が十分にある必要があります。
最大速度は最大生産性を意味しますか?
絶対にそうではありません。ベロシティを最大化しようと試みるあまり、チームは実際には逆の結果になることがあります。ベロシティの最大化を求められると、チームはユニットテストや受け入れテストを省略したり、顧客とのコラボレーションを減らしたり、バグ修正を省略したり、リファクタリングを最小限に抑えたり、その他様々なアジャイル開発手法の重要なメリットを享受できなかったりするかもしれません。短期的には改善（と呼べるかどうかは別として）が見られるかもしれませんが、長期的にはマイナスの影響を及ぼします。目標はベロシティの最大化ではなく、最終製品の品質を含む多くの要素を考慮した、長期的なベロシティの最適化です。
反復の長さが変わった場合、速度をどのように測定するのでしょうか?
少なくとも、それほど簡単にはできません。速度の価値は、その本質的な一貫性にあります。固定されたイテレーションの長さは、プロジェクトの安定したリズムを維持するのに役立ちます。このリズムがなければ、常に修正、再見積もり、調整が必要になり、結果の一貫性が失われ、将来の予測能力が低下します。一方、もしほぼ全員が1週間の休暇や全社会議のために数日間不在になる場合は、常識に従ってイテレーションの日付や速度を適宜調整してください。多くのアジャイルプラクティスと同様に、これらはガイドラインであり、ルールではありません。
