見積もりは困難です。ソフトウェア開発者にとって、見積もりは業務の側面の中で、たとえ最も困難でないとしても、困難なことの 1 つにはちがいありません。チームやビジネス全体に影響を及ぼすプロダクトオーナーの意思決定に役立つ、多数の要因を考慮する必要があります。それらがすべて懸かっているため、開発者から管理上層部に至るだれもがつまらないことでむきになる傾向があっても不思議ではありません。しかしそれは間違いです。見積もりは見積もりに過ぎません。血の誓いではありません。 

作業工程の過小評価を埋め合わせるために週末に仕事をすることは、前提条件ではありません。そのためにも、見積もりを可能な限り正確に行う方法をいくつか検討してみましょう。  

プロダクトオーナーとのコラボレーション

アジャイル開発では、プロダクトオーナーはバックログの優先順位付けを任されています。バックログとは、製品に必要な全てのフィーチャーと修正に関する短い説明を含んでいる順序付きの作業リストです。プロダクトオーナーは業務部門から要件を収集しますが、必ずしも実装の詳細を理解しているわけではありません。したがって、優れた見積もりは、各作業項目に傾注する労力のレベルについてプロダクトオーナーに新たな洞察を与えることができます。この洞察が各項目の相対的優先度に関する判断に反映されます。

通常、エンジニアリングチームが見積もりを開始すると、要件とユーザーストーリーに関する問題が生じます。これは良いことです。こうした問題は、チーム全体が作業をより完全に理解するのに役立つからです。特に、プロダクトオーナーの場合、作業項目の細分化と見積もりによって、作業の全ての領域 (潜在的に隠れているものも含めて) の優先順位を付けることができます。開発チームの見積もりが出てしまえば、プロダクトオーナーにとってバックログでの項目の並べ替えは珍しいことはではありません。 

アジャイル見積もりはチームスポーツ

あらゆる人 (開発者、デザイナー、テスター、デプロイメント担当者など) をチームに参加させることが鍵です。各チームメンバーは、製品に対する様々な観点とユーザーストーリーを実現するために必要な作業を挙げます。たとえば、製品管理チームが新しい Web ブラウザーのサポートのような、単純に見える何かを行いたいと提案した場合、開発および QA チームは、表面に見えるものの陰に怪物が潜んでいる場合があることを経験上知っているため、その議論に加わる必要があります。同様に、設計変更には、デザインチームの意見だけでなく、開発および QA チームの意見も取り入れる必要があります。広範な製品チームの一部を見積もりプロセスから外してしまうと、低品質の見積もりが作成されることになり、重要な貢献者に当事者意識が生まれないため士気が下がり、ソフトウェアの品質に関して妥協を余儀なくされます。

チームとは無関係に作成される見積もりによってチームに犠牲を強いてはいけません。そのような見積もりは失敗への近道です。 

ストーリーポイント VS 時間

従来のソフトウェアチームは、日数、週数、月数という時間数で見積もりを提供します。しかし、多くのアジャイルチームはストーリーポイントへ移行しています。ストーリーポイントは、 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 のように、フィボナッチ数列に似た形式で作業の相対的労力を評価します。直感的にわかるものではないように聞こえるかもしれませんが、この抽象化は、作業の難しさを中心にしてチームに厳しい決断を下すよう促すので、実際に役立ちます。以下に、ストリーポイントを使用する理由をいくつか示します。

  • 日付は、日常で必然的に生じるプロジェクト関連外作業を考慮に入れていません。このような作業には、E メール、ミーティング、面接などがあり、チームメンバーが関わっている場合があります。
  • 日付で見積もると日付に執着してしまいます。相対的見積もりは、この執着を取り除きます。
  • 各チームは作業を微妙に異なった規模で見積もります。つまり、速度 (ポイントで測定される) が必然的に異なってきます。このため、速度を武器として使用して策を弄することは不可能になります。

ストーリーポイントから開始するチームは、プランニングポーカーという方法を使用します。Atlassian では、プランニングポーカーは全社的によく行われています。チームはバックログから項目を取り上げて少しの間話し合い、各メンバーは心の中で見積もりを立てます。次に、メンバーは一斉に数字が書かれたカードを上げて、各自の見積もりを示します。全員が一致していれば申し分ありません。一致しない場合、しばらくの間 (といっても、長すぎてはいけません。数分です)、様々な見積もりの根拠について話し合います。ただし、見積もりはハイレベルのアクティビティであることを忘れないでください。チームが枝葉末節にとらわれすぎていたら、深呼吸をして、概要レベルの議論に戻します。 

Keep estimations high level. If the team is too far into the weeds, take a breath, and up-level the discussion. #AgileTips

見積もりがスマートになるほど楽になる

個々のタスクは、作業が 16 時間を超えないようにしてください。(ストーリーポイントを使用している場合、たとえば、上限を 20 ポイントとします。) これより規模が大きいと、高い信頼度で個々の作業項目を見積もることが非常に困難になるだけです。その信頼性がバックログの最優先項目では特に重要です。チームの 16 時間 (または 20 ポイント) の閾値を超える見積もりがある場合、それをさらに細分化して見積もりをやり直す必要があることを示しています。

バックログ内のより深いレベルにある項目については、大まかな見積もりをします。そのような項目は、作業を実際に開始する頃には要件が変化している場合があり、アプリケーションは確実に変わってしまいます。したがって、事前見積もりでは正確さを求めすぎないようにします。変化する可能性のある作業の見積もりで時間を無駄にしてはいけません。プロダクトオーナーが製品ロードマップの優先順位付けを適切に行うために使用できる程度の概算見積もりを提供してください。

過去の見積もりから学ぶ

Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools (like JIRA Software) track story points, which makes reflecting on and re-calibrating estimates a lot easier. Try, for example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. If not, discuss why. Use that insight in future estimation discussions.

アジャイルにおけるあらゆる事柄と同様に、見積もりは訓練です。実践を重ねることによって上達します。 

関連する製品
Jira Software logo
プロジェクト / 課題管理