アプリケーションをゼロから設計する際に、ジュニア開発者をどのように関与させるのが最善ですか？[閉まっている]

私たちは3人の開発者（2人の経験豊富な開発者と1人のジュニア）のチームです。

私たちは真新しいプロジェクトを始めました。アプリケーションを設計し、適切なアーキテクチャを選択することに集中して取り組み、コードの最初の行を配置します。その中核、つまりアプリケーション全体の基礎となるものを書いています。

これも簡単なアプリケーションではありません。厳しいパフォーマンス要件、大規模に分散された複雑なエンティティモデルなど。

私たちは皆、特にジュニアの快適ゾーンの外にいます。彼は優れたデザインを事前に作成する経験がありません。私と他の開発者が助けを求めており、私たちは両方ともメンタリングとチームの構築を信じているため、それは問題ではありません。楽しい経験とスキルの最大量を学びます。

新しいプロジェクトには後輩がいないことに気づき、既存のプロジェクトでは後輩が学習し、刺激するための完全なコードベースを持っていたので、後輩にとっては簡単でした。しかし、このアプリにはほとんどコードがありません。始めたばかりです。

私たちはいくつかのアプローチを考えていました：

• 彼に数日間自分で試してもらい、コードに介入して一緒にリファクタリングし、正しい方向に彼を導き、次に繰り返す=>すべてのリファクタリングで彼の間違いを指摘するので、彼にとって楽しい経験ではないかもしれない;
• 彼に私たちの1人とプログラミングをペアリングさせる=>彼は単なる「傍観者」になり、実際に多くの情報を学習したり、多くの情報を要約したりせずに、私たちのすべてに同意するかもしれません。
• 各モジュールのスケルトンを構築し、しっかりとした設計で、不足している部分を追加するようにモジュールを彼に与えます=>私たちの後にピックアップするのは面白くないかもしれません。デザイン全体ではありません。

彼をどうにかして設計に関与させて、彼がどういうわけかそれの外に残されたと感じないようにし、彼が経験から多くを学び、自分で試してみるのに十分な自信を得ることはできますか？

次のガイドラインをお勧めします。

• デザインミーティングにジュニア開発者を参加させ、彼の意見を求めます。これにより、高レベルのデザインを自分で行う準備ができていなくても、全体像を考えることができます。
• ジュニア開発者に割り当てるアプリケーションのモジュールを分離して明確に定義するようにしてください。モジュールの入力/出力およびその他の要件を書面で説明します。簡単にテストできないモジュール、または他のまだ作成されていないモジュールと統合したときにのみテストできるモジュールを彼に割り当てないでください。
• おそらく、ジュニア開発者は、コアアプリケーションのコーディング以外の方法で支援することができます。たとえば、テストコードを作成できます。面倒な作業ではなく、優れたテストスクリプトを作成することは、プロジェクトに貴重な貢献をし、また、ジュニア開発者にプロジェクトをしっかりと理解させます。

ジュニア開発者にどの領域を改善してほしいかによります。私が（非常に）ジュニアだったとき、彼らは私にAPIを与えていました：私は次のような特定の制限されたものを構築する必要があります：

• この関数は、PersonnelテーブルからN人の要員を提供します
• この関数は、個人のIDを指定して、個人統計を提供します

->

タスク：人事レコードがクリックされたときに彼/彼女の統計を表示する人事のリストを含むページを作成します。これは、プロジェクトで以前に作成した簡単なサンプルページです。

与えられたタスクの最も重要な側面は、与えられたリソースによってのみ解決可能であり、それらを変更する必要がないことです。

3つの方法すべてが私によく見えます。実際に10種類のアジャイル方法を同時に試してみると、すぐに良い結果が得られるはずです。少なくとも、どちらが効果的でどれが効果的でないかはわかります（どちらが効果的かはプレイヤーの性格に大きく依存します）。

ケントベックによって最初に記述されたプロセス（例外はどこか覚えていません）に従って、タイピング/シンキングハットが10分（またはその程度）ごとに切り替わるプロセスに固執する場合、ペアプログラミングの問題は発生しません。

設計に他の人を巻き込むことに関しては、設計段階でいくつかの設計ドキュメント（UMLモデルを含む）が作成されると役立つことがわかりました。他の人々（あなたの後輩）は、それらを校正し、レビューし、悪魔の支持者を演じることができます。独立した手付かずのサードパーティのこの役割は、探索的テストなど、実際には非常に有益です-http ://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-boundaries