スクラムの肝はプロダクトバックログ

2009年2月の後半から開発を始めて6ヶ月が経過。
7月末で一旦区切りがついた。(現在も細々と継続中)

やったことなど

スクラム
Ruby
Rails
TDD
ペアプロ
CI
ふりかえり
スプリントレビュー
デモ
チームビルディング
コミュニケーションワークショップ
RubyやRailsのレクチャー
読書会
進め方の模索　設計書、コード規約、時間割、かんばん、バーンダウンチャート
途中でのメンバー入れ替わり
ユーザビリティワークショップ
ペアプロ探求
オブラブ全員参加
スプリント期間の変更
コミットの決め
バグの決め
朝会のGood＆New
tracでプロダクトバックログ、スプリントバックログ管理
顧客をプランニングに巻き込む

思ったこと

いろいろやってみた結果、相互依存が多くて、どれがよかったというのはなくて、どれもよかった。
で、これぞスクラムだ！って思うのは、プロダクトバックログ。

顧客とプロダクトオーナーがROIを考えながらストーリーに優先度をつける。
優先度の高い順に、実装可能ストーリーをきめる。
スプリント終了し、スプリントレビューで実装状況を報告。
報告に基づき、優先度を見直す。(新しいストーリーを追加することもある)
(繰り返し)

このインクリメンタルな開発を支えるのが、Railsだったり、TDDだったり、CIだったり。

さらに進むと、顧客が、
　このストーリは２(ストーリーポイント)くらい？
　５を超えるなら優先度下げよう。
と言い出す。
顧客が実装者の見積もりを信用してくれていた。
規模間がチームでそろった瞬間。

歯車が徐々にかみ合って、回りだした。
私の中での伝説のチーム。

まぁ、ここにいたるまでには
スクラムマスターの試行錯誤とか、
プロダクトオーナーのヒアリング力、分析力とか
いろいろな助けがあってのこと。

とても楽しいプロジェクトになったことが最大の収穫。
このチームを超えるチームを作るという新しい目標ができた。