プロジェクトを体系的に引き渡す方法は？
少し前に、オンショアチームから私たちのチーム（オフショア）にプロジェクトを引き継いでいます。しかし、引き継ぎのプロセスに問題がありました。
膨大な量の情報に圧倒されたため、デザインのウォークスルー中に質問することは考えられませんでした。聞きたかったのですが、何を聞いたらいいのかわかりませんでした。質問がなかったので、経営陣は引き継ぎがうまくいったと思います。
ハンドオーバーのプレゼンテーションに参加する前に、会社のwikiページからすべてのドキュメントを確認しようとしましたが、ドキュメントが多すぎて、どこから始めればよいのかさえわかりません。
私たちから、または私たちへのプロジェクトの引き渡しを成功させるために、私たちが従うことができるルールやベストプラクティスはありますか？.
ありがとう。
ドキュメントを読むという点では、個人的に私はこの注文に行きます：
アプリケーションの基本機能の概要を説明します-それが何を達成することを意味するのか。ビジネスケースは、おそらくすでに存在する最高のドキュメントです。
次に、機能仕様。この時点では、どのような方法やテクノロジーを理解しようとしているのではなく、アプリが何をするのかを理解しようとしているだけです。大規模な場合は、主要なビジネスプロセスとは何かを尋ね、それらに焦点を合わせます。
次に、高レベルの技術概要。これには、アーキテクチャ図、必要なプラットフォーム、バージョン、構成などが含まれている必要があります。質問があればリストしてください。
次に、他の便利な技術文書をざっと読みます-確かにFAQある場合は、詳細な「ハウツー」タイプのシナリオを概説しているので、テストスクリプトも良いでしょう。多分それは私だけですが私は見つけますシステムを無駄にする前に技術文書を読む-それはあまりにも学術的で、通常は衝撃的に書かれています。それは確かに、私が合理的な利益を得ていると感じなかった場合に費やす時間を制限する領域です。私が過ごしていた時間。
あなたの中に構造化されたレビューを何人か持っている場合は、あなたが読んだ文書について話し合い、あなたがそれから必要なものを持っていることを確認してください。システムが大きい場合は、それぞれが領域を取り、その上で他の人に提示します-できるだけ多くを学ぶ理由を自分自身に与え、あなたがクイズされることを知っていることは良い動機です。何かがわからない質問のリストを作成します。あなたの間で構造化されたレビューを持つことは、退屈なドキュメントのページを次々とトロールするのではなく、あなたの心を集中させ、よりインタラクティブなタスクにするでしょう。
あなたが彼らと顔を合わせたら：
完全なシステムデモから始めます。彼らが出てきたときに質問をし、不明確な答えであなたをだましてはいけません-彼らが何かに答えることができない場合は、それを書き留めて、答えを得ることを彼らに任せてください。
次に、コードをチェックアウトして、マシンで実行します。これは、少なくとも2台のマシンで実行します。1台はリードし、もう1台はあなたがリードします。プロセス全体を文書化します-これは最も重要なステップです。コードを実行できない場合は、失敗します。
ビルドプロセスを実行します。アプリをビルドできることを確認します（自動ビルドとユニットテストを含む）。すべての単体テストに合格する必要があることに注意してください。合格しなかった場合、または「ああ、それは常に失敗します」と言った場合は、最終的に受け入れる前にそれを修正する必要があります。
インストールプロセスを実行します。あなたがリードしたら、これを少なくとも2回行います。文書化されていることを確認してください。
次に、アプリケーションで実行される一連の一般的なビジネス機能を考え出します。これを使用して、コードを一緒に歩きます。コードベースは大きすぎて全体をカバーできませんが、代表的なサンプルをカバーしていることを確認してください。
データベースまたはAPIがある場合は、同様の演習を行います。抽出する必要のあるいくつかの標準データ、またはAPIを使用して実行する必要のあるいくつかの基本的なタスクを考え出し、それらを使用してこれらの作業に時間を費やします。
あなたが知っておくべきだと彼らが思うことは何かあるかどうか彼らに尋ねてください。
他の場所に書き留めた質問には必ず答えてください。
バグリスト（オープンとクローズ）を確認する価値があると考えるかもしれません-優先度の高いものから始めて、特に心配なことを話し合ってください。彼らがそれを修正したとしても、それは面倒なコードのビットを指すかもしれません。
そして最後に、機会が存在する場合-未解決のバグや変更がある場合は、ペアプログラミングができるかどうかを確認してください。
次のことができると100％確信が持てない限り、最終的にアプリを受け入れないでください。
- コンパイルするコードを取得する
- ビルドするコードを取得します（データベースを含む）
- アプリケーションをインストールする
次の状態になるまで、ハンドオーバーが完了することを受け入れないでください。
- あなたが拾ったものがあなたの満足にカバーされなかったものを文書化した
- あなたのすべての質問に答えました-彼らが隠している何かについて繰り返し叫んだ後に彼らが答えない質問
そして、彼らの電子メールアドレスと電話番号を入手してください。それが非公式であるとしても、たわごとが本当にファンを襲った場合、彼らはおそらく喜んで手伝ってくれるでしょう...
幸運を。
ハンドオーバーを受信するための私の基本的なプロセスは次のとおりです。
- アプリの一般的な概要を取得し、文書化します
- クライアントが期待するすべての将来の作業のリストを取得します
- ...すべての既知の問題
- ...実装の詳細
- 彼らが持っているのと同じくらい最新のドキュメント
- 可能であれば、システムの重要なコンポーネントについていくつかのテストを書いてもらいます（または少なくとも完全に文書化してもらいます）
ドキュメントが多すぎる（可能性がある）場合は、すべてが最新であることを確認し、明確でない場合は、それらどこから始めればよいかを確認してください。
できるだけ多くの質問をします。二度とチャンスがないかもしれないので、頭に浮かぶことは何でも。
ほとんどのハンドオーバー、おそらくすべてのハンドオーバーにより、多くの情報が失われます。私が見たハンドオーバーを実行する唯一の効果的な方法は、徐々にそれを実行することです。そのための1つの方法は、フェーズ1の数人の主要人物がフェーズ2までプロジェクトにとどまることができるようにすることです。
極端な解決策は、すべてのハンドオーバーを取り除き、アジャイルの考え方を使い始めることです。
最初に、ハンドオーバーの終了基準を定義します。これは、両当事者と話し合い、交渉し、合意し、上級管理職がこれを知っていることを確認する必要があります。次に、終了基準を達成するために必要なすべてのもののチェックリストを作成し、それを追跡します。
プロジェクトに関する情報を収集するときに尋ねる質問のアイデアについては、 "ソフトウェア要件" および ソフトウェア要件パターン を確認してください。彼らが新しい開発のために働くのと同じように、彼らはあなたが既存のプロジェクトに同意するのにも役立つと思います。