この記事はランサーズ Advent Calendar 2016の２３日目です。
昨日夜の暴風雨で家が少し揺れたりして危機感を感じたプロダクト開発部のakin.です。
今年のAdvent Calendarも今日を含めあと３日！
今回は弊社Advent Calendar２日目のsayaさんで紹介されていたGoogleSpreadsheetの部分を具体的にご紹介できればと思います。
はじめに
現在GitHubのチケット駆動をカンバンとして可視化するためにwaffle.ioやZenHub等のツールを利用し検討を行っている段階です。
スプリント単位は上記のツールでMilestoneを設定することで見える化が行えると思います。
では、全体的にはどう動いているのか可視化するためにGoogle Spreadsheetを利用しツールを作成してみました。
以下の図の様にバーンダウンチャートとして可視化を行っています。
どんなシートなのか
説明の前に、前提として各ストーリーにストーリーポイント(SP)付けされており、1SPを1時間として置いていますがあくまで目安です。
SPはプランニングポーカーを利用しポイント付けを行います。
なぜ時間として置いているかというと実際の作業時間と絡めるためになります。
本来のSPはストーリーの規模や複雑さを測るものになり、時間にするのはあまりおすすめできません。
それでは具体的に説明へ
最初に行うことはプロダクトを進める前にストーリー出しとストーリーに対してのISSUEやPRを作成しポイント付けを行います。
この記事では今日のアドベントカレンダーを書くというプロダクトで進めたいと思います。
プロダクト内容からストーリーをざっくり出したのが以下のISSUEとSP(Estimate)になります。
このタイミングでGitHubのAPIでデータを取り出しSPの設定だけ行えるようになっています。
ポイント付けを行ったあとは各種設定をします
SPの合計を初期見積もりとして48を、1日に作業できるポイント(時間)を3とします。
今回は途中で2人に増員すると前提なため、作業人数を２に設定し1日総ベロシティ(時間)が６として算出されます。
あとはプロダクトの開始日や実装目処を記入します。
企画からの希望日とデータからエンジニア１人で頑張るとこの日になりますよという希望日を設定します。
そうすると、以下の図のようにバーンダウンチャートが出来上がります。
この時点で１人で記事を書くと12月28日になってしまいアドベントカレンダーなんて無かったことになってしまいますね。あるあるです。
内訳として消化SPと週間消化SPは棒グラフで、それ以外は折れ線グラフで表示されます。
消化SP：１日に消化したISSUEやPRの終了日(closed_at)から何ポイント消化したか
週間消化SP：金曜日時点で月曜日からの消化SPの合計
ガイドライン：１人で実装を行った場合の理想線
皆ガイドライン：１日総ベロシティからの理想線
残SP：消化SPからの実績線
作業PT：実際にプロダクトで作業したポイント(時間)
実際に開発を始めてから２日目(12月02日)には以下の図になります
残SPラインと作業PTラインの位置関係から作業PTが掛からず３SPを消化出来たようです。
※ 残SPラインより作業PTラインが下に行けば行くほどウナー状態です。
12月02日は金曜日で振り返りの日です。
KPT出しを行い次のスプリントに向けて盛り込む内容を決め、スパイクが打てるものはスパイクを打ちストーリーの分解を行います。
このタイミングで人員追加予定とスパイクを打ちISSUE４〜８が出てきました。
また、分解することによって「素材の準備」というISSUEのSPを0にし、
ISSUE４〜８へプランニングポーカーでポイント付けしました。
総SPが48SPから44SPに減った！
まぁそうですね。。。
「作業の準備」だけではふわっとしていてどんなストーリーなのか分かりません。
Milestoneも設定しておきましょう。次のスプリントではない時は後からでも大丈夫です！
12月09日の振り返り日
Milestone：準備_1
作業PTが一時的にウナー状態だったみたいですが、なんとかスケジュール通りにSPを消化しています。
次は助っ人にお手伝いをお願いして進めていくスプリントです。
12月16日の振り返り日
Milestone：準備_2
助っ人の方は想定SPより早い作業PTで終わったみたいですが、
頼んだ本人は怠けていて途中作業PTが下回っていますね。
でも、振り返り日には巻き返してる！
後はブログを書くだけです。
Milestoneも必要か微妙ですが「書く」を付けました。
12月22日までのスプリントになります。
12月22日の企画希望日
Milestone：書く
ウナーになりつつも12月21日には完成したようです。
なぜラインが０に行っていないのは最初に見積もった48SPから44SPへ減ってしまっているからです。
上記の図のように上手くいくケースですが、作業PTが下回りすぎてマイナス値に行く場合もあります。
その場合は見積もりの誤りや、直ぐスパイクを打ちストーリーの分解をして作業を分けるなりウナー状態を解消するためにも周へ相談をするか周りから声をかけることでウナー状態がどんどん深刻化しなくなるかと思います。
まとめ
今回のバーンダウンチャートには計画線がないため、追加しようと思いました。
振り返り時にウナー状態だったときに企画サイドへリリース時期をリスケする資料にもなります。
また、可視化することでエンジニアだけではなく企画側もある程度把握できるのではないかと思います。
それでは良いクリスマスを！