新しいチームメンバーをプロジェクトの最新状態にするにはどうすればよいですか？
ソフトウェアチーム（3人の開発者、1人のテスターで構成される）に1〜2人の新しいエンジニアを採用しようとしています。
それらをチームに統合する手順は何ですか？
私の考えは：
- ドキュメントを読む（コーディング標準、使用する開発方法論のドキュメント）
- 彼らに既存のコードを読ませる
- いくつかの簡単なタスクを割り当てます
- 最後に、コード部分を担当させます
他に何ができますか？
このプロジェクトは医療部門（超音波システム）で行われており、すでに5年が経過しています。毎年リリースがあり、1〜2人のエンジニアを追加したいときに、1つのリリースを終了しようとしています。
プロジェクトはメンテナンス段階です（レガシーコードのリファクタリングと新機能の追加）。ほぼ予定どおりです（多かれ少なかれ）。
私のキャリアの中で多くの異なるコードベースに精通しなければならなかった誰かから来て、私が提案するのはこれです：
- 製品の使い方に慣れるように、製品の使用に関連するアクティビティに短い時間（1日か2日程度）を費やします。これは、バグの検証、QAテスト計画の実行、またはユーザートレーニングの実施です。
- 小さなローカライズされたバグに取り組みます。これにより、エンジニアは、多くのアーキテクチャを学習する必要なく、アプリケーションのビルドとデバッグの方法を理解できます。
- 理想的には、ローカライズされた小さな新機能を記述します。これにより、彼らはコードのチャンクを書くことができ、彼らがそれを書くとき、彼らは彼らの新しいコードが動作する必要がある周囲のコードのビットに慣れるでしょう。
そこから、エンジニアの経験レベルと適性に応じて、割り当ての範囲と複雑さを徐々に拡大していきます。これにより、開発者はコードベースの知識を自然に拡張できます。
タスク（ドキュメントまたはコード）のみを読むことは避けます。ドキュメンテーションを読むことは本当に退屈で本当に速くなり、ランダムなコードを読むことは彼らが扱うコンテキストがないので役に立ちません。製品とコードベースをすでに知っている場合、コードレビュー用のコードを読み取るのは十分に困難です。まったく新しいエンジニアがコードを読んでいるだけでは、役に立つものは何もありません。
リードとして、私は新しい開発者と少なくとも2日間過ごします。 「進歩はどうですか？」という不可避の質問をするのが心地よい関係を築くことがわかりました。必須です。どんな新しいコミュニティにも適合する恐れがあります...私たちは間違いを隠し、完璧に行動し、物事を彼らよりも良くし、困難を減らします。誰かと2日間過ごすマネージャーは、それが自分の文化ではないことを彼らに知らせ、模範を示すことができます。新しいコーダーは、あなたがどこから来たのか、どこまで進んでいるのかについての歴史のレッスンが必要です。ドキュメントは正義の仕事をしません。
ドキュメントを読むことに対するほとんどの人の許容度はかなり低いと感じています（1〜2日は良いですが、それを超えると、もう少し実際に何かをするのがむずかしいでしょう）。
アプリケーション自体を適切に理解していなければ、アプリケーションのコードを実際に理解することはできないと思います。このソフトウェアには、ユーザーとして「楽しむ」ことができる機能がたくさんあると考えられます。最終的にはテストできるようにする必要があるため、インストール方法、設定方法、一般的なタスクの実行方法を知っていることが非常に重要であることを期待しています。
私は個人的に、高レベルのアーキテクチャの概要が、物事がどのように機能するかの基本的な感覚を得るために非常に便利であることに気づきます-単に通過するために、最初の週に上級エンジニアの時間（または必要に応じてあなた自身？）メインアプリケーションの基本的な注意点。例えばすべてのサブシステムを理解し、物事がどのように結び付けられているかを理解し、どのビットがサードパーティのソフトウェア/ライブラリによって処理され、どのビットを社内で維持する必要があるかを理解します。 （組織が本当に並外れた品質の最新のドキュメントを持っていない限り、ホワイトボードを使用して誰かに直接説明せずにそのようなことを理解する方法はないと思います：- ））
彼らに「実践的な」何かを与えることに関しては、メンテナンス/バグ追跡タスクは、しばらくの間（数週間/数か月）彼らをスピードアップするための良い方法かもしれません-彼らは機能の特定の領域がある状況になるでしょう理解、テスト、デバッグが必要。コード、要件、会社が使用するツール、開発プロセス、および製品全体に関する知識の構築を支援する一方で、他の開発チームからあまり多くの時間を費やす必要がないことを願っています。
私は産業界で10か月間しか働いていません（配置時）が、次のことが役立つことがわかりました。
- 他の開発者とチームを組み、問題への取り組み方を観察します。
- ソフトウェアのテストが役に立ったので、機能xをテストする必要があります。つまり、機能xのドキュメントを読みます。私はこれをたくさんやった、それは助けた。
どちらも私をかなり助けてくれました。幸運を。
高レベルから低レベルに行きます。
できるだけ早くアプリをデモ
最も重要なことの1つは、開発者が自分が何に取り組むかについての考えを持っていることです。デモ中に、最近開発されていることのいくつかと、アプリの方向性を指摘します。
高レベルのアーキテクチャについて説明してください
これも非常に重要です。新しい開発者が聞いて質問できるようにします。これを他の開発者とのグループ演習として行います。これにより、新しい開発者は、率直に率直に発言してもよいことがわかります。
優れたオンボーディングドキュメントを用意してください
優れたオンボーディングドキュメントを持つことは、新しい開発者だけでなく、古い開発者にも役立ちます。期待、役立つリンク、環境設定情報を含めることができます。 （新しいコンピューターを入手したときに、オンボーディングを使用して環境をセットアップした回数はわかりません...）これは適切に構造化されていて、長続きせず、長引くことなく、少し詳細。
質問するように（そして回答できるように）彼/彼女を励ます
答えとともに、彼らを導きますが、何をすべきかを伝えないでください。ヒントを与えますが、最終的に自分でそれを理解できるようにします。
他のチームメンバーが新人を歓迎するのを助ける
誰かがチームに参加するとき、コインの表裏があります。チームには、新しい開発者をも歓迎するツールが必要です。
1つまたは2つの小さなタスクを取り上げる
デモ可能なプロジェクトに新しい、目に見えるものを追加できるようにします。デモが行われたら、誰がやったか、彼らが何をしたかを声に出してください。これは本当に自尊心を高めることができます。彼らが価値を付加しているように彼らが感じるのが速ければ早いほど、彼らは彼らがチームの一員であると早く感じる。彼らがより速く、彼らができる最善を尽くす力を与えられていると感じるでしょう。
彼らがますます快適になったら難しい仕事に入るように彼らを励ます
良い候補者はこれを自然に行います。
私がこれまで経験した（そして有用であるとわかった）「方向付け」フローの1つは、次のようなものでした。
- コンポーネントの概要、全体的なアーキテクチャを「全体像」にまとめた簡単なプレゼンテーション。
- コードの概要、自分に割り当てられたコンポーネントのメインロジックを処理する関数の概要。コーディング規約とスタイルに関連するいくつかのものをカバーしました。
- 多数の未解決の問題と優先度の低いバグが割り当てられました（これらは主に、私に割り当てられたコンポーネントにローカライズされており、かなり単純です）。
- 私はアプリケーションを介してデバッグし、解読できなかったものについて助けを求めることが期待されていました。
- 修正が行われた後、統合にリリースするプロセス（コードレビュー、開発者レベルのテストなど）を実行しました。
- 割り当てられた残りのタスク/バグについて繰り返します。
このアプローチ（およびそのバリエーション）は次の理由で役立つと思います。
- これは、より実践的で比較的独立したものでした（常に手持ちなどはありません）。そのため、新しい人がコードに慣れるのに十分な余地と時間が与えられ、チームでの作業方法が提供されます。
- また、いくつかの優先度の低いタスク/バグを解決できるため、チーム全体にとっても有益です。新しい人を手助けする人は、常に手を握る必要がなく、新しい人が直面する可能性のある問題や問題に対処するための時間を特にスケジュールできるため、割り当てられたタスクを処理する時間も多くなります。
最初の採用には、作業を行うために、小さいが、小さすぎず、明確に定義されたタスクが必要です。このようにして、彼らは彼らの仕事を成し遂げる方法を理解しようと試みることによってコードがどのように構造化されているかについての感触を得始めることができます。その過程で質問が出てきます。その時点で、コードベースの内部化を支援するために使用できるドキュメントやその他のリソースに質問を導くことができます。また、開発、コミット、展開のサイクルが短く、作業の成果をできるだけ早く確認できる場合にも役立ちます。
これが私のやり方です
- プロジェクトに関連するいくつかのタスクを与えます（例：プロジェクトがデータベースアプリケーションの場合は、データベースに接続するためのアプリケーションを作成して簡単な操作を実行するように依頼します）。
- 彼らが作業のアイデアを理解しているのを見つけたら、プロジェクトのデモを提供します。
- ドキュメントを読むように依頼します。
- コーディングスタイルと標準に慣れる
- 後で、デバッグの練習をします（プロジェクトのフローを知るため）。
- あなたがすでに修正したポイントを修正するように依頼してください（それで彼らの論理を見つけてください）。
- 最後に、それらをプロジェクトの一部にします。
覚えておいてください。たとえどんなに努力しても、参加者がプロジェクトを完全に理解しない限り、参加者は彼から最も効率的に作業を行うことができません。
ナンバーワン-まず、ソフトウェアを使用して、ユーザーの観点から解決する問題を発見する方法を学びます。 UI（バックエンドサービスなど）がない場合は、利用可能なインターフェースを使用して使用できるようにします。ソフトウェアに対するユーザーの見方を新しく理解することは常に良いことであり、すでにプロジェクトに組み込まれているため、新しい従業員があなたが見ることができないものを見るのを助けるかもしれません。
この後、適切な最初のプロジェクトは、ソフトウェアに追加するアドオンまたは新しいモジュールのようなものになり、既存のコードベースに必要な知識の量を最小限に抑えます。何か新しいものを書くことは、多くのソースファイル全体で多くの変更を必要とする可能性があるバグ修正を実行するよりも常に簡単です。私の意見では、新入社員にバグ修正タスクを与えることはおそらくあなたの会社をオフにするでしょう。
新しいものをプロジェクトに慣れるためのあなたの概要は合理的であるようです。ただし、最初は多くのことを学ぶ必要があることに注意してください。これは通常、圧倒的な状況です。辛抱強く、同じ質問に繰り返し答える必要があります。これは正常です。新しい開発者は多くのことを学ぶ必要があります。これを過小評価しないでください。これらの繰り返される質問に腹を立てると、質問をしないで一人で物事を見つけようとするリスクが高まります。また、彼らは専門用語を学ぶ必要があります。ほとんどのチームプロジェクトは独自の言語を開発します。説明するときは、意識的に専門用語を避けてください。お母さんに説明するように説明してください。もう一度、我慢してください。
さらに、いくつかの評価センタースタイルのタスクを試すことで、すでにチームに参加している他の人とそれらを統合しようとすることができます。コーヒーカップを支える4枚の紙から45分で橋を架けます。ソフトウェアエンジニアリングの実践的なコースでこの手法を使用して、8人の学生のグループが3つの週の単一のプロジェクトに取り組む前に氷を解くようにします。チーム形成フェーズのスピードアップに役立ちます。
これらは私の公式であり、いくつかの新しいコーナーで使用されました-これらのステップは非常に効果的であることが証明されています。
a）すべての新しい開発者には、プロジェクトの要件と開発プロセスに関する2日間の紹介が与えられます。
b）十分なカバレッジがないコードにJunitテストを書くという3週間のタスクを割り当てる。
c）3が完了したら、小さなタスクを割り当てます
d）複雑なタスクを割り当てて完了。
1）コードルールとガイドラインについて説明します。また、アプリケーションがどのように機能するか、および一般的なコード構造の概要を説明します。
2）他のコードからほとんど独立しているいくつかの小さなバグまたはプロジェクトを見つけます。コードのどこで何をする必要があるかを説明し、定期的にチェックします。
3）徐々にチェックを減らしながら、徐々にプロジェクトを大きくしていきます。
4）時々彼らの隣に座る。他の誰かが問題に取り組む方法を見るだけで、多くのことを学ぶことができます。 「ああ、ctrl-を押すことでコード内の関数を探すことができます。」のような小さなこと。とても便利です。
今、私は2つの極値があることを発見しました：
5分ごとに質問する人。 「このPath.Joinは何をしますか？」彼らは最初にグーグルで答えを求め、彼らが答えを見つけられないときだけあなたのところに来るべきです。
そしてもう1つの極端なことは、1つの質問もしないで半日働いている人です。質問をするのは良いことだと彼らは感じるはずです。私は彼らに彼ら自身で最初にそれを試して欲しいだけです。
いくつかの小さなタスクを割り当てて、いくつかの単体テストを作成するように依頼し、いくつかのリグレッションが失敗した場合にデバッグするようにします。大きすぎたり、要求が厳しいものはありませんが、足元に置くには十分です。
また、できれば候補者のメンターを助けることができる新しい開発者ごとに、上級開発者を割り当てる必要もあります。
そして、はい、システムについて学んでいることを文書化します。ここでは、何らかの内部Wikiページがあると想定しています。そうでない場合は、長期的にも短期的にも絶対に必要なことです。人々を驚かせるために驚くほど速い方法です。 Wikiページには、コードドキュメントだけでなく、既知の制限（これはソフトウェア：Dです）、回避策、時間/メモリパフォーマンスメトリックなども含める必要があります。
コーディングの優良事例と標準だけを説明するのではなく、読み取ったコードの構造を説明してください。ソフトウェアが何をすることになっているのか、そしてこれがどのように達成されるか、または達成されるかを説明してください。
やらなければならない仕事があるまで理解できないので、実際の作業を開始する前と、作業を開始した後の2つの部分に分けることをお勧めします。彼らはいくつかのコードやドキュメントを調べて、「WTF！？」と考えます。これが発生すると、誰かが同行し、細かいことを説明します。