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