ディープソートマシンのアジャイルユーザーストーリー
ヒッチカーのGalaxyガイドをご覧になった方は、Deep Thought（下図）が生命の意味を計算するために作られたマシンであることをご存じでしょう。
アジャイルスクラムを使用してこのマシンを構築し、ユーザーストーリーを使用するという任務を負ったと想像してみましょう。
実際には、ストーリーは1つしかないように見えます。つまり、「ユーザーとして、人生の意味を知りたいので、自分が存在する理由を知りたい」
マシンはいつの間にか複雑で、ビルドに非常に長い時間がかかるため（1つのスプリントに収まるよりも長い）、1人のユーザーを分割したいと思いますスプリントに収まる小さなユーザーストーリーへのストーリー。
真のアジャイルでは、ユーザーストーリーをより小さなユーザーストーリーに分割し、DeepThoughtシステムを介して垂直スライスを作成します。ただし、この場合、ユーザーのストーリーは、ユーザーがシステムに求める最小の（そして唯一の）ものであるため、これよりも小さいものに分解できないようです。この場合、垂直スライスisシステム全体。バックエンドシステム全体が完成するまで、ユーザーに何の役にも立ちません。さて、シェルを構築してそれを配信することはできますが、それから内部が完了するまで、ユーザーに違いはありません。
ただし、ユーザーストーリーを Technical User Stories に分割して、ユーザーストーリーをサポートするために作成されるバックエンド機能を説明することはできますが、これによりシステム内に水平方向のスライスが作成され、真のAgilistsに嫌われています。
私が尋ねている理由は、上記と同じ方法で記述できるシステムを作成する必要があるためです-単一のエントリポイントを持つ大規模なバックエンドシステムであり、応答の前に実装するのに長い時間がかかります（スタブ以外による）そのエントリポイントに作成できます。
では、どうすれば「ユーザーとして人生の意味を知りたいので、自分が存在する理由を知ることができます」をバックログに分解するにはどうすればよいですか？アイテム？
この一般化された抽象的なものはあなたの気をそらします。アジャイルは、実用的になることをすぐに教えてくれます。非常に具体的な小さな部分の問題に取り組むことによって学ぶべきことがもっとあります。各部分を理解したら、このプロセスを繰り返すことで、プロセスの学習とドメイン知識の構築を同時に行うことができます。したがって、これらの小さな部分をどんどん積み上げていくにつれて、全体のより大きな部分に進むことができます。
類推することなく、「単一のエントリポイントを持つ大規模なバックエンドシステム」をはるかに正確に説明できたはずです。
私はあなたの「垂直スライス」の物語を読んで、MVPエピックのようなものを最初から作成しようとしていると思います。この意図に対して私の拍手があります。これは無駄のないスタートアップの特徴であり、私がこれまでにやったことでもあります。
MVPの目的は、学習することです。最もリスクの高い仮定をテストし（「リスクを軽減」）、それらのコア要素を検証します。したがって、次のステップは、この大きなアイデアを仮定に分解することです。これは非常に漠然としていて仮説的であるため、この「分解」プロセスを示すために、私自身のいくつかの仮定を立てます。さあ行こう：
- valueの一部ユーザーとして、人生の意味を知りたいので、自分が存在する理由を知りたいは「私が存在する理由を知るために」です。
- 「私が存在する理由を知るために」は、「なぜ私が存在するのか」という広範で非常に「根底にある」哲学的質問に答えます。
- 「Deep Thought」が「なぜ私は存在するのですか？」という根本的な質問に答えることができる場合、たとえば「1 + 1は何ですか？」のように、はるかに派生的で具体的な質問に答えることができると想定するのは当然です。
- 垂直スライスを「ユーザーとして、基本的な算術を計算したいので、算術の理解を検証できる」と定義できますか？ （または同様に無意味な何か）
- たぶん、ルート計算のすべての複雑な内部の完全な垂直スライスではないかもしれませんが、クエリ入力システム、結果/出力配信システム、およびクエリ/リクエストのキャプチャといくつかの処理パイプライン（多分）
- つまり、私たちの叙事詩がであるとしましょう。ユーザーとして、基本的な算術を計算したいので、算術の理解を検証できますそして最初の話はとしてユーザー、1 + 1を評価したいので、基本的な算術演算を確認できます。ブーム！これで具体的かつ明確なものが得られました。エンドツーエンドのテストを作成することもできます（たぶん）
さらに発見したら、このストーリーを入力、出力などのユーザーフローに分解することもできます。しかし、この発見プロセスは、このような議論（これらの箇条書き）によって促進されます。ブレーンストーミングを行い、物事を切り詰めるように強制すると、ドメインと詳細の具体化についてさらに知ることができます。物事は具体的かつ明確になるか、少なくともあなたはそれらを強制します。
ちなみに、これも間違っています。「バックエンドシステム全体が完成するまで、ユーザーに役立つものを提供することはできません」。
ビジネスが コンシェルジュサービス テクニックを使用して自動システムへのファサードを構築できるのと同じように、あなたも同じことを実行でき、それでも値を提供します。 「1 + 1」ストーリーが発生し、結果「2」をアサートするある種の自動テストがある場合、静的コードを使用してこれを実装し、テストに合格することができますか？ （ TDDを考えてください 。）最初は二項演算子を使用する必要さえありません。
これを本番環境に完全にデプロイし、製品（Deep Thought）が非常に具体的なクエリからどのように推論して結果を生成できるかを「ユーザー」に示すことができます。 「ハードコードされている」と言う必要はありません。アジャイルな方法で仮定をテストし、タイトなループでフィードバックをキャプチャしようとしています。
これがアジャイルとリーンのすべてです。できるだけ早く学習をキャプチャすることです。これは、可能な限り小さなバッチサイズによって可能になります。このプロセスの結果、無駄が最小限に抑えられます。
「真のアギリスト」というものは存在しないので、自分で定義します。
「真のアギリスト」は、大きな物語が小さな物語で構成されていることを知っています。アジャイルプラクティスは、これらのストーリーをユーザーに関連付け、スプリントの範囲内で完了することができる個々のピースになるまで、これらのストーリーをますます小さなピースに分解することを教えてくれます。
ストーリーがユーザーストーリー、テクニカルストーリー、フロントエンドストーリー、バックエンドストーリー、垂直スライス、水平スライスなどであるかどうかは実際には問題ではありません。重要なのは、大きなジョブを一連の小さなジョブに分割し、それらのジョブに優先順位を付けることです。可能な限りユーザーのニーズに応じて、その過程で絶え間ないフィードバックを得ながら、それらの仕事に取り組みます。
ストーリーはユーザーに関連付ける必要があります。ブラックボックスを構築している場合、顧客は実際にはユーザーではありません。ユーザーストーリーの実際のユーザーは、ボックスを提供しているチームです。
顧客は、質問を送信して回答を取得するためのUIを必要としています。 UI開発者は、質問を送信して回答を取得できるAPIを必要としています。 API開発者は、通信するためのバックエンドが必要です。バックエンド開発者は、知識を保存するためのデータベースを必要としています。テスターは、ソフトウェアをテストできるようにAPIを必要とします。あなたのストーリーは、それらすべてのユーザーのニーズに対応する必要があります。