コーディングの前に機能を知ることはどのくらい重要ですか？
私は開発作業がオフショアされているソフトウェア開発会社で働いています。オンショアチームがサポートを担当し、クライアントと直接話します。クライアントと直接話をすることはありません。オンショアチームのクライアントと直接話をするだけです。
要件が発生すると、オンショアチームがクライアントと話し合い、要件のドキュメントを作成して通知します。要件を検討した後、設計ドキュメントを作成します（従来のウォーターフォールモデルに従います）。
しかし、プロセス全体に1つの問題があります。オフショアチームまたはオンショアチームの誰もアプリケーションの機能を完全に理解していません。私たちは、複雑な注文処理、カタログ管理、キャンペーン管理、その他のアクティビティを処理する大きな複雑なWebアプリを知っています。要件が明確ではないため、設計ドキュメントに取り組んでいます。次に、オンショアチーム、オフショアチーム、クライアントの間で一連の質問/回答を行ったり来たりします。コードから機能を理解するように言われることがよくあります。しかし、コードベースが巨大であり、単純なメニュー項目を理解することさえ、数週間ではなくても数日かかるため、通常、それは現実的ではありません。アプリケーションについてナレッジトランスファーを提供するようクライアントに指示しましたが、役に立ちませんでした。設計ドキュメントが完全でない場合や要件が明確でない場合でも、マネージャーからコーディングを開始するよう指示されることがよくあります。明確に見える要件の一部をコーディングすることから始めて、残りを待ちます。
これは通常、展開を1か月遅らせます。極端なケースでは、開発と本番環境でのエラーは非常に少なくなりますが、クライアントはそれを求めていなかったと言います。それは非難ゲームと一連の変更リクエストを開始し、私たちは非常に異なる何かを開発することになります。
私の質問は、アプリの機能を完全に知らない場合、どのように開発作業を行うかです。
[〜＃〜]更新[〜＃〜]
開発の方法論は本当に私の選択ではなく、私のチームのリーダーではありません。それはそれが始まった方法です。アジャイルの利点について人々に伝えようとしたが、役に立たなかった。その上、私のチームはアジャイル環境で作業するために必要な考え方を持っているとは思いません。
ショートバージョン：
何をすべきかを知る≠顧客を知る。
これを想像してみてください。あなたは不動産開発に関連する会社です。パートナーに大規模な複合施設を建設するよう依頼します。パートナーは、あなたが彼に与えたすべての文書にもかかわらず、この複合施設でアパートを購入する人々と直接話し合う必要があると言います。マジ？
ロングバージョン：
物事を学ぶのは楽しいので、特定のアプリケーションがどのように使用されるかを知ることは常にいいことですが、大規模なプロジェクトでは常に可能であるとは限りません。
一部のドメインは複雑すぎる。あなたが開発者であり、複数のドメインからの複数のアプリケーションで作業している場合、あなたは常に何が目的かを理解することができないユーザーがやっている、それはあなたが会計を学ぶのに5年、医学部で10年、法律学校で6年などを費やす必要があるからです。
一方、特定のドメインを理解せずに作成されたソフトウェア製品は、せいぜい、少し使用できなくなります。
このため、機能要件と非機能要件は、ドメインを完全に理解している人が作成する必要があります。一般に、要件の収集には同時に以下が含まれます。
技術者（たとえば、特定の機能は不可能であり、この方法でこれを行うとはるかに優れている可能性があり、はるかに安価な代替手段がある一方で、この機能は数千ドルの費用がかかると言う開発者）、
プロジェクト管理を専門とする人々、
顧客のドメインに特化した人々、このドメインと顧客の正確なニーズを完全に理解している。もちろん、これは顧客そのものかもしれません。
機能的要件と非機能的要件の1つが記述され、十分に正確です。それらの要件をコードに変換する作業を行う人として、他に必要なものはありません。
特定のケースについては、問題の原因を自分で説明します。
要件が明確ではないため、設計ドキュメントに取り組んでいます。
すべての問題を引き起こすのは顧客に関する知識の欠如ではありません、それは要件の質の低さです。正しく管理されたプロジェクトでは、機能要件と非機能要件は完全に明確で明確でなければなりません。要件ドキュメントが明確でない場合、または「製品の視覚的なデザインは魅力的でなければならない」またはそのような他の愚かさを示している場合、それはそれを書く方法を知らない人々によって書かれたためです。
それを知って、あなたは違った行動をしなければなりません：
要件を収集するチームが絶望的であり、自分のチームが要件を収集するための熟練した人材を持っていることがわかっている場合は、状況を上司に説明し、他のチームを有能な誰かに置き換える必要があることを伝えます、たとえば、あなたの人たち。
それ以外の場合（つまり、彼らが絶望的でない場合）、それらの低い要件の内部原因を特定してみてください彼らの仕事を正しく行うとプロジェクトの全体的なコストが削減されるだけであることを彼らに伝えます。ここでは、不適切に記述された要件がコストにどの程度影響したか（どのくらいですか）と、期限に間に合わないリスクがプロジェクトにどのように影響したかについての統計を表示することをお勧めします。
おそらく、要件ドキュメントは不完全です。私はこれをいつも見ています。経験の浅いプロジェクトマネージャーは、1ページのドキュメントで十分であると確信しているだけで、なぜ1ページではなく300〜400ページを書くのか理解していません。自社に当てはまる場合は、要件により多くの時間を費やすとコストが削減されることを示します。
あなたが直面している問題に対して、まったく間違った開発方法論を使用しています。
ウォーターフォールを使用することで、次のことにコミットします。
- 適切な要件を事前に取得する-これは明らかに機能していません
- 顧客から離れて要件をコーディングする-要件への開発に専念していると、顧客との問題を効果的にチェックすることができません
- お客様が機能を確認する最初のチャンスはテスト中です-発生している問題を考えると、これは遅すぎます
可能であれば、別の方法でプロジェクトを管理することを検討してください。 アジャイルソフトウェア開発 には、直面している問題に取り組むために設計されたいくつかの機能があります。
Waterfall vs Agile のまともな比較はしばらく前に書かれましたが、そこからいくつかの引用を取り、あなたの問題を強調します：
マークがありません：
ウォーターフォール方式でステージが完了すると、ウォーターフォール方式で設計および実装されたほとんどのソフトウェアは時間とユーザーのニーズに応じて変更することが難しいため、後戻りすることはできません。この問題を修正するには、前に戻って、まったく新しいシステムを設計する必要があります。これは、非常にコストがかかり、非効率的な方法です。
縛られ...
アジャイル方式では、エンドユーザーの要件に従って仕様を変更できるため、顧客満足度を高めることができます。すでに述べたように、ウォーターフォール方式を採用している場合、変更を加えるとプロジェクトを最初からやり直す必要があるため、これは不可能です。
...そして移動できません
2つの違いを概説すると、アジャイル方法論は適応性を表す一方で、古典的なウォーターフォール手法は予測可能性を表していると言えます。アジャイル手法は、理論的根拠、正当化、文書化、会議などのオーバーヘッドを減らし、可能な限り低く保つのに優れています。そして、それがアジャイル手法が、大規模なプロジェクトよりも、常に変化する要件を持つ小さなチームに利益をもたらす理由です。
あなたが今いる場所は悪いです。あなたは顧客の要求に応えていません。そして、もしあなたがソフトウェア開発の責任の部分にいるなら、生産性は窓から出て行き、不信は高まり、そして物事は悪化し、良くはないでしょう。
顧客との関係はcritical;ここでは、問題を効果的に収集して、現在の作業方法で変化する要件に適応することができないようです。したがって、それを変更する方法を検討する必要があります。
それはそれが機能する方法ではありません。私の現在の教育の主題の1つは、分析と、顧客との関係です。プロジェクトを明確に定義することに常に重点が置かれています。これを想像してみてください：
- あなたは家を建てるように建築会社に注文しましたが、あなたがそれがどのように見えるかを知りません。 1階をカスタマイズするだけで、チームは1階まで家を建てます。次に、1階のレイアウトを変更します。おっとっと...
アプリケーションの（部分的に）正しい基盤を作ることができると確信がない限り、明確に定義された目標と機能を使用する以外にそれを行う方法はないとクライアントに伝えます。それは、それが何であるかを突き刺すだけの場合、大量のお金を投じて時間を浪費するリスクがあるからです。