落ち着いて新しい開発チームに移行する

ソフトウェア製品は、その存続期間中にある開発チームから別の開発チームに移行するのが一般的です。 製品のさまざまな段階で、さまざまなタイプの開発チームが必要になる場合があります。初期バージョンを構築するコンサルタント、それを維持するための単独のフリーランス開発者、規模を拡大するための社内チーム、またはいくつかの「ポップ"。

これが頻繁に発生するにもかかわらず、多くの非技術的な創設者や製品所有者は、次のチームを立ち上げるときが来ると、準備ができておらず、スクランブリングをしていることに気づきます。 これにより、新しいチームが迅速に進歩できなくなり、時間が無駄になり、関係者全員がフラストレーションを感じることがよくあります。

これが現在または将来のあなたである可能性があるように思われる場合は、多少心配する必要があります。 幸いなことに、この不測の事態に備え、可能な限りスムーズに移行するために実行できる手順を説明します。

トーチを渡す：新しい開発チームのオンボーディング

この記事では、そのような変更に備えるために役立つ項目のチェックリストを提供します。 製品をより親密なレベルで理解し、製品を製造するためのさまざまなサービスやテクノロジーをより細かく制御できるようになります。これにより、自信を持って比較的簡単に新しいチームに参加できるようになります。

しかし、チーム全体を入れ替えない場合はどうでしょうか。 わざわざこれを読むべきですか？

前のチームの一部が残っていても、スムーズな移行に必要なすべての回答と情報を持っていない可能性があります。 彼らは継続性を提供し、古いチームから新しいチームに知識を移転するプロセスを支援することができますが、現職のチームメンバーに依存することは、製品所有者が責任を持って移転を促進することに代わるものではありません。 また、担当を怠ると、新旧のチームメンバーが摩擦したり、古いチームメンバーに不必要な作業を負わせたりして、新しいチームメンバーとのコミュニケーションやさまざまな問題の解決に多くの時間を費やすことになります。

それでも、一部のチームメンバーが参加している場合、それらは移行作業において非常に貴重な資産になる可能性があります。 彼らに相談し、彼らをループに保ち、あまりにも多くの移行関連のタスクで彼らを氾濫させることなく彼らの経験を活用しようとします。 彼らがすべての重労働をすることを期待しないでください！ それがあなたの仕事です。

それで、それ以上の苦労なしに、飛び込みましょう！

ドキュメントを収集する

フリーランスの開発者は、これまでに見たことのない既存のコードベースに飛び込むように求められることがよくあります。 これは、Toptalソフトウェアエンジニアに関して特に当てはまります。 私たちの目標は、常にできるだけ早くスピードを上げて、クライアントにプラスの影響を与え始めることができるようにすることです。

プロジェクトに関する明確で徹底的なドキュメントにアクセスできることで、オンボーディングプロセスが劇的に加速され、開発者が前進を妨げる可能性のある落とし穴を回避するのに役立ちます。

優れたドキュメントは、少なくとも次のトピックをカバーする必要があります。

• 開発環境のセットアップ-初心者にとっての最初のタスクは、アプリケーションを自分のコンピューターで起動して実行することです。 そのためのプロセスは、テクノロジーによって異なります。 一般に、ソースコードの取得、データベースのセットアップ、依存関係のインストール、APIキーとクレデンシャルを使用した環境の構成、サンプルデータのインポートなどのタスクが必要です。 開発者は、それぞれの分野でこのプロセスに関係するすべてのことをよく理解しており、それに応じて詳細を調整できる必要があります。
• 自動テストスイートの実行-アプリケーションのテストパスを確認することで、すべてが適切に設定され、将来の変更によって既存の機能が損なわれないことが保証されます。
• ステージングサーバーと本番サーバーへのデプロイ-最新の変更でライブアプリケーションを更新することは、高度にスクリプト化されたプロセスであり、これらの操作の順序は、可能な限り詳細に段階的に概説する必要があります。
• 新しくオンボーディングされた開発者に関連するその他の情報-すべてのアプリケーションには独自の癖があります。 それらを書き留めることで、将来のチームは、前のチームが対処方法をすでに理解している問題をデバッグするための多くの無駄な労力を節約できます。

ドキュメントは、アプリケーションのセットアップとコードベースへの貢献を直接経験した開発者が作成する必要があります。

移行が発生する前に、前の開発チームが上記のトピックに触れるリソースを作成することにより、知識の伝達を促進するように要求してください。

執筆が苦手な場合は、開発環境のセットアップや展開などを示す1つ以上のスクリーンキャストを録画するように依頼します。現在、開発環境全体をパッケージ化して他のユーザーに配布できるVagrantやDockerなどのツールもあります。 本質的には、ハンマーの作り方を誰かに指示するのではなく、ハンマー自体を与えます。

プロジェクトのドキュメントがどれほど包括的で効果的であるかについてのリトマス試験は、新しい開発者が開発環境のセットアップとアプリケーションの実行をどれだけ迅速に行えるかということです。

あなたの製品を理解する

優れたドキュメントを持っているからといって、自分の製品のテクノロジーの基本を知る必要がなくなるわけではありません。 ソフトウェア製品の所有者として、あなたがあまり技術的でなくても、あなたのアプリケーションをできる限り理解することはあなたの責任です。

次の質問は一般的であり、調べなくても答えを知っていることが期待されます。

• アプリケーションはどのテクノロジースタックを使用していますか？ -バックエンドとフロントエンドには多くの一般的なアプリケーションフレームワークがあり、新しい開発チームは、アプリケーションが使用するものに精通している必要があります。 バックエンドWebテクノロジーの例としては、Ruby on Rails、Node.js、Djangoがあります。 フロントエンドWebテクノロジーの例としては、React.js、Angular.js、Ember.jsがあります。
• どこでホストされていますか？ -Webホストが異なれば、展開プロセスも異なり、さまざまなレベルの経験が必要になります。 近年、クラウドテクノロジーは多くの新しいホスティングオプションを作成しました。使用している特定のオプションを特定し、それが他のオプションよりも選択された理由を説明する必要があります。
• 開発プロセスとは何ですか？ -チームはGitなどの特定のソース管理ツールを使用していますか？ もしそうなら、新機能が開発され、テストされ、承認され、展開されるプロセスは何ですか？ プロセスは標準化され、適切に文書化されており、新規参入者が簡単に複製できる必要があります。
• アプリケーションはどのサードパーティサービスを使用していますか？ -一部のアプリケーションは、Shopifyなどのサードパーティサービスに基づいて構築されています。 サードパーティのサービスへの依存度は徐々に高まっており、現在追加のサービスを使用していなくても、プロジェクトが後でサードパーティのサービスを採用することを決定する可能性があることに注意してください。
• アプリケーションはどのプラットフォームで実行できますか？ -アプリはデスクトップアプリケーション、Webアプリ、レスポンシブモバイルWebサイト、ネイティブiOSアプリケーション、ネイティブAndroidアプリケーション、またはその他のものですか？ いくつかの異なるプラットフォームで実行されていますか？ どのプラットフォームを常に優先しますか？ あなたの製品はどのプラットフォームで最も強く、最も弱いですか？ アプリケーションの現在のプラットフォームのすべての詳細と、どのプラットフォームに拡張できるかを必ず知っておいてください。

所有権を得る

今日のソフトウェア開発プロセスでは、多数のサードパーティのサービスとツールを利用しています。 あなたがそれを知っているかどうかにかかわらず、あなたのアプリケーションも例外ではありません。

開発の過程で、前のチームがあなたに代わってサインアップしたか、必要なサービスにアクセスするために自分のアカウントを使用した可能性があります。 新しいチームに移行するということは、仲介者を経由したり追跡したりすることなく新しいチームへのアクセスを許可できるように、アプリケーションが依存するすべてのサービスとツールの所有権を取得して管理する必要があることを意味します。元の開発者。

以下は、アプリケーションが利用する可能性のあるさまざまな外部ツールまたはサービスのリストです。

• ソース管理-GitHub、Bitbucket、Gitlab
• Webホスティング-Heroku、EngineYard、Digital Ocean、Bluehost、Amazon Web Services
• ファイルホスティング-アマゾンウェブサービス（S3）
• DNSプロバイダー-GoDaddy、DNSimple、Hover
• 開発サービス-NewRelic、FileStack、Segment、Bugsnag（およびその他無数）
• 決済サービス-Stripe、Braintree、PayPal
• ブログサービス-WordPress、Tumblr、Ghost
• Eコマースソリューション-Shopify、Squarespace
• 分析/追跡-GoogleAnalytics、Mixpanel、Kissmetrics
• Eメールマーケティング： MailChimp、コンスタントコンタクト

どちらが適切かを開発チームに尋ねてください。 開発チームが所有するサービスについては、所有権をあなたに譲渡するように依頼してください。 それが不可能な場合は、自分の新しいアカウントを作成するのを手伝ってもらい、アプリケーションが自分のアカウントではなく自分のアカウントを使用するようにしてください。 これには、アプリケーションのいくつかの構成設定を変更する以外に何も必要ありません。

言うまでもなく、すべての開発契約が最初からあなたの利益を保護し、何があってもスムーズな移行を保証することを確認してください。

アクセス許可

アプリケーションのエコシステムと、アプリケーションが使用するすべてのさまざまなツールとサービスの所有権をしっかりと理解することで、次のチームまたは個人へのフルアクセスを提供できるようになります。

ほとんどのサービスでは、アカウントに共同編集者を追加して、特定のレベルのアクセスを許可できます。 ここでは保守的にしてもかまいません。 多くの創設者、特に独身の起業家は、開発者にサービスへの完全な管理者アクセスを許可し、すべてを処理させることを好みます。 これには、ループから抜け出すというマイナスの副作用があります。これは、私たちが学んだように、将来の移行を困難にする可能性があります。

開発者に完全な管理者権限を与える必要がありますか？ それはあなたの呼びかけであり、ほとんどの人はこのアプローチに問題はありません。 ただし、常に事前に計画を立て、決定が新しい開発チームに悪影響を与えないようにする必要があります。 プロジェクトの初期段階でこれを怠ると、将来的に厄介な結果を招く可能性があります。

ハンドオフの管理

すべての拠点がカバーされたので、あるチームから次のチームへのハンドオフを管理する必要があります。 ここでは、着信チームと発信チームの両方に対処するための基本的なヒントをいくつか紹介します。

着信チーム

• 期待を設定する-新しいチームは、正しい方向に集中できるように、あなたの最も重要な目標が何であるかを知っている必要があります。 新しいチームがすぐに達成できることについてのあなた自身の期待を管理することも同様に重要です。
• 頻繁にチェックインする-新しいチームを離れて沈んだり泳いだりしないでください。 頻繁にチェックインして、必要なものがすべて揃っていることを確認し、自分で身を守る必要があるとは思わないようにします。 細かく管理せずにこれを実行してみてください。 彼らが必要に応じてあなたがサポートし、助けるためにそこにいることを彼らが知っていることを確認してください、しかし彼らに不必要な圧力をかけないでください。
• 辛抱強く-開発者が新しいコードベースに慣れるには時間がかかります。 新しいチームが前のチームのペースに合わせるには、ある程度の学習時間が必要であることを理解してください。

発信チーム

• すべての未処理のコードを収集する-すべてのソースコードがメインリポジトリにチェックインされていること、および展開されているものと展開されていないもののステータスがわかっていることを確認します。 新しいチームは、どこでピックアップして作業を開始するかを正確に知る必要があります。 私自身、メインリポジトリにコードを配置せずにコードをデプロイしたチームを引き継ぐという状況を経験しました。 これにより、バグ、重複作業、および頭痛の種が発生しました。これらの問題は、発信チームがソースコードを一貫した状態のままにしておけば簡単に回避できたはずです。
• アクセスレベルを更新する-良い条件で別れた場合は、コードやデプロイメントへのアクセスを許可したままにすることをお勧めします。 多くのチームは、新しいチームが完全に引き継ぐことができるまで、移行フェーズ中に喜んでお手伝いします。 そうでない場合は、偶発的な問題や新しいチームとの競合を防ぐために、アクセスをダウングレードまたは取り消すことを検討してください。
• 彼らの仕事に感謝します-移行は多忙になる可能性があります。 新しいチームとのやり取りで忙しい間は、プロジェクトに貢献してくれた発信チームに感謝することを忘れないでください。

結論

人生の変化は恐ろしいものであり、それがうまくいくかどうかの不確実性、未知のものへの恐れなどをもたらします。 新しい開発チームへの移行も例外ではありませんが、それを容易にするための措置を講じることができ、またそうすべきです。 ほとんどの場合、それはほんの少しの長期計画を必要とします。

ソフトウェア製品、開発プロセス、およびプロセスに含まれるすべてのことについて、技術的および非技術的な理解を深めることで、あるチームから次のチームへの移行を可能な限りシームレスかつ簡単に行うことができます。

何よりも、あなたの新しいチームはあなたのゲームの上にいることを尊重し、感謝します！ あなたは彼らに時間と労力を節約する可能性があります、それはまたあなたがお金を節約することを意味します。 さらに、新しいチームが高い専門的基準を主張することに気付くのが早ければ早いほどよい。 プロジェクトを引き継いだ後も、これらのプラクティスを引き続き実装し、次の移行もスムーズにする可能性があります。

それでは、ソフトウェア製品の所有権を譲渡する前に必要な重要なポイントを確認しましょう。

• アプリケーション、開発環境、および展開プロセスについて、できるだけ多くのドキュメントを収集または作成します。
• あなたの製品を内外に知ってください。
• アプリケーションのすべてのサードパーティサービスと依存関係の制御を維持し、すべてのユーザー名とパスワードを用意します。
• 新しいチームが立ち上がって実行するために必要なすべてのものにアクセスできるようにする準備をしてください。
• 積極的に行動し、偶然や外向的な開発チームに何も任せないでください。