単一のアジャイル作業項目内の「関連」作業の処理

私は4人の開発者のプロジェクトチームに所属しています。単一の作業項目で発生する余分な作業を処理する方法については、長い間議論を重ねてきました。

この余分な作業は通常、タスクにわずかに関連するものですが、アイテムの目標を達成するために必ずしも必要なわけではありません（意見かもしれません）。例には以下が含まれますが、これらに限定されません。

• ワークアイテムによって変更されたコードのリファクタリング
• アイテムによって変更されたコードに隣接するコードのリファクタリング
• チケット周辺のより大きなコード領域を再構築します。たとえば、アイテムで単一の関数を変更した場合、クラス全体を再実行してこの変更により適切に対応できるようになることに気付きます。
• 変更したフォームのUIを改善する

この余分な作業が小さい場合は問題ありません。問題は、この追加作業により、元の特徴点の推定を超えてアイテムが大幅に拡張されることです。5ポイントのアイテムは実際には13ポイントかかる場合があります。あるケースでは、振り返ってみると80ポイント以上であった13ポイントのアイテムがありました。

これをどのように処理するかについての議論では、2つの方法が考えられます。

1. 同じ作業項目で余分な作業を受け入れ、誤推定としてそれを書き留めることができます。これに関する議論は次のとおりです。

   • この種のことを考慮して、スプリントの最後に「パディング」を計画しています。
   • 常にコードを見つけたときよりも良い形にしてください。中途半端な作業をチェックインしないでください。
   • リファクタリングを後で行う場合、スケジュールを立てることが難しく、完了しない可能性があります。
   • あなたはすでにコードの奥深くにいるので、あなたは今この仕事を処理するのに最高の精神的な「状況」にいます。後で戻ってきたときにそのコンテキストを失うよりも、今それを邪魔にならないようにして効率的にする方が良いでしょう。

2. 現在の作業項目に線を引き、追加の作業は別のチケットになると言います。引数は次のとおりです。

   • 個別のチケットがあると、新しい見積もりが可能になるため、実際のポイント数について自分自身に嘘をついたり、見積もりの​​すべてがひどいことを認めたりする必要はありません。
   • スプリントの「パディング」は、チケット要件を完了するための直接的な障壁である予期しない技術的な課題のためのものです。これは、「便利な」だけの副次的なアイテムを対象としたものではありません。
   • リファクタリングをスケジュールする場合は、バックログの先頭に配置してください。
   • それが出てきたときにいくぶん恣意的であるように思われるので、私たちが推定においてこのことを適切に説明する方法はありません。コードレビューアは、「これらのUIコントロール（実際にはこの作業項目で変更しなかったもの）は少し混乱します。それも修正できますか？」これは1時間のようですが、「このコントロールが他のコントロールと同じ基本クラスから継承するようになった場合は、この（数百行の）コードをすべてベースに移動して、これらすべてを再配線しないでください。 、カスケード変更など？」そして、それは一週間かかります。
   • これは無関係な作業をチケットに追加することで「犯罪現場を汚染」し、元の特徴点推定を無意味にします。
   • 場合によっては、余分な作業がチェックインを延期し、開発者間のブロッキングを引き起こします。

追加のものが2 FP未満の場合は同じチケットに入れられ、それ以上の場合は新しいチケットにするなど、一部の人はカットオフを決定する必要があると今言っています。

私たちはアジャイルを使用して数ヶ月しか経っていないので、これをどのように処理するかについて、この辺りの経験豊富なアジャイル退役軍人の意見は何ですか？

アジャイル計画とユーザーストーリーは、プロジェクトの利害関係者とソフトウェアのユーザーに価値と透明性を提供することに重点を置いています。これは良いことですが、優れたアーキテクチャガイドライン、デザインスチュワードシップ、優れた開発手法、および技術的負債の維持の重要性に取って代わったり、含めたり、降格したりすることはできません。

アジャイルは、後者のほとんどが技術的な問題や問題への回答として意図されていなかったため、後者をうまく実行していません。

リファクタリングタスク、技術的な負債処理、および設計作業は、特定のスプリントの個別のユーザーストーリーを考慮に入れるべきであることに私が非常に同意しないことを知っている。これらは、そのスプリントのユーザーストーリーを満たすために開発者が実行する可能性があるタスクにすぎません。

タスクは、指定されたユーザーストーリーをアーキテクチャガイドラインの範囲内で完了し、ソフトウェア全体の優れた設計と開発の実践を維持するのに役立つ割り当て可能な作業の任意の単位であることを忘れないでください。

このため、時間の見積もりはユーザーストーリーではなくタスクに基づいて行う必要があります。これは、複数のユーザーストーリーを完成させるためにいくつかのタスクが重要な理由でもあります。

赤、緑、リファクタリング。それが単一の作業項目の範囲です。変更の範囲をカバーする不合格のテストスイートを作成し、テストに合格するために必要な最小量をコーディングします。次に、テストに合格しながらコーディング基準を満たすようにリファクタリングします。これらの3つの手順はすべて必須です。問題を定義するまでソリューションをコーディングすることはできません。コード行を記述するときにリファクタリングすると、常にYAGNIに違反しますが、テストに合格してリファクタリングしないと、定義上、技術的負債が発生します。最終的に返済しなければならないこと。

この定義とそれに続くことを考えると、13ポインターであることが判明した5ポインターは誤推定でした。リファクタリング作業を検討するとしたら、おそらくリストラのようなものでした。新しい機能を理解しやすく保守しやすい方法で組み込むには、コードベースのかなり重要な領域を再編成する必要がありました。これは通常、チームが開発の一般的な将来のパスを理解できず、最終的に非常にSOLIDであることが必要になる前の反復で非常に簡単に何かが実装されることを示します。バックログでさらに下にあるものを知っているBAとPMの間のより良いコミュニケーションと、現在のスプリントに一般的に焦点を合わせている開発チームは、これを軽減することができます。代わりに、この話は過去の開発で発生した大量の技術的負債を露呈しました、そしてそれは単にチームに追いついた。設計パターンとプロジェクトの一般的な将来のパスに関する概念的な知識に加えて、コードレビュープロセスを改善することで、このような発生を減らすことができます。

覚えておくべきことの1つは、リファクタリングは「理想的でない」作業であることです。アジャイルSCRUMでは、タスクは「理想的な時間」で見積もられます。つまり、存在しなかったまったく新しいコードを書き下ろして、プロジェクトの機能ベースを促進するのに費やした時間数です。8時間の開発者日では、現実的には5時間しか理想的ではありません。時には、特にチームが本当にハミングしているプロジェクトの「ストレッチ」で、6を当てにすることができます。プロジェクトの機能には影響を与えないが、コードベースを他の方法で改善するリファクタリング、または前に戻って変更を加えることは、計画、設計、通信、レビュー、中断、または技術的なダウンタイムのように、理想的ではありません。技術的なダウンタイム以外の非理想的な作業は重要ですが、製品所有者の目には進歩しません。

したがって、リファクタリングが実際の時間を2倍にしない場合、理想的な時間で見積もると、ある程度のリファクタリング作業が予想されます。たとえば、チームのポイントスケールがどのように調整されているのか正確にはわからないため、5ポインターは1週間の理想的な開発者、つまり約25時間の理想的な作業に相当します。13（同じスケールで2週間以上の開発者週）に変わったその5は、複雑さが膨らんだ原因を振り返る原因になります。おそらく、コードベースは実際に行われたほどのリファクタリングを必要としなかったかもしれません。おそらく、新機能を機能させるために解決しなければならないチームには知られていない大量の技術的負債が積み上げられたでしょう。

別のユニバースでは、新しいコードといくつかの以前のビットを適切にパターン化するために10時間の追加のリファクタリングが必要だったため、理想的な時間で見積もられた5が実際の時間に基づいて7（〜35時間）になったと想像してみてください設計アーキテクチャ。その場合、エクストラは、ストーリーがかかるはずの開発者の日数の間の理想的な時間と合計時間の間の「ギャップ」内にあります。したがって、プロジェクトマネージャーとして、私は5が7になったことを妥当な見積もりと呼んで先に進みます。

ストーリーポイントは、特定のユーザーストーリーの相対的な複雑さの推定です。ストーリーポイントを使用していると、これにはX人日/時間かかると思われます。代わりに、2つの目標に向けて努力する

1. 一貫した範囲（3、5、または8ポイント）になるまでストーリーを分解します
2. ストーリーに必要なリファクタリングが含まれていると想定します

時間が経つと、速度のベースラインが得られます。5ポイントのストーリーごとに他のストーリーと同じ時間はかかりませんが、スプリントごとの平均速度（チームが完了できるストーリーポイントの数）は一定です。

特定のストーリーにかかる時間を心配することは逆効果です。推定値は、ボリュームが一定のサイズのストーリーの平均のみです（つまり、リファクタリングのために1つの5ポインタが少し長くかかる可能性がありますが、関連するものに対するその努力の利点を理解します）。

元のワークアイテム内にある量と、他の何かにある量の相対的なカットオフがあるはずです。ユーザーストーリーはディスカッションの開始点であり、したがって、ストーリーの作業中にスプリント中に釘付けになるあらゆる種類のスコープ要素が存在する可能性があります。

スプリントの計画において、ストーリーが「スコープクリープ」を回避するために追加の基準が追加される場合があります。これは、ユーザーが新しいフォームを必要とし、次にそのフォームに101の変更が現実的でない場合に起こります。 2週間のスプリントで時々完了する。

心に留めておく必要があるのは、この余分な作業からどれだけの価値が得られるかということです。実行できる可能性のあるリファクタリングはたくさんあるかもしれませんが、そのすべての作業に対してだれにとってもどのくらいのメリットがありますか？これは、チームを適切に機能させるためにいくつかのガイドラインが必要ですが、コードを完璧にしようとすることに迷うことはありません。