チームに新しい開発者を追加する方法

私は2人の開発者で構成される小さな会社を経営しています。私たちは、クライアントの1人に対して非常に大きなアプリケーションを構築しています。このプロジェクトの開発は1.5年間続いています。

現在、このクライアントは重要なスポンサーを獲得しており、このプロジェクトに関連するイベントを開催しています。だから今、私たちは2ヶ月で期限があり、私たちはそれを見逃すことはできません。

チームに新しい開発者を追加することを考えていますが、彼の統合を支援するために何ができるのかと思います。

これが状況です：

• ブルックスの法則の限界に近づいています-新しい開発者を追加するときのポイントは非生産的です。
• アプリケーションは比較的適切に設計されていますが、実装はいくつかの点で混isとしています（特に古いコード）。
• ユニットテストは、より新しいコードに対してのみ行われます。このプロジェクトが始まったとき、私たちは定期的にテストを行いませんでした。
• ドキュメントとコメントは不完全です。
• アプリケーションは大規模で複雑です。
• クライアントは、プロジェクトに関するほとんどすべての詳細を、非常に明確で「プログラマーに優しい」方法で書き留めています。

今すぐ人を追加することをお勧めしますか？もしそうなら、新しい開発者がチームに統合するのを助けるために何ができますか？

編集：

スポンサーは来春にインターネットベースのスポーツイベントを開催しています。年の特定の日に開始する必要があります。変更することはできません。

開発者（私は2人のうちの1人）がする必要があるのは：

• 既存のアプリケーションを完了します（実行する作業の約25％）。

• このイベントの組織に不可欠な新しいモジュールの作成（行う作業の約75％）。この新しいモジュールは、メインプログラムのAPIを理解しないと開発できません。

正確な時間の見積もりはできませんが、私たちは危険な状況にあります。

最善の方法は、新しい開発者を火の中に投げ込むのではなく、代わりに開発者が飛び込むことのない機能やバグ修正を掘り起こすことです。人がアーキテクチャ全体、要件、コードベースを一度にすべて知る必要のない作業が必要な領域を見つけます。システムをより早く学習するために、ドキュメントの作成に取り組んでもらうことができます。

チームに新しい開発者を追加するのではなく、2〜3か月間経験豊富なコンサルタントを追加して、会社のワークロードの一時的な増加に対処することを検討してください。アイデアは、ほぼゼロの起動時間を処理できる人を獲得することですが、同時にチームに最適な追加とは限りません。

ワークロードの増加は一時的ではないと考えても、チームを有機的に成長させるのに最適な時期ではない可能性があります。厳しい締め切りは、移行を悪化させるだけです。

トレードオフは、一時的な助けと引き換えに、部外者がコードを書くことです。このリスクを軽減するには、両方のユーザーがすべてのコードレビューを必ず行うようにしてください。彼のユニットテストもすべて確認して理解してください。

今すぐ人を追加することをお勧めしますか？

いいえ。可能な場合は、代わりに範囲を縮小することにクライアントに同意してもらいます。

今晩人を追加すると重大なリスクが追加され、期限を延期することはできません（私が理解している限り）。

しないでください。

まだ。

トラディショナルビュー

あなたの質問では、Mythical Man-Monthの Brooksの法則を参照しています。

後期ソフトウェアプロジェクトに人員を追加すると、後でそれが可能になります。

ブルックの法則を無視することには代償が伴います。マルチタスクしないでください。最小実行可能製品（MVP）の配信に焦点を当てます。次に、新しいチームメンバーの採用、人材調達、トレーニング、管理にエネルギーを集中します。

2か月はとても短いです。バーンダウンリストを使用して採用を計画すると、どれだけ時間がかかるかがわかります。

ラリーペイジとセルゲイブリンは、2年を費やしてGoogleの初期チームを選びました。従業員番号3の選択も慎重に行う必要があります。

アジャイル、ニューミレニアムビュー

競争は、神話の男月が書かれた時代（1960年代半ば）よりも、現在、動的なチーム化を推進しています。ある会社での長いキャリアはなくなりました。現在、プロジェクトと企業の間を頻繁に移行しています。迅速なチームビルディングは成功をもたらします。緩やかな立ち上げは、厳しい制限要因です。すばらしい例は、オープンソースプロジェクト、スタートアップ、およびコンピューターサイエンスコースでのチームプロジェクトの使用の増加です。

潜在的に、アジャイルチームはスケジュールに制約を考慮します。利用可能なリソースに最適化されているため、遅れることはありません。新しいスタッフを統合することはもう1つの制約であり、短期目標と長期目標の間のトレードオフと見なされます。アジャイルチームはコードを継続的に統合しています。なぜ人もいないのでしょうか。

新しいスタッフ向けのアジャイルチームの技術的および社会的統合では、以下を使用できます。

• 毎日のスクラム
• ペアプログラミング
• リファクタリング
• 欠落している単体テストを追加する
• 無駄のないドキュメントの肥大化
• コードレビュー

犠牲の子羊

「アジャイルソフトウェア開発の組織パターン」で、 James Coplienはグループダイナミクスと新しいチームメンバーを追加するコストについて説明しています。彼のパターン「犠牲の子羊」は、すべてのメンタリングとトレーニングを1人に割り当て、チームの残りを中断から守ります。

これは、実装を検討する必要がある戦略です。

別の戦略は、毎日特定の時間に新規採用者からの質問を担当する新規採用メンターを割り当てることです。あなたがたった一人の男をspareしむことができれば、おそらく彼は朝または午後に中断することなく働き、それぞれ午後または朝に質問に答えます。私が所属しているグループには、昨年の夏に10人のインターンがいたので、多くの人が大いに中断されました。

現在、メンタリングは、主に午前中のスクラム中と直後（午前8時30分から午前9時15分頃、合わせて）、午後12時から3時30分（午前7時から3時30分まで）に1人で行われます。午後）。

ブルックの法則に言及したことを心から思います。よくできました。別の開発者を追加することの主な問題は、開発者をスピードアップするためのオーバーヘッドと、プロジェクトのどこにいるかについて状態を同期するオーバーヘッドです。したがって、3番目の開発者を取得することにした場合は、これを試してみます。

• 新しい人に、最高速度のコストが低く、できるだけ早く行動を開始できるエリアを提供します。これは、あなたが雇う人と彼らが持っているスキルに大きく依存します。
• 同期のオーバーヘッドが小さくなるように、この領域がアプリケーションの他の領域と疎結合されていることを確認してください。彼をDBの激しい仕事に送り、テーブルを再編成するのは多すぎるかもしれません。
• 士気を保つためにできることをしてください。他の人が指摘しているように、新しいチームメンバーを追加することはストレスになる可能性があるため、炭酸飲料への投資が役立つ可能性があります。

ブルックの法則を厳密に守れば、おそらくチームを成長させることはないでしょう。

秘Theは、あなたの現在のチームにあまりにもスローダウンを起こさずに、新しい人を攻撃することです。最終的には新しい人が追いつき、あなたはこぶを乗り越えることができます。

あなたの場合は？私は新しい人にすべてのそれらの行方不明の単体テストを書くことを勧めます。

1. これらは回帰エラーに対する保護手段として非常に必要です。これは、Brooksの減速よりも速くあなたを燃やすでしょう。
2. 新しい人はあなたのシステムの根性を学びます。火災による試練のようなものですが、彼らの出力は本番用のコードには入らないので、リスクはほとんどありません。
3. 他のチームメンバーが費やすことができる時間に厳しい制限を設けます。たとえば、質問をキューに入れて、期限が切れるまで、他のチームメンバーと1日30分だけ対話できるようにします。

また、それに直面しましょう。新しい人を連れてくるかどうかに関係なく、範囲とクライアントの期待を管理する必要があります。ペイオフは次のサイクルに来ます。

エド・ユアドンはブルックの法則について素晴らしいコメントをしました。彼は言う：もちろん、人を追加すると遅くなるが、プロジェクトが危険にさらされているとき、管理者が新しい人を雇うのは唯一の時間だ。だから：それらを取り、現在のリリースへの影響を最小限に抑え、できるだけ早くパフォーマンスの悪い人を取り除く。このようにして、時間をかけて強力なチームを構築できます。

他のプロジェクトに取り組んでいる場合は、現在の2人の開発者が時間の余裕ができて、役立つ期限の大きな成果物に集中できるようになります。

元の作業の25％に加えて、新しい作業を完了する必要があると言います。また、2か月でこれを行う必要があります。作業の75％を行うのに18か月かかりました。率直に言って、これはあなたの評価能力がコード中心のプログラマーにとって平均的であることを私に示しています-つまり、あなたは物事が本当にそうである限り約半分から三分かかると思います。

Heroicsを使用すると、契約した製品を提供できる場合がありますが、あなたや顧客に利益をもたらすことはありません。これらの条件の下では見掛け倒しでバグが多くなり、ヒュームで走ります。

雇用に費やす時間も可用性に大きな影響を与えることに留意してください。これは週末にできることではなく、適切な人材を見つけるのに時間がかかります。検索、インタビューなどに少なくとも数週間を費やすことを期待してください。あなたとあなたの既存の従業員が検索中に週に約10時間の生産的な時間を失うことを期待してください。

私の推薦：

顧客と一緒に座って、頭上にいることを説明し、顧客と協力して範囲を最小限に抑えます。

編集ここで日付を見ました。それでどうやって終わったの？（3か月の質問を投稿してくれたArs Technicaに感謝します;）

調査を検討する方法はいくつかあります。

1. ドメインの知識を新しい人に伝えることに集中しやすいように、期限が過ぎるまで新しい開発者を雇うのを控えてください。これは、いくつかの点で少し難しい場合があるため、私の好みです。

2. 新しい開発者を招いて、ドキュメント、単体テスト、および既存のコードを変更しないその他のものに取り組みます。これは、現在の作業負荷への影響を最小限に抑えるために新しい人を雇う場合に提案することです。

日付はすでに過ぎていますが、これを後で読んでいる人のために。

考慮すべき重要なことは、この状況のクライアントはあなたよりも失うものがはるかに多いということです。彼らはすでに多くのお金を費やしており、彼らのビジネスを成功させるか破るかもしれない重要な出来事があります。すでにお金を持っているので、1人のクライアントを失ってもビジネスに支障はありません。もしそうなら、ひどいプロジェクト管理を超えた他の深刻なビジネス上の問題があります。

あなたの最善の策は、機能の本質的なサブセットをネゴシエートし、それを成し遂げるために残業することです。小規模なサブセットを実現できない場合、またはそのような状況で残業する気がない場合は、おそらくビジネスに参加すべきではありません。これは、他のクライアントを保留にすることを意味するかもしれませんが、あなたの他のクライアントは3人年分の時間を払っていないので、お金がある場所にリソースを置いてください。

スコープをネゴシエートする意思がない場合、失敗するように設定されます。

このプロジェクトを期間内に完全に提供することはできません。これまでに18か月かかったプロジェクトの25％が残っていると思われる場合、少なくとも6か月（〜2人の開発者）が残っています。別の人を追加しても、これは大きく変わりません。

指摘されているように、採用には時間がかかります。私の経験では、少なくとも1か月かかります。その後、トレーニングを追加すると、時間がなくなりました。

これがあなたの役に立つことを願っています。