バックエンド
落ち着いて新しい開発チームに移行する
ソフトウェア製品は、その存続期間中にある開発チームから別の開発チームに移行するのが一般的です。製品のさまざまな段階で、さまざまなタイプの開発チームが必要になる場合があります。初期バージョンを構築するためのコンサルタント、ソロ フリーランスの開発者 それを維持するために、それをスケールするための社内チーム、またはいくつかの「ポップ」を追加するためのプロのデザイナー。
これが頻繁に発生するにもかかわらず、多くの非技術的な創設者や製品所有者は、次のチームを立ち上げるときが来ると、準備ができておらず、スクランブルをかけていることに気付きます。これにより、多くの場合、新しいチームが迅速に進歩できなくなり、時間の浪費になり、関係者全員がフラストレーションを感じることになります。
これが現在または将来のあなたである可能性があると思われる場合は、多少心配する必要があります。幸いなことに、この不測の事態に備え、移行を可能な限りスムーズにするために実行できる手順を説明します。
トーチを渡す：新しい開発チームのオンボーディング
この記事では、そのような変更に備えるのに役立つ項目のチェックリストを提供します。製品をより親密なレベルで理解し、製品を作成するためのさまざまなサービスやテクノロジーをより細かく制御できるようになります。これにより、自信を持って比較的簡単に新しいチームに参加できるようになります。
しかし、チーム全体を入れ替えない場合はどうでしょうか。わざわざこれを読むべきですか？
前のチームの一部が残っていても、彼らは持っていない可能性があります すべて スムーズな移行に必要な答えと情報。彼らは継続性を提供することができますが 援助 古いチームから新しいチームに知識を移転する過程で、現職のチームメンバーに依存することは、製品の所有者が担当し、移転を促進することに代わるものではありません。また、担当を怠ると、新旧のチームメンバーが摩擦したり、古いチームメンバーに不必要な作業を負わせたりして、新しいチームメンバーとのコミュニケーションやさまざまな問題の解決に多くの時間を費やすことになります。
それでも、一部のチームメンバーが参加している場合、それらは移行作業において非常に貴重な資産になる可能性があります。彼らに相談し、彼らをループに保ち、あまりにも多くの移行関連のタスクで彼らを氾濫させることなく彼らの経験を活用しようとします。彼らがすることを期待しないでください すべて 重い物を持ち上げる！それがあなたの仕事です。
それで、これ以上面倒なことはせずに、飛び込みましょう！
ドキュメントを収集する
フリーランスの開発者は、これまでに見たことのない既存のコードベースに飛び込むように求められることがよくあります。これは、ApeeScapeソフトウェアエンジニアに関して特に当てはまります。私たちの目標は、常にできるだけ早くスピードを上げて、クライアントにプラスの影響を与え始めることです。
プロジェクトに関する明確で徹底的なドキュメントにアクセスできると、オンボーディングプロセスが劇的に加速し、開発者が前進を妨げる可能性のある落とし穴を回避するのに役立ちます。
優れたドキュメントは、少なくとも次のトピックをカバーする必要があります。
- 開発環境のセットアップ -初心者にとっての最初のタスクは、アプリケーションを自分のコンピューターで起動して実行することです。そのためのプロセスはテクノロジーによって異なります。一般に、ソースコードの取得、データベースのセットアップ、依存関係のインストール、APIキーと認証情報を使用した環境の構成、サンプルデータのインポートなどのタスクが必要です。開発者は、それぞれの分野でこのプロセスに関係するすべてのことをよく理解しており、それに応じて詳細を調整できる必要があります。
- 自動テストスイートの実行 -アプリケーションのテストに合格することで、すべてが適切に設定され、将来の変更によって既存の機能が損なわれないことが保証されます。
- ステージングサーバーと本番サーバーへのデプロイ -ライブアプリケーションを最新の変更で更新することは、高度にスクリプト化されたプロセスであり、これらの操作の順序は、可能な限り詳細に段階的に概説する必要があります。
- 新しくオンボーディングされた開発者に関連するその他の情報 -すべてのアプリケーションには、独自の癖があります。それらを書き留めることで、将来のチームは、前のチームが対処方法をすでに理解している問題をデバッグするための多くの無駄な労力を節約できます。
ドキュメントは、次のような開発者が作成する必要があります。 直接体験 アプリケーションをセットアップし、コードベースに貢献します。
移行が発生する前に、前の開発チームが上記のトピックに触れるリソースを作成して知識の伝達を促進するように要求してください。
執筆が苦手な場合は、開発環境のセットアップや展開などを示す1つ以上のスクリーンキャストを録画するように依頼します。今日では、次のようなツールもあります。 Vagrant そして Docker これにより、開発環境全体をパッケージ化して他のユーザーに配布できます。本質的には、ハンマーの作り方を誰かに指示するのではなく、ハンマー自体を与えます。
プロジェクトのドキュメントがどれほど包括的で効果的であるかについてのリトマス試験は、新しい開発者が開発環境をセットアップしてアプリケーションを実行するまでの時間です。
あなたの製品を理解する
優れたドキュメントがあるからといって、自社製品のテクノロジーの基本を知る必要がなくなるわけではありません。ソフトウェア製品の所有者は、技術的でない場合でも、アプリケーションをできる限り理解する責任があります。
次の質問は一般的であり、調べなくても答えを知っていることが期待されます。
- アプリケーションはどのテクノロジースタックを使用していますか？ -のための多くの一般的なアプリケーションフレームワークがあります バックエンドとフロントエンド 、および新しい開発チームは、アプリケーションが使用するものに精通している必要があります。バックエンドWebテクノロジーの例は次のとおりです。 Ruby on Rails 、 Node.js 、および Django 。フロントエンドWebテクノロジーの例は次のとおりです。 React.js 、 Angular.js 、および Ember.js 。
- どこでホストされていますか？ -Webホストが異なれば、展開プロセスも異なり、さまざまなレベルの経験が必要になります。近年、クラウドテクノロジーによって多くの新しいホスティングオプションが作成されました。使用している特定のオプションを特定し、それが他のオプションよりも選択された理由を説明する必要があります。
- 開発プロセスとは何ですか？ -チームは、次のような特定のソース管理管理ツールを使用していますか？ 行く ？もしそうなら、新機能が開発され、テストされ、承認され、展開されるプロセスは何ですか？プロセスは標準化する必要があります、 適切に文書化されている 、および新規参入者が簡単に複製できます。
- アプリケーションはどのサードパーティサービスを使用していますか？ -一部のアプリケーションは、次のようなサードパーティのサービスに基づいて構築されています Shopify 。サードパーティのサービスへの依存度は徐々に高まっており、現在追加のサービスを使用していない場合でも、プロジェクトが後でサードパーティのサービスを採用することを決定する可能性があることに注意してください。
- アプリケーションはどのプラットフォームで実行できますか？ -アプリはデスクトップアプリケーション、ウェブアプリ、レスポンシブモバイルウェブサイト、ネイティブiOSアプリケーション、ネイティブAndroidアプリケーション、またはその他のものですか？いくつかの異なるプラットフォームで実行されていますか？どのプラットフォームを常に優先しますか？あなたの製品はどのプラットフォームで最も強く、最も弱いですか？アプリケーションの現在のプラットフォームのすべての詳細と、どのプラットフォームに拡張できるかを必ず知っておいてください。
所有権を得る
今日のソフトウェア開発プロセスでは、多数のサードパーティのサービスとツールを利用しています。あなたがそれを知っているかどうかにかかわらず、あなたのアプリケーションも例外ではありません。
開発の過程で、前のチームがあなたに代わってサインアップしたか、必要なサービスにアクセスするために自分のアカウントを使用した可能性があります。新しいチームに移行するということは、仲介者を経由したり追跡したりすることなく新しいチームへのアクセスを許可できるように、アプリケーションが依存するすべてのサービスとツールの所有権を取得して管理する必要があることを意味します。元の開発者。
以下は、アプリケーションが利用する可能性のあるさまざまな外部ツールまたはサービスのリストです。
- ソース管理管理 - GitHub 、 Bitbucket 、 Gitlab
- ウェブホスティング - Heroku 、 EngineYard 、 デジタルオーシャン 、 Bluehost 、 アマゾンウェブサービス
- ファイルホスティング - アマゾンウェブサービス（S3）
- DNSプロバイダー - GoDaddy 、 DNSimple 、 ホバー
- 開発サービス - NewRelic 、 FileStack 、 セグメント 、 Bugsnag （そして他の無数の）
- 決済サービス - 縞 、 Braintree 、 PayPal
- ブログサービス - WordPress 、 タンブラー 、 幽霊
- Eコマースソリューション - Shopify 、 Squarespace
- 分析/追跡 - グーグルアナリティクス 、 Mixpanel 、 Kissmetrics
- メールマーケティング： MailChimp 、 コンスタントコンタクト
どちらが適切かを開発チームに尋ねてください。あるサービスの場合 所有 開発チームによって、所有権をあなたに譲渡するように依頼します。それが不可能な場合は、独自の新しいアカウントを作成するのを手伝ってもらい、アプリケーションが自分のアカウントではなく自分のアカウントを使用するようにしてください。これには、アプリケーションのいくつかの構成設定を変更する以外に何も必要ありません。
初心者のためのemberjsチュートリアル
言うまでもなく、すべての開発契約が最初からあなたの利益を保護し、何があってもスムーズな移行を保証することを確認してください。
アクセス許可
アプリケーションのエコシステムと、アプリケーションが使用するすべてのさまざまなツールとサービスの所有権をしっかりと理解することで、次のチームまたは個人にフルアクセスを提供できるようになります。
ほとんどのサービスでは、共同編集者をアカウントに追加して、特定のレベルのアクセスを許可できます。 ここで保守的にしても大丈夫です 。多くの創設者、特に一人の起業家は、開発者にサービスへの完全な管理者アクセスを許可し、すべてを処理させることを好みます。これには、ループから抜け出すというマイナスの副作用があります。これは、私たちが学んだように、将来の移行を困難にする可能性があります。
開発者に完全な管理者権限を与える必要がありますか？それはあなたの呼びかけであり、ほとんどの人はこのアプローチに問題はありません。ただし、常に事前に計画を立て、決定が新しい開発チームに悪影響を与えないようにする必要があります。プロジェクトの初期段階でこれを怠ると、将来的に厄介な結果を招く可能性があります。
ハンドオフの管理
すべての拠点をカバーしたので、あるチームから次のチームへの引き継ぎを管理する必要があります。ここでは、着信チームと発信チームの両方に対処するための基本的なヒントをいくつか紹介します。
着信チーム
- 期待を設定する -新しいチームは、正しい方向に集中できるように、あなたの最も重要な目標が何であるかを知っている必要があります。新しいチームがすぐに達成できることについてのあなた自身の期待を管理することも同様に重要です。
- 頻繁にチェックイン -新しいチームを離れて沈んだり泳いだりしないでください。頻繁にチェックインして、必要なものがすべて揃っていることを確認し、自分で身を守る必要があるとは思わないようにします。細かく管理せずにこれを実行してみてください。必要に応じてあなたがサポートと支援を行うためにそこにいることを彼らが知っていることを確認しますが、彼らに不必要な圧力をかけないでください。
- 我慢して -開発者が新しいコードベースに慣れるには時間がかかります。新しいチームが前のチームのペースに合わせるには、ある程度の学習時間が必要であることを理解してください。
発信チーム
- 未解決のコードをすべて収集する -すべてのソースコードがメインリポジトリにチェックインされていること、および展開されているものと展開されていないもののステータスがわかっていることを確認します。新しいチームは、どこでピックアップして作業を開始するかを正確に知る必要があります。私自身、メインリポジトリにコードを配置せずにコードをデプロイしたチームを引き継ぐという状況を経験しました。これにより、バグ、重複作業、および頭痛の種が発生しました。これらは、発信チームがソースコードを一貫した状態のままにしておけば、簡単に回避できたはずです。
- アクセスレベルを更新する -良い条件で別れた場合は、コードやデプロイメントへのアクセスを許可することをお勧めします。多くのチームは、新しいチームが完全に引き継ぐことができるまで、移行フェーズ中に喜んでお手伝いします。そうでない場合は、偶発的な問題や新しいチームとの競合を防ぐために、アクセスをダウングレードまたは取り消すことを検討してください。
- 彼らの仕事に感謝します -移行は多忙になる可能性があります。新しいチームとのやり取りで忙しいときは、プロジェクトに貢献してくれた発信チームに感謝することを忘れないでください。
結論
人生の変遷は恐ろしく、うまくいくかどうかの不確実性、未知への恐れなどをもたらす可能性があります。新しい開発チームへの移行も例外ではありませんが、それを容易にするための措置を講じることができ、またそうすべきです。ほとんどの場合、それはほんの少しの長期計画を必要とします。
ソフトウェア製品、開発プロセス、およびプロセスに入ったすべてのことについて、技術的および非技術的な理解を深めることで、あるチームから次のチームへの移行を可能な限りシームレスかつ簡単に行うことができます。
何よりも、あなたの新しいチームはあなたのゲームの上にいることを尊重し、感謝します！あなたは彼らに時間と労力を節約する可能性があります、それはまたあなたがお金を節約することを意味します。さらに、新しいチームが高い専門的基準を主張することに気付くのが早ければ早いほどよい。プロジェクトを引き継いだ後もこれらのプラクティスを実装し続け、次の移行もスムーズにする可能性があります。
それでは、ソフトウェア製品の所有権を譲渡する前に必要な重要なポイントを確認しましょう。
- アプリケーション、開発環境、および展開プロセスについて、できるだけ多くのドキュメントを収集または作成します。
- あなたの製品を内外に知ってください。
- の制御を維持する すべて アプリケーションのサードパーティのサービスと依存関係を把握し、すべてのユーザー名とパスワードを用意します。
- 新しいチームが立ち上がって実行するために必要なすべてのものにアクセスできるようにする準備をしてください。
- 積極的に行動し、偶然や外向的な開発チームに何も任せないでください。
