スクラムってなんだ

はじめに

以前、以下の記事でDevOpsについてまとめました。
DevOpsってなんだ

ここではDevOpsという考え方が、アジャイル開発の元に成り立っていることを紹介しましたが、アジャイル開発というのはあくまで概念であり、手法のレベルには彫り込めていません。
今回は、アジャイル開発に属する開発手法として、スクラムという手法についてschooの動画で学んだので、こちらをまとめていこうと思います。

はじめてのスクラムマスター

また、スクラムという考え方の最も上位に存在する資料は無料で公開されているため、こちらも必要に応じて読んでいただけるとよいでしょう。

スクラムガイド2016

#スクラムの基礎理論

スクラムとは

アジャイル開発を実現するためのフレームワークであり、短期間で開発→リリース→評価→改善を繰り返し、高速に開発を進める手法。
複雑で流動的なプロジェクトに向いている。

ベースとなる考え方

「経験、知っていること」から判断を下すということを繰り返していくことで「知識」が生まれ、「予測を可能としリスクマネジメントを行えるようになる」という考え方がある。
スクラムは高速で機能を実装し、評価し、改善するというサイクル「経験、判断」を行うことによって「知識」をため、「予測」と「リスクマネジメント」の精度を高めプロジェクトの成功率を上げるということを目的としている。

概念的に言えば、「透明性」「検査」「適応」という概念をスクラムの柱としたうえで、反復的かつ漸進的なアプローチを行うのがスクラムの考え方である。

守るべきルール

まずスクラムはアジャイル開発で行うもので、ウォーターフォールや不規則な反復の上では成り立たない。
そして、1サイクルあたり1週間ならそれとしてスクラムは時間をきっちり決めて進めなければならない。
このサイクルを
####スプリント or タイムボックス
と呼ぶ

チーム、役割

スクラムは必ず1チーム当たり5~11人で構成される。
3種類の役割が存在し、それぞれが上下関係を持たずに役割を果たす。
チームは単体で「自己組織化」「機能横断的」でなければならない

性質

####　自己組織化
スクラムチーム内でやり方を改善したりするのに、外部からの支援を必要としない、自立したチームである。

機能横断的

チーム内のメンバーですべての機能をまかなえていること。
一人がすべてを見れる必要はなく、あるプロダクトが持つすべての機能それぞれに対してチーム内で担当を割り振れること。

役割

プロダクトオーナー　1人

プロダクト全体を把握しており、各種開発機能の優先順位付けを行える。
何をどういう順番でつくるかをステークホルダーと決める。
プロダクトリリースにおける責任者。

####　スクラムマスター　1人
スクラム全体を把握。
スクラムについてのコーチングもおこなう。

####　開発チーム　6 ± 3人
実際にプランニング、開発、評価を行う。

イベント

スクラムは、開発フローの中にいくつかのイベントを行い、それらを反復しながら行う。
このイベントによってスクラムの柱である「検査」「適応」を実現する。
なお、以下のイベントはすべて開発チームの仕事となる。

###スプリントプランニング
スプリントの開始時点で行う。
そのスプリント内で、どの機能を実装するかを設定する。

###デイリースクラム
毎日決まった時間に15分以内に行う。
開発メンバーが「昨日やったこと」「今日やること」「困っていること」を報告する。

###スプリントレビュー
スプリントの最後に行う。
実装された機能を確認し、フィードバックを行う

###レトロスペクティブ（振り返り）
スプリントの最後に行う。
スプリントの進め方について反省を行う

##　成果物
スクラムを進めていくうえで必要な成果物

###プロダクトバックログ
プロダクトオーナーが作るべきもの
未完成の要求リスト
これは常にメンテナンスされ続けなければならない
評かと改善を繰り返すたびに必要な機能は変化していく
あいまいなものは優先度を下げる
スプリント内に終わらなそうなものは分割してタスク化する

###スプリントバックログ
今回のスプリント内で何をやるかの優先順位付け
スプリント内で変更不可
対象は詳細にきまっていて完成可能である必要がある。
1タスクあたり4時間-1日で終わるようにしなければならない。

###インクリメント
動くソフトウェアそのものに今回追加した機能をのせたもの
常に動き出荷できる状態でなければならない。
このインクリメントを作るためにスプリントのゴールを決める。
スプリントレビューがぼろぼろだとインクリメント出せないねってことになるが、
スプリントを短く設定しているので傷は浅い。問題ない。

これらの作成物を常に見える状態にしておくことでプロダクトの「透明化」を実現する

#計画とプロダクトオーナー

スプリントの期間は固定だが進捗は変動する。
ベロシティが計画に満たない場合、次のスプリントでは計画を調整する。
スプリントを繰り返して予測の精度を上げていく。

見積もりは見えないので予測するしかないが、最初から完璧に作ることはできない。
スプリントを回すうえで知識を蓄える必要がある。
また、メンバーによって作業可能な内容が変わる。
適切な割り振りが必要

最初はうまくいかない。
計画に対してベロシティが0ということもありうる。
ただし、うまくいっていないことがわかっているならそれがプロジェクトの透明性が十分であり検査もできていることを表す。
そこでうまくいかないとスクラムをためるのではなく、しっかり失敗に対して適応すべき。

##　スプリント計画（前半）
何をつくるを明確化する。
開発チームとプロダクトオーナーの共同作業

開発できる機能の予測は開発チームのメンバーに任せる。
プロダクトオーナーは達成すべき目的とバックログの項目を検討し、プロダクトバックログに優先順位をつける。
最終的にスプリントバックログを作るのがここのゴール

開発チームのキャパシティは、一人当たり（4時間-個人の事情）を計算したもので計算する。
1日8時間で計算したり祝日や睡眠時間を無視するのはブラック

##　スプリント計画（後半）
どうやって作るを明確化する。
開発チーム主体の作業。

開発チームがスプリントゴールをインクリメントにする方法を決める。
タスクを開発可能な粒度に細分化。
キャパシティをオーバーする場合はプロダクトオーナーとスプリントバックログを調整する。

タスクボードとバーンダウンチャート

進捗管理に使うツール

###　タスクボード
バックログの項目にToDo Doing Doneのステータスを持たせて、タスクを左から右へ移動していく。
これでタスクの状態を可視化する。
Doingがたくさんたまってるとかだとすぐに問題がわかる。
開発者は自分のタスクが終わったらToDoからまた新しいタスクを勝手にもらっていくことが多い。

###　バーンダウンチャート
タスクの数と時間を表した右肩下がりの関数で、進捗が良いか悪いかすぐ見れる。
時間の基準線より上にタスクの線が来るなら思ったより進んでない。
下に来るなら進みすぎてるというか、作業力を過小評価、タスクが足りてない。
タスクの数が増え続けるなら横やりが多い、スプリントの計画が破綻してるので、横やり入れてくる奴を止めろ。
等々

開発とレビュー

プロマネや開発マネージャが計画を立てて、コーダーがそれを実装するという流れはよくあるが、スクラムでは開発者自身が計画段階から強くかかわる。
そしてここからは開発チームがその計画を遂行していく上での説明していく。

とはいえ、実はスクラムとしては開発者に指定するイベントはデイリースクラムしかない。
テスト駆動開発をしようとか、CI/CDをどうしようとかは、スクラムの範囲ではない。

##　デイリースクラム
開発チームだけでおこなう
スプリントゴール達成のため、今日の計画を立て、細かく修正するためにある。
進捗報告ではなく、計画のずれを修正するという意識を持つ。
「昨日やったこと」「今日やること」「阻害要因」について報告する。
必ず15分以内に抑え、詳細はなす場合は別MTGを設置

スプリントレビュー

スクラムチームと関係者でおこなう
スプリントの成果をレビューする
インクリメントの確認・評価
成果を踏まえてのプロダクトバックログの調整

プロダクトバックログの内容のうち、完成未完成を説明
インクリメントのデモと関係者からの質問対応
プロダクトバックログの審査
次のスプリントの予算や期日についての確認やプロダクトの市場価値調査など

##　レトロスペクティブ（ふりかえり）
スクラムマスターが主催
スクラムチームとしての反省(KPTやYWTという手法がある)
スプリントの検査
完成の定義を調整
　各イベントで何が終わったらOKとするかっていう定義を調整（後述）
改善実施計画

完成の定義

このイベントが完了する＝こういう状態という定義
透明性と検査のために用いる共通見解
スクラムチームで共通認識を持つべきものであり、インクリメントの完成評価基準となる。

インクリメントの例
・利用可能/リリース可能
・組織の持つ慣例やガイドラインに準拠している（コード規約とかルール）
・品質基準

プロダクトバックログの例
・優先順位順にならんでいる
・あいまいなものは優先度が下がっている

スプリントバックログの例
・想定開発工数が規定内に収まっている

実践メモ

・アジャイルはリードタイムを減らすためのもので、効率よく開発を進めるというものではない。工数の効率を重視するならウォーターフォールのほうが効率的とさえいえる。