FPAはアジャイルと互換性がありませんか？
私は現在、アジャイル+スクラムベースのプロジェクトで働いています。私は低レベルのモジュールに取り組んでいます。これは特有の問題につながります。私が行っている作業は、多くの場合、ユーザーストーリーに直接関連付けることはできません。ユーザーストーリーを自分の仕事に直接関連付けることができないため、要件が不明確であるという問題に直面することがよくあります。また、私はスプリントの後半でしか明らかにならないいくつかのことを「見逃す」傾向があります。そして、私のレイヤーの動作を直接テストすることはできません。
同様に、私たちのGUIチームは、マイナーな暗黙の要件を見逃したために多くのバグを生成していました。たとえば、テキストフィールドの幅が予想よりも小さかったなどです。
以前に別のプロジェクトでFPAを使用したことがありますが、要件を原子の細部に分解し、マイナーポイントを明確にして、ポイントをチェックリストとして使用してソフトウェアを構築するのに適した方法だと思います。それが私たちのプロジェクト、特に私のレイヤーに利益をもたらすと本当に感じました。私はチームミーティングでそれを提案しましたが、ドキュメントが関係しているために却下されました。 「賢者」の理論的根拠：FPAはドキュメントが多く、アジャイルは重いドキュメントに眉をひそめます。私は、アジャイルは優れた製品を生産することであり、アジャイルプロセスを成形して欠陥を減らし、優れたコードを生成するプロセスを追加できない場合、それは単に「アジャイル」ではないと主張しました。結局、チームはそれが「アジャイル」ではないと主張して提案を却下しました。しかし、その理由は怠惰である可能性が高いと思います。
関係するドキュメントの量が多いため、FPAは本当にアジャイルと互換性がありませんか？アジャイルマニフェストの高尚な目的はどうですか？それは単に「動作するコード」ですか、それとも「正常に動作するコード」ですか？
これは、誤解を招くSCRUM実装の典型的なケースです。あなた（およびあなたのチーム）は、基本的に、分解の時点から必要な変更に戻るまでこれに従う必要があります（覚えておいてください：SCRUMは適応プロセスであり、レビュー会議の後半は把握するために使用されることになっています次のスプリントでそれをより良く機能させる方法を見つけてください！）。
ブレークダウンのポイントは、明らかにGUIチームによって提起されたすべてのバグです。コードを直接テストできないという事実には、別のブレークダウンポイントがあります。これらは両方とも、ストーリーの定義が不十分であることを示しています。この詳細レベル（テキストフィールドの長さなど）は、事前に行う必要はありません。スプリント中に発生する可能性がありますが、チームメンバーと製品所有者（あなた[〜 ＃〜] do [〜＃〜]製品の所有者がいますよね？）この相互作用が発生した場合、追加のドキュメントは必要ありません。インタラクションが行われない場合、問題が発生し、スクラムマスターが介入する必要があります。
また、あなたの仕事をユーザーストーリーに関連付けることができない場合、製品の所有者は仕事を適切に行っていません。
私は長年SCRUMを使用しており、認定されたSCRUMマスターです。私は経験からあなたに言うことができます、あなたが基本的な原則に従えば、それは美しく働きます。ただし、自分に合ったものだけでなく、[〜＃〜] all [〜＃〜]に従う必要があります（このコンテキストでは、製品の所有者を含むスクラムチーム全体を意味します）。
FPAは必要ありません。スクラムプロセスを修正するだけです。