新しいチームメンバーにプロジェクトを最新の状態にする方法は？[閉まっている]

ソフトウェアチームに1-2人の新しいエンジニアを雇おうとしています（3人の開発者、1人のテスターで構成されています）。

それらをチームに統合する手順は何ですか？

私のアイデアは次のとおりです。

• ドキュメントを読む（コーディング標準、使用する開発方法論のドキュメント）
• 既存のコードを読ませる
• それらにいくつかの簡単なタスクを割り当てます
• 最後に、コード部分の責任を負わせる

他に何ができますか？

このプロジェクトは医療分野（超音波システム）であり、すでに5年が経過しています。1年に1回のリリースがあり、1〜2人のエンジニアを追加するときに1つのリリースを終了します。

プロジェクトはメンテナンス段階にあります（レガシーコードのリファクタリング、および新しい機能の追加）。物事はほぼスケジュールどおりです（多少なりとも）。

私のキャリアの中で多くの異なるコードベースに精通しなければならなかった誰かから来て、ここに私が提案するものがあります：

1. 製品の動作に慣れるために、製品の使用に関連するアクティビティに短時間（1〜2日程度）費やします。これは、バグの検証、QAテスト計画の実行、またはユーザートレーニングの実施です。
2. 小さなローカライズされたバグに取り組みます。これにより、エンジニアは、多くのアーキテクチャを学習することなく、アプリケーションを構築およびデバッグする方法を熟知できます。
3. 理想的には、ローカライズされた小さな新機能を記述します。これにより、彼らはコードの塊を書くことができ、それを書くと、彼らは彼らの新しいコードが動作するために必要な周囲のコードのビットに精通します。

そこから、エンジニアの経験レベルと適性に応じて、時間の経過とともに割り当ての範囲と複雑さを拡大します。これにより、開発者はコードベースの知識を自然に広げることができます。

タスク（ドキュメントまたはコード）のみを読むことは避けます。ドキュメンテーションを読むのは本当に退屈になりますし、ランダムなコードを読むことは役に立たないため、役に立ちません。すでに製品とコードベースを知っている場合、コードレビューのコードを読むのは十分に困難です。新しいエンジニアがコードを読んでいるだけでは、何の役に立つこともありません。

私の考えでは、ほとんどの人はドキュメントを読むことに対する寛容性がかなり低いと感じています（1〜2日は良いですが、それ以上に、もう少し実践的なことをしたいと思うかもしれません）。

アプリケーション自体を合理的に理解しなければ、アプリケーションのコードを本当に理解できるとは思いません。ソフトウェアには、ユーザーとして「おもちゃ」で使用できる機能が十分にあると思われます。最終的にそれをテストできるようにする必要があるので、インストール、設定、一般的なタスクの実行方法を知っていることがかなり重要だと思います

個人的には、高レベルのアーキテクチャの概要は、物事がどのように機能するかの基本的な感覚を得るために通常非常に便利であることがわかります-おそらく、最初の週にシニアエンジニアの時間（または必要に応じてあなた自身）の1時間または2時間を割り当てるだけですメインアプリケーションの基本的なナッツボルト。例えば、すべてのサブシステムと物事がどのように結び付けられているかを理解し、どのビットがサードパーティのソフトウェア/ライブラリによって処理され、どのビットが社内で維持される必要があるかを知る。（あなたの組織が本当に並外れた品質の最新のドキュメントを持っていない限り、誰かがホワイトボードを使って直接説明せずにそのようなものを把握する方法はないと思います：- ））

彼らに何か「実践」を与えることに関しては、メンテナンス/バグ追跡タスクはしばらくの間（数週間/月？）それらをスピードアップする良い方法かもしれません-彼らは機能の特定の領域の状況になります理解、テスト、デバッグする必要があります。コード、要件、会社が使用するツール、開発プロセス、および製品全体の知識の構築を支援する一方で、他の開発チームからあまり時間を浪費する必要がないことを願っています

主任として、私は新しい開発者と少なくとも2日間過ごします。私は、「あなたの進歩はどうですか」という避けられない質問をするのが快適であると感じる関係を開発することを発見しました。必須です。どんな新しいコミュニティにも適合する恐れがあります...私たちは間違いを隠し、完璧に行動し、物事をより良くし、困難を減らします。誰かと2日間過ごすマネージャーは、それが彼らの文化が何であるかではないことを彼らに知らせ、彼らが模範によって導くことを可能にします。新しいコーダーは、あなたがどこから来たのか、そしてあなたがどこまで進んでいるのかについての歴史のレッスンが必要です。文書はタスクの正義を実行しません。

私は業界で10か月しか働いていませんが（プレースメントについて）、次のことが助けになったことがわかりました。

• 他の開発者とチームを組み、彼らが問題にどのように取り組んでいるかを観察します。
• ソフトウェアのテストは役に立ちました。機能xをテストする必要があります。つまり、機能xのドキュメントを読む必要があります。私はこれをたくさんやった、それは助けた。

両方ともかなり助けてくれました。幸運を。

私は高いレベルから低いレベルに行きます。

できるだけ早くアプリをデモする

最も重要なことの1つは、開発者が自分が何に取り組むのかというアイデアを持っていることです。デモ中に、最近開発中のいくつかのことと、アプリが進む方向を指摘します。

高レベルのアーキテクチャを説明する

これも非常に重要です。新しい開発者が聞いて質問できるようにします。これを他の開発者とグループで練習してください。これにより、新しい開発者は、率直に率直に話すことができます。

優れたオンボーディングドキュメントを用意してください

優れたオンボーディングドキュメントを持つことは、新しい開発者だけでなく、古い開発者にも役立ちます。期待、有用なリンク、環境設定情報を含めることができます。（新しいコンピューターを入手したときに、環境をセットアップするためにオンボーディングを何回使用したかはわかりません...）少し詳細。

彼/彼女に質問することを奨励する（そしてそれらに答えることができるようになる）

答えがあれば、彼らを導きますが、何をすべきかを彼らに伝えないでください。ヒントを与えますが、最終的に自分で理解できるようにします。

他のチームメンバーが新参者を歓迎するのを助ける

誰かがチームに参加すると、コインの両面があります。チームには、新しい開発者を歓迎するツールも必要です。

少々のタスクを1つか2つ受けさせます

デモ可能なプロジェクトに新しいものや目に見えるものを追加できるようにします。それがデモされたら、誰がそれをやったか、彼らが何をしたかを声に出してください。これは本当に自尊心を高めることができます。価値を高めていると感じるほど、チームの一員であると感じることが速くなります。より速く彼らは彼らができる最善を尽くすために力を与えられると感じるでしょう。

彼らがますます快適に感じたら、彼らがより困難な仕事に入ることを奨励する

優秀な候補者はこれを自然に行います。

私が経験した（そして有用であると感じた）1つの「方向」フローは、次のようなものでした。

1. コンポーネントの概要、適合性、および一般的なアーキテクチャを「全体像」を示す簡単なプレゼンテーション。
2. コードの概要、私に割り当てられたコンポーネントのメインロジックを処理する関数の紹介。コーディング規約とスタイルに関連するものをいくつか取り上げました。
3. 多数の未解決の問題と優先度の低いバグが割り当てられました（これらは主に私に割り当てられたコンポーネントにローカライズされていて、かなり単純でした）。
4. 私はアプリケーションを介してデバッグし、解読できないものについて助けを求めることが期待されていました。
5. 修正が行われた後、統合にリリースするプロセス（コードレビュー、開発レベルのテストなど）を順を追って説明しました。
6. 割り当てられた残りのタスク/バグについて繰り返します。

このアプローチ（およびそのバリエーション）が役立つのは、次の理由からです。

• これは、より実践的で比較的独立したものでした（手持ちなどは常にありません）。したがって、新しい人がコードに慣れるのに十分な部屋/時間と、チームで物事が行われる方法を提供します。
• また、いくつかの優先度の低いタスク/バグを解決できるため、チーム全体にとっても有益です。また、新しい人を手伝う人は、割り当てられたタスクを処理する時間が多くあります。これは、一定の手で保持する必要がなく、新しい人が直面する可能性のある問題/問題に対処する時間を明確にスケジュールできるためです。

最初の採用には、作業するための小さいが、小さすぎず、明確に定義されたタスクが必要です。このようにして、彼らは自分のタスクを達成する方法を見つけ出すことにより、コードがどのように構成されているかを感じ始めることができます。その過程で質問が出てきますが、その時点でドキュメントまたはコードベースの内部化を支援するために使用できる他のリソースに質問を送ることができます。また、開発、コミット、展開のサイクルが短く、作業中の成果をできるだけ早く確認できる場合にも役立ちます。

これは私がどのように行くかです

1. プロジェクトに関連するタスクをいくつか与えます（例：プロジェクトがデータベースアプリケーションの場合、データベースに接続して簡単な操作を実行するアプリケーションを作成するように依頼します）。
2. 仕事のアイデアを理解していることがわかったら、プロジェクトのデモを提供します
3. ドキュメントを読むように依頼します。
4. コーディングスタイルと標準に慣れさせる
5. 後で彼らにいくつかのデバッグ演習を行います（プロジェクトの流れを知るため）。
6. 既に修正済みのポイントを修正するように依頼します（そのロジックを確認するためです）。
7. 最後に、それらをプロジェクトの一部にします。

覚えておいてください：あなたがいくら努力しても、参加者がプロジェクトを完全に理解しない限り、あなたは彼から最も効率的に仕事を成し遂げることができません。

ナンバーワン-最初にソフトウェアを使用して、ユーザーの観点から解決する問題を発見する方法を学びます。UIがない場合（たとえば、バックエンドサービスなど）、それらを使用するために使用可能なインターフェイスを使用させます。あなたのソフトウェアに対するユーザーの見方を常に新鮮にすることは常に良いことであり、プロジェクトに既に組み込まれているために、新しい従業員があなたができないことを見るのに役立つかもしれません。

この後、良い最初のプロジェクトは、既存のコードベースに必要な知識の量を最小限に抑え、ソフトウェアに追加するアドオンまたは新しいモジュールのようなものになるかもしれません。何か新しいものを書くことは、バグ修正を実行するよりも常に簡単です。バグ修正は、多くのソースファイル全体で多くの変更を必要とする場合があります。私の意見では、新しい従業員にバグ修正タスクを与えると、おそらくあなたの会社をオフにするでしょう。

新しいものをプロジェクトに慣れさせるためのアウトラインは合理的なようです。ただし、最初は多くのことを学ぶ必要があります。これは通常、圧倒的な状況です。忍耐強く、同じ質問に繰り返し答える必要があります。これは普通のことで、新しい開発者は多くを学ぶ必要があります。これを過小評価しないでください。これらの繰り返される質問に腹を立てると、せいぜい非常に遅いかもしれませんが頻繁に不可能なことだけを尋ねたり、見つけようとしたりするリスクがあります。また、彼らは専門用語を学ぶ必要があります。ほとんどのチームプロジェクトは、独自の言語を開発します。意識的に説明するときは、専門用語を避けてください。お母さんに説明するように、このことを説明してください。繰り返しますが、我慢してください。

さらに、コーヒーカップを支える4枚の紙から45分で橋を架けるなど、いくつかの評価センタースタイルのタスクを試すことで、既にチームにいる他の人と統合することもできます。ソフトウェアエンジニアリングの実践的なコースでこの手法を使用して、8人の学生のグループが3週間単一のプロジェクトに取り組む前に氷を砕くようにします。チームの形成段階をスピードアップするのに役立ちます。

1）コードのルールとガイドラインについて説明してください。また、アプリケーションの仕組みと一般的なコード構造の一般的な説明も提供します。

2）他のコードにほとんど依存しない小さなバグやプロジェクトを見つけます。コードのどこで何をする必要があるかを説明し、定期的にチェックしてください。

3）徐々にチェックを減らしながら、徐々に大きなプロジェクトを提供し始めます。

4）時々隣に座る。他の誰かがどのように問題に取り組んでいるかを見るだけで、多くを学ぶことができます。「ああ、ctrl-を指定することでコード内の関数を探すことができます。」非常に便利です。

今、私は2つの極端があることがわかりました：

• 5分ごとに質問する人。「このPath.Joinは何をしますか？」。最初にGoogleが回答を求め、回答が見つからない場合にのみあなたに来ます。

• もう1つの極端な例は、1つの質問をせずに半日働いている人です。質問をするのは良いことだと感じるはずです。最初に自分で試してもらいたいだけです。

これらは私の処方であり、いくつかの新しいコーナーで使用されました-これらのステップは非常に効果的であることが証明されました。

a）すべての新規開発者には、プロジェクト要件と開発プロセスに関する2日間の紹介が提供されます。

b）十分なカバレッジを持たないコードのJunitテストを記述する3週間のタスクを割り当てます。

c）3が完了したら、小さなタスクを割り当てます

d）複雑なタスクを割り当てて完了します。

いくつかの小さなタスクを割り当てて、いくつかの単体テストを作成するように依頼し、いくつかのリグレッションエラーをデバッグさせてください。大きすぎたり、要求の厳しいものはありませんが、それらを立ち上げるには十分です。

また、できれば候補者を指導できる新しい開発者ごとに上級開発者を割り当てる必要があります。

そして、はい、彼らは彼らがシステムについて学んでいることを文書化します。ここでは、何らかの内部Wikiページがあると想定しています。そうでない場合、長期的にも短期的にも間違いなく必須です-驚くほど速い方法で人々を育てます。Wikiページには、コードド​​キュメントだけでなく、既知の制限（これはソフトウェア：D）、回避策、時間/メモリパフォーマンスメトリックなどの情報も含める必要があります。

コーディングのグッドプラクティスと標準だけを説明するのではなく、読み取りコードがどのように構成されているかを説明してください。ソフトウェアが何をするべきか、そしてこれがどのように達成されるか、または達成されるかを説明します。

彼らはやるべき仕事があるまで理解しないので、実際の仕事を始める前と仕事を始めた後の2つの部分に分けることをお勧めします。彼らはいくつかのコードやドキュメントを見て、「WTF !?」と考えます。これが発生すると、誰かが彼らに同行し、小さな詳細を説明します。