複雑な処理を伴うアプリケーションにアジャイルを適用するにはどうすればよいですか？
アジャイルに関する文献のほとんどは、裏で起こっていることをユーザーがかなり意識しているCRUDタイプのビジネスアプリケーションに偏っているようです。 （書かれているコードのほとんどはおそらくこのクラスに属しているので、それは問題ありません。）
このタイプのアプリケーションの場合、ユーザーストーリー（要件）と開発タスクの関係はほとんど単純です。ユーザーストーリーをいくつかのタスクに分割するだけです。
しかし、ほとんどのコードがユーザーには直接見えない複雑な処理を処理しなければならない別のタイプのアプリケーションがあります。例は次のとおりです。
- コンパイラ
- 自動運転車の画像解析システム
- 流体シミュレーションシステム
ここでは、タスクとユーザーストーリーを関連付けるのが非常に難しくなる可能性があります。この問題を克服するためのテクニックはありますか、それともそれを受け入れて最大限に活用する必要があるものですか？
これは私が計画したよりも長いことがわかりました（コメントとして始まっていました）が、追加された長さ/詳細が役に立ち、あなたがそれらが正当であることを願っています。
アジャイルはCRUDアプリに固有ではありません
アジャイルに関する文献のほとんどは、裏で起こっていることをユーザーがかなり意識しているCRUDタイプのビジネスアプリケーションに偏っているようです。 （書かれているコードのほとんどはおそらくこのクラスに属しているので、それは問題ありません。）
これは、この種のシステムを対象とした方法論ではなく、このタイプのわかりやすい例を作成する方が簡単だからだと思います。それほど簡単ではない例を作成すると、読者がアジャイルの概念について読者に教えることになっているときに、読者がその例を理解しようとして行き詰まってしまう危険があります。
ユーザーストーリー！=要件
このタイプのアプリケーションの場合、ユーザーストーリー（要件）と開発タスクの関係はほとんど単純です。ユーザーストーリーをいくつかのタスクに分割するだけです。
ユーザーストーリーは要件と同じではありません。確かに、要件がどの程度「高レベル」であるかに応じて、一部が重複する可能性がありますが、通常は同じではありません。私の以前のマネージャーの多くが陥った同じ落とし穴に遭遇しているような印象を受けます。ユーザーストーリーを単に「要件」の同義語と考えます。これは、SVNユーザーがGitに移行しようとする場合と同様ですが、 SVNの観点から考えます。 （その後、悪い前提条件のために問題が発生します。）
IMHO、要件とユーザーストーリーの主な違いは、要件が特定のシステムコンポーネントの動作方法を詳細に指定することです。それらは、入力、出力、仮定/前提条件、発生する可能性のある例外などを含む仕様です。彼らはsystemが行います。
OTOH、ユーザーストーリーは、システムコンポーネントの詳細な動作仕様を作成することなく、エンドユーザーに期待される結果に焦点を当てています。彼らは期待されるユーザーエクスペリエンスに重点を置いています。
私が以前使用していたこと、これは私のチームが採用した習慣であり、ユーザーストーリーをタスクに分解することでした。あなたのタスクは、あなたが望む/必要とするのと同じくらい具体的または曖昧なものである可能性がありますが、それらは、ストーリーを完了状態にするために行われた実際の作業の進行状況を示すためのものでした。
例
ユーザーがテストケースを自分で割り当てて、重複する作業を回避するために作業しているTCをチームの全員が認識できるようにする必要があった、何年も前に取り組んだ米国を大まかに思い出しました。 UIは（n内部の）Webアプリケーションでした。ユーザーはボタンしか見ませんでしたが、ストーリーはいくつかの技術的な実装の詳細などを含むいくつかのタスクに分割されました。
ユーザーの可視性
しかし、ほとんどのコードがユーザーには直接見えない複雑な処理を処理しなければならない別のタイプのアプリケーションがあります。
何らかの方法でユーザーに表示することは可能ですか？
GPSについて考えてみましょう。順番を逃した場合、実際のルートの再計算プロセスは表示されませんが、ユーザーはいくつかの有用なフィードバックを受け取ります（例：「再計算しています...」）。
コンパイラーは警告やエラーを表示したり、GUIに新しい設定/オプションを含めたりして、ユーザーが新しい何かが追加されたことを確認できます。コンパイラのユーザーはプログラマだと思いますよね？新しい標準のサポートが追加されたと思いませんか？
新しい標準をサポートすることはおそらくfeatureレベルであり、ユーザーストーリーに分解する必要がありますが、必ず、少なくとも一部のケースでは、代わりに機能を使用する必要があるときにストーリーを使用しようとしないのですか？
車内での画像分析は、自動車事故に至る可能性が低減されたことをユーザーに知らせる方法で表現できます。例えば：
自動運転車の乗客として、私がより安全に移動できるように、認識されていない物体に衝突することによって事故を引き起こす車両の確率ができるだけゼロに近い必要があります。
米国は、セキュリティ、安全性など、機能的要件と非機能的要件の組み合わせを使用して通常指定する必要があることを高レベルで捕捉します。
ただし、要件はシステムについての詳細かもしれません。例えば。：
コンポーネントabcの関数Aは、ゆっくりと移動するオブジェクトをより適切に検出するために、画像比較アルゴリズムで許容しきい値を下げる必要があります。
私にとって、これは上記のユーザーストーリーの下でtaskになりやすく、次のようなタイトルが付けられます。関数の許容度を下げるA.abc次に、その他の関連する詳細を含めます。
流体シミュレーションシステムの場合、システムが実行しているバックグラウンドタスクに関するフィードバックを提供するプログレスバーを使用することもできます。 （スパム行為を避けたい場合もありますが、ユーザーに何かを通知する方法は常にあります。）
私があなたが述べた特定のドメインについて十分に知らないので、より良いまたはより現実的な例を思い付くことができますが、ここでのテイクアウェイがある場合、目に見えないものについてユーザーフィードバックを提供するためにさまざまな方法を使用できます。システムが実行している可能性があります。つまり、目に見えないものをもう少し目に見えるようにする方法があるかもしれません。 （結局のところ、あなたの努力などにより、システムのパフォーマンスがどれだけ速くなったかを文書化した一連のリリースノートを書くことになったとしても）
ストーリーとタスクの関係
ここでは、タスクとユーザーストーリーを関連付けるのが非常に難しくなる可能性があります。
私たちのアプローチは、ユーザーストーリーをwhatリクエストに焦点を合わせ続けることでした、whyそれが行われたこと、および米国が「完了した」と見なすために何がtrueになる必要があるかhowは常に米国から除外され、開発者に任されていました。
開発者は、米国で説明されている問題をtheyが取り組む一連のタスクに分解します。
これは、ほとんどの場合、バックエンドのサーバー側プログラミングを行った人物と言っています。これは、エンドユーザーが入手できるように「目に見えない」可能性があります。
必要な作業に応じて、AJAXを使用して単純な「読み込み中...」のアニメーション/ gifを表示し、ユーザーが何か他のものを待つ必要があることをユーザーが知っているようにします間違った印象を与えることなく完了することができます。これはこれほど単純な場合もありました。このためのタスクが適切です。
異なるパラダイム、実践、経験
この問題を克服するためのテクニックはありますか、それともそれを受け入れて最大限に活用する必要があるものですか？
パラダイムシフトを受け入れ、実践し、蓄積された経験を超えて、おそらく言うまでもありません。私は多くの人がプロセスを介して近道をしようとしているのを見ました。私はそれに対してアドバイスをします、あなたが始めているなら特に。より多くの経験を積むにつれて、ある程度の柔軟性を可能にすることができますが、自分自身を損なうことは避けてください。
以前の言い回しを考えると、ストーリーは「要件の名前が変更された」ものであるかのように考えています。これは誤った仮定だと思います。これは、アジャイルアプローチと非アジャイルアプローチの根本的な違いに関するより深い問題の症状だと思います。
第2に、アジャイルはウォーターフォールと比較してパラダイムシフトであることを受け入れる必要があると思います。つまり、プロセスには同様の目標がありますが、非常に異なる方法で。 （それが役立つ場合は、SVN対Gitを考えてください。）
要件とユーザーストーリーの概念的な違いについての現在の理解を深め、それらが同じものではないことを受け入れてください。
スプリントから学ぶ-回顧
私が十分に強調できないのは、各スプリントの終わりにスクラムマスターと開発者の間の回顧です。それは、彼らが「うまくいった」または「うまくいかなかった」ことを正直/透明な方法で話し合う場所であり、何ができるかが変わる「うまくいかなかった」点に対処する次のスプリントのために実装されます。
これにより、お互いの経験に適応し、さらにはそれを学ぶことができました。そして、それを知る前に、チームの速度の全体的な一貫性から判断すると、大幅に改善されていました。
アジャイルの原則は確かにこれらの場合に適用できます。どうやって？
- コンパイラーは、後で別のユーザー・ストーリーに追加される新しい言語機能を持つことができます
- 画像分析システムは、異なる画像分類として追加された新しい機能を備えている場合があります
- 流体シミュレーションシステムは、シミュレーションでさまざまなモデルの側面を考慮することができます
ゾウ全体を一度に食べる必要はありません。アジャイルは、次の象のサービングの前に皿を洗ったことを示すように要求するだけです。
ユーザーストーリーに厳密に準拠している人は、バックエンドの技術的な変更がユーザーに影響を与える方法を思い付くという非常に愚かな演習に従事していることがわかります（もちろん、それらは単なる素朴なので、ユーザーにはわかりません）ユーザーとあなたはあなたのデータ分析パイプラインまたはその種の何かの複雑な変更について話している）または彼らは「この作業をどのように組織することができるのか！？！」
私は明白な解決策はより実用的であることだと思います。仕事が本質的に非常に技術的であり、ユーザーに特に顕著な影響を与えない場合は、その方法を説明するために眠りに落ちないでください。ユーザーにメリットをもたらす明白でシンプルな方法を選択し、開発者が仕事をするのに必要な詳細に沿ってストーリーを方向付けてください。絶対に必要なときに、POが技術情報をストーリーに含めないように要求すると、それは信じられないほどイライラします。それは、そのアーティファクト（ストーリー）が実際に何であるかについての全体論的な見方ではありません。彼らは自分たちのためだけに存在すると考えているように、ほとんどの場合、エンジニアにとっても重要です。
これらの技術的なタスクのほとんどについて、ユーザーへの影響に関して、効率が向上して将来の配信がより高速になり、パフォーマンス、信頼性などが向上するかどうかについて、いくつかの懸案事項があります。それらは、「ユーザーストーリー」を考えるときに実際に人々が考える傾向があるものではありませんが、企業が技術的負債またはそのために何かを行う理由を理解したい場合、これらの説明は通常、最も簡単に提供できます。
tl; drは、スクラムナジが適応するには四角形が大きすぎるという理由だけで、あなたの人生を特別に困難にしないでください。適応性は、結局のところ、アジャイルのコアコンセプトです。スクラムまたはアジャイルの厳格な遵守は、通常、顔または実用主義と実用性（実際に最も効果的に機能するもの）を飛ばします。
問題は、ユーザーストーリーに彼らが持っていない意味を与えることにあると思います。スクラムでは、PBI、または製品バックログアイテムという用語を使用しています。 PBI will多くの場合、ユーザーストーリー形式に従います。たとえば、「サブスクライバーはサブスクリプションの詳細を表示できるはずです」のようなPBIがあるかもしれませんが、「作成」のようなPBIも同じくらい簡単にあるかもしれません。サブスクライバーの詳細を取得するためのストアドプロシージャ」。
ユーザーストーリーはtoolです。これらは、ユーザーの立場に立って機能の説明や要件を作成するのに役立ちます。しかし、写真を掛ける必要があるときにレンチが役に立たないのと同じように、ユーザーストーリーが必要ない場合があります。
とはいえ、多くのチームは実際には「ユーザー」の部分で速くてルーズにプレーします。 「開発者は、ストアドプロシージャを呼び出してサブスクライバーの詳細を取得できるようにする必要があります」などの「ユーザーストーリー」があり、基本的には「開発者ストーリー」です。これも同様に有効なオプションですが、個人的には、何をする必要があるかを説明し、一連の承認基準を考え出せる限り、実際のユーザーストーリーがあるかどうかは問題になりません。