あるチームで設計し、別のチームでコーディングする
私は、すべてのソフトウェア設計がローカルチームによって作成され、これらの設計がコーディングのためにオフショアチームに送信されるプロジェクトに関与します。
これが私がこのような特徴を持つプロジェクトに直面するのは初めてで、私にとっては少し奇妙に感じます。マネージャーは、非常に詳細な設計ドキュメントを作成して、オフショアチームにエラーの余地がないように期待しています。私の見解では、彼らは私たちがIDEでそれをすることができる間、彼らを私たちに紙でコーディングさせています。
それで、私の質問は、このアプローチが良いのか、それとも証明されているのでしょうか？私たちのソフトウェアプロセスがプロジェクトで成功するために必要な主な考慮事項は何ですか？
私の意見：
あなたがオフショアの人々に与えるすべてがドキュメントとダイアグラムであるならば、あなたはたくさんの誤解と失望を持つでしょう。
私の推薦
あまり多くのドキュメントを渡さないでくださいインターフェイスと抽象クラスそれらを設計目標に拘束する。
既知の命名基準を使用するように要求します。
ユニットテストを使用するように要求します。
設計者/建築家の1人をオフショアの施設に派遣してプロセスを監督します。社内でコーディングするよりもコストはかかりませんが、より良い結果が得られます。
ビッグデザインアップフロント、別名ウォーターフォールと呼ばれています。それは非常に成功した方法論として広く考えられていません。しかし、私はそれが機能するのを見てきました。正しく行うには非常に費用がかかります。
それはまたあなたの雇用主があなたに何をするように頼んだかです。
オフショアチームは、オンショアチームのようには機能しません。あなたはあなたが望むものについて正確に非常に具体的でなければなりません、そうでなければあなたはあなたが望むものを得ません。
最後のプロジェクトはソフトウェアデザイナーでした。すべての開発はオフショアで行われました。私たちは成功しました。したがって、このプロセスは機能します。
私はたくさんのドキュメントを作成しましたが、それは決して包括的ではなく、決してステップバイステップの説明やクラス名、関数名などの詳細ではありませんでした。たとえば、シーケンス図、ユースケース、ワークフロー、システム、および統合を作成しましたダイアグラム、および必要に応じてより詳細な設計ドキュメント。
それは本当にあなたがオフショア開発をどれだけ信頼するかにかかっています。私のオフショアチームは有能な開発者であると信じています。そうは言っても、私は全体的な方向性を提供しましたが、オフショアチームが満足できる満足のいく実装をする余裕を彼らに与えました。以前は、それらはより細かく管理されていました。特定の状況では、必要に応じて設計パターンを使用してそれらをガイドします。また、私は定期的にコードのレビューと彼らが書いたコードの分析を行い、リファクタリングやクリーンアップの取り組みをアドバイスしました。また、一部のチームにはレクリエーション用車両で事故が発生したため、一部のリソースが不足したため、実装中にストーリーの一部をコーディングしてしまいました。
さらに、このプロセスは、プロジェクトの技術リーダーの力と、ビジネス、デザイナー、リード、および開発者間のコミュニケーションでのみ成功すると思います。私たちは、各機能とストーリーの調査に多くの時間を費やし、オフショアのリード/リソースが要件の内容に精通していることを確認しました。機能/ストーリーのレビュー中に質問をしていない場合は、いくつかの問題が予想されます。また、業務が承認されるまで、作業は完了したとは見なされませんでした。つまり、アジャイル開発を管理するツールですべてが追跡されていたため、誰もが責任を負うようになりました。
他の回答の1つがすでに触れたように、開発プロセスには命名標準（組み込みのリシャーパールール）、テストケースのカバレッジ（TDD、モッキングなどを使用）が含まれていたため、適切なコーディングプロセスと手順があれば、それが増加します。プロジェクトを成功させるチャンス。
オフショア開発の主なコストはコミュニケーションです。ドキュメンテーションはコミュニケーションの1つの方法ですが、ドキュメントは通常、すべての詳細と潜在的な変更をカバーすることができません。
プロジェクトの規模がわからない。それは大きいと思いますが、そうでなければオフショア開発チームを使用することは価値がありません。したがって、私の経験は
- スケルトンコード、パブリックインターフェイス、サービスインターフェイスなどを定義し、一緒に確認する
- 反対側で受け入れテストを定義する
- 大きなドキュメントを小さなストーリーに分割し、小さなストーリーに基づいて作業します。大きなドキュメントは、システム全体の全体像にすぎません
- ストーリーのチェックポイントを1週間または2週間設定する
1と2は実際には開発に関するものであり、反対側が要件を十分に理解し、両方が同じパターンを使用していることを確認します。 3と4はアジャイル開発方法論の一部ですが、オフショア開発の場合、完全なアジャイルプロセスを使用することは困難です。
私たちはある程度そのように働いていると思います。誰かがどこかで何かを設計し、システムの一部であるか、システムと連携する何かをコーディングします。例としては、モバイルデバイス上のゲーム以外のアプリなど、フレームワークに基づいてアプリを構築する場合があります。 UIの多くの決定は、フレームワークを構築した人々の設計チームによって行われました。彼らはアプリの書き方の学習からアプリの販売まですべてを管理していました。このモデルが成功した理由を知りたい場合は、一部のベンダーから提供されているドキュメントとツールの量を見てください。
別の例は、多くのWebアプリケーションがRESTスタイルを実装しようとしていることです。これは、HTTPの使用方法に関する仕様がある場合でも、実際の実装方法を示していません。とにかくは、従うべき仕様と指針です。REST stackexchangeや職場での実装についての議論が多い場合、建築家が特定の方法で何かを実装するように指示するアーキテクトがいるようなものです。それでもまだ成功したモデルだと思います。
これら2つの例から、デザインがどのように伝播されるかを確認できます。一部は紙の仕様で、他は本、ツール、例が付属しています。人々がどの基準/設計に従っているのかによって、さまざまな程度で理解を深めようとする（ボリュームで）人々がどのように尋ねているかを見ることができます。ただstackoverflowに行き、見てください;）
ご指定頂ければお願い致します。ユニットテストを提供していただければ、コーディングとテストを行います。