ユーザーストーリーの基本。 パート3：質の高いユーザーストーリーへの投資

転送の継続。 パート1 、 パート2 。



翻訳：アレクサンダー・ヤキマ（ www.enter-agile.com ）

独立コンサルタント、アジャイルトレーナー。 2002年以降のIT業界。 彼は、プロジェクトおよびプログラムマネージャー、アウトソーシング会社のセールスマネージャー、シリコンバレーのスタートアップの開発ディレクターとして働いていました。 2007年から2008年にかけて、彼はトレーニングセンターLuxoftと協力しました。



質の高いユーザーストーリーに投資する



柔軟なチームは、ユーザーストーリーの調査、開発、分析、および受け入れテストの作成にかなりの時間（おそらく半分以上）を費やします。 これは次の事実を確認するため、そうあるべきです。 ：



すでに理解されている目的のためにコードを書くことは、必ずしも製品開発の最も難しい部分であるとは限りません;コードを書く本当の目的が何であるかを理解するのが最も簡単です。



したがって、最後の重要な瞬間であるにもかかわらず、質の高いストーリーに努力を注ぐことは、チームにとって価値のある仕事です。 ビルウェイクは、優れたユーザーストーリー^8の属性を説明するために、略語INVEST ⁷を導入しました。







INVESTモデルは非常に広く普及しており、多くの柔軟なチームがこれらの属性に基づいてストーリーを評価しています。 以下に、チームがどのように投資すべきかという正確なビジョンを示します。

独立

独立性とは、ストーリーを独自に設計、テストし、場合によっては配信することもできることを意味します。 これにより、独立した価値をもたらすことができます。



ユーザーストーリーの多くは、製品の機能が向上するにつれて、自然で徐々に蓄積される依存関係を獲得しますが、それでも各要素は独立した価値を持つことができます。 たとえば、製品は単一のエントリを表示し、次にリストを表示し、それを整理し、それをフィルタリングし、ページナビゲーションを追加し、リストをエクスポートし、アイテムを編集します。これらのアイテムの多くは順次依存関係を持ち、それぞれが独立した値を提供しますこれらのポイントのいずれかで開発が一時停止された場合、製品が配信される可能性があります。



それにもかかわらず、技術的または機能的に最終的な利益にならない多くの依存関係にも、バックログに陥るという特性があります。それらを特定して排除する必要があります。 役に立たない機能依存性の例を次に示します。

1）管理者として、ユーザーパスワードのセキュリティルールを設定して、ユーザーがシステムセキュリティを維持しながら安全なパスワードを作成および維持する必要があるようにすることができます。

2）ユーザーとして、アカウントのセキュリティを維持するために、管理者が設定したパスワードセキュリティルールに従う必要があります。

この例では、消費者のストーリーは管理者のストーリーに依存しています。 管理者のストアは、セキュリティポリシーのインストール、クリーニング、および保守についてのみテストされていますが、エンドユーザーへのポリシーの適用に関してはテストされていません。 さらに、管理者のストーリーを実装しても、製品が潜在的に提供される形にならないため、独立したユーティリティはありません。



ユーザーストーリー（およびシステムアーキテクチャ）を修正することで、異なる方法でストーリーを再分割することで依存関係を削除できます。この場合、セキュリティポリシーの種類によって、各ストーリーでポリシー設定とそのアプリケーションを組み合わせます。

1 '）管理者として、パスワードの有効期限を設定できるため、ユーザーは定期的にパスワードを変更する必要があります。

2 '）管理者として、パスワードの複雑さの特性を設定できるので、ユーザーは手に取りにくいパスワードを作成する必要があります。

現在、各ストーリーはそれ自体で存在することができ、非常に独立して実装、テスト、および配信できます。

交渉可能性

従来の要件とは異なり、ユーザーストーリーは特定の機能に関する合意ではなく、まだ議論、実装、テスト、および承認されていない要件の受容体です。 ビジネスとチーム間のこの議論のプロセスは、ビジネスから得られる情報の正当性と優先度を適切に反映しますが、コラボレーションとフィードバックによる研究の素因にもなります。



垂直的な組織構造を持つ過去の企業では、書面による要件により、部門間のコミュニケーションが制限され、過去の合意の記録として機能していました。 それどころか、アジャイルは、動的な環境で問題を解決するのにチームアプローチがより効果的であるという考え方に基づいています（会社のさまざまな部門間の協力ではなく、製品所有者が代表する技術スタッフとビジネスの両方を含む1つのチームは、翻訳者のコメントです）。 ユーザーストーリーは、この効果的な直接コミュニケーションとコラボレーションのアプローチを効果的に使用するための構造化されたリアルタイムツールです。



最後に、ユーザーストーリーの交渉可能性により、チームは予測可能性を達成できます。 制限が厳しく、詳細すぎる要件がないため、機能範囲と納期の間のトレードオフを見つけるためのチームとビジネスの能力が向上します。 各ストーリーは特定の柔軟性を可能にするため、チームはリリースの目標を達成するための柔軟性も高め、信頼性と信頼性が向上します。

便益

柔軟なチームの目標はシンプルです-利用可能な時間とリソース内で最大限のメリットを提供することです。 したがって、利益（私たちは値と呼ぶこともあります - 翻訳の著者によるコメント ）はINVESTモデルで最も重要な属性であり、各ユーザーストーリーは製品のユーザー、顧客、または利害関係者にとって特定の値を表す必要があります。 バックログの優先順位はストーリーのメリットに基づいて設定され、チーム全体が提供できるメリットに応じてビジネス全体が成功するかクラッシュします。



チームが直面する典型的な課題は、価値を効率的に提供するのに適した小規模で段階的なユーザーストーリーの書き方を学ぶことです。 従来のアプローチでは、要件を技術的なコンポーネントに機能的に分類するためのアルゴリズムが採用されていました。 システム設計に対するこの「階層化」アプローチは、複数の反復の結果としてすべての層が結合されるまで配信を遅くします。 Wake ⁹ （Wake）は、技術（水平）レイヤーではなく垂直レイヤーのビジョンを提供します。

ストーリー全体をパフペストリー、つまりネットワーク層、データ操作層、ビジネスロジック層、ユーザーインターフェイス層として想像してください。 ストーリーの（水平）分離により、パイの一部のみを提供します。 しかし、ユーザーにケーキ全体の味を一度に感じる機会を与えたいと思います。これを達成するための最良の方法は、レイヤーを縦に切ることです。 開発者は非常に多くの場合、一度に1つのレイヤーのみで作業する傾向があります（したがって、「適切」になります）。 ただし、システムにユーザーインターフェイスがない場合、データへのフルレベルのアクセス（たとえば）はユーザーにとってほとんど価値がありません。

有用なストーリーを作成するには、水平から垂直へのパーティションを介して思考の方向を変える必要があります。 ユーザーに価値を提供し、できるだけ早く頻繁にユーザーのフィードバックに頼ることができるように、アーキテクチャを「カットスルー」するユーザーストーリーを作成します。



通常、価値はシステムと対話するユーザーに焦点が当てられますが、利益は顧客の代表者または主要な利害関係者により自然に焦点を合わせられる場合があります。 たとえば、エネルギー会社のマーケティングディレクターは、サイトでより高いバナーコンバージョン率を要求します。 ストーリーはユーザーの観点から記述できますが、

ユーザーとして、自分の注意をより効果的に引き付ける他の料金プランを見ることができるので、自分のライフスタイルにより適したプランの1つに登録できます。

...しかし、真の価値のより明確な見方を提供するために、マーケティングディレクターの観点からストーリーを書くことはより自然になります。

マーケティングディレクターとして、新しい料金プランをユーザーに提供できるため、ユーザーは引き続き当社から電力を消費する可能性が高くなります。

チームが直面するもう1つの困難は、リファクタリング、コンポーネントのアップグレードなどの技術的なストーリーのメリットを実証することです。たとえば、製品がどのようにプロを実行してこの価値を判断できるか。

エラーロギングシステムをリファクタリングします。

技術ソリューションの価値をユーザーストーリーとして定式化すると、ビジネスにその有用性を伝えるのに役立ちます。 例：

消費者として、製品のどこかで完全で理解可能なエラーメッセージを受け取ることができるので、問題の対処方法を知ることができます。 または

テクニカルサポートエンジニアとして、ユーザーがアプリケーション内のどこでも完全で理解可能なメッセージを受信できるようにして、テクニカルサポートに連絡することなく問題に対処できるようにします。

これらの最後の例では、価値はユーザー、Obounerの製品、利害関係者、そしてチームにとって明らかです。

適合性

優れたユーザーストーリーが最適化されます。 バックログには任意のサイズのストーリーを含めることができるという事実にもかかわらず、1回の反復で実装およびテストできるようにするために、チームはその複雑さとそれを完了するために必要な作業量のおおよその見積もりを提供できる必要があります。 ストーリーを見積もるための最小限の投資は、1回の反復の範囲内に収まるかどうかを判断することです。 推定の精度が上がると、チームの予測可能性が向上します。



チームがストーリーを確立できない場合、ストーリーは大きすぎるか、明確に定義されていないとしてマークされます。 推定するには大きすぎる場合は、小さなストーリーに分割する必要があります。 ストーリーの定義が弱すぎて確立できない場合は、不確実性を減らすために、機能的なスパイクを適用して、1つ以上の合理化されたユーザーストーリーを作成します。 （これらの各ケースについては、次の章で詳しく説明します）。



ユーザーストーリーを推定する主な利点の1つは、正確なボリュームのアイデアだけでなく、隠された仮定、受け入れ基準の欠落を分離し、チームのストーリーのアイデアを明確にする機能です。 したがって、評価のプロセスに伴う対話は、評価自体と同じくらい重要であり、おそらくより重要です。 以下に示すように、ユーザーストーリーを合理化する能力は、そのボリュームに大きく依存します。

コンパクトさ

ユーザーストーリーは、反復の一部として実行できるほど小さくする必要があります。そうしないと、ユーザーストーリーは価値がなくなったり、反復の終わりに完了したと見なされなくなります。 さらにコンパクトなストーリーでは、柔軟性と生産性がさらに向上します。 これには2つの主な理由があります。スループットの向上と複雑さの軽減です。



帯域幅の増加



キューイング理論からわかるように、よりコンパクトなパッケージはシステムをより速く通過します。 これは、無駄のない製造の重要な原則の1つであり、リトルの法則に反映されています。







安定したシステム（スループット、つまり単位時間あたりに実行できる作業量が一定である）では、サイクルの期間（開始と終了の間の時間間隔）を短縮するために、現在の作業の量を減らす必要がありますプロセス）。 私たちの場合、これは、 よりコンパクトなユーザーストーリーが少なくなり、開発サイクルをより速く進むことを意味します 。



さらに、システムが完全にロードされると、システムが不安定になり、問題が蓄積する場合があります。 輻輳の激しいシステムでは、スループットが低下するため、大きなパケットがシステム内を過度にゆっくりと移動します。 （ラッシュアワーの高速道路を想像してください。オートバイは車やトラックよりも正常に移動する可能性がはるかに高くなります。ロードされたシステムで運転する場合、コンパクトなオブジェクトを操作するのがはるかに簡単です。） 80-120％）、彼らは「ラッシュアワー」にも該当します。



負荷が約80％以上に達すると、オブジェクトが大きいほどサイクル時間が長くなり（スローダウン）、小さいオブジェクトよりもはるかに大きくなります。 さらに、サイクル時間の変動が増加します。つまり、パッケージが実際にシステムを離れることができる時期を予測することがより困難になります。これを図1に示します¹⁰ 。 次に、この低い予測可能性は、チームの計画、コミットメント、および信頼を破壊します。







図1.大型パッケージでは、サイクル時間が長くなり、バリエーションが大きくなります。



複雑さの軽減



よりコンパクトなユーザーストーリーは、比例したボリュームだけでなく、複雑さも少ないため、開発プロセスをより速く進めます。 複雑さは非線形にボリュームに依存します。 これはテストで最もよく観察されます。テストでは、機能の検証に必要なテストシステムの分岐が、機能自体の量に対して指数関数的に増加します。 これは、クリーンなコードを開発するための推奨事項と一致しています。つまり、Robert Martin [Martin 2009]は、システム機能について次の規則を提案しています。







これは、フィボナッチ数列（つまり、1、2、3、5、8、13、21、...）がユーザーストーリーの推定に非常に効果的である主な理由の1つです。人件費の推定は、タスクボリュームの増加に比例して増加します。



ボリュームと独立性の比率について



ボリュームと独立性の関係の問題は完全に正当なものです。これは、ストーリーが小さいほど依存関係の数が増えることは論理的に思えるからです。 ただし、依存関係がわずかに増加したとしても、ストーリーが小さいほど、大きなユーザーストーリーよりもスループットが高くなり、ユーザーフィードバックの応答性が向上します。 したがって、アジャイルサポーターは常に小さなストーリーに傾倒し、それらをさらに小さくします。

テスタビリティ

本格的なアジャイルでは、 すべてのコードがテストされるため、ストーリーのテスト容易性が確保されます。 ストーリーがテスト不可能な場合、それは形成が不十分であるか、複雑すぎるか、バックログの他のユーザーストーリーに依存している可能性があることを意味します。



ストーリーから抜け出せない （つまり、正常にテストされる） 場合にストーリーが反復に陥らないようにするために 、今日の多くの柔軟なチームは「最初のテスト」アプローチを使用しています。 これは、Development Through Testing（TDD）を使用したXPコミュニティに由来します。TDDは、これらのテストを満たすコードを記述する前に自動化された単体テストを記述する慣行です。



それ以来、この哲学は、それ自体をコーディングする前のストーリーと必要な機能テストの受け入れ基準の開発に適用されてきました。 チームがストーリーをテストする方法を知っていれば、おそらく彼らもそれを実装する方法を知っています。



テスト容易性により、ユーザーストーリーは要件と同じ「落とし穴」に陥ります。 すばやく、管理し、美しく、きれいに 、などのあいまいな単語は簡単に綴ることができますが、テストするのは非常に困難です。なぜなら、異なることは異なる人々にとって異なることを意味するため、避けるべきだからです。 そして、これらの言葉はある程度の議論を提供するという事実にもかかわらず、明確な境界でそれらを制限することは、チームとビジネスが結果への期待を同期させ、大きな驚きを避けるのに役立ちます。

文学

• コーン、マイク。 2004.適用されるユーザーストーリー：アジャイルソフトウェア開発用。 マサチューセッツ州ボストン：Addison-Wesley。
• マーティン、ロバート。 2009. Clean Code：A Handbook of Agile Software Craftsmanship。 ボストン：MA：Pearson Education。
• ポッペンディーク、メアリー、トム・ポッペンディーク。 2007.リーンソフトウェア開発の実装：コンセプトからキャッシュへ。 マサチューセッツ州ボストン：Addison-Wesley。
• ジェフリーズ、ロン。 2001年8月。 「エッセンシャルXP：カード、会話、そして詐欺？Rmation。」 XPマガジン

---

• ⁷ビル・ウェイク。 www.XP123.com
  
  ⁸翻訳の著者のメモ：用語の実用的な互換性のために、私は英語の元の略語を優先しました。 言語、しゃれや人工構造物を控えます。
  
  ⁹同上
  
  ¹⁰出典：[Poppendieck 2007]。