如何にしてスクラムを組むに至ったか

プログラマタスクの進捗管理って難しいじゃないですか。 ずーっと難しいなーって感じで特に何もしてこなかったので、何かこう出来ることは無いかと考えていて。 すると、進捗管理の難しさってのは、言ってしまえば以下の2点が問題だという結論に至った。

  • 工数見積が甘い
  • 個々人の能力が把握できていない

つまり、妥当性を欠いた工数上で能力不一致な人員アサインが行われ、結果、遅延する。 しかし、正確無比な工数見積や、個々人の能力把握は不可能だと思われるので、悩ましいなーと。

そこで、取り敢えず、基準値があっての実績値だと思った僕は、工数、能力の両側面における基準値とはなんぞやと考えた。 組織内で個々人の能力を基準にすることは割りと難しいので、工数というものを基準に出来ないかと考えた。工数、すなわち時間は誰にとっても同じはずなので、基準になり得るなーと。

ただ、例えばある機能があるとして、

  • Aさんは8hで見積もって7hで終わらせた
  • Bさんは4hで見積もって6hで終わらせた

みたいなことが往々にしてあって、工数を基準にするにしても人それぞれみたいな感じになってなんだかなーって感じがあった。

ただよく考えてみると、AさんとBさんは見積もり時に倍近くあったものの、実績値としては1hくらいの差であると。これは都合の良い例なんだけど、要するに、見積もり時にAさんが懸念していた点、あるいはBさんが軽視していた点をマージ出来たら、AさんBさんによってその機能の工数は6hという共通の見積もりを弾き出せるはず、つまり、チーム内の基準値作れるよねという理論が成り立つんじゃないかと。 というかこれが見積もりポーカーなんだ、という感じで。 こうすると、タスクをチーム内の基準値として利用でき、そのタスクをどれだけ捌くかで個々人の能力というものもある程度見えてくるかなと。

具体的にはGitHubマイルストーンにイシュー紐付けて、各イシューにタスクの重み(pointと呼んでる)をラベルで付与する。最初は大体1point=3hくらいの換算でやってるけど、実績値によって point:時間 の関係は変動するので多分変わってくだろうな。 ここまで準備すると、AppNeta: Burndown before you burn outを使うことでバーンダウンチャートも作ることが出来る。

最終的には、

という感じに仕上がった。これをスクラムとしてちょっと踏ん張って結果出したい。