理想的には、機能は以下の基準に従う必要があります
- それは提供すべきである ビジネス価値。
- そのはず 尊敬に値する – 開発チームが実装に必要な作業の見積りを提供できるほど十分な定義が必要です。
- そのはず 十分に小さい 反復内に収まるように、大きすぎる場合はさらに細分化する必要があります。
- そのはず テスト可能 – 機能が顧客に受け入れられるためには、どのような自動テストまたは手動テストに合格する必要があるかを理解する必要があります。
異なる方法論では、機能を表す際に異なる用語が使用されます。どの方法論または用語を使用するかは、チームに委ねられます。エクストリームプログラミング（XP）では、機能を表すために「ユーザーストーリー」または「ストーリー」という用語が使用されます。スクラムでは機能リストを表すために「プロダクトバックログ」が使用されます。機能駆動開発では「機能」が使用され、DSDMでは「要件」が使用されます。同様に、統合プロセス（アジャイルUP）には、段階的に提供可能な機能を定義するために「要件」や「ユースケース」を使用する軽量版が数多く存在します。最終的な目標は、ビジネス価値を小さな増分で定期的に、そしてできるだけ早く提供することです。
方法論の違い
スクラム 機能を バックログ項目は、粒度が大きい傾向があり、「本番環境のハードウェアをセットアップする」や「xyz オプションを調査する」などの機能以外の項目も含まれることがあります。
XP 機能を ストーリーこれは、機能性を定義するための特に役立つアプローチとなります。
DSDM 機能を 要件これには、システム機能以外のものも含まれる場合があります。
アジャイルアップ 実践者が使用する こちらから の三脚と ユースケース 特徴を定義する.
機能内訳構造（FBS）
詳細計画の段階では、 アジャイル開発 ウォーターフォール型開発で使用される作業分解構造（WBS）ではなく、フィーチャー分解構造（FBS）アプローチを推奨します。フィーチャー分解構造の利点には、以下の理由があります。
- 顧客と開発チームの間で、両者が理解できる言葉でコミュニケーションが可能になります。
- 顧客はビジネス価値に基づいてチームの作業に優先順位を付けることができます。
- 実際に生み出されたビジネス価値に照らして作業を追跡できます。
最初は大きな機能から始めて、徐々に小さな機能に分割していくことは許容されます。これにより、実際の設計とデリバリーを円滑に進めるために詳細が必要になるまで、顧客は詳細に踏み込む必要がありません。
初期機能リストの作成
リリース計画と 反復計画チームは、システムに適用可能な機能を可能な限り多くリストアップする必要があります。通常、機能収集の責任者は1人（例：プロダクトマネージャー、顧客、プログラムマネージャー、ビジネスアナリスト、その他の顧客代理人）ですが、機能に関する要望は様々なソースから寄せられる可能性があります。ユーザー、顧客、営業、マーケティング、RFP、開発チームメンバー、経営陣、競合他社、政府規制など、様々なソースから要望が寄せられる可能性があります。チームの中心的な機能リストには、重複項目、実現不可能な機能、そして過度に曖昧な要望を防ぐための制御機能を設けるべきです。しかし、チームが新しい機能を発見したら、すぐに入力するように促し、優先順位付けと計画プロセスに組み込むようにする必要があります。
初期の機能リストは、リリースと最初のイテレーションの計画のための入力として使用できる、大まかなスケッチ、つまり上位集合となります。これは、システムが将来どのようになり得るか、そしておそらく複数のリリースを経て、どのようなものになるかという、現時点での潜在能力を表しています。すべての機能が定義されるまで待つ必要はありません。 ソフトウェアの提供元のリスト、元の説明、元の優先順位に無意味に固執する必要はありません。アジャイル開発の重要なポイントの一つは、このリストが（他のすべてと同様に）反復ごとに進化していくことです。
大まかな機能リストが完成し、リリース計画とイテレーション計画が策定され、最初のイテレーションが完了したと仮定しましょう。その時点ではまだ、いくつかの重要な機能が特定されていません。これらの機能は、進化するリリース計画とその後のイテレーションに組み込まれ、できるだけ早く提供されます。しかし、その間も時間は無駄になりません。チームはできるだけ早く価値の提供を開始し、プロジェクトが時間の経過とともに新たな優先事項、情報、そしてビジネスダイナミクスに適応できるようにするためのインフラストラクチャを構築します。
機能一覧
機能リストを作成する際、まずは短い段落（通常は2～4文）で機能を説明します。この説明は、機能のハイレベルな概要、予備的な理解のための仮置き、そして将来のコミュニケーションの基盤となります。これは、後ほど執筆する記事の見出しのようなものです。目標は、機能の相対的な規模、複雑さ、そして他のすべての機能と比較した優先度を合理的に理解するのに十分な時間をかけることです。作業を進める中で、さらにいくつかの詳細が明らかになるでしょう。 反復計画しかし、機能の正確で具体的な理解は、顧客と開発者がそれを実装するまで十分に議論したり、（方法論によっては）それを確定的に指定する自動受け入れテストを作成したりすることで、反復中に明らかになります。
役立つ参考資料
ユーザーストーリー
適用されたユーザー ストーリー: アジャイル ソフトウェア開発向け マイク・コーン
ウェビナー
PI計画を実行する方法 Digital.ai Agility
整理機能
長い機能リストを一つ一つ管理するのは困難です。カテゴリ、上位レベルの機能グループ、ビジネス価値または優先度、リスクなどを指定して機能を整理すると非常に便利です。これらの様々な属性でフィルタリングや並べ替えを行うことで、膨大な機能リストを管理しやすい単位に分割できます。
機能リスト全体を単一の連続した順序でランク付けすることで、プロジェクトチーム全員がどの機能が最も価値があるかを容易に把握できるようになります。プロジェクト開始時にリストに100個の機能が含まれている場合、そのうち50個の機能が「高」優先度カテゴリに分類されることは珍しくありません。機能を単一の順序でランク付けすることで、「最重要」な機能を特定し、提供価値を最大化するために最初に完了させるべき機能を特定するのに役立ちます。
リスクの考慮
特定の機能に関連するリスクについては、追加の考慮が必要になる場合があります。一部の機能には、チームにとって新しい、またはリスクの高い設計、アーキテクチャ、フレームワーク、アルゴリズムが含まれます。このような機能が最高のビジネス価値をもたらさない場合でも、多くの場合、初期のイテレーションで対処できるように優先度を上げます。高リスクの機能がプロジェクトの早い段階で対処され、何らかの理由で機能しないことが判明した場合でも、チームにはまだ対応して回避する時間があります。これにより、プロジェクト全体のリスクが最小限に抑えられます。開発チームは、顧客と緊密に連携して、これらの種類の問題、リスク、および依存関係を特定する必要があります。最終的には、機能の優先順位付けは顧客次第ですが、この重要なプロセスは孤立して行われるべきではありません。優れたチームは、プロジェクトのライフサイクル全体を通じて価値を提供し、リスクを軽減するために協力します。
特徴の推定
機能を特定した後、顧客は多くの場合、主要な開発関係者と協力して機能の見積もりを定義します。機能の見積もりは、開発を推進するための予備的な高レベルの見積もりです。 リリース計画 イテレーション計画も必要です。見積もりに関わるステークホルダーには、アーキテクト、テクニカルリード、開発者、テスター、ライター、マネージャーなどが含まれます。多くの組織では、グループが協力して初期見積もりを迅速に作成するプロセスを導入しています。このステップは、機能をさらに細分化する必要があるかどうかを初期段階で判断するのに役立ちます。
機能の初期見積もりでは、妥当な高レベルの見積もりに迅速に収束させることが目標です。機能に 17.5 アイデア時間 (または Gummi Bears、NUT、その他の使用されている単位。以下を参照) が正確に必要かどうかに焦点を当てるのではなく、ほんのわずかな時間で妥当に近づくことが目標です。機能の実装に理想的な日数が 2 ～ 3 日かかることに同意するのに 2 分かかるのに対し、17.5 アイデア時間という正確な見積もりを確立するのに 30 分かかる場合、前者のアプローチが好まれます。グループ内で意見が異なる場合に単一の見積もりを確立するには、平均を取る、妥当な近似値を作成する、常に最良のシナリオを使用する、またはより複雑な計算が適切であれば最良のケース、最悪のケース、および予想される見積もりを含む計算を使用するなど、さまざまな方法があります。いずれにしても、異なる見積もりについての議論から、多くの場合、有用な知識が得られます。
機能の定義と見積りというこのプロセスは、最初は難しく感じるかもしれません。チームが初めて導入する際には、自分たちにとってうまく機能するプロセスに慣れるまでに、何度かのミーティングが必要になるかもしれません。しかし、時間をかけていくうちに、機能を単一のイテレーションで提供できる作業単位に分解することが容易になります。チームは練習を重ねることで非常に上達し、アジャイル開発では、リリースとイテレーションごとに見積りを練習することができます。
推定単位
見積もりはその性質上不正確であり、開発者はこれまで開発タスクの完了に必要な時間全体について有用な見積もりを出すのが困難でした。実際のプログラミング時間の見積もりは不正確になることが多いです (特に実際の数値と厳密に比較していない場合)。しかし、プログラミング以外の時間を正確に算出することはさらに困難です。誰かが町を車で横断するのにどのくらい時間がかかるか尋ねたら、何と答えますか? 相対的な尺度を使用します。「ラッシュアワー以外で、天気が良く、工事もなければ 1 時間、そうでない場合は 2 時間くらい」などです。これらの外的要因は制御不可能であり、予測も困難です。コードの開発に加えて、プログラマーはテスト、ドキュメントの作成、設計、会議やレビューへの参加、メールの対応などに時間を費やします。プログラミング作業と比較すると、プログラミング以外の作業は予測や制御が困難です。業界、組織、時期、組織にかかるあらゆる外部からのプレッシャーによって変わる可能性があります。
一部のチームは、プログラマーにプログラミング以外の作業をすべて見積もりに含めるよう求めます。しかし、前述のように、これは容易ではありません。特定のアジャイルプロジェクトでは、チームがプログラミング以外の作業に費やした時間を正確に測定するずっと前から、さまざまな機能を完成させるために必要な相対的な作業量を把握し、それに応じて計画を立てることができます。そのため、アジャイルチームは、最も簡単に見積もり・測定できるもの、つまり実際のプログラミング作業に重点を置いた見積もりを行うのが一般的です。各機能と各技術タスクが、他の機能や技術タスクと比較してどれだけの作業量を要するかに焦点を当てます。これにより、数回のイテレーションを経て実際の速度が明らかになるにつれて、プログラミング以外の作業に費やされる時間が明確になります。このようにプログラミング作業に焦点を絞るために、アジャイルチームが使用する見積もり単位は主に2つあります。
- 作業単位
- 理想的な時間
作業単位
作業単位は相対的な尺度であり、実際の時間と混同されることがないよう配慮されています。作業単位の例：
- Points
- グミベアーズ
- フィートポンド
- NUT（漠然とした時間単位）
これらは、ある機能（またはタスク）を実装するために必要な作業量を、他の機能（またはタスク）と比較した相対的な量を表します。チームが一定の速度（通常は数回のイテレーションを経て）に落ち着いて初めて、これらの作業単位を実際の時間単位にマッピングできるようになります。まさにこれが速度の目的です。つまり、チームが実際の時間単位あたりにどれだけの作業を実行できるかを示すのです。
チームまたは組織が見積り単位について合意したら、それを一貫して実装し、当初の定義を忠実に守るよう努力することに同意する必要があります。特にプロジェクトの初期段階においては、これらの単位を時間単位に正確にマッピングしようとする衝動を抑えることが重要です。
理想的な時間
作業単位と同様に、理想時間にはプログラミング以外の時間は含まれません。チームが見積もりに理想時間を使用する場合、それは機能やタスクを完了するために必要なプログラマーの時間のみを、他の機能やタスクと比較して明示的に参照していることになります。繰り返しますが、最初の数回のイテレーションでは、見積もり履歴が蓄積され、実際の速度が明らかになり、理想時間を実際の経過時間にマッピングできるようになります。
理想時間を採用している多くのチームでは、最終的な工数がプログラマーの初期見積りの 1 ～ 2 倍を超え、数回の反復でこの値が許容範囲内に安定することに気づいています。タスクごとに比率は異なりますが、反復全体を通して見ると、チームが導き出す比率はほぼ一定であることが証明されています。特定のチームにとって、理想時間と実時間の既知の過去の比率は、リリースの計画において特に役立ちます。チームは必要な機能を素早く確認し、理想日数 200 日という大まかな見積りを提示できます。チームの理想時間と実時間の過去の比率が約 2.5 であれば、チームは 500 プロジェクト日という見積りを提出してもかなり自信を持てるでしょう。固定入札のシナリオでは、この種の見積りは信頼できるものとなります。
相対推定
多くのアジャイルチームは、機能の相対的な見積もり手法を採用しています。様々な単位長にわたって機能を見積もるのではなく、少数（3～5個）の相対的な見積もりカテゴリー（バケット）を選択し、それらのカテゴリーに基づいてすべての機能を見積もります。
機能計画とタスク計画
計画の初期段階ではスピードと機能ごとの相対的な作業量に重点が置かれますが、ある時点では機能をそれぞれのタスクに分解し、より正確に見積もる必要があります。これはリリース計画とイテレーション計画の段階で行われます。一般的に、機能の見積りとタスクの見積りは目的が異なります。
- 機能の見積もりは、リリースと反復にわたるスケジュールの推進に役立ちます。
- タスクの見積もりは、反復内のリソースの読み込みを促進するのに役立ちます。
それぞれの目的が異なるため、ある特徴量の推定値は、その特徴量のタスク推定値の合計と完全に一致するとは限りません。しかし、様々な特徴量において、特徴量の推定値と各特徴量のタスク推定値の合計の間には、少なくとも大まかな相関関係があるはずです。
よくあるご質問
機能の大きさはどのくらいですか?
これは、チームが行っている開発作業によって大きく異なります。一般的な目安としては、機能は1回のイテレーションで完了できるほど小さく、かつスケジュールを組む価値があるほど大きい必要があります。例えば、10人のチームが1ヶ月のスプリントで作業している場合、1時間かかる機能だけをスケジュールするのは避けたいでしょう。スケジュールと追跡を行う項目が多すぎるからです。特定の機能にそれほど小さな変更がある場合は、スケジュール管理の観点から、それらの小さな変更を1つの大きな項目にまとめるのが最善です。1時間かかる作業ごとに、その機能のタスクを作成します。
バグ修正は機能ですか?
可能です。例えば、スクラムでは、チームが達成すべきすべての作業をバックログリストに載せるべきだと教えています。バグ処理の一般的な方法としては、1) バグごとに機能項目を作成する、2) 各イテレーション内に「バグ修正」という機能項目を作成し、修正すべきバグのリストまたは種類を詳細に記載する、3) バグを個別に処理し、バグに対する時間を追跡しない、などがあります。どの方法を選択するかは、チームが遭遇すると予想されるバグの数と規模によって大きく左右されます。
なぜ特徴を推定するのですか?
機能の見積もりは、リリース計画とイテレーション計画における優先順位付けとスケジュール策定に役立ちます。特定の期間内にどれだけの作業をスケジュールすべきかを知るには、各作業の規模を見積もる必要があります。また、以下もご覧ください。 機敏な速度2 つの機能のビジネス価値は同じだが、一方が他方の半分の規模である場合、チームは最初の機能に取り組む方が効率的であるため、最初の機能を 2 番目の機能よりも上位にランク付けする必要があります。
タスクの見積もりが合わない場合、機能の見積もりを更新する必要がありますか?
いいえ、機能の見積もりはスケジュールを決定します。タスクの見積もりはリソースの割り当てを決定します。これらの値には相関関係があるはずですが、完全に一致する必要はありません。
