あるチームで設計し、別のチームでコーディングする

私は、すべてのソフトウェア設計がローカルチームによって行われ、これらの設計がコーディングのためにオフショアチームに送られるプロジェクトに関与します。

この特徴を持つプロジェクトに直面するのはこれが初めてであり、私にとってはちょっと奇妙に感じます。マネージャーは、私たちが非常に詳細な設計文書を作成することを期待しています。私の観点からは、IDEで行うことはできますが、彼らは紙でコーディングすることになります。

だから、私の質問はこのアプローチが良いですか、それとも正しいですか？ソフトウェアプロセスがプロジェクトで成功するために必要な主な考慮事項は何ですか？

私の意見：

オフショアの人々に文書と図表だけを提供すると、多くの誤解と失望が生じます。

私の推薦

• あまり多くのドキュメントを提供するのではなく、インターフェイスと抽象クラスを設計目標に拘束するためにそれらを提供します。

• 既知の命名標準を使用するように要求します。

• ユニットテストの使用を要求します。

• 設計者/アーキテクトの1人を自社の敷地に送り、プロセスを監督します。社内でコーディングするよりも安価ですが、より良い結果が得られます。

これは、ビッグデザインアップフロント、別名ウォーターフォールと呼ばれます。それは非常に成功した方法論として広くみなされていません。しかし、私はそれが動作するのを見てきました、そしてそれが動作するとき、それは非常にうまく動作します。正しく行うのは非常に高価です。

また、あなたの雇用主があなたに何をするように頼んだかです。

オフショアチームは、オンショアチームのようには機能しません。あなたはまさにあなたが望むものについて非常に非常に具体的である必要があります。

最後のプロジェクトは、私がソフトウェアデザイナーでした。すべての開発はオフショアでした。成功しました。したがって、このプロセスは機能します。

私は多くのドキュメントを作成しましたが、決して包括的ではなく、ステップバイステップの指示やクラス名、関数名などの詳細な説明も決してありませんでした。たとえば、シーケンス図、ユースケース、ワークフロー、システム、統合を作成しましたダイラグラム、および必要に応じてより詳細な設計ドキュメント。

それは、オフショア開発をどれだけ信頼するかにかかっています。オフショアチームが有能な開発者であると信じています。とはいえ、全体的な方向性を示しましたが、オフショアチームが満足のいくものであると判断した実装の余地を与えました。以前は、より細かく管理されていました。特定の状況では、必要に応じて設計パターンを使用してガイドします。また、私は定期的に彼らが書いたコードのコードレビューと分析を実施し、リファクタリングやクリーンアップの努力を勧めました。また、一部のチームがRVで事故を起こしたため、いくつかのリソースが不足していたため、実装中にストーリーの一部をコーディングすることになりました。

また、このプロセスは、プロジェクトのテクニカルリードの強さと、ビジネス、デザイナー、リード、開発者間のコミュニケーションでのみ成功すると思います。私たちはそれぞれの機能とストーリーについて多くの時間を費やし、オフショアのリード/リソースが要件を熟知していることを確認しました。機能/ストーリーのレビュー中に質問をしていない場合は、いくつかの問題が予想されます。また、業務はサインオフするまで完了したとは見なされませんでした。そのため、すべてがアジャイル開発を管理するツールで追跡されていたため、全員に説明責任が与えられました。

他の答えの1つがすでに示唆しているように、開発プロセスには命名基準（リシャーパールールが組み込まれています）、テストケースカバレッジ（TDD、モッキングなどを使用）が含まれていたため、適切なコーディングプロセスと手順がある場合は増加しますプロジェクトを成功させるチャンス。

オフショア開発の主要なコストはコミュニケーションです。ドキュメントはコミュニケーションの1つの方法ですが、ドキュメントは通常、すべての詳細と潜在的な変更をカバーすることはできません。

プロジェクトの大きさがわからない。それ以外の場合はオフショア開発チームを使用する価値がないと思います。したがって、私の経験は

1. スケルトンコード、パブリックインターフェイス、サービスインターフェイスなどを定義し、一緒にレビューする
2. 反対側で受け入れテストを定義する
3. 大きなドキュメントを小さなストーリーに分割し、小さなストーリーに基づいて作業します。大きなドキュメントは、システム全体の単なる全体像です
4. ストーリーのチェックポイントを1週間または2週間設定します

1と2は実際には開発に関するもので、反対側が要件を十分に理解し、両方が同じパターンを使用していることを確認します。3と4はアジャイル開発の方法論の一部ですが、オフショア開発では、完全なアジャイルプロセスを使用することは困難です。

ある程度、私たちは皆そのように働くと思います。誰かが何かを設計し、システムの一部であるか、システムで動作する何かをコーディングします。例は、モバイルデバイス上のゲーム以外のアプリのような、フレームワークに基づいたアプリの構築です。多くのUIの決定は、フレームワークを構築した人々の設計チームによって行われました。彼らは、アプリの作成からアプリの販売まで、すべてを制御しました。このモデルが成功した理由を知りたい場合は、一部のベンダーから提供されているドキュメントとツールの量を見てください。

別の例は、RESTスタイルを実装しようとする多くのWebアプリケーションです。HTTPの使用方法に関する仕様がある場合でも、これは実際に何かを実装する方法を教えません。とにかく、従うべき仕様と指針があります。stackexchangeまたは職場でのREST実装についての議論をたくさん見ると、ある特定の方法で何かを実装するように人々に伝えるアーキテクトがいるようなものです。それはまだ成功したモデルであり、非常に多くの人々がスタイルに従っていると思います。

これらの2つの例から、デザインがどのように伝播されるかを見ることができます。一部は紙の仕様であり、他は書籍、ツール、およびサンプルが付属しています。人々がどのように求めているのかを（ボリュームで）見ることができ、彼らが従おうとしている基準/設計に応じて、さまざまな程度で理解を正しくしようとします。stackoverflowに行き、見てください;）

仕様を教えてください。単体テストを提供していただければ、コーディングとテストを行います。