ソフトウェア製品のチームに、純粋な時間の見積りを用いた正確さを求めるのは難儀です。 それは煩雑で、一般的に、意味のある決定ができるほど正確ではありません。 アジャイルな製品開発であっても、時間の見積りを正確に行うには不確実性が多すぎます。 経験的な工程管理に基づくアジリティは、テストから学習することを示唆し、このことから時間の見積りがさらに困難になります。 それに加えて、開発の後半であっても変更を歓迎し、計画に従うことよりも適応するというアジャイルの原則と価値観があり、プロジェクト計画の正確な時間の見積りを提供するようにチームに依頼することは無駄で、役に立たず、イライラするということは明らかです。 より良い代替手段は、ストーリーポイントの見積りです。
ストーリーポイントの見積りとは？
スクラム チームは、しばしば、シンプルで、迅速で、正確であり、意図的に不正確なストーリー ポイントの見積りを用います。 通常、ストーリーポイントの見積りにはフィボナッチ数を使用します。 これにより、見積りは、プロダクトバックログ内の他の作業との相対的な見積りとして、明確な、増加する作業のバケツ（１、２、３、５、８ など）に収まるようになります。
たとえば、ユーザー ストーリーの見積りが５の場合、チームは、３ポイントを与えられたユーザーよりも多くの労力が必要で、８ポイントのユーザーよりも少ない労力が必要であると感じます。 アジャイルの見積りにより、チームは精度よりも正確度を重視します。 これは、各要件にかかる時間を示すのではなく、要件を３、５、８などのバケツに入れることにおいて正確であることを意味します。
ストーリー ポイントの見積りは、完了の定義に合意した後に使用しよう
チームは、ユーザーストーリーの受け入れ基準を満たし、合意された完了の定義に到達するために、見積りにすべての作業を含めます。 チームが完了の定義に同意するまで、ストーリー ポイントのサイズ見積りを実行すべきではありません。
見積りの際には、精緻化、設計、開発、テスト、自動化、文書化、トレーニング、保護、サポート、そしてさまざまな環境へのコードの普及にかかる労力を考慮します。 見積り票を検討しながら、出荷可能な製品インクリメントを作るために考えられることはすべて取り入れます。
プロダクトオーナーと開発チームが見積りを使用する
プロダクトオーナーは見積りを使って作業に優先順位を付け、通常、プロダクトバックログでは、労力が少なく価値が高い見積りストーリーを早めに配置します。 開発チームは、見積りを使ってベロシティの履歴（最近のスプリントで、１スプリントあたりどれだけのストーリー ポイントをこなせたか）を測定し、チーム全体が実際の経験的データを使って製品リリースを予測するのに役立てます。る。 また、開発チームは、プロダクトバックログから、どれくらいの量をスプリントに取り込むかを、より正確に予測できます。 これにより、チームにとってより公平なシステムが実現し、ビジネス目標の達成をより正確に予測できる傾向があります。
しかし、より重要なことは、作業を行っている人が見積もりを提供することです。 この理由から、設計と品質保証（ＱＡ）のスキルを持つチームの担当者が、チームの見積りに不可欠なのです。
デザインがストーリーポイントの見積もりの一部である理由
顧客が、設計されただけの機能に満足する可能性は低いです。 同様に、顧客は一般的に質の低い設計のものを購入すると後悔します。 顧客は、彼らの生活を楽にしてくれる、完全に機能し、設計も優れた機能を使いたいと考えています。 製品設計は、「潜在的に出荷可能」なものを作るためには不可欠な側面です。
チームの完了の定義とストーリーポイントの見積りに、設計を含めることで、設計をできるだけ開発に近づけることができます。 これにより、使えない設計ができあがる可能性が減り、顧客のニーズと行動をチームが理解したうえで、設計を最新の状態に保ちます。 このことは、見積もり作成に関わるすべての人が、完了したアイテムの定義とともに製品設計を検討するのに役立ちます。
ＱＡがストーリーポイントの見積りの一部である理由
実用的でテスト済みの機能（あるいはサポートするバックエンド）のないデザインは使えません。 完成しても使えない製品のインクリメントは、進行中の作業と同じです。 進行中の作業は、顧客にとってまったく価値がありません。 それは、タイヤが１つでエンジンのない、美しい設計の新車を所有しているようなもので、デザインがどんなに素晴らしくても、売りづらい中途半端で使えない製品だということです。
同様に、ＱＡとテストは、チームにおける完了の定義の一部です。 これらは、製品開発に必要な重要なスキルです。 チーム全体は、テスト能力に関係なく、見積りどおりにテストを検討します。 簡単に言えば、ＱＡはストーリーの一部です。 チームが品質について合理的な保証がない場合、またはそれが実際に機能するという保証がない場合、ストーリーが完了したと言っても何にもなりません。
たとえば、開発者は要件を見て、開発作業の単純さを考慮することができます。 テストまたはテスト自動化のスキルを持つピアチームのメンバーは、同じニーズを反映し、必要なテストの複雑さを考慮する場合があります。
両方のチームメンバーは、お互いの視点から利益を得ます。 見積りに合意すれば、適切なバランスに達することができます。 スクラムチームが仕事を受け取ると、チームメイトの有益な視点を尊重しながら、それを達成する方法がより明確に見えてくるでしょう。
見積りが機会を生む
アジャイルの習慣が、作業を行うすべての人に見積りを奨励するのです。 チームとして見積りを行うと、素晴らしい会話の機会が生まれますが、それこそがチームとして見積りを実行するもっとも重要な理由です。 このような会話は、ユーザーストーリーを将来の議論のためのプレースホルダーと考えたときに期待されるやりとりそのものです。
見積りには、設計やQAなど、実用的な製品のインクリメントを作るために必要な、すべてのスキルが反映されています。設計とＱＡを含めることで、単に「開発が完了しました」または「私の作品が完了しました」ではなく、顧客を喜ばせるために潜在的に出荷可能な製品のインクリメントを提供することに重点を置いています。 アジャイルマニフェストの原則5では「やる気のある個人を中心にプロジェクトを構築する」ことが提案されています。彼らが必要とする環境とサポートを提供し、彼らが仕事を成し遂げるために、彼らを信頼してください。」
見積りは、定義上、正しいという保証はないということを忘れないでください。 私たちのアドバイスは、見積もりを改善する能力よりも、顧客を「驚かせる」製品の構築にもっと焦点を当てることです。 経験主義を活用しましょう。 テストと学習、検査と適応を行い、チームの見積りに設計と QA の考慮事項を含めることで、すべてを透明にします。
ストーリー ポイントの見積りについて知りたいですか？ 私たちがお手伝いします。 今すぐアジャイルの専門家にお問い合わせください。
