アジャイル開発やスクラムの手法を理解し始めると、必ず「ベロシティ」に遭遇します。これは、R&D チームが反復サイクル内で完了することができるすべてのストーリー ポイントの合計を表し、長期的な作業の見積もりと反復計画を支援するための測定ベンチマークとしてよく使用されます。
数年後、私が優秀なソフトウェア エンジニアのチームのマネージャーを務めていたとき、「速度」を実際に測定すると、非常に欠陥があることに気付きました。だからこそ、本当の正しい研究開発効果測定指標を見つけることができました。
01 なぜ「スピード」は役に立たないのですか？
レート計算式から始めましょう。
- 実際の率 = 完了した合計ポイント / 反復回数
- 予想される速度= 生成された推定合計ポイント / 反復回数 (推定ストーリー ポイントは、反復に追加されるストーリー ポイントの数です)
管理の実践では、ほとんどのチームが「実際の速度」を選択するため、この記事もそれを中心に展開します。では、使用中の実際のレートの具体的な欠点は何ですか?
1.浮遊空間を表示できない
実際のレートは、R&D チームの実際のワークロードの変動を数値で示すことはできません。以下は、4 回の反復のそれぞれで同じポイント定義を持つ 2 つのチームのストーリー ポイント統計です。
結果から、両チームのベロシティ値は 20 ですが、「両チームとも 1 回の繰り返しで 20 ポイントの作業を完了できる」と言えますか?
反復ポイントの変動が小さい (± 2 ポイント) 2 番目のチームでは機能する可能性がありますが、最初のチームの変動ははるかに大きくなります (± 18 ポイント)。実際のレート値だけを見ていると、マネージャーは研究開発チームの安定性を理解し、把握することができません。
さらに、開発するストーリーとミッションの負荷を正確に見積もることも、叙事詩 (Epic) の予想されるリリース日を策定することも不可能です。
2. 変化に柔軟に対応できない
研究開発チームとニーズは頻繁に変化します.メンバーの出席、人事異動、緊急のバグ修正、企業トレーニングなどはすべて、実際に利用可能なリソースに影響します.
ただし、実際のレートは、チームの理想的な平均稼働能力に基づいて計算されます。イテレーション中にメンバーが不在の場合、チームはすべてのストーリーを完了することができますか? これは速度にどのように影響しますか? チームは開発能力も正確に見積もることができますか?
同様に、チームが新しいメンバーを歓迎した場合、実際のベロシティは増加しますか? それとも、新しいメンバーにトレーニングを提供する必要があるため、このイテレーションの開発速度は実際には遅くなりますか? バックログを再評価する必要がありますか? これについては何もわかりません。
3. 見積もりは本質的に不正確です
研究開発のパフォーマンスをベロシティで管理することが効果的でない理由は、それがストーリー ポイント (チーム内でコンセンサスに達するのが難しい人為的に定義された評価) に依存しているためです。同時に、研究開発チームがイテレーション全体でポイント測定基準が一貫していることを確認することも困難であり、これは現在の作業見積もりの最大の問題でもあります。
研究開発の労力を比較的標準的かつ正確な方法で見積もらないと、安定した開発速度を維持することは困難です。これは、その後の反復の管理に影響を与えるだけでなく、推定精度の検査と改善にも制限を加えます。
4.メンバーが燃え尽きる
最後に、ベロシティ値に基づいてチームの反復目標を設定すると、必然的にメンバーが燃え尽きてしまいます。
多くのチームが締め切りや緊急の配達に遭遇したと思います。納期が迫るわずかな期間、部員は1日15時間働き、土日も休むことなく、イテレーションを達成するためにできる限りすべてのToDo項目を完了させようと、仕事に追われています。ゴール。
二度とこのような事態が起きてほしくないのですが、「エクストリームチャレンジ」状態でのチームスピードが確実に向上したことは否めません。では、次のイテレーションを計画するとき、R&D チームは現在よりも多くの作業を受け入れることができるでしょうか? 長期的には、ワークロードは確実にメンバーを疲れさせます。
ベロシティは、チームの目標を設定するために使用するべきではありませんが、パフォーマンスの前例を設定し、将来の価値を予測するためにマネージャーが使用する必要があります。
率は実現不可能なので、測定と管理のために代わりにどの指標を使用する必要がありますか?
02 正しい管理指標: コミットメントの差異
コミットメント バリアンス (CV)を使用して、チームの自己組織化と自己動機付けを強化するのに役立ちます。その計算式は次のとおりです。
- PointsCompleted-Total Points Completed : 前回のイテレーションで R&D チームが正常に配信したストーリー ポイントの数。
- PointsCommitted-Total Commitment Points : 反復バックログに追加されたポイントの合計として表される、チームが反復計画で完了することをコミットしたストーリー ポイントの数。
1. 指標管理の目的
コミットメントの差異を使用する場合、R&D チームは R&D の労力を可能な限り正確に見積もり、同じ基準を使用して完了目標を達成します。
コミットメント分散の最適化の目標は、その絶対値を可能な限り 0 に減らすことです。チームは、イテレーションの最後にすべてのタスクを完了し、バーンダウン チャートを 0 にするように努力します。
2. 結果の解釈
コミットメント差異の値が
- 0 より大きい場合は、目標を超えたことを意味します。チームは、コミットメント値とイテレーション プロセスに基づいて次のイテレーションのコミットメント値を増やすか、イテレーション レビューを組み合わせて、過大評価されたストーリー ポイント、計画外の人員増加など、過剰配信の具体的な理由を分析するかどうかを決定できます。
- 0 未満の場合は、コミットメントの期待値が高すぎることを意味します。現在の数値ベースラインに基づいて、オーバーコミットメントの原因を分析し、次の反復で再調整します。
- 0 に等しいということは、チームが R&D タスクを正確に見積もり、提供能力を評価できることを意味します。リズムに乗って前へ！
3. アドバンテージ分析
速度ではなくコミットメントの分散を使用して R&D の成果を管理することで、チームは次の利点を得ます。
- 各イテレーションの実際の状況を組み合わせて、イテレーションのコミットメントと目標を柔軟に策定します。
- ストーリー ポイントを正しく定義し、正確な作業見積もりに重点を置きます。
- チームの成果を適切に評価し、目的を持ってコミットメントと目標を設定します。
- スプリントでの疲労のリスクを軽減するために、自分で設定したコミットメントを回避する作業を調整します。
チーム マネージャーにとって、コミットメントの差異も非常に重要であり、主に次の点に反映されます。
- チームと協力して新しい機能や製品の複雑さを見積もる機会を持つことで、安心感と自信を得ることができます。
- より正確な納期予定を関係者に提供します。
- メンバーに自信を持って自己組織化を許可し、チームが自力で成長するように動機付けます。
4. 潜在的なリスク
もちろん、コミットメント差異管理の使用には潜在的なリスクがいくつかあります。
-
自己圧力と退縮/摩擦。メンバーが配信ワークロードを業績評価などに関連付けると、過度の内部的/個人的な圧力、過大な約束、過大な配信が発生する可能性があります。マネージャーは、メンバー間の内部摩擦を回避するための安全な環境を作成する必要があります。また、チームの長期的な健全で安定した発展を維持するために、過剰なコミットメントを特定することに熱心でなければなりません。
-
コミットメントを故意に減らす。一部のチームは、人為的にコミットを下回ったり、コミットメントの一部のみを完了したりする場合があります。管理者は、リソースの浪費を避けるために疑似パターンの存在を特定する必要があります。
小さな提案: コミットメントの差異を使用して最初に作業を管理し、比較的正確な見積もり基準を確立した後、速度を使用して能力のベンチマークを確立し、コミットメントの差異に基づいてスピードアップ バッファーを構築します。
03 ケース分析
以下では例を使用して、コミットメント分散の実際の適用についてさらに説明します。冒頭で述べた 2 つのチームは、コミットメントの差異を使用して、タスクの見積もりと能力の評価を完了するとします。
上記の表では、チームの「反復によって実際に完了した平均ワークロード」が実際の速度です。両チームの「コミットされたストーリー ポイントの平均数」は 22 (± 0.25) ポイントに非常に近かったが、実際の完了は大きく異なっていた。
最初のチームは、コミットメントの分散を使用して、「ポイント」の現在の定義が正しい労力の見積もりと能力の評価をサポートしていないことを発見しました。
そのため、4 回目のイテレーションでは、「ちょっとした作業」の定義を調整し、内部でコンセンサスに達しました。メトリックの粒度のために、彼らは 28 ポイントのコミットメントを与えました (ただし、データは最後の反復で 12 ポイントしか達成していないことを示しています)。
2 つのチームのコミットメント分散の傾向をプロットすると、ストーリー ポイントの数を最適化することも、継続的な改善のプロセスであることがわかります。
04 LigaAI まとめ
Commitment Variance は、同じポイント基準に基づいて、ワークロードの見積もりとキャパシティの見積もりを有機的に組み合わせ、レート管理の柔軟性と精度が不十分であるという問題を解決します。
コミットメント分散の管理目標は、その絶対値を可能な限り 0 にすることです。過度にコミットしてチームを疲弊させてはいけませんが、リソースの浪費につながるコミットメントを過小評価することも避けてください。
(元の著者: Michel C; 記事の出典: Medium)
成長のボトルネックを打破するために、LigaAI は R&D パフォーマンス測定システムの構築の経験と、測定指標の科学的管理方法を引き続き共有します。パフォーマンスの最適化と成長の詳細については、 LigaAI@oschinaをフォローしてください。一緒に大きく、強くなりましょう!
また、LigaAI をクリックすることも楽しみにしています。LigaAI は、私たちとコミュニケーションをとるための新世代のインテリジェントな R&D コラボレーション プラットフォームです:)
LigaAI は開発者の出航を支援します。皆さんと一緒に歩んでいけることを楽しみにしています!