スキルレベルの異なるチームをどのように管理すればよいですか？

私は友達と一緒にソフトウェアプロジェクトに取り組んでおり、テクニカルリーダーに任命されました。これらの人はどれも悪いプログラマーではありませんが、私は彼らよりもかなり多くの経験を持っています。チームの全員に作業を分散できるようにする必要があります。また、お互いのつま先を踏まないようにする必要があります。彼らがこのプロジェクトを成功させるために必要な品質とスケーラビリティの比較的高い基準を満たしていること、彼らがコミットするすべてをレビューする必要はありません。

マイクロ管理を避けながら標準を維持するにはどうすればよいですか？ダイアグラムを作成し、コードレビューをスケジュールし、壊れる可能性のあるものを修正できると信頼するだけで十分ですか、それともTDDルートに行ってチームが満たす明示的なテストを作成する必要がありますか？

それらのコードの一部を確認し、お互いに確認させる必要があります。チェックインポリスになりたいのではなく、できるだけ頻繁にフィードバックを提供したいのです。レビュアーになると、理解が深まります。彼らにもあなたのコードをレビューさせてください。モデルになりましょう。

サイドノート：年次レビュー中に驚きはないはずです。

とりわけ、できるだけ多くの異なる方法であなたの期待とデザインを伝えます。ダイアグラムは一部の人に適しています。定義されたインターフェイスは他のインターフェイスで機能します。ペアプログラミングも機能します。正式なコードレビューも一部の人々に役立ちます。

また、可能な限り自動化を使用することをお勧めします。

• .Net領域にいる場合は、NDependやResharperなどのツールを使用するようにチームに依頼してください。気に入らない場合は、標準のルールを微調整します。
• 実用的な限りテストを自動化します。

うまくセットアップされていれば、失敗したテストケースや自動検査ツールについて議論するのは困難です。

同じプロジェクトで多種多様なスキルレベルで本当に作業している場合、いくつかの問題が発生します。問題は、いつそれらに対処するかです。彼らはあなたが彼らの支援を受けないほうが良いかもしれないような悪いコードを書くつもりですか？これは個人的な緊張を引き起こすでしょうか？友情を終わらせるつもりですか？あなた以外の誰も答えられないこれらの質問。

全員がチームにとどまると仮定して、割り当てを小さなチャンクに分割し（大きなものはより熟練した男に行く）、完了したら最も熟練した開発者がリファクタリングできるようにすることをお勧めします。QAは、厳密で定期的な間隔で実行してください。とにかくこれは現実に起こることとかなり近い。

可能な限り、雑草を避けてください。どのチームでも、リーダーである場合、危機と全体像のために帯域幅の特定の部分を保存する必要があります。ダイアグラムは優れており、コーディング標準は常に正常ですが、人々が互いの作業をチェックするプロセスをセットアップすることはさらに優れています（クロステスト、ピアレビュー、ペアプログラミング）。チームの全員がスターである必要はありません-チームは通常、個人の弱点を克服できます。

私がお勧めするのは、コーディングで見たエラーを人々に伝えたいという衝動にできるだけ抵抗することです。開発作業の共同レビューの一部として残りますが、他のメンバーよりも多く貢献しないようにしてください。代わりに、あなたが見ているものを見るように人々を奨励し、あなたが見るものが重要である理由について多くの説明を与えることに余分な努力を注いでください。

重複についてあまり心配する必要はありません-賢明な作業のブレイクアウトを超えて、チームメンバーに相互にチェックインするように依頼し、コミュニケーションが行われたことを確認することができます。チームはコンセンサスを達成する方法としてお互いをすぐに見始め、それによって仕事が約20倍簡単になります。その後、主要な分野が一致しない場合に必要なのはタイブレーカーだけです。

次に、チームをまとめて確認する手間を省きます。各人には、いくつかの素晴らしい長所と魅力的な弱点があります。理想的には、チームの生産性を損なわない方法で弱点を克服する機会を与えながら、自分の強みに合った人に仕事を投げかけ始めます。

チームリーダーシップの究極のゴールドスターは、弱点を人々に認識させ、動機付けを行い、修正を開始するのに十分な情報を提供することです。

座って、チームの全員が同意する技術とツールのセットについて議論します。一部の人々は、チームの他の人々よりも合意されたツールに精通している可能性があるため、より経験のある人々は、経験と知識を他の人と共有することを喜んで同意する必要があります。

標準（命名規則、コーディングのベストプラクティス、フォルダー構造など）について話し合い、同意し、書き留め、モデル化し、伝えます。

継続的かつ定期的なテストとQAチェックを行います。矛盾が見られたら、できるだけ早く人に通知してください。

「チームで最も経験のある人を集めて整理してください」と言っていましたが、あなたはその人のようです。

可能であれば、プロジェクトを2つのレベルに分割します。アプリケーション層/ドライバー層は適切な分割です。チーム内で2つのサブグループを形成し、各レベルで1人ずつそのレベルを担当させます。それは非常にうまく機能します。

辞任してください。特に早い段階で、彼らがコミットするすべてをレビューしなければなりません。すべてが泳いでいる場合は、コードを目で見て見てください。確認するのにそれほど時間はかかりません。また、物事が順調に進んでいるという自信を得ることができます。誰かがセマフォを誤って使用している、または独自のバージョンのライブラリ関数またはそのような狂気を書いている可能性が高いでしょう。私の経験では、コードの問題を解決するためにコードを監視する必要があります。

あなたの会社の技術リーダーに通常期待されることは何ですか？私はマネージャーで、この場所に数回来ており、今週から再びやろうとしています（20年と4年の経験豊富な人々のチームに参加する初心者や他の人を雇います）。

私はマネージャーであり、技術的なリーダーになることができます（ここ数年、私は後者の役割を果たしてチーム内のリーダーシップを高めました。いずれにせよ、いくつかの考え：

• チーム全体のスキルと弱点を評価します。
• 成長計画を作成する-最も弱いメンバーを成長させることに焦点を当てている間、個人としてもチームとしても全員を成長させることに集中する必要があります。
• この計画を伝え、全員の期待を設定します。
• 学習と検証をチーム全体に配布します。あなたがリードとして、私が仕事の大部分を所有している間、仕事を分配することはあなたのより上級のチームメンバーをリーダーに助けるでしょう。
• 定期的なフィードバックループを作成します。チームメンバーと会って進捗を評価し、フィードバックを提供します。
• 成功を保証するために、必要に応じて計画を調整します。
• 誰かがうまくいかず、合理的な支援があっても、それらを押し出す準備ができていない場合。これは複雑ですが、計画と期待を設定し、フィードバックループを提供すれば、それを行うためのはるかに優れた立場になります。
• チームの士気に注意してください。この種の状況は、チームを成長させたり、ばらばらにしたりするために素晴らしいことをすることができます。あなたのリーダーシップスキルとチームへの投資は、結果を出すのに大いに役立ちます。

「ソフトウェアアーキテクチャ」の定義に含まれるものを調べてみてください。個別に開発可能なモジュールを作成することは、事前の設計と分析を行う主な理由の1つです。この種の作業を行うのはスタイルに合わないことを知っていますが、新しい開発方法が支持する一部のケースとは対照的に、すべてのケースで機能します。

チームで最も経験豊富な開発者として、あなたの重いコーチングに期待しています。

チームにkanbanを使用して自分自身に仕事を割り当ててから、丸1日かけてそれぞれとペアプログラミングを行います。

あなたが悪い習慣や何かを見るとき、彼らは（すべて）知っているべきであり、すべてを止めて、ホワイトボードに描いてください。

数週間後、チームの全体的なスキルがあなたのものに近づくので、あなたは重いコーチングを遅くすることができます。

あなたの立場から見直そうと思うリストがいくつかあります。

1. このチームをどれだけよく知っていますか。チームの全員の長所と短所を知っていますか？各人を最大限に活用する方法を知っていますか？誰にとっても比較的公平な方法で作業を分割する方法を知っていますか？これらの種類の質問は、一部の人々が自分の見方を変える可能性のあるスキルを開発する可能性があるため、これらのリストに時間が経つにつれて変化する可能性があることを尋ね、理解するものです。あなたが任命されたとき、チームの何人かがあなたに持っていた期待がありましたか？その最後の質問は、人々に正直に答えさせるのは難しいかもしれませんが、議論されていることが非常に個人的なものである場合、犯罪やcanりをかき乱すことなく有意義な方法で開示および議論できる場合、それは非常に役立ちます人。グループ会議で個人的な意見を求めようとしないでください。

2. 自分をどれだけよく知っていますか。ここで技術的な権威を主張するために、あなたの経歴のどの要素を使用していますか チームにどのような長所と短所をもたらしますか？定期的にtrenchに入ることを期待していますか？あなたが見た中で、彼らを導くためにこのチームに紹介したいプラクティスがありますか？過去の経験から、チームが行っている作業にこれらのいずれかが現れ始めているかどうかを確認するのに役立つかもしれない警告サインがありますか。

ある意味では、これはすべてコミュニケーションに帰着します。幸運を！

いくつかの技術トピックの定期的な（毎週）プレゼンテーションを行い、グループを中心に回転させます。そうすれば誰もが何かを学ぶでしょう。そして、若いメンバーにもプレゼンテーションをさせましょう。何かを教えることよりも、何かを本当に理解するより良い方法はありません。トピックの選択を支援する必要がある場合があります。

話をする方法についてのコーチングは、皆のためにあるかもしれません。大学の教授が私のためにそれをしてくれたので、とても助かりました。