単一のアジャイルワークアイテム内での「関連する」作業の処理
私は4人の開発者のプロジェクトチームに所属しています。単一の作業項目の過程で発生する余分な作業を処理する方法について、長い間議論してきました。
この余分な作業は通常、タスクにわずかに関連するものですが、アイテムの目標を達成するために必ずしも必要ではありません（それは意見かもしれません）。例には以下が含まれますが、これらに限定されません。
- 作業項目によって変更されたコードのリファクタリング
- アイテムによって変更されたコードに隣接するリファクタリングコード
- チケット周辺のより大きなコード領域を再設計します。たとえば、アイテムで1つの関数を変更した場合、この変更に対応するためにクラス全体をやり直すことができることに気付きます。
- 変更したばかりのフォームのUIを改善する
この余分な作業が少ない場合、私たちは気にしません。問題は、この余分な作業によって、元の特徴点推定を超えてアイテムが大幅に拡張される場合です。 5ポイントのアイテムは実際には13ポイントかかる場合があります。あるケースでは、振り返ってみると80ポイント以上であった13ポイントのアイテムがありました。
これを処理する方法については、2つのオプションがあります。
同じ作業項目で余分な作業を受け入れ、それを誤推定として帳消しにすることができます。これに対する議論は次のとおりです。
- この種のことを説明するために、スプリントの最後に「パディング」を計画しています。
- コードは常に、見つけたよりも良い形のままにしてください。中途半端な仕事をチェックインしないでください。
- 後でリファクタリングを残すと、スケジュールを立てるのが難しく、完了しない可能性があります。
- あなたはすでにコードに深く関わっているので、今この作業を処理するのに最適な精神的な「コンテキスト」にいます。後で戻ってきたときにそのコンテキストを失うよりも、今それを邪魔にならないようにして効率的にする方が良いでしょう。
現在の作業項目に線を引き、追加の作業は別のチケットになると言います。引数は次のとおりです。
- 別のチケットを持っていると、新しい見積もりが可能になるので、実際に何ポイントあるかについて自分自身に嘘をついたり、すべての見積もりがひどいことを認める必要はありません。
- スプリントの「パディング」は、チケット要件を完了するための直接的な障壁となる予期しない技術的課題を対象としています。これは、「Nice-to-haves」だけのサイドアイテムを対象としたものではありません。
- リファクタリングをスケジュールしたい場合は、バックログの一番上に置いてください。
- それが出てくるときそれは幾分恣意的であるように思われるので、私たちが見積もりでこれらのものを適切に説明する方法はありません。コードレビューアは、「これらのUIコントロール（この作業項目で実際に変更しなかった）は少し混乱しますが、それも修正できますか？」と言うかもしれません。これは1時間のようなものですが、「このコントロールが他のコントロールと同じ基本クラスを継承している場合は、この（数百行の）コードをすべてベースに移動して、これらすべてを再配線してみませんか。 、カスケード変更など？」そしてそれは一週間かかります。
- チケットに無関係な作業を追加することで「犯罪現場を汚染」し、元の特徴点の推定を無意味にします。
- 場合によっては、余分な作業がチェックインを延期し、開発者間のブロックを引き起こします。
私たちの中には、追加のものが2 FP未満の場合は同じチケットに入れられ、それ以上の場合は新しいチケットにするなど、カットオフを決定する必要があると言っている人もいます。
アジャイルを使用してまだ数か月しか経っていないので、これをどのように処理するかについて、このあたりのベテランのアジャイルベテラン全員の意見は何ですか？
アジャイル計画とユーザーストーリーは、プロジェクトの利害関係者とソフトウェアのユーザーに価値と透明性を提供することに重点を置いています。これは良いことですが、優れたアーキテクチャガイドライン、デザインスチュワードシップ、優れた開発方法、および技術的負債の維持の重要性に取って代わったり、含めたり、降格したりすることはできません。
アジャイルは、これらの主に技術的な問題や問題への回答として意図されていなかったため、後者をうまく実行しません。
リファクタリングタスク、技術的な負債処理、および設計作業は、特定のスプリント内の個別のユーザーストーリーを考慮に入れるべきであることに私が強く同意しないことを知っている。これらは、開発者がそのスプリントのユーザーストーリーを満たすために行う可能性のあるタスクにすぎません。
タスクとは、アーキテクチャガイドラインの範囲内で特定のユーザーストーリーを完了に移行し、ソフトウェア全体の優れた設計と開発プラクティスを維持するのに役立つ割り当て可能な作業の任意の単位であることを忘れないでください。
このため、時間の見積もりはユーザーストーリーではなくタスクに基づいて行う必要があります。これは、複数のユーザーストーリーを完成させるためにいくつかのタスクが重要である理由でもあります。
赤、緑、リファクタリング。これが単一の作業項目の範囲です。変更の範囲をカバーする失敗したテストスイートを記述し、テストに合格するために必要な最小量をコーディングし、テストに合格している間にコーディング基準を満たすようにリファクタリングします。これらの3つのステップすべてが必要です。問題を定義するまでソリューションをコーディングすることはできません。コード行を記述しながらリファクタリングすると、必ずYAGNIに違反しますが、テストに合格した後に自分の後ろに来てリファクタリングしないと、定義上、技術的負債が発生します。あなたが最終的に返済しなければならないこと。
この定義とそれに従ったものを考えると、13ポインターであることが判明した5ポインターは誤推定でした。リファクタリング作業を検討するのは、おそらくリストラのようなものでした。新しい機能を理解しやすく保守しやすい方法で含めるには、コードベースのかなり重要な領域を再編成する必要がありました。これは通常、チームが開発の一般的な将来のパスを理解できず、最終的に非常に堅実である必要がある前の反復で非常に単純に何かが実装されることにつながることを示します。バックログでさらに下にあるものを知っているBAとPMの間のより良いコミュニケーションと、現在のスプリントに一般的に焦点を合わせている開発チームは、これを軽減できます。あるいは、この話は過去の開発で発生した大量の技術的負債を明らかにし、それは単にチームに追いついただけです。デザインパターンとプロジェクトの一般的な将来のパスに関するより良い概念的知識に加えて、より良いコードレビュープロセスは、そのような発生を減らすのに役立ちます。
覚えておくべきことの1つは、リファクタリングは「理想的ではない」作業であるということです。アジャイルスクラムでは、タスクは「理想的な時間」で見積もられます。つまり、存在しなかったまったく新しいコードを真っ向から書き、プロジェクトの機能ベースを促進するために費やした時間数です。 8時間の開発者の日は、現実的には5時間しか理想的ではないかもしれません。特にチームが本当にハミングしているプロジェクトの「ストレッチ」では、6を当てにすることができる場合があります。プロジェクトの機能に影響を与えないが、他の方法でコードベースを改善するリファクタリング、または戻って変更を加えることは、計画、設計、コミュニケーション、レビュー、中断、または技術的なダウンタイムと同様に、理想的ではありません。技術的なダウンタイム以外に、非理想的な作業は重要ですが、製品所有者の目には進歩しません。
したがって、リファクタリングによって実際に費やされた時間が2倍にならない場合、理想的な時間で見積もると、ある程度のリファクタリング作業が予想されます。たとえば、チームのポイントスケールがどのように調整されているのか正確にはわからないため、5ポインターは1週間の開発者の理想的な時間、つまり約25時間の理想的な時間に相当します。 13（同じスケールで2週間以上の開発者週）に変わったこの5は、複雑さが膨らんだ原因を振り返る原因になります。おそらく、コードベースは実際に行われたほどのリファクタリングを必要としなかったかもしれません。多分、新機能を機能させるために解決しなければならないチームに知られていない大量の技術的負債が積み上げられたか、あるいはこれは正直な誤推定でした必要な新しい作業の量（実際にはいくつかの新しいドメインクラスと関連するスキーマの変更が必要な場合でも、チームはドメインの既存の部分を拡張するだけで十分だと考えました）。
別の世界では、新しいコードと以前のビットを適切にパターン化するために10時間の追加のリファクタリングが必要だったため、理想的な時間で推定された5が実際の時間に基づいて7（〜35時間）になったと想像してみましょう。デザインアーキテクチャ。その場合、追加の時間は、ストーリーが想定されていた開発者の日数の理想的な時間と合計時間の間の「ギャップ」内にあります。したがって、プロジェクトマネージャーとして、私は7になった5を妥当な見積もりと呼び、次に進みます。
ストーリーポイントは、特定のユーザーストーリーの相対的な複雑さの推定です。ストーリーポイントを使用して、これにはX人の日/時間かかると言っているようです。代わりに、2つの目標を目指して努力してください
- ストーリーを一定の範囲（3、5、または8ポイント）になるまで分解します
- ストーリーに必要なリファクタリングが含まれていると想定します
時間の経過とともに、これにより速度のベースラインが得られます。 5ポイントのストーリーごとに他のストーリーと同じ時間はかかりませんが、スプリントあたりの平均速度（チームが完了できるストーリーポイントの数）は一定になります。
特定のストーリーにかかる時間を心配することは逆効果です。見積もりは、ボリュームの一貫したサイズのストーリーで平均化されるだけです（つまり、1つの5ポインターはリファクタリングのために少し時間がかかる場合がありますが、関連するストーリーでその努力のメリットを享受できます）。
元のワークアイテム内の量と、他のワークアイテムの量の相対的なカットオフが必要です。ユーザーストーリーはディスカッションの開始点であり、したがって、ストーリーの作業中にスプリント中に釘付けになるあらゆる種類のスコープ要素が存在する可能性があります。
スプリント計画では、ユーザーが新しいフォームを必要とし、101がそのフォームに変更された場合に発生する可能性がある「スコープクリープ」を回避するために、ストーリーに追加の基準が追加される場合があります。 2週間のスプリントで時々完了する。
覚えておくべき裏返しは、この余分な作業からどれだけの価値が得られているかです。実行できる可能性のあるリファクタリングはたくさんあるかもしれませんが、そのすべての作業に対して誰にとってもどのくらいのメリットがありますか？これは、チームをうまく機能させるためにいくつかのガイドラインがなければならないが、コードを完璧にしようとすることに迷わないようにする必要がある場所です。