アジャイルチームは、技術的負債を扱うタスクのように、純粋に技術的なタスクの計画に難儀する場合がある。このようなタスクは直接的にはシステムを利用する顧客のためにはならないが、問題なく動作するソフトウエアを提供するには避けて通れない。このような技術的なタスクや技術的負債を扱う場合にもユーザストーリーを作るべきだろうか。
"As a Developer…” Is Not a User Storyというブログ記事でBill Wake氏は、顧客の価値にはならないユーザストーリーについて書いている。氏が例示しているのは、"開発者として、私はJenkinsを構成して継続的統合を実現したい"というようなユーザストーリーだ。これをユーザストーリーと呼ぶべきでない理由を氏は説明する。
これらの活動はよいものでもないし重要でもないと主張したいわけではありません。しかし、このような活動をユーザストーリーとして捉えてしまうとチームや顧客を混乱させます。何かをユーザストーリーの形式で記述するにもかかわらず、それがユーザに関係ないことだとしたら、ポイントを外しています。
ユーザストーリーと呼ばずにタスクと呼ぶべきだというのが氏の意見だ。リーンの考え方を適用することで、氏はこのようなタスクを無駄と考えている。
リーンの考え方からすれば、チームの活動の多くは無駄と見なされる可能性があります。しかし、そのような無駄なしにソフトウエアを効率的に開発する方法を私たちは知りません。リーンチームはこのような無駄を"Non-Value-Added But Necessary"として話します。やらなければならないからやる仕事なのです。
氏は、ソフトウエアのユーザではなく開発側の誰かが登場人物になるユーザストーリーに対して批評的に接することを薦める。このようなユーザストーリーを機能的な振る舞いや品質の問題として再解釈し、もしそれが不可能だったらタスクとして捉えるのだ。タスクは開発チームが追跡するが、価値を提供しないのでユーザストーリーとしてバックログに積み上げるべきではない。
(…) チームがタスクを抱えるだろうと認識すると、内部的にタスクを追跡しようとするかもしれませんが、そのタスクが開発しているシステムの進捗に直接貢献すると捉えてはなりません。
how to translate “business value” of things that are technically importantというブログ記事でMattias Marschall氏は技術的タスクをバックログで扱う方法を提案している。氏はユーザストーリーと技術的タスクの関係を説明することから話を始める。
ユーザストーリーはユーザがシステムに求めるものを記述するべきです。純粋な技術的タスクは普通、ユーザストーリーの一部として実装されます。
しかし、特定のユーザストーリーと直接的に関係しない技術的タスクはどうなのだろうか。氏はプロダクトバックログにこれらのタスクを積み上げることを提案する。
技術的タスクをプロダクトバックログに積み上げて優先順位を付けるには、それぞれのタスクにユーザストーリーを作ります。しかし、これはだましていることになるでしょうか。次の2つの質問に答えられればだましていることにはなりません。
- タスクを遂行した結果は誰の利益になるのか
- なぜこのタスクが必要なのか
氏の方法では、顧客のユーザストーリーの一部のタスクにしろ、技術的タスクに特化したユーザストーリーにしろ、すべての技術的タスクをバックログのユーザストーリーで覆うことになる。
技術的タスクをユーザストーリーとして形式化できるなら、利害関係者はそのタスクの必要性を理解し、他のユーザストーリーを含めて優先順位を付けることができるでしょう。
Bastian Buch氏はeffective steps to reduce technical debt: an agile approachというブログ記事で開発者とプロダクトオーナが技術的負債に関連する技術的タスクについて意見が食い違う可能性があることを説明する。
開発者は技術的負債を知っており、これに対処することは重要なことだと認識しています。
しかし、プロダクトオーナは技術的負債を低減する必要性や利点を理解しません。バックログやリリース計画に技術的プロジェクト/ストーリーがあることを考えませんし認めません。
氏はプロダクトオーナが技術的負債を低減することに責任を背負うことを薦める。チームのメンバは技術的負債についてプロダクトオーナと議論し、バックログ上で適切な優先順位が付けられるようにする。
チームはプロダクトオーナがチームの一員であることを忘れないようにするべきです。彼の痛みはチームの痛みであり、チームの痛い身は彼の痛みです。顧客でもチームの雇用主でもありません。SME(内容領域専門家)でありマネージャであり、異なる利害関係者の要求のアナリストなのです。
チームとして、プロダクトオーナに製品の成長が最も重要なことであり続ける、と保証します。しかし、短期的(パフォーマンス)観点はもちろん、長期的(健康)観点も重要だということも含めて保証するのです。
氏は技術的な問題をユーザストーリーにまとめ、解決にどのくらいかかるか、解決すればどのくらい利益があるのか見積もりことを薦める。氏はこのときの利益を“支払い”と呼ぶ。技術的負債が少なくなるからだ。
(…) 私たちはJIRA上で“TechnicalDebtItems”とマークされるストーリーを作りました。これらのアイテムに優先順位を付け、正しい結論に導くために見積もりと支払いの関係を示すチャートを作りました。
視覚的に把握できるようにすることでプロダクトオーナとチームが協力して技術的負債の削減に取り組める。
負債を視覚化し支払いの方法を考えます。(…) こうすることでチームは一番重要なステップに注力できます。そして、有用な副作用があります。プロダクトオーナが技術的負債を把握できるので、他の利害関係者と一緒に働きやすくなるのです。