フィーチャブランチで接線可能なリファクタブルコードを扱う方法

Question

フィーチャブランチで作業しているときに、リファクタリングするコードが、ブランチに関連していないことがわかりました。

新しいユーザーストーリーを作成する必要がありますか？

また、リファクタリングコードのユーザーストーリーをどのように記述しますか？

小規模な修正の場合は、修正するPBIとブランチの作成を正当化しますか？

最も関連性の高いユーザーストーリーを見つけて、タスクを実行しようとするのは貧弱です。

クロスポスト：https://softwareengineering.stackexchange.com/questions/342503/how-to-address-tangential-refactorable-code-in-a-feature-branch

Answer 1

答えは、チームがユーザーストーリーとタスク、およびリファクタリングへのアプローチを使用している方法によって異なります。彼らはあなたがする作業項目にコミットを関連付けるために強制的に任意のポリシーを持っている場合は

をコミットする作業項目の関連付け

は、その後、ポリシーを上書きするかを関連付ける必要がありますどちらか。いくつかの種類のリリースレポートでは、この関連付けが必要になるため、リリース内のすべての変更が表示されることがあります。 おそらく、チームは関連付けを使用してタスクの時間を追跡していますか？その場合は、コミットを関連付けるタスクを作成します。
答えは、チームがどのように関連付けを使用しているかによって異なります。 以前は、リファクタリングを関連付けるためにユーザーストーリー「コンポーネントXを改善する」を使用しました。このユーザーストーリーは、改善を追跡する場所として公開されています。 私の一般的なアドバイスは、不必要な作業（例えば、価値のあるもののために実際に使用されていないタスクの作成など）を避け、可能な限り簡単なことです。リファクタリングをできるだけ簡単にしたいと思っています。

を分岐

は、機能とは異なる時間にメインラインに行くためのリファクタリングの必要性をしていますか？そうであれば、別のブランチが必要です。 リファクタリングが機能と同時に実行できる場合は、機能ブランチでリファクタリングを単純化してリファクタリングしてください。私は少なくとも、リファクタリングのために別のコミットを使用します。