私は、外部委託されたいくつかのプロジェクトで開発者またはチームリーダーとしての経験があり、すべてのケースで優れた結果は得られていません。これらのプロジェクトのほとんどは、大規模なキックオフミーティング、数か月にわたる要件収集フェーズ、多数の電話会議、および無数の電子メールを含む、ウォーターフォール哲学を採用しています。私がいつもイライラしていることの1つは、コードへの早期アクセスがないことです。契約は、オフショアチームが機能要件を満たす責任がある方法で設定されます。これは経営幹部が懸念していることです。ただし、これは、アーキテクチャの決定、実装の詳細、パターンの使用法、および他の開発者に関係する事項が、製品が提供されるまでに非常に深く解決されているため、フィードバックを提供したり、実際の変更を要求したりできないことを意味します。
ここで、これらの問題を経験していないオフショアプロジェクトを管理している人はいますか?具体的には、オフショアチームがより短いサイクルで作業し、オンショア開発者からのフィードバックに基づいてリファクタリングまたは再設計するように契約を構成する方法があるかどうか疑問に思っています。私はアジャイル方法論についてあまり経験がありませんが(一般原則には同意しますが、方法論が定着している保守的なショップで働いています)、これらを何らかの形でオフショア開発の管理に役立てることができるかどうか疑問に思います。全体として、私は、開発チームが一度に数か月間孤立して作業することを余儀なくされたときに必然的に発生する驚きとメンテナンスの悪夢を最小限に抑えることを目指しています。
私はそれをしました、そして私はそれを好みます。契約は、固定入札ではなく、時間と材料に基づいている必要があります。固定入札は理論的にはベンダーにリスクをもたらし、より競争力のある価格になる可能性がありますが、実際には、変更管理の定義などをめぐる争いは言うまでもなく、あなたが説明するようなはるかに多くの作業が必要になります。タスクごとに作業を割り当てて、より動的に作業します。ただし、スクラムには参加していません。彼らを代表するオンショアリードがあります。本質的に、オンショアは3人の仕事をしているように見えますが、彼はオフショアにタスクを分割しています。オンショア/オフショアモデルでは、明らかにオンショアの人との料金が高くなります。