コーディングの前に機能を知ることはどのくらい重要ですか？

私は、開発作業がオフショアされているソフトウェア開発会社で働いています。オンショアチームがサポートを担当し、クライアントと直接話します。クライアントと直接話をすることはありません。オンショアチームのクライアントと直接話をするだけです。

要件が発生すると、オンショアチームがクライアントと話し合い、要件ドキュメントを作成して通知します。要件を検討した後、設計ドキュメントを作成します（従来のウォーターフォールモデルに従います）。

しかし、プロセス全体で1つの問題があります。オフショアチームまたはオンショアチームの誰もアプリケーションの機能を完全に理解していません。私たちは、複雑な注文処理、カタログ管理、キャンペーン管理などのアクティビティを処理する大きな複雑なWebアプリを知っています。要件が明確ではないため、設計ドキュメントに取り組んでいます。次に、オンショアチーム、オフショアチーム、クライアント間で一連の質問/回答を行ったり来たりします。コードから機能を理解するように言われることがよくあります。しかし、コードベースが巨大であり、単純なメニュー項目を理解することさえ、数週間ではなくても数日かかるため、通常、それは現実的ではありません。クライアントに知識を伝えるよう伝えましたアプリケーションについてですが、役に立ちません。設計ドキュメントが完全でない場合や要件が明確でない場合でも、マネージャーからコーディングを開始するように指示されることがよくあります。要件の明確な部分をコーディングすることから始めて、残りの部分を待ちます。

これは通常、展開を1か月遅らせます。極端なケースでは、開発と本番環境でのエラーは非常に少なくなりますが、クライアントはそれを求めていなかったと言います。これは非難ゲームと一連の変更要求を開始し、非常に異なる何かを開発することになります。

私の質問は、アプリの機能を完全に知らない場合、どのように開発作業を行うかです。

更新

開発の方法論は本当に私の選択ではなく、私のチームのリーダーではありません。それはそれが始まった方法です。アジャイルの利点について人々に伝えようとしたが、役に立たなかった。その上、私のチームはアジャイル環境で作業するために必要な考え方を持っているとは思いません。

短縮版：

何をすべきかを知る≠顧客を知る。

これを想像してみてください。あなたは不動産開発に関連する会社です。あなたはパートナーに大きな複合施設を建てるように頼みます。パートナーは、あなたが彼に与えたすべての文書にもかかわらず、この複合施設でアパートを購入する人々と直接話し合う必要があると言います。マジ？

ロングバージョン：

学ぶことは楽しいので、特定のアプリケーションの使用方法を知ることは常に良いことですが、大規模なプロジェクトでは常に可能であるとは限りません。

一部のドメインは複雑すぎる。あなたが単なる開発者であり、複数のドメインの複数のアプリケーションで作業している場合、エンドユーザーが何をしているかを常に理解することはできません。会計を学ぶのに5年、医学部で10年を費やす必要があるからです。ロースクール等で6年

一方、特定のドメインを理解せずに作成されたソフトウェア製品は、せいぜい少ししか使用できません。

このため、機能要件と非機能要件は、ドメインを完全に理解している人が作成する必要があります。一般に、要件の収集には同時に以下が含まれます。

1. 技術者（たとえば、特定の機能は不可能であり、この方法でこれを行うとはるかに優れている可能性があり、この方法ははるかに安価な代替手段がある一方で数千ドルの費用がかかると言う開発者）、

2. プロジェクト管理を専門とする人々、

3. 顧客のドメインに精通し、このドメインと顧客の正確なニーズを完全に理解している人々。もちろん、これは顧客そのものかもしれません。

1つの機能的要件と非機能的要件が記述され、十分に正確です。これらの要件をコードに変換する作業を行う人として、他に必要なものはありません。

特定のケースについては、問題の原因を自分で説明します。

要件が明確ではないため、設計ドキュメントに取り組んでいます。

すべての問題を引き起こすのは、顧客に関する知識の欠如ではなく、要件の質の低さです。正しく管理されたプロジェクトでは、機能要件と非機能要件は完全に明確で明確でなければなりません。要件ドキュメントが明確でない場合、または「製品の視覚的なデザインは魅力的でなければならない」などの愚かさを示している場合、それは、それを書く方法を知らない人々によって書かれたためです。

それを知って、あなたは異なった行動をしなければなりません：

• 要件を収集するチームが絶望的であり、自分のチームが要件を収集するための熟練したスタッフを持っていることがわかっている場合は、状況を上司に説明し、他のチームを有能な誰か、たとえば自分のチームに置き換える必要があることを伝えます。

• それ以外の場合（つまり、彼らが必死ではない場合）、それらの低い要件の内部の原因を特定し、正しく機能することでプロジェクトの全体的なコストが削減されるだけであることを説得してください。ここでは、不適切に書かれた要件がコストにどの程度影響したか（どのくらいですか）とプロジェクトの締め切りに間に合わないリスクについての統計を表示することをお勧めします。

おそらく、要件ドキュメントは不完全です。私はいつもこれを見ています。経験の浅いプロジェクトマネージャーは、1ページのドキュメントで十分であると確信しているだけで、なぜ1ページではなく300〜400ページを書くのか理解していません。自社に当てはまる場合は、要件により多くの時間を費やすとコストが削減されることを示します。

あなたが直面している問題に対して、まったく間違った開発方法論を使用しています。

ウォーターフォールを使用することで、次のことにコミットします。

1. 適切な要件を事前に取得する-これは明らかに機能していません
2. 顧客から離れた要件をコーディングする-要件への開発に専念した場合、顧客との問題を効果的にチェックすることはできません
3. 顧客が機能を確認する最初の機会はテスト中です-あなたが抱えている問題を考えると、これは遅すぎます

可能であれば、別の方法でプロジェクトを管理することを検討してください。アジャイルソフトウェア開発には、直面している問題に取り組むために設計されたいくつかの機能があります。

ウォーターフォールとアジャイルの適切な比較はしばらく前に書かれましたが、そこからあなたの問題を強調するいくつかの引用を取りましょう：

マークがありません：

ウォーターフォール方式でステージが完了すると、ウォーターフォール方式で設計および実装されたほとんどのソフトウェアは時間やユーザーのニーズに応じて変更することが難しいため、後戻りすることはできません。この問題は、前に戻ってまったく新しいシステムを設計することによってのみ解決できます。これは、非常にコストがかかり、非効率的な方法です。

縛られ...

アジャイル方式では、エンドユーザーの要件に従って仕様を変更できるため、顧客満足度を高めることができます。すでに述べたように、ウォーターフォール方式を採用している場合、変更を加えるとプロジェクトを最初からやり直す必要があるため、これは不可能です。

...そして移動できません

この2つの違いを簡単に説明すると、アジャイル方法論は適応性を表す一方で、古典的なウォーターフォール手法は予測可能性を表すと言えます。アジャイル手法は、理論的根拠、正当化、文書化、会議などのオーバーヘッドを減らし、可能な限り低く保つのに優れています。そして、それがアジャイル手法が、大きなプロジェクトよりも、常に変化する要件を持つ小さなチームに利益をもたらす理由です。

あなたが今いるところは悪いです。あなたは顧客の要求に応えていません。そして、もしあなたがソフトウェア開発の責任の部分にいるならば、生産性は窓から出て行き、不信は高まり、そして事態は悪化するかもしれませんが、良くはありません。

顧客との関係は重要です。ここでは、問題を効果的に収集し、現在の作業方法で変化する要件に適応できないようです。したがって、それを変更する方法を検討する必要があります。

それはそれが機能する方法ではありません。私の現在の教育の主題の1つは、分析と、顧客との関係です。プロジェクトを明確に定義することに常に重点が置かれています。これを想像してみてください：

• あなたは家を建てるように建築会社に注文しましたが、それがどのように見えるか知りません。1階をカスタマイズするだけで、チームは1階まで家を建てます。次に、1階のレイアウトを変更します。おっとっと...

アプリケーションの（部分的に）正しい基盤を作成できると確信がない場合は、明確に定義された目標と機能以外に方法がないことをクライアントに伝えます。それは、それが何であるかを突き刺すだけの場合、大量のお金を投じて時間を浪費するリスクがあるからです。

問題を克服するのに役立ついくつかのものがあります：

1. 2つのチーム間のコミュニケーションを改善します。要件を3ワードに圧縮するように他のチームに依頼すると、プログラマーはそれらのワードを正確に実装します。言葉は正しい必要があります。それらの言葉なしでは何も実装されません。すべての単語が2000行のコードを提供します。新しい単語が判明すると、実装が始まります。
2. プログラマが単語をすぐに理解できない場合、プログラマは単一の質問をすることができます。質問は正しいものでなければなりません。すぐに答えが必要です。答えは世界の反対側からの往復を待つことはできませんが、事前に知っておく必要があります。回答を受け取った直後に実装が始まり、回答はレターに続きます。
3. 実装中に不明瞭またはあいまいな要件がある場合、それらを解決する方法は、最初に（既存の）3ワードを調べることです。それでも不明な場合は、プログラマーが可能な限りの推測を行います。このプロセスの遅延は絶対に禁止されています。そして、他のチームに助けを求めることはそれを解決する正しい方法ではありません-彼らはすでに正しい3ワードを決定することによって要件を変更するチャンスを持っていました。
4. 結局のところ、要件がまだ不明確であるか、実装が不可能な場合は、問題を引き起こした3つの単語を拒否して、次の単語に移動するのが正しい方法です。拒否された単語は収集されて他のチームに渡され、システムに再入力する前に単語を修正する必要があります。単語を拒否すると、常に締め切りが厳しくなり、実装を再度計画する必要があります。
5. チームは、拒否された単語の数に基づいて評価する必要があります。要件が実装された後、それは永久に修正され、変更できなくなります。すでに実装されている機能を変更しようとしても、拒否されます。
6. 質問の実際の問題は、より多くの情報が実装を容易にすることを前提としていることです。本当じゃない。もっと自由あなたのプログラマが持っている、簡単に実装。要件を圧縮することで、プログラマが実行できることを制限しすぎずに、大量の情報を伝達できます。