仕事のスピードを計測しよう

スクラム

スクラム開発を導入して、スクラムイベントをこなせるようになってきたら仕事のスピード※を計測してみよう

『Scrum is a gamge』・・スクラムは”スピード”と”ステークホルダーの幸福度”を追求するゲーム

スクラムでは追求していきますが、スピードが測れないとゲームをやっている感覚が出てこないですよね。スクラム開発を楽しむためにスピードの計測をやっていきましょう。

スクラム開発の用語ではスピードではなく、ベロシティと呼ばれます

スピードを把握すれば、チームの成長がわかる。スプリントでこなせるタスク量がわかる

アジャイル開発を進めるためには、開発チームの進捗を見えるようにすることが重要です。そのためにチームが仕事をこなすスピードを把握して、チームの成長の見える化、スプリント期間でこなせるタスクの把握をできるようになりしょう。

そうすれば、スクラム開発がスピードを追求するゲームになり、スプリント期間での仕事へのコミットメントに自信がでてきます。

ステップ1 タスクの大きさのモノサシをつくる

いままでの代表的なタスクをいくつかピックアップしてタスクの大きさを元に小さいものから順番にならべて代表的なタスクのリストをつくりましょう
ここで大切なのは順番は厳密に考える必要はなく、おおまかに並べればOKです

タスクのリストに対して、チーム全員でタスクの大きさを定量化します
ここで大切なのは、工数や時間を見積もるのではなく、その作業の複雑さや労力ポイントを見積ることです。個人のスキルなどに依存せずに、他の作業との相関で決めることです。
その際に使用する数値はフィボナッチ数列を使うことが多いです

フィボナッチ数列とは前の2つを数字を足した数字の数列です
(例)1、2、3、5、8、13、21、34、55・・・
人口増加の推定や、金融市場の行動予測などでも使われている数列です

アジャイル開発における仕事は、初めて実施するような仕事も多く、確実に見積どおりにこなせるかどうかはわかりません。見積はあくまでも指標であって絶対的なものではないことを認識して、ずれてもいいので、チーム全員の感覚値で決めてしまいましょう

このタスクの大きさを定量化した数値をスクラム開発ではストーリーポイントと呼びます

スプリントバックログではひとつのタスクを一日以下の作業量にしますので、一日の作業量程度までのモノサシをつくりましょう

【タスクの大きさのモノサシ】

タスク作業の複雑さや労力
(ストーリーポイント)
AAAA1
CCCC1
DDD2
FFF2
BBBB3
JJJJJ3
EEE5
・・・・・・
PPP13
・・・・・・
スプリントプランニングでスプリントに集中する
計画がうまく作れない、計画倒れになってしまう。そんなチームでもスクラム開発で経験&成長していけばきっと計画がつくれるよう...

ステップ2 スプリントバックログの各タスクにストーリーポイントを割り当てる

スプリントバックログの各タスクについてステップ1でつくったモノサシを元に、チーム全員でストーリポイントを決めていきます

各タスクについてチームメンバーひとりひとりが、そのタスクのポイントを考えて一斉に公開します

同じ数字にならないときにはその数字を出した理由を簡単に話し合いましょう
話し合いに時間がかかる場合には、一番小さい数字と一番大きい数字を出した人だけ発言するなどもいいでしょう
開発チーム全員の知恵を持ち寄って様々な視点で意見を出して、ストーリーポイントを決めていきましょう

100%正確な見積や計画はありません。特にアジャイル開発をするようなプロジェクトでは不確実な要因も発生します。その不確実性を認めて、見積には時間をかけすぎず、素早くストーリーポイントを決めてましょう

ステップ3 スプリントで完了したストーリーポイントを集計してベロシティを算出する

スプリントが終わったら、完了したタスクのストーリーポイントを集計します

完了しなかった”未着手のタスク”および”実行途中のタスク”は集計対象から外します。

ステップ4 スプリントごとのベロシティのリスト化していく

スプリントごとのベロシティをリスト化して、チームのベロシティを把握しましょう

ベロシティのばらつきが大きくなるかもしれませんが、直近3回のベロシティを平均化するなどして、ばらつきの傾向を把握しましょう

チームのベロシティを把握できれば、スプリントプランニングでのコミットメントも自信をもってできるようになってきます

ベロシティ計測で大切なこと

  • プロダクト開発でのタスク見積はそもそもばらつく、ベロシティが多少変動しても根拠もなく想像するよりは確実な数字になる
  • 人間は仕事の絶対値を見積もることは不得意、いままでの経験を元に相対比較で類推しよう
  • ベロシティは決めるものではなく、測るもの
  • スクラム開発の3本柱は”透明性””検査””適応”、間違っていたらカイゼンすればいい、

◆ソフトウェア開発でよく知られている不確実性コーン
プロジェクトの初期段階で見積は現実との乖離が大きく、プロジェクトの進行とともに乖離が縮まっていきます。

不確実性コーンについて

プロジェクトの本質とはなにか
前回は「プロジェクトとはそもそも難しいものである」ということ、そして「プロジェクトをうまく回すには、プロジェクトの本質を知る必要がある」ということについて解説しました。今回は、プロジェクトの本質と、プロジェクトをうまく回すためのアプローチについて説明します。

スクラム開発について知りたいかたは以下の書籍も参考にしてみてください

タイトルとURLをコピーしました