2025-05-22 ユーザーストーリーへの再挑戦
プロダクトバックログでの階層構造について調べた。一般的なエピックやストーリーなどにもうすこし寄せてみたいと考えている。
理由のひとつは現状バックログのタスクの階層構造が適切でなく、タスク間の繋がりが失われるケースがあるためだ。
たとえば、あるユーザー向けに機能を提供することを考える。実装としてバックエンド・フロントエンドの両方に変更があるとする。この場合に 2 つのタスクに分かれることもあるだろう。こういったタスク分割をしたとき、親タスクなしでは、これらはフラットに並んでしまい、関係が捉えづらくなる。相互にリンクすることは可能だが、親子関係ほと明確ではない。両方を完了しないと機能を提供できないにも関わらず、一方が完了すると、もう一方が中途半端になっていることに気づくのが難しくなる。親タスクを In-Progress にして、子タスクの一方が Done で、他方が Not Started なら、親タスクが中途半端なのは明確だろう。
他には、ストーリーの導入による、外向けの価値提供と期間の認識の改善のためだ。
(ユーザー)ストーリーのようなユーザー視点での記述は失われている。以前はそういう記述だった時期もあるが書きづらいだなんだと開発者視点での作業の記述に変化してしまった。すべてのタスクについてユーザー視点にしろとは言わないが、ある階層ではそういった記述にしたほうが良いと考えている。そう考えるのは、作業・変更についての記述になっていると、それによって誰がどう嬉しいのかを見失うことが多いからだ。そこがあいまいなことになっていることのデメリットはいろいろあるが、たとえば変更範囲が不必要に広がることがある。対象ユーザーや想定しているユースケースがいつの間にか広がっているのだ。そも明示していないのだから広がっていることに気づいてさえいない。外向けの価値提供を意識し、そこに集中した実装にすることで、たとえば変更範囲の判断の誤りを防ぎたい。
期間の区切りもいい加減だ。スプリントが作業の進捗報告の区切りになってしまい、誰に何を提供しているのかも怪しいスプリントがある。スプリントが変わってもだらだらと同じタスクを繰り越して続けている。スプリントゴールが大きいタスクの 50% の進捗、みたいなことになっている。強引ではあるがストーリーの単位を 1 スプリントに制限することを試してみたい。小さな価値でもいいのでスプリント内で実現できる単位で計画し、「スプリント」を取り戻したい。
今回はストーリーを 1 スプリント単位・誰が・何を・なぜを明記する形で親タスクとして追加する、そういう再チャレンジしようと考えている。
なんとなく気力が出ず、横になっている。
今日のコミット。