経験豊富な開発者とは別のサブプロジェクトを新規採用者に提供することで、初心者はより迅速に立ち上がることができますか？

チームには7人の開発者がおり、短期間（約1か月）で開発ペースを2倍にする必要があります。「より多くの開発者を雇えば、最初の数か月間だけ生産性を失う」という常識的なルールがあることを知っています。このプロジェクトはeコマースWebサービスであり、約27万行のコードが含まれています。

現在の私の考えは、プロジェクトを多かれ少なかれ独立した2つのサブプロジェクトに分割し、新しいチームが2つのサブプロジェクトのうち小さい方で作業し、現在のチームがメインプロジェクトで作業することです。つまり、新しいチームはチェックアウト機能に取り組み、最終的にはカップリングを減らすために独立したWebサービスになります。このようにして、新しいチームはコードが10万行だけのプロジェクトに取り組みます。

私の質問は、このアプローチは初心者の開発者が新しいプロジェクトに簡単に適応するのに役立つのでしょうか？初心者がバグよりもソフトウェアの生産を開始するまで2か月待たずに開発チームを迅速に拡大する他の方法は何ですか

=======

更新

この企業は完全に失敗しましたが、皆さんが言及した理由ではありません。まず第一に、私は新しいチームの規模と能力について誤解されていました。自分で評価すべきだった。第二に、そのサイトでの採用は大変な仕事でした。メインオフィスのサイトでは、雇用ははるかに簡単でしたが、2番目のチームの都市では、必要な資格を備えた開発者が明らかに不足していました。その結果、1.5か月を予定していたのではなく、約4.5か月に延長され、その途中でトップマネジメントによってキャンセルされました。

私が犯したもう1つの間違い（およびアレックスDから警告された）は、リファクタリングを経営陣に売り込もうとしていたことです。リファクタリングは決して販売せず、機能のみを販売します。

とにかくスタートアップは成功したことが判明した。決して起こらなかったリファクタリングは技術的な負債に変わりました。システムはよりモノリシックになり、保守性が低下し、開発者の生産性は徐々に低下しました。私は現在チームにいませんが、近い将来に完成することを願っています。そうでなければ、私はプロジェクトの存続に一銭も払わないでしょう。

私はここにいる他の皆と同じように、

「...開発者を遅延プロジェクトに追加すると、プロジェクトが作成され、さらに遅延します...」

私は、あなたがどこでもそれをするつもりだと感じていますので、...

既存のプロジェクトがモジュール、サブシステム、またはサブプロジェクトによって十分に編成されている場合、あなたのアイデアが役立つかもしれません。

試してみたいと思うかもしれないのは、プロジェクト全体ではなく、プロジェクトの小さな断片/モジュール/フォーム/クラスを提供することです。

データベースを使用する場合は、データを含む作業用DBのコピーを作成し、使用するコードのモジュールまたはサブシステムからそれらにアクセスすることができます。

プログラミング言語またはプログラミング環境を知っている新しい開発者がいるだけでは不十分であり、ソフトウェアアプリケーションは非常に複雑になる可能性があります。

UML、ER、Codd-Yourdonなど、アプリケーションのドキュメントはありますか？

幸運を。

私の質問は、このアプローチが初心者の開発者が新しいプロジェクトに簡単に適応するのに役立つかどうかです。

「初心者」とは、あなたにとって新しいことを意味する場合もあれば、ソフトウェア開発者として働くこと自体が新しいことを意味する場合もあります。開発者のグループを雇い、重要なプロジェクトをスケジュールどおりに行う場合は、少なくともほとんどの新規採用が経験豊富な開発者であり、できればあなたがしようとしているものに似たプロジェクトを書いた人であることを確認してくださいビルドします。

バグよりもソフトウェアの生産を開始するまで2か月待たずに、開発チームを迅速に拡大する他の方法は何ですか？

• 独自の製品を構築する代わりに、既存の製品を購入またはライセンスを取得してください。あなたは本当にチェックアウトホイールを再発明する必要がありますか？

• 上で言ったように、あなたが望む種類のシステムを構築した経験のある人を雇ってください。

• この新しいチームを採用する前であっても、既存のものについて彼らが知っておくべきことについて考えるべきです。トレーニングセッションに十分な時間を確保して、トレーニングセッションをスピードアップできるようにしてください。

• 要件の書面セットを作成しましたか？そうでない場合は、今すぐ実行してください。新しいチームに任せるのではなくプロジェクトを設計することを期待する場合は、明確な設計文書も準備する必要がありますが、新しいチームメンバーからの入力に応じて変更を受け入れる必要があります。

• 明確に定義された開発プロセスはありますか？バグデータベース？バージョン管理？コードレビュープロセス？スタイルガイド？それらを適切な場所に置きます。

• 奇跡を期待しないでください。あなたはしたい 7人のチームを雇うために、彼らは数週間のうちに生産的作業が、それはあなたがそれを持つことができることを意味するものではありません希望しています。所在地によっては、7人の適切な人を見つけるのに1か月以上かかる場合があります。今すぐ物事を急いでしようとすると、後で痛みと費用が発生します。

私見では、既存のチームから切り離された新しいプロジェクトにすべての新しい開発者を配置すると、問題が発生することになります。はい、これにより（おそらく）古いチームは現在のペースで多かれ少なかれ作業を続けることができます。しかし、新しい人たちは全体的なアーキテクチャと全体像についての手がかりを持っていないので、スピードに慣れるのに多くの時間がかかります...そしてそれでも彼らは間違った方向に向かっているかもしれません。

既存のチームを2つに分割し、新しいメンバーを両方のチームに雇用することをお勧めします。このように、両方のチームに新参者を指導し、共通の首尾一貫したアーキテクチャのビジョンを維持できる人々がいます。

そうでなければ、明確な要件を文書化し、開発プロセスとツールを定義し、トレーニングの時間を確保することに関して、Calebに同意します。また、7人のチームが1か月以内に採用され、スピードを上げることを期待することは非現実的です。

ドミトリー、短時間で開発ペースを倍増させることは、非常に野心的な目標です。いくつかの良い提案がここに投稿されています。しかし、あなたが何をしようとしても、それが起こらないかもしれないことに注意してください。開発のペースが2倍にならない場合、ビジネスの観点からはどのような結果になりますか？期限を満たすためにプッシュしようとしていますか？

期限に間に合わせようとしている場合、機能をカットすることで確実にそれを行うことができますか？顧客に「期限の遅れ」を受け入れられるようにする素晴らしい方法は、段階的にリリースすることです。必要な機能のサブセットを含むバージョンをリリースし、さらに多くの機能の準備ができたら、最終リリースまで段階的にリリースします。

ですからあなたは神話男月の犠牲にならないチームになろうとしています。いくつかの問題があり、チームの誰かが技術面接を行わなければなりません。そして、彼らがポジションを受け入れてから開始するまでに数週間待たなければなりません。新しい開発者がキーボードの前に立つまでに2か月かかる場合があります。

すべての新しい従業員は、最初の数か月で生産性が低下します。さらに悪いことに、現在の開発者はそれらを指導する必要があり、生産性がさらに低下します。

MMMのもう1つの部分は、チームが成長するにつれて通信の問題も増加することでした。会議が大きくなり、メールチェーンが長くなります...

私はそれらをより小さなグループにまとめ、生産性がチームの規模の拡大に比例しないことを長い間知っています。また、搭乗費用と設備により、最初の数か月間のキャッシュフローの流出が著しくなる可能性があることも理解してください。

アレックスDへのコメントの中で、「私たちの期限ではなく、新しい機能を提供する実証可能な能力」と述べました。そのため、機能を小さなチャンクで、より頻繁にロールアウトする開発スタイルに切り替えます。チームの新しいメンバーに新しい機能をテストしてもらいます。これは、コードベースを理解するのに役立ちます。

誰も新規採用せずに、プロセスを見て、どこで変更を行うことができるかを確認して、物事を迅速に進める方が良いでしょう。バグが早く発見されると、バグの修正にかかる時間が短くなりますが、どのようにテストしていますか？コードレビューを行っていますか？要件の品質に注意を払っていますか？ビルドとデプロティメントプロセスを自動化しましたか？自動テストはありますか？毎日のスタンドアップミーティングを行っていますか（誰かが毎日あなたの健全性を尋ねてきたときに、どれだけ速い開発ができるのでしょうか！）？アジャイルプロセスを使用していますか？開発の残りの部分を高速化するために対処する必要がある基本的な設計上の欠陥がありますか（設計が不適切な場合、開発プロジェクトが非常に遅くなる可能性があります）。

神話マン月を読んでください。プロジェクトをスピードアップするために摩耗した選択をする理由を上級管理職に伝えることができるようにする必要があることは明らかです。。

だから、あなたは彼らを崖から投げ捨てて、彼らが飛ぶことができるかどうかを見たいですか？あなたが自分で物事を発見すると、彼らはあなたに解決策を与えるだけでなく、長期的にはあなたに固執する傾向があると思います。ただし、実際にはより優れたソリューションを発見することを前提としています。このチームに、質の良い例から学ぶことで指導や指示を与えながら、自分でいくつかの間違いをさせてバランスをとる資格のあるリーダーを持たせることができない理由はわかりません。