受け入れ基準なしでソフトウェアをどのように開発しますか？
テスターが何をテストするのかを知らずに、製品の所有者として複数（2〜3人）が協力して、受け入れ基準なしで4〜5人の開発者のチームでソフトウェアを共同開発するにはどうすればよいですか。
私たちが持っているのは、いくつかのスクリーンショットといくつかの箇条書きを含む大まかな「仕様」です。
簡単になるので、これらは必要ありません。
どうすればいいのか途方に暮れている。
追加情報
厳しい締め切りが与えられました。
顧客は内部にいて、理論的には製品の所有者がいますが、ソフトウェアをテストする少なくとも3人の人が作業項目に失敗する可能性があります。失敗するまで実際にテストしているもの。
製品の所有者は、質問に答えたり、フィードバックを提供したりすることができません。定期的な会議やそれらとの電話はなく、フィードバックには数日かかる場合があります。
完璧なスペックはあり得ないことは理解できますが、各スプリントで実際に取り組んでいるものの受け入れ基準があることは「普通」だと思いました。
反復プロセス は、詳細な仕様なしでこれをうまく実現します。
簡単なプロトタイプを作成し、顧客にフィードバックを求め、フィードバックに基づいて変更を加え、アプリケーションが完了するまでこのプロセスを繰り返します。
顧客がこのようにそれを行うのに十分な忍耐強いかどうかは別の問題です。一部のクライアントと開発者は実際にこのプロセスを好みます。顧客は常に実地にいるので、（最終的に）彼は欲しいものを正確に手に入れます。
言うまでもなく、この方法で固定費または固定時間の契約を結ぶつもりはありません。
あなたが言っていることが真実であり、仕様があなたが始めるのに十分に近いところにない場合（そしてあなたはこの評価で正直なところです）、私はこのアプローチをお勧めします：
- あなたが与えられたスケッチと「スケッチ」仕様を読んでください。
- 独自の仕様を、コードを記述できるように ちょうど十分 のレベルに記述します。あなたは大量の推測をしなければならないかもしれません。
- 仕様をお客様に見せてレビューしてもらいます。彼らが好む部分に注意してください、そしてあなたがそれをあなたが間違っていると思った部分についてのより多くの情報を入手してください。
- あなたとお客様が同期するまで、手順2と3を繰り返します。
- これで十分なスペックが得られました。
「簡単になるだろう」と顧客が言っていたのが正しかった場合、この演習は簡単なはずです。
顧客が間違っていて、実際にあらゆる種類の落とし穴や要件にギャップがある場合、ドラフト仕様は問題をすぐに説明し、間違っていることを（指を向けたり、議論したりすることなく）伝えます。それらの真正面にあり、明白です。また、仕様はこれらのあいまいさを解決するための優れたディスカッションツールとして機能し、フィードバックで修正する際の重要な決定の記録として機能します。
製品の所有者から試作品が渡されました。より良いものを彼に手渡す（あなたが完了するまで）
プロジェクトを開始するための紙のプロトタイプが提供されたようです。それはひどい始まりではありません。徐々に対応できるプロトタイプを提供することで、同じ言語でビジネスオーナーに連絡することをお勧めします。
プロトタイプは紙から始まり、デジタルモックアップに移り、次に「実際の」テクノロジーで構築する必要があります。
Treehouse はこのための優れたガイドを持っています。
フレームワークを使用したプロトタイピングのすばらしい点は、構造とスタイルがすでに整っているため、プロトタイプが実際のサイトになることがよくあることです。同じフレームワークを使用する場合、サイトを最初から再作成する必要はありません。
特に悪い結果のせいにされることを心配している場合は特に、正式な仕様も提供したいと思うかもしれません。しかし、おそらくプロトタイプからより多くのフィードバックを得るでしょう。
締切に間に合います
後の作業は、使い捨てではないため（またはそれらの一部ではないため）、従来の「プロトタイプ」ではないことに注意してください。締め切りが成果物になる前に完了する最後の最も有能な反復。
あなたの締め切りはあなたが持っている最も明確な要件です。時間どおりに提供できる、完全で一貫性のあるものを用意します。
テスターと協力する
この緩いプロセスが会社にとって新しいものである場合、テスターはおそらくあなたよりもさらに困窮しており、ガイダンスのためにあなたを探している可能性があります。あなたはプロセスの早い段階で彼らの時間のいくらかを得なければなりません。正式な承認基準を受け取らずに有意義なテストを提供できるように支援していることを上司に伝えます。
テスターが提供する必要のある確固たる資料があるかどうかを確認します。たとえば、「証明」文書など、「戻る」ことができます。
試すTest First Design
正式な要件がないため、テストケースを開発することで、いくつかの構造が提供されます。
Test First Design および/または test駆動開発 に精通し、必要に応じてプロセスについてテスターにガイダンスを提供します。このような迅速なプロジェクトでは、プロセスの専門家になる必要はありません。しかし、実績のある方法論を使用すると、あなたとあなたのテスターによく反映されます。
特にUIについては、標準に固執する
ルックアンドフィールに関する要件はありませんが、期限はあります。他の誰かの設計作業を使用して、プロ並みのアーティファクトを作成するために必要な作業を最小限に抑えます。
サイトの標準UIを選択し、指示がない限り、カスタマイズしないでください。どのプラットフォーム用に開発しているのかはわかりませんが、 Bootstrap または Google Material Design はその2つの例です。
コミュニケーションはするが、困らない
1日に1通は製品の所有者にメールを送信することをお勧めします。緊急の場合にのみ、それ以上を送信してください。
質問がある場合は、ガイダンスを受け取らなかった場合の対処方法を説明してください。例えば：
このアプリのユーザーはモバイルデバイスでアクセスする必要がありますか？現在、これはデスクトップ/ラップトップのみのシステムになると想定しています。
慌てないで
「要件」という用語を知らない人のために、私は多くのプロジェクトに参加してきました。ほとんどが成功した。手作業の製品所有者は、優れたソリューションを構築するための自由度を提供します。
これらのプロジェクトの一部のプロジェクトオーナーは、満足することが不可能であり、無能であることを理由に「忙しすぎて...」という言い訳に隠れていました。しかし、ほとんどが最終結果に「喜んで」いました。
プロジェクトは確実性が達成されるまで不確実性を減らす行為です：
- 最初は常にある程度の不確実性があります。場合によっては、要件が少しあいまいになることがあります。時々、それは非常に大ざっぱなものです。あなたは仕事の一環として運動しなければならないでしょう。
- 秘訣は、この不確実性（分析、設計と実装の組み合わせ）を繰り返し減らし、ユーザーストーリーを洗練し、システムを実装することです。
- テストケース/シナリオ、および受け入れ基準も同じ方法で明確にする必要があります。それらは、（とりわけ）品質と正確さに関する不確実性の低減に貢献します。
- 最後に、十分な確実性が得られます。顧客は自分のニーズに適合し、使用できるテスト済み製品を入手します。
それが段階的精緻化の原則です。要件、基準、結果は段階的に詳細化され、顧客が開発プロセスに関与することで顧客の期待と要件を理解できるようになります。
これは問題ですか？
初期要件のスケッチが粗いほど、不確実性が高くなり、タスクの実行に必要な時間が長くなります。したがって、それは、誰が追加の作業を行い、誰が費用を支払うかという問題です。
これらの2つの質問の答えは契約書にあるはずです。または交渉の対象となります。そして、顧客は追加の関与を受け入れる必要があります（主な議論は「ガベージイン、ガベージアウト」ですが、より外交的な方法で提示することを強くお勧めします;-)）
「定期的な会議はありません」。さて、あなたはなぜ定期的な会議をスケジュールすることから始めますそれではどうですか？複数の製品所有者がいるという事実だけで、プロジェクトは容易ではないことが保証されます。これらの人々はそれぞれ、存在するすべての利害関係者と直接話し合わなければならない矛盾する要件があるからです。
さらに、私は本当に、本当に、本当にお勧めします詳細な決定ログを保管してください。最低限、誰かが決定したすべてのことを、日付と、決定がなされたときに存在していた人々のリストとともに書き留めます。あなたが何かがそれがそうであった方法が決定された理由を書き留めることができればさらに良いです。 PC上のファイル、イントラネットWiki内のページ、または机上のノートブックのいずれであってもかまいません。ログはあなたとプロジェクトを保護します。テスターがいくつかの項目を「失敗」と言うとき、これらの人々と一緒にそのように決定されたことが指摘できます。それはあなたの問題ではなく、彼らとテスターの間の問題です。これが仕様の変更につながる場合は問題ありませんが、現時点では、彼らが考えていた期限に間に合わせることができないか、またはどこかでスコープを削減する必要があります。
明確な要件のないプロジェクト、ゆるいリーダーシップ、完了の定義（DoD）、タイムリーな方法で仕事をして会うために必要な情報を持っていることを確認する責任がある人their締め切りは、プロジェクト失敗のレシピです。
反復的な開発は悪い提案ではありませんが、製品の所有者と開発者の間の緊密な協力が必要です。 「質問があることは承知しております。プロジェクトの配信が遅れないように、誰が定期的に回答してくれるのでしょうか？」進捗状況を確認し、障害を取り除くために、誰かと定期的にスケジュールを立てます。表示されない場合、または拒否された場合は、丁寧な書面による連絡と文書の遅延または応答がないことをフォローアップします。製品の所有者が対応できない場合は、対応できる代表者を提供するよう依頼してください。
また、反復的な開発のもう1つの特徴は、要件の変更によりタイムラインの変更が必要になることです。次の場合は、締切に間に合わせることができません。タイムラインを作成することはできません。また、何をする必要があるのかがよくわからなければ、タイムラインを作成することはできません。独断的に仕様を尋ねる代わりに、現在の仕様を確認し、それがどのように機能することになっているのかについてあなたやチームが持っている質問を文書化し、製品所有者と話し合って時間を計画し、回答を文書化します。完了すると、それらの決定に基づいて仕様が作成され、製品の所有者に同意してもらうことができます（書面）。仕様の目的は、あいまいさを取り除き、DoDを作成することです。DoDは、Q＆Aセッションが提供できるものです。仕様に反対がある場合は、仕様と呼ばないでください。
彼らがあなたに言ったときに誰も信じないでくださいそれは簡単です。時々それは本当に簡単なことであり、私はこれを信じるかもしれませんif（そしてifのみ）私は、要件が本当にあることを完全に信頼できるほど十分に製品の所有者を知っています彼らが言うように単純であり、私が提供した仕様は一目瞭然です（そうでない場合は、Q＆Aセッションをスケジュールして文書化します）。操作の観点からeasyが信じられないほど難しい状況が多すぎます-）開発の観点から、または完全に完了したと思い、絶望の言葉を聞く（「ああ、ところで、私たちは忘れていた...」）。例...「あなたがしなければならないのは、これらを読むことだけですPDFファイルをドキュメントリポジトリから取り出します。」これは、受け入れテスト中に、「ああ、これらの一部が読み取られたことを忘れていました完全に一貫性のない方法で横向きに、いくつかは間違ったページサイズが定義されており、いくつかはこれらの3つのページを追加する必要があり、すべてを同じように表示する必要があります。それは本当に簡単に修正できますよね？」.
重要なのは、それは本当に簡単かもしれないし、簡単なミーティングでそれを確認できるので、すべての仮定を文書化し、それらが正確で正しいことを確認することができます。つま先を踏むかどうかに関わらず、結局誰かが多分不幸になるので、期待に応える実際のコードを書く必要がある障害を取り除くために立ち上がることをお勧めします。質問への回答を得続け、誰かを苛立たせている場合、要件を満たす優れた製品を予定どおりに納品すると、彼らはそのことを忘れてしまいます。説明が得られず、配信しなかった場合、バグを報告しないように言われたことを誰も覚えていないでしょう。
仕様がなければ、チームワークがあります。アジャイルに移動します。
POに腰を下ろし、いくつかの小さな開始ストーリーを具体化します。 「このボタンだけを押して、この画面だけを配信します。」一部のACで解決します。ストーリーを伝えます。 Demonstrateストーリー。ボタンが赤くなっていることがわかります。バグや新しいストーリーを上げてください。ボンとバンのボタンをお届けします。等々。
頻繁に示される小さな垂直スライスを共同で指定して提供します。
お客様がこの方法で対応しない場合は、解決策を探します。