要件収集ミーティングに参加する開発者にとって理想的な考え方は何ですか？
私はチームの中間レベルの開発者として、自分が参加するプロジェクトの要件収集/スコープ計画ミーティングに参加しています。ディスカッションや私の知識に付加価値を与える質問を考え出すのは難しいと感じてきました。いくつかの自己分析の後、議論をリードするプロジェクトを担当する上級エンジニアがいることを知っていると、私はこれらの議論のいくつかでのんびりさせられたことがわかりました。しかし、私は自分にもっと責任を任せ、自分でプロジェクトを処理するスキルを身につけたいと思っています。考え方とは少し抽象的な質問ですが、以下に挙げるいくつかのことについてアドバイスをお願いします。
これらの会議を最大限に活用するには、どのような準備が必要ですか。チームメンバーからの観察から、プロジェクトがどのようなシステムに影響を与えるか、どのようなビジネス上の決定がプロジェクトの設計に大きな影響を与えるかなどを理解していることに気づきました。
すべての要件について、低レベルの実装の詳細について考えることを避ける必要がありますか？一方で、実現可能性について知ることになるので、それらを検討することの重要性を感じますが、すべての選択肢を検討することの妨げになることも理解しています。
最後に、開発者として、私が心配してはいけないことは何ですか？
質問に順番に答える：
- 準備に関してこれに入る考え方は、ユーザーが正確に何を望んでいるかを知ることができるように適切な質問をすることです。これは思ったよりずっと難しいです。私は強調する必要があります正しい質問をする。具体的に説明してください。あいまいな点がある場合は、別の質問をしてください。通常、これらの会議中に、クライアントからの1つの回答が3つの新しい質問を生成します。彼らが何を望んでいるかがわかったら、それが彼らのシステムではなく、さまざまなシステムにどのように影響するかを理解するのはあなたの仕事です。
不可能であるという要件に関してクライアントが望むものがあれば、それを伝えます（私の教授はこれを「車の翼」と呼んでいました）。場合によっては、クライアントがソフトウェアを十分に理解していないため、機能を知ることができません。回避してください。
いいえ、それは設計段階で発生します。機能しない場合は、要件が再検討されます。
間違いなく最初から正しく理解する必要はありません。機能のクリープ、クライアントが新しいことを望んでいるが、あなたには決して言わないなどによって、要件は常にめちゃくちゃになっています。
ほとんどの場合、ユーザーは日々の作業と、解決する必要のある問題を正確に把握しています。彼らが通常知らないのは
a）ソフトウェアがそのプロセスをサポートするために正確にどのように見える必要があるか。
b）彼らがあなたに彼らのプロセスをどのように説明できるか。
質問に焦点を当てて、ユーザーが本当に何を望んでいるか（その目標、作業プロセス）を理解し、ボタンを青、赤、ダイアログボックスの左側または右側。 anyのあいまいさを明確にすることはあまり重要ではないことがよくありますが、右側あいまいさを明確にします。
「低レベルの詳細」について：会議中は避けてください-多くの場合、同じ目標を達成するためのさまざまな解決策があり、さまざまな低レベルの詳細、さまざまなコスト/開発努力、さまざまな実現可能性があります。私の経験では、要件について（ミーティングの後で！）しばらく考え、後で要件を徹底的に分析したときに、実行可能な解決策を提案する方がはるかに優れています。
そして、特定の要件に対する潜在的な開発作業について心配しないようにしてください（少なくとも、ミーティング中は）。すべての要件を書き留めるだけでは、それらを1対1で実装する必要があるという意味ではありません。会議後、あなたまたはチームはそれらを分析し、実装の見積もり（おそらく、同じ要件に対して考えられるさまざまなソリューションに対して異なる見積もり）を行う機会を得ます。その後、要件に優先順位を付けたり、再度検討したりします。あなたが避けるべきであるのは、たとえ彼らがあなたにプレッシャーをかけたり要求したりしたとしても、会議中にあなたの胃からの推定を人々に伝えることです。 「後でお答えします」と言ってください。
要件収集を行う際に強調したいのは、これが既存のシステムの置き換えである場合、既存のシステムでの方法を考えるのではなく、何をすべきかを達成するための理想的な方法は何かということです。
そのため、多くの場合、ユーザーは物事のやり方に行き詰まり、その方法で自分のニーズを説明することしかできません。
実装者としてのあなたにとって最も重要なことは、彼らが本当に達成しようとしていることを理解することです。ビジネス分析の方法を学んでいるときに私を助けた1冊の本 Software Requirement Patterns この本では、見落とされがちな暗黙の要件のいくつかをより深く理解する方法について説明します。
また、 ドメイン駆動設計 は、（特に ユビキタス言語 の概念を使用して）学習するのに適した本です。開発者が話す」というのは翻訳で失われてしまいます）。
重要なもう1つの項目は、ターゲットドメインについてできるだけ早く知識を得ることです。私が物流会社のために開発したとき、荷主、共同荷受人、責任当事者、トラックロード未満、ハブ、ドック、およびビジネスとインテリジェントに会話するために知っておく必要があるその他すべてについて学んだと信じています。私は石油会社で働いていたとき、ボアズ、ウェルズ、フィールズ、アウトプット、サチュレーション、およびその業界に関連するすべての楽しいことについて時間をかけて学びました。
それは私が与えることができる最も価値のあるアドバイスです。ソフトウェアを開発している業界を学び、ユーザーからより良い要件を収集することができます。