技術的な負債/技術のアップグレードは、機能（ポイントを与える）または雑用（ポイントを与えない）としてスケジュールする必要がありますか？
Pivotal Trackerの技術的負債のユーザーストーリーに対して、私たちは何をすべきですか？これらを特徴（ポイントを与える）または雑用（ポイントを与えず、速度を下げる）と見なす必要がありますか？
私は雑用と見なされるべきものを混乱しています：
コードの複製-同じコードを複数の場所に配置した場合、それはコードの実践としては非常に悪いことであり、チームの開発者がソフトウェアを保守可能にするためにもっと考え、リファクタリングを行い、コードレビューに時間を費やす必要があることを示しています。これにはすべて、成熟度、時間、コードレベルの経験が必要になるため、提供するポイント数を少なくして、コードの品質が損なわれないようにすることをお勧めします。したがって、そのような間違いは罰せられるべきであり、雑用にポイントを与えないことによって速度を下げる必要があります。
テクノロジーのアップグレード-JS、HTTP2、React、MVCまたはその他の新しい/より優れたテクノロジーのモジュール化への移行と同様。これらの手順により、コードのパフォーマンスとメンテナンスが改善されます。しかし、これは雑用か機能か？これがテクノロジーの世界のあり方であり、新しいテクノロジーが時々登場し、それに移行する必要があると私は信じています。したがって、そのような作業に対してチームの速度にペナルティを課しても意味がありません。提案？
レガシーコードの複製/サブスタンダードコード-長い間変更されていないコードはほとんどありませんOR新しいチームが結成されたがコードベースが少し古い場合、この課題に直面します。チームはこのセクションをコーディングしていないので、なぜそれらの負債を作成したことがないので、そのような技術的負債を選ぶことによって彼らの速度がペナルティを科されるのかと言います。
ビジネスの緊急性による標準以下のコード-競合他社/ターゲット/ビジネス/ユーザーのプレッシャーにより、開発者は機能をできるだけ早くプッシュする必要があります。そのような悪いコードの片付けも雑用（ポイントを与えない）と考えるべきでしょうか？今回は開発チームに問題はないので、なぜ彼らの速度を下げなければならないのですか？.
上記のすべての種類の雑用は、賢明に行えば、将来的にチームの速度を向上させるはずだと思います。しかし、チームの速度を維持しながらバランスの取れたバランスを保ち、チームが悪い決定を下すことで技術的なミスを罰する必要があるでしょうか。
質問は似ています： 技術的な負債は機能または雑用（またはバグ）としてスケジュールされますか？ ですが、4つのポイントすべてをカバーする説得力のある回答が見つからなかったため、再投稿しています別の方法。
短い答え：技術的負債の返済は面倒です。エンドユーザーに新しい機能を提供するわけではないため、指摘されません。
公式回答：
バグや雑用はデフォルトでは推定できません
特集記事は、ビジネス価値に貢献するため推定されています。バグと雑用は、通常のソフトウェア製品のオーバーヘッドの一部と見なされます。これらは時間の経過とともに発生し、継続的なオーバーヘッドであり、ビジネスを行うための継続的なコストです。トラッカーの自動速度計算では、これが組み込みコストとして考慮され、ビジネス価値のある作業を各反復でどれだけ完了できるかが見積もられます。これにより、計画をビジネス価値、リスク、優先順位に集中させることができます。そのため、トラッカーのバグや雑用は通常推定されません。プロジェクト設定でバグや雑用の見積もりを有効にできます。ただし、バグと雑用の見積もりをオンにすることはお勧めしません。気が変わった場合、後でオフにすることはできません。
https://www.pivotaltracker.com/help/articles/planning_with_velocity/#bugs_and_chores
バグや雑用として分類されたストーリーは、PTのデフォルト設定では見積もりを割り当てることができないのはこのためですが、これらのタスクをポイントとして取得するためだけの機能としてカウントしない方がよい理由についても説明します。
まず、速度の低下をペナルティとして数えるべきではないと思います。それは単なる情報です。おそらく、新しい人が加わるなど、トレーニングに余分な時間を費やす必要があったのは自然なことでした。おそらく、容量が減ったり（病気など）余分に消費されたり（たとえば、「世界を止める」バグ）予期せぬ事態でした。おそらく、何らかの理由で機能を十分に評価していなかった可能性があります。これはあなたが学ぶことができるものです。あるいは、チームとして、新機能の提供よりも技術的な負債の支払いを優先することを決定したためかもしれません（おそらく、より多くの負債を負うことになるでしょう）。
第二に、技術的負債を負うことは必ずしも間違いではありません。それを負うことは理想的ではありません偶然、しかしあなたが例えばたとえば、ユーザーフィードバックを増やしたり、厳しい締め切りに間に合わせたりできるように、後で整理する必要があるという知識のもとに、「迅速かつ汚い」ものを構築します。これは、チームとして作成した意図的な選択であり、大丈夫です。
エンドユーザーが気にすることはありますか？SEOの改善について言及している：これは何かまったく興味がありますか？彼らが気にかけるパフォーマンスかもしれませんが、一方で、ロードタイムが数百ミリ秒オフになっている同じ機能よりも新しい機能が必要になるかもしれません。いくつかの調査を行います。行き、彼らが欲しいものを彼らに尋ねます。チームの時間を過ごすのに最適なものを優先順位付けできるように支援します。
現在のテクノロジーの選択により、特定の機能を必要なだけ効率的に提供することが妨げられていると判断する場合があります。その場合、アプリケーションのすべてまたは一部を新しいものに移行するのに（意図的に）時間をかけることは完全に合理的です。
上記のすべての種類の雑用は、賢明に行えば、将来的にチームの速度を向上させるはずだと思います。
ここで私はあなたに完全に同意しますが、これらの家事の二重カウントのポイントを獲得していませんか？後でより多くの機能を提供できるように作業を行っている場合は、より速い速度が表示されますafterではなく、完了しましたwhile実行中それ。
また、コードレビューや配信プロセスの基本的なリファクタリング（例：TDDサイクルの「リファクタリング」部分）などは、すでに進行中の作業の一部であり、チームの全体的な速度の一部としてすでに含まれているはずです。
開示：私はピボットで、ロンドンのピボタルラボで働いていますが、トラッカーチームではありません。
ただ逆らうために、私たちは他のPBIと同様にバグと技術的負債を扱います。実際、「バグ」タイプすらありません。すべてがPBIです。私たちのバックログは、PBIに割り当てられたビジネス価値によって並べ替えられます。その結果、問題を引き起こしているユーザーが直面する顕著なバグには、ビジネス上の価値が高く割り当てられます。一方、実際にはあまり影響がなく、収益に影響を与えないバグは、ビジネス価値が比較的低く、しばらくは修正されない可能性があります。それは取り壊されるべき重要な精神壁です：すべてのバグが修正されるべきではありません。冒涜のように聞こえるかもしれませんが、バグの修正に伴う労力がそれをもたらすビジネス価値よりも大きい場合、ROIはマイナスになります。すべてをPBIとして扱うことにより、「バグ」であるという理由だけで、気が散ることなく、こうしたタイプの経験的な決定を自由に行うことができます。
同様に、技術的負債があっても、ビジネス上の価値はまだ非常に多く残っています。一部の技術的負債は、ほとんど費用がかからずに長期的に残る可能性がありますが、一部の技術的負債は時間の経過とともにビジネスを停止させるため、非常に高いビジネス価値があります。重要なのは、すべてが単なるPBIであることを認識することです。すべてがバックログに入り、ビジネスに付加する価値に基づいて、そのバックログのアイテムに取り組みます。それが機能、バグ、または技術的負債であるかどうかは、実際には重要ではありません。
これには、質問を完全に回避するという利点もあります。すべてがPBIであるため、すべてが速度に寄与します。実際の速度ではなく実際のサイズではない作業を行うという考えは、私にはちょっと狂気です。基本的に、経験的データに巨大なブラックホールを作成しています。速度はすでにかなり大まかなメトリックであり、それはさらに多くの推定に基づいた推定に基づいた推定です。追跡されていないさまざまな量の作業を追加すると、その数はほとんど意味がなくなります。チームがスプリントで行うすべてのことは、速度の一部です。