Paul Tevis氏はスクラムに移行して4ヶ月になるチームにいる。このプロジェクトは非常に多くの技術的負債を抱えており、Tevis氏は、どのようにこの技術的負債を追跡して支払うかという問題と格闘している。Tevis氏は次のように述べた。
私の懸念は、(1) ストーリーのないタスクを追跡し始めるとすぐに、顧客に価値を提供することに集中できなくなることです。そして、(2) このようなタスクを見えるようにしなければ、必要としているほどの進展は見られないでしょう。ストーリーに直接結びつけられていない (または、複数のストーリーにまたがる) 技術的なタスクを処理するために、あなたは何か良いパターンを見てきたでしょうか?
技術的負債とは何だろうか? Ward Cunningham氏が造り出した「technical debt (技術的負債)」という新語は、短期間の目標に合うようにするためにコードベースの品質を落としたときに、企業が負うべき義務のことを指していた。コード品質を考えれば、品質に直ちに対処した場合にかかったコストよりも、後で対処することで常により多くのコストがかかることが分かる。この余分なコストは、技術的負債の「利息」を表している。
Malcolm Anderson氏は、ある状況で技術的負債を引き受けるケースを挙げた。
短期間の技術的負債を引き受けるのには、数多くの理由があります。利息が36%のクレジットカードの例えを使いましょう。あなたは、そのようなカードは使いたくないでしょう。しかし、短期間の状況でそのカードを使うのがビジネス的に有利であることがあるはずです。
あなたがビジネス上の決定をする場合、少なくとも次のことを知りたいでしょう。チームが自発的に技術的負債を引き受ける場合、これらの質問の答えを1つでも知っていることはめったにありません。
- いくらお金を使っているでしょうか?
- どのくらい利息を負担するのでしょうか? どのくらいの期間でしょうか?
- 返済できるくらい十分な収入を得られるでしょうか?
そうすることがいい考えであろうとなかろうと、Tevis氏のケースでは、負債はすでに負うことになっていた。それでは、私たちのプロジェクトで既存の技術的負債を減らすのにもっともうまくいくのは何だろうか?
Roy Morien氏は、技術的負債の支払い方の問題に対して、2つの可能な解決策を提案する。
本当にそんなに難しい選択でしょうか? 「技術的な」開発要求がそれほど重要で、それほど大きく、そして、それほど多いならば、ユーザが直面している開発を一時中断して、それらの技術的問題を調整し、外してしまうのが現実的ではないでしょうか?そうでなければ、チームの残りの人たちは、ユーザ重視のタスクをし続ける一方で、これらの技術的な問題を終わらせるために、開発者を何人か再配置することは可能でしょうか? これは、チームのベロシティに影響するかもしれませんが、だからどうだと言うのでしょうか?
Ron Jeffries氏は、 これら2つのアプローチとは意見が異なります。しかしながら、以下のように述べています。
「技術的負債」に取り組むことは、ストーリーによって動かされている時にもっともうまくいきます。コードベースは、おそらくどこででも作業を必要としていますが、ユーザの直面している理由のためにコードに取り組む所でだけ、その報酬を受け取れるでしょう。粗悪な部分を通り過ぎるストーリーがない場合、その部分に取り組むことは大きな無駄です。
それゆえに、私はいつもどおりに(おそらく少し少ないだろうが)ストーリーを手に入れて、見つけた時よりもきれいにしてキャンプ場を去る「ボーイスカウトルール」に従うアプローチを好みます。言い換えれば、ストーリーが私たちを導くところはどこでも、もっとテストを書いて、もっと攻撃的にリファクタリングしましょう。
このアプローチには、少なくとも次のような利点があります。
- 「最高に分別のある」ストーリーの流れを維持する。
- チームのすべての才能から手助けを提供する。
- チーム全体でクリーンなコードを維持する方法を学ぶようにする。
- ちょうど必要なところで改善に集中する。
- 必要「かもしれない」改善をして無駄にしない。
... そして、おそらくもっとあります。
さらに、「banshee858」は、Jeffries氏のアプローチに素晴らしくぴったり合う (もともとはTobias Mayer氏による) この提案を持ちかけている。
タスクボードのすぐわきに、技術的負債を小さな付箋紙に書いて並べます。プロダクトバックログアイテム (PBI) がスプリントのために選択されたら、技術的負債の一部を見て、PBIに取り組んでいる間に終わらせるべきものを見つけます。PBIの作業範囲にこれらを追加して、機能と技術的負債の部分を完成させるのにどのくらいかかるかを見積もります。そうすれば、技術的負債の作業が目に見えるようになり、優先順位をつけて、実際の価値に結びつけられます。