スクラムガイド · 作成物とプラクティス
スクラムにおける技術的負債：見つけ方と管理方法
技術的負債とは、急いで書いたコード、不足しているテスト、古くなったツールなど、今日の手抜きによる将来のコストです。金銭的な負債と同様、少しなら役立つこともありますが、管理しなければすべてのスプリントを遅らせます。
要点
- 技術的負債とは、今日の手抜きによる将来のコストです。
- プロダクトバックログで見えるようにしましょう。
- 強力な完成の定義で新たな負債を防ぎましょう。
負債の発生源
- 期限のプレッシャーによる手抜き。
- 弱い完成の定義。
- 自動テストが不足している。
- 古くなったライブラリやインフラ。
- 知識が1人に属人化している。
- 設計を作った後に変わった要求事項。
負債が増えている兆候
- 低下している、または不安定 ベロシティ.
- ユーザーに流出する欠陥が増えている。
- 簡単な変更に時間がかかるようになっている。
- 開発者が特定の領域に手を付けたがらない。
スクラムでの管理方法
- 見える化する： 負債のアイテムを、コストを明確に説明したうえでプロダクトバックログに追加する。
- 完成の定義を強化する し、新たな負債を生まないようにする。
- キャパシティを確保する を毎スプリント、負債の削減のために確保する（たとえばチームの作業の一定割合）。
- 継続的にリファクタリングする を通常の作業の一部として行う。
- スプリントレビューで話し合う で、ステークホルダーがトレードオフを理解できるようにする。
ステークホルダーへの負債の説明
負債をビジネスの言葉で表現しましょう。「この領域は変更に3倍の時間がかかり、本番インシデントの大半の原因になっています。2スプリント投資すれば、今後この領域のすべての作業が速くなります。」
このトピックの無料テンプレート
よくある質問
技術的負債の返済時期は誰が決めますか？
負債のコストを説明する開発者の情報をもとに、プロダクトオーナーがバックログを並べ替えます。
技術的負債はすべて悪いものですか？
いいえ。素早く学ぶための意図的な短期の負債は、追跡して返済する限り賢明な判断になりえます。
技術的負債とは何ですか？
より良い解決策ではなく、手早く簡単な解決策を今選ぶことによる将来のコストです。変更の遅れ、欠陥の増加、リリースのリスク増大として表れます。
技術的負債という言葉を作ったのは誰ですか？
Ward Cunninghamが1992年に、リファクタリングが必要な理由をビジネス側のステークホルダーに説明するために負債の比喩を用いました。
技術的負債はどのように測定しますか？
唯一の尺度はありません。チームは、簡単な変更にかかる時間、欠陥率、コード解析ツール、プロダクトバックログ上の負債アイテムの大きさなどの兆候を使います。
技術的負債はプロダクトバックログに載せるべきですか？
はい。負債をプロダクトバックログアイテムとして見える化することで、プロダクトオーナーは新機能と比較検討できます。
スクラムチームは技術的負債にどのくらいの時間をかけるべきですか？
決まりはありません。多くのチームは各スプリントのキャパシティの一部を確保し、負債による減速の程度に応じて調整しています。
完成の定義は技術的負債をどのように防ぎますか？
テスト、コードレビュー、ドキュメントを含む強力な完成の定義があれば、手抜きがインクリメントの一部になるのを防げます。
リファクタリングは技術的負債をどのように減らしますか？
リファクタリングは、コードの振る舞いを変えずに内部構造を改善することです。定期的に行うことで、技術的負債が蓄積するのを防げます。
技術的負債はソフトウェアだけの問題ですか？
この用語はソフトウェアに由来しますが、古くなったプロセス、文書化されていない知識、コンテンツやデータの応急処置など、同様の負債は他の分野にも存在します。
技術的負債の返済をステークホルダーにどう納得してもらえばよいですか？
変更がどれだけ遅くなっているか、どれだけインシデントを引き起こしているかなど、ビジネスの言葉で説明し、解消によって期待される効果を次の場で示します： スプリントレビュー.