requirements - 低摩擦 最小要件の収集

Question

私たちのチームは、どのようにして「プロダクト オーナー」から要求を収集し、摩擦をできるだけ少なくしながらも使いやすい方法で収集できるでしょうか?

ここにガイドラインがあります-それができない、またはビジネスが品質を気にするという決定を下す必要があるという投稿はありません、やだやだ。私が働いている製品は、何年にもわたって成功を収めてきた小さなグループです。私は彼らがそれを一段と高めるのを手伝いたいだけです。

基本的に、私は 1 人のプロダクト オーナーを含む 6 人か 7 人のチームに所属しています。彼女は素晴らしい仕事をしていますが、いくつかの異なる役割をこなしています (非常に小さなチームではよくあることだと思います)。通常、要件は散発的に与えられます (電子メールのやり取り、対面でのディスカッション、ミーティングなど)。それらはシステムに入力されることはなく、必要な機能を誰もが忘れたため、機能がリリースされなかったり、リリースが延期されたりすることがあります。

似たような状況で、これを克服する方法を見つけた場合は、ぜひお知らせください。この状況を緩和するためのコードを喜んで書きますが、プロダクト オーナーが何かを成し遂げるために行かなければならない Web サイトにはなりません。彼女は非常に忙しいので、これらの要件を収集するためにチームとして協力する方法が必要です。

私は現在、次のようなことを考えています: 開発者とチーム メンバーは、面と向かって議論された要件を収集し、wiki ページで議論された機能について簡単なメモを書きます。これらのページが更新されるたびに製品所有者に通知され、正確性を確保する責任は製品所有者にあります。

長所: 機能の記録がいくつかあります。短所: 開発者は、通常なら責任を負わないことに対して責任を負うことになります。私はここでそれで大丈夫です。こういう時こそチームワークだと思います。

もちろん、これを行うと、製品所有者が機能の正確さを保証するのに十分な時間がないことがわかります。最終的に彼女は過負荷であり、これはその事実を示すのに役立つと思いますが、最初にそのことに注意を引くことができる必要があります.

提案はありますか？

PS 彼女の時間は非常に限られているため、話し合いの後に要件を入力する必要があると期待するのは合理的ではないと考えられます。彼女には、それらについて一度話し合って先に進む時間しかありません。

Answer 1

「プロダクト オーナー」という概念は私には少しあいまいですが、私は非常に似たような状況で働いていると思います。顧客は非常に忙しく、常に要件を開発する際のボトルネックです。

表面的には、この状況で私たちがやろうとしていることは非常に明白で、一見単純に見えます: 私たちは、顧客が「読み取り専用/会話専用」モードに関与していることを確認しようとします. 書き込みなし。最低限の読書。話すことがほとんどです。

もちろん、悪魔は細部に宿る。そのため、ここに私たちのプロセスに関するいくつかの詳細があります（順不同）：

• 多くの場合、要件の最終的なソースである問題ステートメントの記録から開始します。実際、失われないようにするために、最初に記録するのは問題ステートメントだけである場合があります。

  注意:問題の記述と要件を区別することが重要です。問題ステートメントは、ある要件を明確に暗示している場合もありますが、一般に、1 つの問題ステートメントから多数の要件 (それぞれに重大度と優先度があります) が生じる場合があります。さらに、特定の要件によって、複数の問題に対する解決策 (通常は部分的な解決策) が定義されることがあります。

  問題記述を記録する主な理由の 1 つ (そしてこれはあなたの質問に非常に関連しています! ) は、意味的にそれらが「顧客の肌に近い」ものであり、それらから派生した要件よりも安定しているためです。私は、これらの問題ステートメントにより、顧客が開発チームにフィードバックを提供する時間があるときはいつでも、顧客を適切なコンテキストに導くことがはるかに簡単かつ迅速になると信じています.

• いつ実装するかに関係なく、すべての要件を記録します (そして、それらを問​​題ステートメントに戻します) 。優先順位は、要件が実装される順序を管理します。もちろん、顧客が未完成の要件をレビューする順序も管理します。

  注意: すべての要件を含む単一の分厚いドキュメントは、絶対にダメです! すべての要件は、バグ レポートと共に「問題追跡データベース」に配置されます。(バグは、私たちの本の問題の特殊なケースです。)

• 私たちは常に、各要件 (または関連する要件のグループ) を「完成させる」ために必要な反復回数を最小限に抑えるために最善を尽くします。理想的には、顧客は要件を 1 回だけ確認する必要があります。

  最初のレビューが不十分であることが判明した場合 (常に発生します)、問題の要件が複雑で多くのテキストやイラストが必要な場合は、お客様が最初からすべてを読み直す必要がないようにします。傷。前回の改訂版以降のすべての重要な変更/追加/削除が強調表示されています。

  問題または要件が未完成の状態のままである間、すべての未解決の問題 (主に顧客への質問) がドキュメントに埋め込まれ、強調表示されます。その結果、顧客が要件を確認する時間があるときはいつでも、会議を招集してチームに質問を求める必要はありません。代わりに、顧客は最初に未完成のドキュメントを開き、何が期待されているかを正確に確認してから、未解決の問題に対処するための最善の方法と時間を (顧客にとって) 決定することができます。場合によっては、顧客が電子メールを書いたり、問題のドキュメントに直接コメントを追加したりすることを選択することがあります。

• 公式のドメイン語彙を確立して維持するために最善を尽くしています(ドキュメント全体に散らばっていても)。最も重要なことは、実際にお客様にその語彙に固執するように強制することです。

  注:これはプロセスの中で最も難しい部分の 1 つであり、顧客は時々「反抗」しようとします。しかし、結局のところ、それが顧客との貴重な会議を可能な限り効率的にする唯一の方法であることに誰もが同意しています. 1 時間の会議に出席し、30 分かけて全員が同じページに (再び) 参加したことがある場合は、語彙があればありがたいと思うでしょう。

  注意:可能な限り、公式語彙の変更はソフトウェアの次のリリースに反映されます。

• 場合によっては、特定の問題が複数の方法で解決できる場合があり、顧客に相談しないと正しい選択は明らかではありません。これは、顧客が選択できる「要件のメニュー」があることを意味します。最終的に選択された要件だけでなく、そのような「メニュー」を文書化します。

  これは議論の余地があり、不必要なオーバーヘッドのように見えるかもしれません。ただし、このアプローチにより、顧客 (通常は数週間または数か月後) が突然、「なぜあの方法ではなく、この方法を行ったのか?」などの質問に飛びつくたびに、多くの時間を節約できます。また、要件ドキュメントの適切な構成/フォーマットを使用して「拒否されたブランチ」を非表示にすることは、それほど大したことではありません。退屈だが実行可能。:-)

  注:「要件のメニュー」を作成するときは、無理をしないことが非常に重要です。選択肢が多すぎるか、選択肢のネスト レベルが多すぎます。次のレビューでは、実際に必要以上に顧客の時間が必要になる場合があります。精巧な枝に費やされた時間が完全に無駄になることは言うまでもありません。はい、ここである程度のバランスを見つけるのは困難です (常に急いでいる顧客が、2 つ以上のステップを先に考えて迅速に実行する能力に大きく依存します)。しかし、私は何を言うことができますか？あなたが本当に自分の仕事をうまくやりたいのなら、しばらくすると適切なバランスが見つかると確信しています。:-)

• 私たちの顧客は非常に「視覚的」な人です。したがって、重要なユーザー インターフェイス要素について議論するときはいつでも、画面のモックアップ(または軽量のプロトタイプ) が非常に役立つことがよくあります。時々リアルタイムセーバー！

  注:話し合いを容易にする目的でのみ、お客様専用の画面モックアップを作成します。開発者も使用できますが、決してユーザー インターフェイス仕様の代わりになるものではありません。多くの場合、書面で指定される非常に重要な UI の詳細がいくつかあります (現在は主に開発者向けです)。

• 幸運なことに、非常に技術的なバックグラウンドを持つお客様がいます。そのため、UML ダイアグラムをディスカッションの補助として使用することを躊躇しません。あらゆる種類の UML 図 - 顧客が適切なコンテキストをより迅速に把握し、そこにとどまるのに役立つ限り。

  もちろん、要件レベルの UML ダイアグラムについて話しています。実装レベルのものではありません。あまり技術的な人でなくても、遅かれ早かれ要件レベルの UML 図を掘り始めることができると思います。辛抱強く、図に何を載せるべきかを知っている必要があります。

明らかに、このようなプロセスのコストは、チームの分析スキルと執筆スキル、そしてもちろん自由に使えるツールに大きく依存します。そして、私たちの場合、このプロセスは非常に高価で時間がかかるように見えることを認めなければなりません. しかし、バグの発生率が非常に低く、「蒸気機能」の発生率が低いことを考慮すると... 長期的には、非常に良い見返りが得られると思います。

FWIW: Joel のソフトウェア製品の優れた分類によると、このプロジェクトは「内部」プロジェクトです。そのため、お客様が処理できる限り機敏に対応する余裕があります。:-)

Answer 2

「開発者とチーム メンバーは、直接会って話し合った要件を収集し、簡単なメモを書きます。」

それから始めましょう。メモを取っていない場合は、小さな変更を 1 つ加えてください。メモする。後で、それらを wiki に投稿したり、機能のバックログを作成したり、スクラムやバグジラなどを使い始めたりするかもしれません。

ただし、最初に小さな変更を加えます。何かを書き留めることは、あなたがしていないことのように聞こえるので、それを実行して、何が改善され、次に何ができるかを確認してください。アジャイルであること。段階的に作業します。