開発者間で作業を分割する最良の方法は何ですか

私のチームと私は、約10年前に開発したサイトを再構築しています。アジャイルでそれをしたいと考えています。

そのため、読書に多くの時間を費やした後（おそらく十分ではない）、開発者間で作業を分割する方法についての質問に苦労しています。

もっと具体的に言うと、サイトは互いにあまり統合されていない別々のモジュールに分割されていると言います。

開発者間で作業を分割するための最良/最も受け入れられている方法は何ですか？

• 作業するために各人に異なるモジュールを与える。
• すべての開発者を同じモジュールに割り当て、モジュールの異なる部分（UnitTesting、DALおよびマッピング、ロジック、UI）で作業を分割します
• すべての開発者を同じモジュールに割り当て、異なるロジック（たとえば、各開発者が特定のロジック（おそらくBLのメソッド）を担当する）と、そのUnitTesting、DAL、およびマッピングとUIによって作業を分割します...

それとも完全に異なるものですか？

私のチームは現在、いくつかのリリースで「アジャイル」になろうとしていますが、大企業の一員であることは簡単ではありませんでした。私は答えを持っているふりはしませんが、観察結果の一部を共有できます。

• モジュールごとの開発者の分割：

  • 人々が孤立して働きすぎると、チームはスキルと知識の相互共有の恩恵を受けないため、注意する必要があります
  • 人々が自分のモジュールに集中しすぎて、全体像が見えないと、計画会議や毎日の立ち上げは、誰にとっても信じられないほど退屈になります。人々が退屈したら、彼らはチェックアウトを開始し、アジャイルがテーブルにもたらす利益の多くを失います
  • 本当によく書かれたコンポーネントもあれば、そうでないコンポーネントもあります。人々が孤立して働く場合、あなたの年長者は後輩を訓練することができません。

• 全員が同じモジュールで同時に作業する

  • あるリリースで、経営陣がチーム全体にアジャイルを課すことを決定し、それが完全に彼らの方法になると判断したときに、それを試しました。絶対的な列車の大破として。通常、1人の開発者が行っていたはずの作業を、1年で9人の開発者から成るチームが行いました。（ここでは大げさかもしれませんが、大したことではありません）。
  • 誰も呼吸室がないように感じた。ソフトウェアを気にしない人は、より大きなパックの一部であるため、グループで希釈されているため、自宅にいるように感じました。ソフトウェアに情熱を持っていた私たちは、9人が同意した範囲を超えて移動したり、外に出たりする自由がなかったため、絶対に息苦しく感じました。
  • すべての会議は永遠に自分自身を撃ちたいと思うようになりました。同じ部屋で意見を持っている人が多すぎて、同じ奇妙なDLLで作業することを余儀なくされました。ホラー。
• 前回のリリースでは、別のものを試すことにしました
  • 何よりもまず、開発グループを3〜4人の開発者からなる小さなチームに分割します。各チームは互いに比較的孤立して作業していましたが、チーム内では人々はより密接に作業していました
  • このアプローチでは、立ち上げが迅速であり、計画会議は4時間に比べて1〜2時間かかります。
  • 各チームは、そのチームの開発者が何に関心を持っているかを議論するだけなので、誰もが参加していると感じます。
  • 各チームの技術リーダーは他の技術リーダーと定期的に話し合い、プロジェクト全体が順調であることを確認します。
  • 特定のモジュールの人々を「所有者」にする代わりに、専門分野を人々に割り当てたため、プロジェクトを最初に開始したとき、人々は独自のモジュールを持っているように感じましたが、数ヶ月後、開発者はお互いのコードを次のように見始めましたエリアが重複し始めました。
  • コードレビューは不可欠です。これは2番目のリリースであり、厳密なコードレビューポリシーがあり、チームの全員がそれを気に入っています。特定の領域の専門家は、他の誰かがそのコードを変更するとき、常にコードレビューを行っています。
  • コードレビューでは、多くの知識を共有しており、チームのコード品質の全体的な改善を見ることができます。また、コードは頻繁にレビューされるため、人々が他の誰かの専門分野に入ると、少なくとも数回はすでにコードを見ている可能性があります。
  • 各チームの大部分は設計レビュー会議に吸い込まれているため、たとえコードを見たことがないとしても、チームが担当するすべてのモジュールの一般的な流れに誰もが精通しています。
  • 私たちはこれを約10か月間行ってきましたが、孤立したモジュールアプローチから始めて、すべての人があらゆることに取り組むようになったように感じます。しかし、同時に、彼らがcr屈であるか、または制限されていると感じる人はいません。そして、彼らがまだある程度の権威を持っていることを確認するために、私たちは彼らを地域の専門家として残しました。

私たちはその最後のことをしてきましたが、改善の余地はたくさんありますが、チーム全体としては非常に満足しており、それは私たちが巨大企業の一員であるときにたくさん言います。

「アジャイルに行った」最初の3回で間違いを犯した重要なことの1つは、人々が仕事をする方法を教えられ、何をすべきかを言われたときのことです。それはあなたのチームがプロジェクトに完全に興味を失い、それからあなたが本当のトラブルに陥る一番の方法です。

代わりに、反対を試してください。チームに、彼らがやりたいことは何でもできると伝え、マネージャー/リーダーとして（あなたがマネージャーであれば、マネージャーにこれらの言葉を繰り返さないようにしてください）、あなたの仕事は彼らが可能な限り生産的で幸せであることを確認することです。プロセスは悪いことではありませんが、プロセスが必要なことに気付いたときにチームを支援するためにそこにあるべきです。

チームメンバーの一部が単独で作業することを希望する場合は、それらを（ある程度まで）許可します。彼らがペアで働くことを好むなら、彼らにそれをさせてください。できる限りあなたの人々が自分の仕事を選べるようにしてください。

最後に、これは非常に重要であり、常に見過ごされています。あなたはこの権利を得ることはありません（あなたがスーパーマン、または少なくともバットマンでない限り）。定期的な回顧会議を開催することは非常に重要です。レトロスペクティブを展開したとき、それらは本によって行われ、それはあなたが座らなければならないさらに別のプロセスのように感じました。それは回顧展の目的ではありません。これは、チームの声に耳を傾け、最も痛みを引き起こす領域を特定し、誰もが仕事に取り組めるように修正するためのものです。どうやらソフトウェアエンジニアは一般に、製品や機能を提供したり、最も重要なメッセージの回顧会議でコミュニケーションをとることを好みますが、それは彼らの利益のためだけにあるということです。最も大きな障害物（または最も簡単な障害物）から始めて、障害物を特定して対処したい

チームとミーティングを行い、ToDoリストを見せ、誰が何をしたいかを尋ねます。

モジュールで考えないでください。機能要素を考えてください。これらの機能要素をユーザーストーリー（またはその他の方法）で説明し、受け入れ基準（おそらく現在のアプリケーションによって定義され、ビジネスが期待する変更）を記述することを忘れないでください。機能要素をバックログに入れます。次に、どの機能を最初に提供する必要があるかをビジネスに優先させます（段階的に繰り返し作業を行い、優先度によって最初に実装する必要があるものがわかります）。

元のアプリケーションの少なくとも一部でこれを入手したら、開発の準備が整います。次に何が起こるかは、選択したアジャイル手法に依存します。重要な部分は、通常、各機能を複数のタスクに分割でき、チームメンバーが実行するタスクを選択することです。これが自己組織化と呼ばれます。アジャイルで始めるとき、自己組織化は、誰かが不人気で人気のあるタスクがチームによって等しく共有されることを確認する助けを必要とするかもしれません。チームが成熟したら、開発者は現在の自己組織との意見の相違をspeakすることをためらわず、チーム内で自動的に処理されます。

最初からモジュールを考えることは良い方法である必要はありません。何らかの理由でアプリケーションを書き換えているため、誤ったモジュール分離に基づく現在のアプリケーションアーキテクチャが、目に見える問題の背後にある隠れた理由の1つである可能性があります。また、既存のモジュールの一部の機能が完全に再定義され、別の場所に移動されることがわかります。

デビッドの答えには同意しますが、詳細な説明から利益を得られると感じました。

• アジャイルとは、これらの決定を行わずにチームにプッシュすることです。そのようなプロジェクトマネージャー/リーダーはいません。チームのみ。
• 仕事を分割する方法を最もよく知っているのは、チームメンバー自身です。
• バックログについて話し合い、次のイテレーション/スプリントで実現したいことを見つけてください。
• 利用計画の火かき棒または類似の方法は、あなたがとにかく分割しようとしているどのくらいの仕事のアイデアを得る、とだけにして、実際のワークパッケージを分割開始し一緒に。

基本的に、要点は次のとおりです。SEの誰もあなたにその質問に答えることはできませんし、それに対するポイントもありません。

多くの場合、最も単純なアプローチが最適です。

いくつかの非常に明確で明確な理由を定義できない限り、testing / log / UI / etcなどのグループにタスクを分割することは避けます。私の理由は、プログラマーが通常の専門分野以外で作業できるようにすると、彼らにとって物事をより面白く挑戦的なものにし、彼らがその分野で開発し成長することができるからです。時間の制約により専門知識に基づいて作業を分割する必要があると感じた場合、最低限でも各開発者が独自の単体テストを実行し、コードレビューと受け入れテストを使用して問題をピックアップする必要があることを確認してください。独自のテストを書くことは非常に機敏で、テスターが利用可能になるのを待つのは非常に無駄です。

これと同じ種類のジレンマに直面したとき、私は次のアプローチを採用しました。

• プロジェクトのスコープ。自分が何に興味を持っているのかを考え、プロジェクトを一連のタスクに分解して機能のリストを作成します。

• 機能の優先順位付け。どの機能を早期に完了する必要があり、どの機能が顧客に即座に価値を提供するかを決定します。開発者が同じモジュールで作業することになっても心配する必要はありませんが、コードのマージを管理するための適切なプロセスとツールを用意してください。

• チームを巻き込んで、開発者に、機能をより簡単に管理できるタスクのリストに分解するための支援を依頼してください。グループとしてレビューし、必要に応じてタスクを調整して、タスクをより簡単に推定できるようにします。

• 各開発者に、実装するタスク、または反復の実行方法に応じたタスクのグループを、開発者が作業を希望する優先度キューの先頭から選択するように依頼します。

• 優先度キューの先頭から次の項目を選択する前に、完了するまで各開発者に1つのことだけを行わせます。社員に時々タスクを変更させたいと思うかもしれませんが、これは開発者の時間の面で無駄になります。依存関係のボトルネックがある場合は、タスクの優先順位を調整して無駄を最小限に抑える必要があります。

• 開発者が反復を繰り返して実行することを恐れず、それに応じてリリースを管理してください。これにより、タスクの完了を待つリリース間の無駄な時間を最小限に抑えることができます。

最終的に、アジャイルであることは、チーム、会社、顧客に適したソリューションを見つけることです。最適なプラクティスのバランスを見つけてプロセスを調整するのはあなた次第です。タスクを分割する方法は、はるかに大きなプロセスの非常に重要な部分になりますが、参加を促進し、プロセス関連の問題の解決が困難になることを避けるために、できる限りシンプルに保つ必要があります。

開発者チームの組織的な議論は、フレッドブルックス博士の外科チームに言及せずには完了しません。

基本的な式は次のとおりです。作業単位ごとに1つの外科チーム

手術チームの定義

手術チームの概念は、2つの基本的な考え方に基づいています。

1. クロストークは生産性を低下させるため、作業単位あたりの開発者の数は少なくなります。
2. 高出力の開発者は、低出力の開発者よりも優れています（そして、Brooksによれば、中出力の開発者というものは存在しません）。

外科チームは3〜10人の開発者で構成されています。

1. チーフプログラマー。実際のプログラミングのほとんどを行う高出力の開発者。
2. 副操縦士。別の高出力開発者。プログラミングを行いますが、会議への出席や要件の収集などの管理タスクも行います。
3. 1-8人のアシスタント。 Brooksは、これらをドキュメント、コードクリーンアップ、調査、ツール/アルゴリズムの作成、テストなどの責任を負う開発者と説明しています。60年代にBrooksは正確に8つの役割を提案しましたが、おそらく、プロジェクトのニーズに基づいて割り当てられるべきです。

作業ユニットの定義

さて、チームを編成できるようになったので、何を割り当てますか？

• プロジェクトが非常に小さい場合、これは簡単です。1つの手術チームをプロジェクト全体に割り当てます。
• それ以外の場合は、プロジェクトのアーキテクチャ全体を担当する人またはチームから始める必要があります。ソフトウェアを適切にモジュール化して、作業を追加のサブチームに分割できるようにするのが彼らの仕事です。また、開発チームをあまりthinせないように、アーキテクチャチームも他の作業を行うことができます。

次の3つの基本的な許容可能なパターンが表示されます。

1. 各レイヤーに正確に1つのサブチーム（UI、DALなど）
2. 各モジュール（ホームページ、サポートサイト、ショップ）ごとに1つのサブチーム
3. 2つの組み合わせ（低レベルのフレームワークチーム、および各モジュールのUI中心のチーム）

開発者とモジュール（およびタイムスケール）の数に応じて、一般に開発者に1つの興味深いモジュール（それらに）と1つの挑戦的なモジュール（できれば行っていないもの）を選択させ、残りをスキルレベルと時間の制約。これにより、開発者は作業したいことやプッシュすることができます。

もちろん、これは常に機能するとは限りません...

ここに私がやることがあります：

すべてのモジュールが小さい場合は、各モジュールに作業を与えることができます。それ以外の場合、これを行います：

1. 各モジュールのサイズ、複雑さ、それに必要なスキルを定義します。
2. 各チームメンバーのスキルを定義します。
3. 一緒にうまく働く人と他の人とうまく働かない人を定義します。
4. モジュールスキル要件とチームスキルに基づいて適切に連携する人々のチームに大きなモジュールを割り当てます。
5. モジュールのスキル要件とチームスキルに基づいて、他の人とうまく働けない人に残りのモジュールを割り当てます。

他の人と一緒に仕事をしたくない人が最も熟練している場合、上記は機能しません。これは一般的なケースですので、それに応じて4と5を例外にしてください