受け入れ基準なしでソフトウェアをどのように開発しますか？

テスターが何をテストするかを知らず、製品所有者として行動する複数の（2-3）人と、承認基準なしで4-5人の開発者のチームでソフトウェアをどのように共同で開発しますか？

私たちが持っているのは、いくつかのスクリーンショットといくつかの箇条書きを含む大ざっぱな「仕様」だけです。

簡単だと言われているので、これらは必要ありません。

どのように進むべきか迷っています。

追加情報

厳しい締め切りが与えられました。

顧客は社内にいるため、理論上は製品所有者がいますが、ソフトウェアをテストする少なくとも3人が作業項目を失敗する可能性があります。失敗するまで実際にテストしているもの。

製品の所有者は、質問に答えたり、フィードバックを提供したりすることはできません。定期的な会議や電話会議はありません。フィードバックには数日かかる場合があります。

完璧な仕様を作ることはできないことは理解できますが、各スプリントで実際に取り組んでいるものの受け入れ基準を持つことは「普通」だと思いました。

反復プロセスは、詳細な仕様ずに、うまくこれを実現します。

大ざっぱなプロトタイプを作成し、顧客からフィードバックを求め、そのフィードバックに基づいて変更を加え、アプリケーションが完了するまでこのプロセスを繰り返します。

顧客がこの方法でそれを行うのに十分な忍耐力を持っているかどうかは、別の質問です。一部のクライアントと開発者は実際にこのプロセスを好みます。顧客は常に実践的であるため、（最終的に）望みどおりの結果が得られます。

言うまでもなく、このように固定費や固定時間の契約をするつもりはありません。

あなたが言っていることが真実であり、仕様があなたが始めるのに十分なほど近くない場合（そしてこの評価で正直である）、私はこのアプローチをお勧めします：

1. あなたが与えられたスケッチと「スケッチ」仕様を読んでください。
2. コードを作成するのに十分なレベルに独自の仕様を記述します。たくさんの推測をしなければならないかもしれません。
3. レビューのために仕様を顧客に示します。彼らが好きな部分に注意し、あなたが間違っていると思った部分の詳細を入手してください。
4. あなたと顧客が同期するまで、手順2と3を繰り返します。
5. これで適切な仕様ができました。

「簡単になります」と言ったときに顧客が正しかった場合、このエクササイズは簡単です。

顧客が間違っていて、実際にあらゆる種類の落とし穴や要件のギャップがある場合、仕様の草案はすぐに問題を説明し、彼らが間違っていることを伝えます（指を指すか議論する必要はありません）それらの前にいて、明白であること。また、仕様はそれらのあいまいさを解決するための優れたディスカッションツールとして機能し、フィードバックで修正する際の重要な決定の記録として機能します。

製品の所有者からプロトタイプが渡されました。（あなたが完了するまで）彼をより良いものを返します

プロジェクトを開始するための紙のプロトタイプが提供されたようです。それはひどい始まりではありません。漸進的に機能するプロトタイプを提供することにより、同じ言語でビジネスオーナーに連絡することをお勧めします。

プロトタイプは紙で始まり、デジタルモックアップに移行してから、「実際の」テクノロジーで構築する必要があります。

Treehouseには、このための優れたガイドがあります。

フレームワークを使用したプロトタイピングの素晴らしい点は、構造とスタイリングがすでに整っているため、プロトタイプが実際のサイトになることが多いことです。同じフレームワークを使用する場合、最初からサイトを再作成する必要はありません。

特に悪い結果のせいにされるのが心配な場合は、正式な仕様を提供することもできます。しかし、おそらくプロトタイプからより多くのフィードバックを得るでしょう。

締め切りに間に合う

後の努力は、すべてが古典的な「プロトタイプ」ではないことに注意してください。なぜなら、それらは使い捨てではないからです（またはその一部はそうではありません）。期限が成果物になる前に完了する最後の、最も有能な反復。

締め切りは、最も明確に定義された要件です。時間通りに納品できる、完全で一貫性のあるものを用意してください。

テスターと協力する

この緩いプロセスがあなたの会社にとって新しいものであるなら、あなたのテスターはおそらくあなたよりも損失にさらされており、ガイダンスを求めているかもしれません。プロセスの早い段階で時間を割く必要があります。正式な受け入れ基準を受け取らずに意味のあるテストを提供できるように支援していることを上司に伝えてください。

テスターが提供する必要のあるものがあるかどうかを確認します。たとえば、「証明」のドキュメントを「元に戻す」ことができます。

テストファーストデザインを試す

正式な要件はないため、テストケースを開発するために何らかの構造を提供します。

Test First Designおよび/またはテスト駆動開発に十分に精通し、必要に応じてプロセスに関するテスターに​​ガイダンスを提供します。このような簡単なプロジェクトの場合、プロセスの専門家になる必要はありません。しかし、実証済みの方法論を使用することは、あなたとあなたのテスターに​​よく反映されます。

特にUIの標準に準拠

ルックアンドフィールに関する要件はありませんが、期限があります。他の人の設計作業を使用して、プロフェッショナルな外観のアーティファクトを作成するために必要な作業を最小限に抑えます。

サイトの標準UIを選択し、指示が​​ない限り/カスタマイズしないでください。どのプラットフォーム用に開発しているのかわかりませんが、BootstrapまたはGoogle Material Designは2つの例です。

通信するが、せがらないでください

1日に1つのメールを製品所有者に送信することをお勧めします。緊急の場合のみ、それ以上を送信してください。

質問がある場合は、ガイダンスが表示されない場合の手順を説明してください。例えば：

このアプリのユーザーはモバイルデバイスでアクセスする必要がありますか？今のところ、これはデスクトップ/ラップトップのみのシステムになると想定しています。

パニックにならないで

「要件」という用語を知らなかった人々のために、私は多くのプロジェクトに関わってきました。ほとんどは成功しました。手渡しの製品所有者は、優れたソリューションを構築するための自由度を与えてくれます。

これらのプロジェクトのプロジェクトオーナーの一部は、「私は忙しすぎて...」という無能な言い訳の後ろに隠れて隠せませんでした。しかし、ほとんどは最終結果に「喜んで」いました。

プロジェクトとは、確実性が達成されるまで不確実性を減らす行為です。

• 最初は常にある程度の不確実性があります。場合によっては、要件が少しあいまいになります。時々、非常に大ざっぱなものです。あなたは仕事の一部として解決する必要があります。
• 秘Theは、この不確実性を繰り返し分析し（分析、設計、実装を組み合わせて）、ユーザーストーリーを洗練し、システムを実装することです。
• テストケース/シナリオ、および受け入れ基準も同じ方法で明確にする必要があります。（とりわけ）品質と正確性に関する不確実性を減らすことに貢献します。
• 最後に、十分な確実性が得られます。顧客は、ニーズに合った使用可能なテスト済み製品を入手します。

それが漸進的な精緻化の原則です。要件、基準、結果は段階的に精緻化され、開発プロセスへの関与を通じて顧客が自分の期待と要件を理解することも同様です。

これは問題ですか？

初期要件が大ざっぱなほど、不確実性が高くなり、タスクの実行に必要な時間が長くなります。だから、誰が追加の仕事をし、誰が費用を払うのかだけの問題です。

これらの2つの質問の答えは、契約書の中にあるべきです。または交渉の対象となります。そして、顧客は追加の関与を受け入れる必要があります（主な議論は「ガベージイン、ガベージアウト」です。ただし、より外交的な方法で提示することを強くお勧めします;-)）

「定期的な会議はありません」。では、定期的な会議をスケジュールすることから始めてみませんか？複数の製品所有者がいるという事実だけでも、プロジェクトの容易さを保証するものではありません。それぞれの人々は対立する要件を持ち、すべての利害関係者と直接話し合う必要があります。

さらに、詳細な決定ログを保存することをお勧めします。少なくとも、誰かが決定したすべてのものを、日付と決定が行われたときに出席していた人々のリストとともに書き留めてください。何かを決めた理由を書き留めることができればさらに良い。PC上のファイル、イントラネットWikiのページ、またはデスク上のノートブックのいずれでもかまいません。ログはあなたとプロジェクトを保護します：テスターが「失敗」と言ったとき、あなたはこれらの人々とそのように決定されたことを指摘できます。それはあなたの問題ではなく彼らとテスターの間です。これにより仕様が変更される場合は問題ありませんが、現時点では、彼らが念頭に置いていた期限を満たすことは期待できません。

明確な要件、ゆるやかなリーダーシップ、完了（DoD）の定義がなく、仕事をタイムリーに行い、期限を守るために必要な情報を確保する責任を負わないプロジェクトは、プロジェクトのレシピです失敗。

反復的な開発は悪い提案ではありませんが、製品の所有者と開発者の間の緊密な協力が必要です。「私たちは質問があることを知っています。プロジェクトの配信が遅れないように、誰が定期的に質問に答えることができるでしょうか？」と言って、誰かを引っ掛けてみてください。進捗状況を確認し、障害を取り除くために誰かと定期的にスケジュールを組んでください。それらが表示されない、または拒否しない場合は、丁寧な書面による通信および文書の遅延または無応答でフォローアップします。製品の所有者が利用できない場合は、利用可能な代表者を提供するよう依頼してください。

また、反復開発のもう1つの特徴は、要件の変更がタイムラインの変更を必要とすることです。 タイムラインを作成できない場合は、期限に間に合うようにコミットすることはできません。また、何を行う必要があるかについてよくわからない場合は、タイムラインを作成できません。仕様を独断的に尋ねる代わりに、現在の仕様を確認し、あなたまたはチームがそれがどのように機能するかについての質問を文書化し、製品所有者と議論して時間をスケジュールし、答えを文書化します。完了したら、その決定に基づいて仕様を作成し、製品所有者に（書面で）同意してもらうことができます。仕様の目的は、あいまいさを取り除き、DoDを作成することです。これは、Q＆Aセッションで提供できるものです。仕様に反対する場合は、仕様と呼ばないでください。

彼らがそれが簡単だとあなたに言うとき誰も信じないでください。時には実際にそれが思ったほど簡単で、私はこれを信じるならば（とのみの場合）私は完全に要件が本当に彼らは彼らが言うほど単純であることを信頼する十分の製品の所有者、および私がされている仕様を知っています自明です（そうでない場合は、Q＆Aセッションをスケジュールして文書化します）。私はあまりにも多くの状況にあり、運用の観点から簡単にするのが非常に難しい開発の観点から、またはあなたはあなたが完全に完了し、絶望の言葉を聞くと思う（「ああ、ところで、私たちは忘れていた...」）。例...「あなたがしなければならないのは、これらのPDFファイルをドキュメントリポジトリから読み取ることです。」これは、受け入れテスト中に、「ああ、これらの一部が完全に一貫性のない方法で横に読み取られることを忘れていました。間違ったページサイズが定義されているものや、これら3つのページを追加する必要があるもの、すべて同じものを表示する必要があるものがあります。修正は本当に簡単ですか？」

ポイントは、それは本当に簡単かもしれませんが、クイックミーティングでそれを確認でき、すべての仮定を文書化し、それらが正確で正しいことを確認することができます。つま先を踏むかどうかに関係なく、いずれにしても最終的に誰かが不幸になる可能性があるため、期待に応える作業コードを作成する際の障害を取り除くために立ち上がることをお勧めします。質問に回答し、誰かをいらいらさせることに固執している場合、要件を満たす時間通りに優れた製品を提供すると、彼らはそれを忘れます。明確化に失敗して配信しなかった場合、バグを報告しないように言ったことを誰も覚えていないでしょう。

仕様がなければ、チームワークが必要です。アジャイルに行く。

POに座って、いくつかの小さなストーリーを作りましょう。「この画面だけを配信し、このボタンだけが「鳴る！」」一部のACで解決します。ストーリーを伝えます。 ストーリーを実演します。ボタンが赤になっているはずです。バグまたは新しいストーリーを作成します。鳴り響くボタンをお届けします。等々。

頻繁にデモされる小さな垂直スライスを共同で指定して配信します。

この方法で顧客があなたと協力しない場合は、解決策を探してください。

あなたが概説したように、私はいくつかの仕事にプロジェクトを費やしました。POがあなたがどのような設計上の決定を下し、なぜそれをしなければならないのかを知っている限り、あなたは大丈夫です。一方、彼らが設計の決定を理解していない場合は、少なくとも文書化されたユーザー受け入れテスト文書のためにそれらを押す必要があります。

コードの記述を開始するには、詳細で検証可能な仕様が必要です。それは事実であり、それを回避することはできません。

誰もその仕様を書こうとしないなら、開発者はそれを書かなければなりません。そのため、仕様が不完全になります。完全な仕様に変換します（つまり、「これは、他の人から指示されない限り、これを実装するつもりです」という意味です）。その仕様を関係者に渡し、仕様を変更する機会を彼らに与えます。仕様を変更する機会に過ぎません。たとえば、「この方法が気に入らない」と言って仕様を解除しないでください。その時点で、それはあなたの仕様であるか、別の仕様を提供できますが、仕様を削除することはできません。

仕様を改善する可能性のある同僚からすばやくレビューを取得することをお勧めします。しかし、とにかく、仕様があり、それに応じてコードを記述し、テスターがそれに応じてテストします。そして、あなたは仕事をしました：あなたは仕様を持っていて、それを実装しました。仕様が顧客が望んでいるものではない場合、それは製品所有者、または良い仕様を書くことに煩わされることができなかった顧客の責任です。