アジャイルという考え方

アジャイルサムライを読んだ。組み込み系からWeb業界に移動してきた僕にとっては有益な話が多かくて、忘れる前にメモ程度に書いておこうと思う。

インセンティブデッキを作成する

以下の5項目をプロジェクト開始時に決めておく。

  1. 我々はなぜここにいるのか?
  2. エレベータピッチ
  3. パッケージデザイン
  4. やらないことリスト
  5. ご近所さんリスト

自分たちが何を作成するために集められて、それを作成することでどういうことが起きるのかをまず統一化する。エレベータピッチをみんなで共有することもそうだし、パッケージデザインで作るものの意識を共通化させるのもそう。作成している間にやりたいことやこれがあったらいいというものはどんどん増えていくけど、これは今回の開発では絶対に「やらない」というものを決めておくというのも面白い。ご近所さんリストは大規模開発じゃないとあまりないかなーと思う。

見積もりは変わる

きっちりとした見積なんて最初からできないものだと割りきって考える。最初からできないんだから後からすこしずつ変えていけばいい。そうすれば見積が変わっていくことに対していちいちストレスを感じることもない。出していた見積は作業をすることで時間が変わるものだし、要件は作成している間に増えるものである。要件が増えそうになった際には時にやらないことリストや、パッケージデザインをそれは本当に必要かをその都度見積り直せば良い。まずは大体で見積もって終わりになるほど精度が高くなればいい。

ストーリーを語る

技術者は技術で語る癖がある。データベースのレスポンスを早くする。とか、アニメーション処理をCSSで書くとか。それは技術者間で話すには良いのだけど、技術者ではない人と話す場合はその作業によってユーザ見えでどう変わるのかを話したほうが良い。データベースのレスポンスが早くする。っていうのは、画面表示を早くするって言い換えれるかもしれないし、アニメーションをCSSで書くというのはなめらかなアニメーションを実現するって言い換えれるかもしれない。やっていることがどういう効能があるというのを共用することは大事。

概算見積もり

技術者から見て同じぐらいの重さのものをグループ化してポイント化する。例えば10個のタスクがあったとして、1ptが5個、2ptが3個、3ptが2個みたいな感じで。これも大体でいいらしい。んで、とりあえずやってみる事で、1ptにつきどの程度時間が掛かるかを見積もる。こうすることでスケジュールが進むに連れて見積もりの精度がすごく高くなる(*1)。どう考えても最初に提出したスケジュールに間に合わない場合は、タスクを削る。もしくは時間を伸ばす。間に合わないということがわかるのも見積もりを行なっているからで、スケジュールに間に合わないということが早めにわかって良かったとポジティブに考える。基本的にはスケジュールを伸ばすのではなくタスクを削るほうがうまくいく。作成した機能の25%程度しか使われないのが一般的らしいのでシェイプアップという意味でもタスクを削るっていうのはいいのかもしれない。

バーンダウンチャート

横軸に時間。縦軸に残作業量でグラフを書く。時間が立つほど残作業量が減っていき、残作業量がなくなった時点で作業は終了。見積もりが正しければ作業量と時間がきちんと見積もれているため右下に一直線のグラフとなる。作業量と時間とがわかりやすくていいなぁと思う。Readmineとかでも同じといえば同じなんだけど、全体の作業量から引いていくっていう感じで作れないものかなぁ。僕としては縦軸を作業量としてある一定量まで上に上がれば作業が終了としたほうがいいと思う。こっちの方が途中の仕様変更等で作業量の絶対値が増えた場合に対処がしやすいし、わかりやすい。可視化って大事だと思った。

まとめ

僕は組み込み系のきっちり決まった仕様・スケジュールで仕事をしてきて、今現在状況に応じて変わるスケジュール・仕様・作業量が変わる業界に移って戸惑っているんだけど、考え方を変えるって意味で読んでみてよかった。いろいろ腑に落ちる考え方とかも多かったし可変的にものを作成する環境にいる人は読んで損はない本だと思います。

*1: 書いてて思ったけど、まぁ普通にやってるな・・・。