ユーザーストーリーについて。
経緯
システム開発の大きな問題の一つは仕様の誤りや認識のずれであり、
従来の仕様書ではなく、ユーザーの求めるものをストーリーにする方式を
ケント・ベックが提案した。
ユーザーストーリー
<役割>として
<機能や性能>ができる
それは<ビジネス価値>のためだ
3C
Ron Jeffriesが提案した
Card
ユーザーストーリーはカードに書き出す。
Conversation
ストーリーの詳細は、カードを元に会話で引き出す。
運用の一例として、会話の内容の要点はタスク管理ツールやナレッジ管理ツールなどに残す。
タスク管理ツールのidをカードに記述しておくことで、相互参照する。(物理カードの場合)
Confirmation
受入テストによってストーリーが正しく実装されたかどうか確認する
分割単位
動作する機能単位で分割する
動作可能な単位で分割することで、リリースサイクルを早めることができる。
ビジネス価値を高め、フィードバックサイクルを回すことで質を上げることができる。
その他あれこれ
物理カードの制約
- 物理的な広さ
- 機密の関係でカードを出しっぱなしにできない
など、本当は物理カードを使いたいけど使えないという現場って多くないのだろうか?
そもそもそういった制約が多い現場はユーザーストーリー自体導入されない、
という傾向もありそうだが。
ツールかんばん
最近だと Trello, ZenHubあたりが多いだろうか?