しばらくブログ更新してませんでしたが、12月頭までプロジェクトが大変だった＆その後燃え尽きてたのが原因です。
リハビリがてら、そのプロジェクトの反省でも書いてみます。長くなりそうなので、まずはプロセスや運用面の話から。
プロジェクトの概要
- 某サービス会社向けの Web アプリケーション開発
- 開発期間は 2009/08〜2009/11 の 4 ヶ月＋α。その前に要件定義や調査は少し実施。
- 開発メンバは 4 人
- プロジェクト管理には Trac を使用。
プロセス
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ を読みつつ、アジャイルもどきで実施してみた。どのあたりがもどきかというと、顧客と契約やリリース計画が従来どおりで、社内でできるところだけこっそりやった感じ。
支援ツールとしては Itteco Trac Plugin を使用。タスクの状況を可視化するのが目的だったけど、Agilo は Pro じゃないとホワイトボード使えないみたいなので。Agilo Pro は、月額ってのがちょっとね。一回買って終わりならまだ予算に組み込みやすいんだけど。
ストーリーの一覧は Excel で書いて、ストーリーポイントもそこに書いた。イテレーションプランニングの際に実施するストーリーを決めつつ、Itteco Trac Plugin の Whiteboard（こういうの）上でタスクを分けていく感じ。でもタスクごとの予定時間とかは管理できなかったので、これは次回の課題かな。
Itteco Trac Plugin を使った感想は、
- Whiteboard は状況がわかりやすくて基本的には便利
- ただ、ストーリーの追加は Whiteboard 上からできないので、ちゃんとバックログつかってやってないと不便かも
- イテレーション間のストーリーの移動ができないので、イテレーション中で完了しなかったストーリーは個別にイテレーションを移動してやる必要がある
- その場合に配下のタスクが移動しないのも不便に思えたけど、本来どう扱うべきなんだろう？
- Whiteboard 上で D&D するとステータスを変更できるけど、owner がその操作を行った人になってしまうし、そのタイミングでコメントを追加することもできない
- バーンダウンチャートも生成できるようになるはずだけど、現在のところまだ動作しない
という感じ。全体的に Agilo に比べると完成度はかなり低いかも。
その他個別にアジャイルっぽい部分の感想を書くと、こんな。
- プラニングポーカーとか面白い。メンバが 4 人だからトランプ 1 セットでできた。
- イテレーションプランニングとかやるので、他の案件に比べると担当外だった機能についても理解されていた気がする。
- 通常は要件定義→設計→開発→テストあたりの流れで人数が増減するけど、アジャイルだと固定メンバーで無理なく実施できるから、全員の知識に偏りが出ないのはすごくいい。
- 普通は人数が増えるタイミングで説明に時間取られたり、人数が減るタイミングで引継ぎに時間取られたりするけど、それが一切なくなるので
- 漠然と「アジャイル〜」とかいって適当にプロセスを導入するのではなくて、拠り所となる開発手法を持っていたほうがいい気がする
- Scrum ベースのツールが多い（Itteco Trac Plugin もそう）から、Scrum でも勉強しようかな
運用
- 朝会や週次のふりかえり（KPT）を実施
- 週次のふりかえりで出た Try がなかなか次の週に活かされないので、朝会に「本日の Try」みたいなコーナーを設けてみたりとか
- 毎日 30 分程度勉強会を実施
- この勉強会で たのしいRuby 第2版 Rubyではじめる気軽なプログラミング と、RailsによるアジャイルWebアプリケーション開発 第3版 もひととおり読んだ。ちょっとは底上げになったかな。
- さらに子ネタ（便利なツールやサービス、Tips 等）の紹介もやってもらった。これも悪くないかな。
- 開発者には RailsによるアジャイルWebアプリケーション開発 第3版（当時はまだ第二版だったけど）のケーススタディを独習でやってもらった
- かけた時間のわりに、効果が薄かったかも
- 本を読んでから実際の開発までの間があったせいか、「それ本に載ってたよね？」というような部分でハマる人が多かった
- ニコニコカレンダー もいちおう利用。
- 隣のチームの人曰く、「シールに表情を書き込むアナログ感がいい」らしいので、壁にシールを貼りつける形。
- 最後のほうはなんだか形式的な感じになってたので、今後はコメントを入れるなりなんなり、一工夫したいところ
コミュニケーション、情報共有
- メンバが 4 人なので、一箇所に集まって作業
- 5 人以上だと人を挟んで会話する必要があるけど、4 人だと直接話せるから理想的かも
- 席の配置は島を囲んで向かい合わせるんじゃなくて、背中合わせにする形
- 他人の画面を見やすい＆声を張り上げなくていいから、個人的には背中合わせのほうが好き
- 「背中を預けてる感じが好き」なんて言ってたこともあるけど、恥ずかしいから最近はあまり言わないようにしてる・・・
- 顧客とのやりとりは週次の定例がメインだったので、要件確定のスピードは結構遅い
- タスク管理や情報共有は、基本的に Trac を使用
- ただ、客先から社内 Trac が見えないので、タスクの状況を説明するための資料を作ったり、無駄は多かった
- 次の案件ではプロジェクト予算で回線を引いて、ちゃんと客先から見えるようにする予定
- ちょっとした情報の展開や伝言には、社内 IRC サーバも活用
- Gobby もいちおう議事録その他の共同作成に利用
- でも 0.4.92 のバグのせいであまり気軽には使えなかった。0.4.93 で改善するかな。
結果
開発期間が短いので、ずっと 1 イテレーション＝1 週間（月〜金）の形で回したけど、バーンダウンチャート（イテレーション毎の残ストーリーポイント）はこんな感じ。
これだけ見ると結構綺麗なグラフだと思われそうだけど、当初予定していたのは 5 イテレーションだったので、想定の 2 倍の期間がかかってしまっている。これは当初開発者を 4 人で見積もっていたところが 3 人でやってもらったことと、慣れないフレームワークに手こずったといったところ。せめて運用フロー等が定まって入ればよかったんだけど、全然決まっていなかったから戸惑う場面や手戻りも多かった。
その後に予定していたセキュリティ検査やらユーザ受け入れテストやらの日程をずらしてもらって、なんとかリリース予定日までに動くプログラムはできたけど・・・プロジェクト管理としては失敗かなと。
さらに、図からは読み取れないけど、後半はかなり稼働が高かった。この辺はちゃんと時間も記録できるようにする or 残業をしないという強い意思がないと、バーンダウンチャートの価値が下がるなぁ。
あと、今回は開発関連ものしかストーリーとして洗い出さなかった。サーバやインフラがらみの隠れタスクが山ほどあったので、これもちゃんとストーリーに関連づけて、タスクを分散させないとな。
その他反省
- 諸々のレビューが甘かった。後半になってソースレビューを全員でやるようになった（実装した人がみんなに説明する形）けど、もっと早くからやるべきだった。
- 最後のほうはレビューが漏れないように、「レビュー」というタスクを入れるようにしていた。
- 次回はできればペアで作業したいな。
- 情報共有がちょっと甘かった。
