アジャイル開発では、ソフトウェアの「機能」を誰が所有し、どのように開発を管理するのですか？

私の会社の一部の開発チームはアジャイル開発手法に切り替えており、開発者の作業は、2週間の反復サイクルのため、些細なソフトウェア機能について細かい点について話し合い、プログラムするために減少しているようです。また、「開発者なら誰でもバグを修正できる」という考え方もある。私は最近、それらのチームの1つに参加し、同じ会社の別のチームから転勤しました...

開発者はソフトウェアの機能を最初（設計）から最後（実装および単体テスト）まで所有する必要があると強く感じます。アジャイルはこの考えに反しているようです。私の認識に真実はありますか、それともアジャイルの悪い実装を生きているだけですか？

2週間の反復の間、人々は、そのサイクル中のワークロードに応じて、新しい小さな機能とバグ修正をいくらか恣意的に割り当てられます。ソフトウェアの主要な機能の責任を誰も所有していないようです。我々は追加のような、些細なものに倍の愚かな金額を費やす単一などの話、毎日スクラム、コードレビュー、で、2週間の反復中にダイアログに完了ボタンを

では、アジャイルプロジェクトでは、より大きな機能をどのように管理するのでしょうか。責任は誰にありますか：個々の開発者またはチーム全体？どのようにしてマニューシャから自分自身を抽出し、より長期的な目標に焦点を当てますか？どんなフィードバックも価値があります。

チームの取り組みに役立つと思われる場合は、問題を引き起こしていると見られる「開発者なら誰でもバグを修正できる」という考え方を遠慮なく和らげてください。

Collective Code Ownershipと呼ばれることもあるの実践は、Shared Codeアジャイル開発の多くのフレーバーにおける基本原則であり、おそらく皆さんが経験していることです。

Extremeprogramming.orgから：

共同所有権は、プロジェクトのすべてのセグメントに新しいアイデアを提供することをすべての人に奨励します。開発者はコード行を変更して、機能を追加したり、バグを修正したり、デザインを改善したり、リファクタリングしたりできます。誰もが変更のボトルネックになることはありません。

c2.comから：

ExtremeProgrammingは、コードを個々のエンジニアではなくプロジェクトに属していると見なします。エンジニアは必要な機能を開発するときに、任意のクラスを参照して変更できます。彼らはすべてのUnitTestを実行し続ける（そして新しい機能のために新しいものを書く）責任があります。彼らは、CodeOwnershipの状況でクラスの所有者と同じ整合性を保つ義務を引き受けます。

このモードで作業することにより、責任のあるチームは、適切なオブジェクトの責任を維持しながら、新しい機能を追加するためにすばやく移動できます。CodeOwnershipは、UserStoriesの実装時に依存関係とボトルネックを作成します。コードの所有権は、PlanningGameからのコミットメントと競合するため、避けています。（「コードは何もない、物語はすべてです！」）

にはいくつかの明確な利点がありCollective Code Ownershipます。ただし、そのアプローチの不備に最初に気づくのはあなたではありません。ほかならMartin Fowler氏は、アプローチを記載していないというの両極端の間で、嘘Strong Code Ownership（個人「自分」そのモジュール）とCollective Code Ownership。彼はこれを弱いコード所有権と説明しています：

弱いコードの所有権は、モジュールが所有者に割り当てられるという点で[強いコードの所有権]と似ていますが、開発者が他の人が所有するモジュールを変更できるという点が異なります。モジュールの所有者は、自分が所有するモジュールに対して責任を持ち、他の人が行った変更を監視する必要があります。他の誰かのモジュールに大幅な変更を加えたい場合は、最初にモジュールの所有者と話し合うのが礼儀です。

同じ記事で、彼は続けて言っています：

弱い所有権と集団的な所有権のどちらを選択するかは、チームの社会的ダイナミクスに大きく関係しています。どちらも同じように機能し、失敗します。個人的には、特にエクストリームプログラミングのコンテキストでは、集団的なコード所有チームのダイナミクスを好みます。

要するに、アジャイルの原則を真に守るためには、チームは良質で機能するコードにつながるものを実行する必要があるということです。Collective Code Ownershipそれがのグリップを緩めることを意味する場合、それについては何も問題はありません（または反アジャイル）。

あなたの質問に答えるために、私はあなたの質問で言及された状況を私たちがどのように処理するかを説明します：

アジャイルではスクラムフレームワークを使用しています。スプリントプランニングとバックロググルーミングセッションは、チームが比較的適切に定義されたストーリーを分析するのに役立ちます。

チーム全体では、全体として、スプリント（すべてのストーリー）に対するコミットメントの結果に責任があります。彼らはチームとして成功または失敗します。したがって、チーム全体は、スプリントでジョブを実行するために作業を管理する方法に影響を与えます。

開発者が（スタンドアップで）取ったストーリーカードは、スプリントの最後にリリースする準備ができて完了し、サインオフする責任があります。ただし、チームは毎日のスタンドアップを使用して、ストーリーに苦労している人がいるかどうかを確認してから、開発者が優れたタスクを完了するのを支援する必要があります。

私たちの場合、スクラムでは、元のスプリントコミットメントの一部ではない何かが私たちに与えられた場合、それを「計画外の作業」として追加します。製品の所有者は、計画外の作業を追加すると、元のコミットメントが満たされなくなる可能性があることを知っています。また、チームにはフラットな構造があり、誰もが管理の役割を果たすべきではなく、すべての人が等しく責任を持ってチームを失敗させないように動機付けられています。

製品の所有者がどの部分を所有しています。彼は、製品バックログのどの項目が他の項目よりも優先されるかを決定する責任があり、時間内に利用可能なリソース全体に基づいて製品を提供する責任があります。

（製品の所有者、およびスクラムマスターを含む）スクラムチームの責任はどのように一部。彼らは、チームの管理方法、知識の共有、自己組織化、毎日の会談（毎日のスタンドアップ）、自分自身の修正（回顧会議）、部門横断的なリソースの確保などを決定する必要があります。

ステークホルダーが私やあなたの仲間ではなく機能を所有しているため、このアイデアは機能の所有にはほど遠いものです。

私のやり方は、苦痛が少ないことですが、ボード上のカードをTODOリストからピックアップしてからDONEに移動するまで、各開発者にカードの責任を持たせることです。機能に含まれる機能に関する限り、機能の所有者はチームリード、SME、BAです。各チームには、チームリード（技術エキスパートおよび支持者）、サブジェクトマターエキスパート、およびビジネスアナリストがいます。

通常、BAは、現在カードに取り組んでいる開発者からの質問に答える男/ギャルです。私たちは全員同じ部屋で作業しているので、チームリーダー（私）、BA、またはSMEのいずれかが同意できないことを聞いた場合は、飛び込んで開発者を小会議室に連れてさらに話し合います。通常、私たち3人は、他の3人のメンバーを話し合いに役立てることができると感じた場合は、そのメンバーを呼び込みます。

確かに、問題について話し合う際に時間の浪費につながることもありますが、通常はすぐに適切な解決策にたどり着きます。

最終的には、開発の準備ができているとバックログ項目をサインオフするのはチームリーダーであり、決定を行う必要があるときに最終的な決定権を持ち、実装が「間違っている」場合に責任を負うのはチームリードです。（「間違った」非難ゲームについて質問しないでください：/）。

会話を聞いている他の開発者は意見を提供することが推奨され、すべてのチームメンバーはショーケースの最後のスプリントの最後に新しい機能がデモされるときに意見を述べます。

tl; dr（私たちの場合）：チームリーダーが機能を所有し、個々の開発者が機能カード（またはバグ、改善、技術的負債など）を最初からテストチームが受け入れるまで作業します。

私が目にする最初の問題は、推定プロセスが少し広がっていることです。はい、開発者は自分たちがどれだけの仕事を期待できるかについて発言権を持つべきです。いいえ、それは、Webフォームにボタンを1つ追加するだけで、開発者が2週間のストーリーになることを意味しているわけではありません（ただし、ビジネスの見積もりプロセスに相当する多くのポイントがあります）。それが現在の状況である場合、プロジェクトマネージャーとしてのあなたは何らかの推測を行う必要があります。

次に、「開始（設計）から終了（実装および単体テスト）まで」と聞いて、最初に頭に浮かぶのは、「間違っている」ということです。単体テストは、開発者/開発チームとしての設計作業の一部であり、最初に実行する必要があります。基本的な要件を取り、「If ... When ... Then ...」タイプの文の単純な「チェックリスト」にそれらを抽出し、それらの文をプログラムがそれらを満たしていることを表明する一連の基本的なテストに変換しますアサーション、したがって要件。これは、テストのアサーションを満たす製品コードの行を記述する前に発生します。単体テストが最後になると、ソフトウェアを実装した後で、単体テストのいくつかの重要な側面が失われます。一般的に、開発者は「緑にプログラムする」ことはできません。

開発者が機能を「所有」している限り、それには賛否両論があります。まず、「自己組織化チーム」からのかなり一般的なシェイクアウトは、開発者がペアまたは3で離れて、彼らが最もよく知っていることに取り組む傾向があることです。このように各イテレーションで行われるすべての作業をチームがカバーできるように、開発者の専門知識の総合的なセットが豊富であると仮定すると、単純にこれを実現できます。開発者が反復から反復まで作業してきたコードベースの領域に集中して慣れているため、これはベロシティにとって良いことです。

ただし、1つの機能を一生所有する1人の開発者は、チームの「トラック数」を低くするため、危険な考え方です（非常に率直に言うと、「チームが機能しなくなる前に、トラックが衝突する可能性のある人数は、特定の人々が最悪の状況に陥り、その結果知識が失われるという最悪のシナリオ。ソフトウェアの「ファイルインポート」機能を割り当てて2年間所有している人が3週間休暇を取る場合、FMLA休暇が延長され、変更されます。仕事、または極端に言えば、本当にトラックに襲われて死ぬのですが、コードベースのその領域は何年にもわたって1人の専属の担当者であったため、その機能を知っている人は他にいません。このコードベースの特定の部分で、あなたは大幅な速度を失うことになります。また、コードベースの動作にほとんど慣れていない新しい人は、コードベース内で変更できることやできないことをまったく知らないままになる可能性があるため、欠陥のある別の問題に直面することになります。 。

代わりに、トラック番号を少なくとも2以上に保ち、より大きなチーム（12以上）で3または4に近い分業を育成することを検討する必要があります。 、何らかの理由で、他の人が飛び込むことができます。特に、ペアやDojoスタイルのプログラミングなどのいくつかのXPテクニック（1人の人が新しいアサーションに基づいて書き込むコードが満たさない要件については、次の男がそのテストに合格するようにコード化し、失敗して別の要件アサーションを追加して渡します）。これらの状況での定義により、あなたはコードを見て、それを開発し、それに慣れるようになる複数の目を持っています。

全体として、アジャイルのアイデアは「軽量」開発を促進することです。アジャイルマニフェストのように、チームメンバーとそのやり取り、そしてもちろん機能する機能的なコードに主な焦点を当てる必要がある場合、チームはプロセスとドキュメントの細部に行き詰まっているようです。アジャイルに固有のプロセスは目的を達成するための手段であり、アジャイルを追跡する方法は1つではありません。SCRUMのような主要なアジャイルフレームワークでさえ、会社、チーム、そして日々のニーズに基づいて順応性があります（このような変更を行う場合は、これらのプロセスによって提供される値の基本的な考え方を心に留めておいてください）。

アジャイルプロセスは、ガイドラインに従ってチームによってチームによって定義され、チームごとに異なる場合があります。ほとんどの場合、そうですが、私の経験では、同じプロセスを反映する2つの異なるチームを見たことがありません。基本的には、最も効率的な開発を行うことを目的としています。つまり、同じコードベースの機能にさまざまな人が取り組んでいる場合もあれば、最初から機能が完了するまで1人が機能の所有者である場合もあります。

基本的に大きな機能（ユーザーストーリーと呼ぶことにします）は小さなユーザーストーリーに分解できますが、1人の同じ人物がそれらのユーザーストーリーを複数のスプリントに分散する機能の所有者になることができます。また、それに応じて、その人は機能の所有者になることができ、機能のすべての作業を行うことはできません。例えば

シナリオ：

• 6週間（3スプリント）と推定される大きな機能。
• この機能は、それぞれ最大2日かかるいくつかのユーザーストーリーに分かれています。
• ユーザーストーリーには、機能開発、単体テスト、相互作用テスト、統合（他の機能との）、統合テストが含まれます

チームは技術的には機能の所有者ですが、開発者は機能のように振る舞うことができます。

• 開発者は機能を書き込みます
• 開発者はユニットテストを書きます
• 品質エンジニアが自動化を作成します
• 別の開発者が統合を保証

このシナリオでは、機能の提供を担当する人が少なくとも3人（複数のQEがいる場合があります）ですが、開発者は機能を所有しており、ある意味で機能しています。もちろん、これには開発者の側でこの特定の機能にもっと専念する必要がありますが、アジャイルの範囲外では意味がなく、同時に単一の機能所有者がいます。