自分たちのチームは『ストーリー』という単位で仕事をしている。ストーリーがなんなのかわからないと朝会のことかいても意味わかんないかもしれないので、先にストーリーについて書きます。よくあるバグ管理のチケットや、タスクとは全く違うものですよ。
ストーリーとはXP（Extreme Programmmig）でてくる"User Stories"から生まれたものだそう。一般的な？アジャイル界隈では計画ゲームとかに使ったりするのかな？原文だとなんだか小難しい...
- http://www.extremeprogramming.org/rules/userstories.html
- http://www.extremeprogramming.org/rules/planninggame.html
自分たちでは、ユーザーが動かしてわかる事象の一つを1つのストーリーにしている。なんとか機能とか、なんとか処理とか大雑把なやつではない。あるストーリーが始めるときには、次のことがだいたいきまって始まる。
- ユーザーはなぜ？どういう目的で「それ」をするのか
- ユーザーは「それ」をするとどんなことができるか
- その次にユーザーはどんなことをするのか
いくつもストーリーが反復しながら進化していくことで大きな機能（処理）が完成する。ストーリーが1つできあがると、それまでにできた関連するストーリーを再評価する機会にもなる。ここまでストーリーができたから、次はこういう風に動作するのがよいかもとか、あの動作はこういう風に動作した方がいいかもとか、ひとつひとつのストーリーが大きなストーリーの1部になっていく感じ。わかりにくいですよね？
バグもストーリーとして扱っているのでそれで説明すると、ある機能がなにかのバグで動かなくなったとすると、”ある動作ができない”というストーリーが作成される。なのでゴールは”ある動作ができること”になる。
手順とか実現方法についてちょっとだけ書く。
RWiki( https://github.com/rwiki/rwiki )というRubyでできたWikiの『ストーリーカード』という機能をつかって実現している。ストーリーのページを作るとイテレーションごとに並べくれるもの。（他にもいろいろあるんだけど、それはまたの機会に）ひとつのストーリーには以下のようなことが書かれている。
- タイトル（文字通り、ゴールが書かれる）
- 種類（Story or Bug or Task）
- イテレーション（反復開発しているのでそのイテーレーション）
- ディスクリプション（概要が書かれる）
- サイン（主に担当する人）
- バージョン（複数バージョンあるので）
- 見積もり・実績（どのくらいかかりそうとか、いまはあんまり機能していない）
- 開発者の開発日記、メモ（想起のためもの）
- テスト（このストーリーを確認するためのテストケース）
だいたいのテンプレートはこんなところ。細かいところを書き始めるとキリがないので今回はここまで。手前味噌だけど、ちょっと前にこういうの書いてた。
https://speakerdeck.com/vestige/story