製品バックログと巨大な機能
私はアジャイルプロセスで製品を設計して文書化しています。ユーザーストーリーを書いて製品バックログに追加すると、複雑で巨大な機能に気づきました。
これらの機能を製品のバックログに書き込んで、優先順位に従って注文する必要がありますか、それとも私の計画を混乱させて、私の製品が期待したものから逸脱する可能性がありますか？
数年間アジャイルで仕事をしてきた私の個人的な見方は、（ある程度まで）大きなバックログを恐れるべきではないということです。
自己完結型のユーザーストーリーを作成している場合、それぞれが実質的に完全なものであり、実際に優先度で並べ替えるだけで済みます。新しいストーリーがリストに追加されても、物事は「複雑」にならないはずです。リストが膨大な場合。
人々がバックログが「大きすぎる」と考え始めると、彼らが実際に意味する傾向があるのは、あいまいで、時代遅れで、無関係であるか、または混乱しているアイテムであって、単にリストとしてそれを考える能力を失っていることです。自己完結型の作品の優先順位で並べ替えられたものです。あるべきではない何か。
多くの場合、これはバックログを叙事詩に分類したり、一種の「カテゴリスプリント」（しばしば「雑多」や「調整が必要」などと呼ばれる）として現れたりしますが、これは問題を隠すだけであり、不適切なことの根本的な問題としてさらに複雑さを追加しますバックログへの継続、およびこれらのカテゴリのスプリントに隠されたものが複製されます。
これはあなたではないかもしれませんが、上記のように聞こえてきたら、プロセスにバックログを使用できないと感じたという事実は、何らかの理由で組織がバックログを使用していないことを示していると考えることもできます。その意図された目的のために、これは混乱と無秩序を生み出しています。
tl; dr
これらの機能を製品バックログに書き込んで、優先順位に従って注文する必要がありますか、それとも私の計画を混乱させて、私の製品が期待したものから逸脱する可能性がありますか？
詳細の作成に多くの時間を費やさないでください。お客様とソリューションを開発しているお客様と継続的にコラボレーションします。
アジャイルという用語をどのように理解していますか？単一のアジャイルプロセスはありません。 アジャイルソフトウェア開発のマニフェスト の4つの値と12の原則によって記述される哲学を支持するプロセス、フレームワーク、方法論、フレームワークなどがあります。 「アジャイル」は3回しか使用されておらず、そのすべてが説明する形容詞として使用され、名前の名詞として使用されていないことに注意してください。
その基盤により、質問のフレージングにいくつかのレッドフラグがあります。大きな設計と多くのドキュメント（伝統的な計画主導のプロジェクト管理）を通じてそれをすべて前もって理解しようとするという問題のあるパラダイムが、「ソフトウェア開発のより良い方法を発見する」ことがマニフェストをもたらした理由です。
- 問題の解決に役立つスキルを持つ個人を集める
- 取り組み全体を通して、お客様と協力して問題を理解し、新しいソリューションがどれほど効果的であるかを理解する
- 必要なサポート、トレーニング、リソース、その他の人員配置などを提供する
- 小さな反復サイクルで作業し、さらに学習し、現在のソリューションが評価されるにつれて、ソリューションを増分します。
詳細については、 The Scrum Guide および Extreme Programming を参照してください。どういうわけかウォーターフォールSDLCモデルにつながる 大規模ソフトウェアシステムの開発の管理 という論文は、図2を超えて読まれたことはないようです。