アジャイルチームにおけるリード開発者の役割は何ですか？
非アジャイル開発チームでは、リード開発者一般的に：
- 標準を設定します（コーディングなど）
- チームの新技術を研究
- チームの技術的な方向性を設定します
- 問題について最終的な発言権があります
- システムのアーキテクチャを設計します
ただし、アジャイルチームの動作は異なります。
- アジャイルチームは、前もってではなく、新しいデザインに依存します
- アジャイルチームは、1人で設計するのではなく、一緒に設計する
- アジャイルチームは、プロジェクトを提供するのに最適な独自の技術的方向性を決定します
これにより、アジャイルチームのリードデベロッパーはどこに残りますか？アジャイルチームにリード開発者を置くことは可能ですか？アジャイルチームは、リードとは異なる責任を要求しますか？
アジャイルでは、リード開発者の機能が変わることはありません。チームの残りのメンバーには、システムアーキテクチャの決定と、どの開発モデルに従っているかに関係なく技術的な方向性を含める必要があります。
布告によって決定を渡すことは、開発チームが実行するためのひどい方法です。アジャイルは、チームの他のメンバーからの賛同をより明確なプロセスにするだけであり、リード開発者はとにかくそうするべきでした。
スクラム方法論にリード開発者の役割が決まっていないからといって、経験豊富なプログラマの意見が最も尊重されているわけではありません。アジャイルは、誰もが自分のことに夢中になって、それをすべて一緒にしようとするのではなく、統一されたビジョンと方向性を設定する必要があります。
アジャイルチームでは、誰もが自分のエゴを脇に置くことになっています。
アジャイルチームの1人のメンバーが他のメンバーよりも多くの経験を持っている場合、起こりそうなことは、経験豊富なメンバーがほとんどのコードレビューに関与し、人々がチームの決定を行うときにその人の経験にしばしば従うことです。
したがって、「リード」開発者は「リード」を継続しますが、彼らの経験の当然の結果としてであり、タイトルの義務付けられた機能としてではありません。
それは、人々が自分のエゴを脇に置くことができる理想的な世界です。幸運を！
あなたは、あたかも彼らがチームから完璧に調和して調和して流れるかのように、新しいデザインとチームの方向性について話します。人々のグループ、プログラマーのグループは特に矛盾を持っています。チームがリードするとき、アジャイルチームでのあなたの仕事は、ウォーターフォールでのレフェリーや触媒のようなものです。たとえば、チームがどのデザインを使用するかについて対立する場合、人々が平等に発言し、メリットについて議論することに固執することを確認します。そして、あなたは、パスが明確でない場合にチームが提案する解決策のアービターになることになります。
これはリードの最も重要な責任の1つですが、多数の人々をチームにするには、他にも多くのことが必要です。優れたコーディングに関する限り、例を設定する必要があり、多くの場合、それを実施します（直接またはそれを行う文化を作成することによって）。スタンドアップで1日に1度はそれをカットするつもりはないので、すべてのチームメンバー間のコミュニケーションを促進する必要があります。
あなたが見落としたもう一つの重要なことは会議です。チームがビジネスマンや他の技術チームなどとやり取りする必要のあるすべての会議にチーム全体を参加させることは実際的ではありません。チームのリーダーとして、あなたはチームの代表です。あなたは会議に行き、彼らが彼らの机に留まり、仕事をすることができるようにします。直接立ち寄る人に邪魔されないように、あなたは連絡先です。そして、外部の世界から情報を取得し（他のチームが取り組んでいること、アジャイルチームが次のスプリントのように見えること、そのオープンリクエストのステータスは何であるかなど）、それらをまとめて伝えます。
要するに、あなたはそれらがスムーズに動くことができることを確実にする潤滑剤です。
アジャイルでない説明は、アジャイルな説明を無効にするものではありません。
アジャイルチームは、前もってではなく、新しいデザインに依存します。
リードデベロッパーの定義について、デザインを前もって作成する必要があるとは言いません。彼は方向性を設定するかもしれません、そして、彼はまだ最初のデザインをレイアウトするかもしれません。そのデザインは間違いなく新興です。
アジャイルチームは、1人で設計するのではなく、一緒に設計する
リード開発者のあなたの定義については、彼が（dictates design）であるとは言っていません。彼はmayに最終的な発言権を持っていますが、貧弱なリードだけが彼の過半数のチームメイトの考えを完全に無視します。反対に、貧しいチームだけが主任開発者の考えを完全に無視しました。
アジャイルチームは、プロジェクトを提供するのに最適な独自の技術的方向性を決定します
繰り返しますが、これはリードが最初にsetこの方向を向いていないという意味ではありません。リードはこのアジャイルチームの一部です。アジャイルでない環境であっても、チームが故意に実行不可能になったとき、またはこの方向を無効にするための新しい情報が提示されたとき、貧弱なリードだけがチームをその方向に行進させ続けます。
質問は他のいくつかの質問を引き起こします。ソフトウェアエンジニアのチームに何をすべきかを伝える資格があると思いますか？それはあなたの経験ですか？それはあなたの上司があなたに渡した面白い小さなタイトルですか？それはあなたの自我ですか？会社での在職期間は？あなたの「パナッシュ」ですか？あなたの「スタイル？」あなたの「リーダーシップスキル？」
アジャイルチームは、「おめでとう、あなたは私たちの超天才です。あなたは超秘密の二重の天才の仕事をすることが許可されている唯一の人です」と言っているバッジや帽子を互いに渡しません。むしろ、焦点はTHE WORK AT HANDです。もしあなたが本当に経験豊富であれば、その経験はあなたのデザインがどれほど上手くいくかを示すはずです。自分で選んだ課題（カード）は、あなたが最も専門的な分野を反映している必要があります。一方、大学を出たばかりの子供がより優れたアイデアを持っていて、40歳のベテランが思いつくものよりもコンテキストに適している場合、なぜ地球上でより貧弱なデザインを採用しますか？私たちの職場はセラピーオフィスではありません-素晴らしいものを構築するためにここに来ています。
それは別の質問をします：「より良い」が何を意味するかを誰が決めるのですか？答えは、利害関係者のチームです。つまり、問題の構築者およびユーザーである開発者、要件担当者、テスター、ビジネス担当者などです。優れたアイデアがある場合は、それが優れている理由を示すことができます。それができない場合、チームがあなたのアイデアの方が優れていると信じる理由はありません。アジャイルは実力主義を奨励します。
では、「開発チームのリーダー」はどうなりますか？アジャイルで？何も-彼らはその名にふさわしいだけです-彼らは実際にはチームの他の人々よりも優れたソフトウェアをよりよく生産することができます。それ以外の場合は、彼らを「リード」と呼ぶ理由はありません。それは単なるバッジまたは面白い帽子であり、意味がありません。多くの人がこれを脅かしています。彼らは、バッジや面白い帽子を「働いていた」ように感じます。優れた開発者は、変な帽子をかぶることはできません。彼らは優れたソフトウェアを構築するために尽力しており、彼らが鳴くまでそれを実行する計画を立てています。それがあなたではない場合は、プロジェクト管理を検討することをお勧めします。あなたはおそらく幸せになるでしょう。
アジャイルの私の経験では、開発チームは全体としてあなたの例が意味するよりも少ない責任を負っています。リード開発者とアーキテクトはトップレベルの設計選択を調整することに任せますが、全体としてアジャイルチームに下位レベルの設計を引き継ぎます。
したがって、主要な開発者は、システムアーキテクチャとテクノロジの選択について引き続き責任を負います。これは非常に重要です。アジャイルは緊急の設計とリファクタリングを奨励しますが、これはコードオブジェクトのレベルで発生するはずです。システム全体としては、事前設計と剛性のレベルを高くする必要があります。そうしないと、プロジェクトが調整不能な混乱になるリスクがあります。
私たちのプロジェクトでは、主要開発者がテクノロジーの選択を義務付け、システムコンポーネントが相互にどのように相互作用するかを設計しました。アジャイル計画会議は、彼の上位レベルの権限内でこれらのコンポーネントを設計する方法に焦点を当てました。余談ですが、これにより、面倒な計画会議の範囲が制限されます。
彼は最後の手段としても機能しました。個々のプログラマーが修正できない問題に遭遇したとき、彼らは先頭に立ち、物事を修正する最終的な責任は彼にありました。