スクラム学習日記「スクラムの概要」
この記事について
スクラム開発について勉強した内容をアウトプットしていく記事です。
スクラムにちょっと興味のある方、スクラムについて学びたいという方、スクラムの復習をしたい方にとって役に立つような記事になれば嬉しいです。
まえがき
アジャイルという言葉は知っていたものの、今までちゃんと勉強したことがありませんでした。
以前は実際の開発経験がなく、ウォーターフォール型開発の欠点や適応型開発手法のメリットなどを肌感として理解できず、積極的に学ぶ動機がなかったからです。
しかし開発経験を一年程経験すると、手続的な開発方法に疑問を持つ様になり、「流行りの開発方法」程度でしか認識していなかったアジャイル開発手法が今の自分と同じような問題意識のもと生み出された手法であることが理解できるようになりました。
スクラムを学ぼうと思ったのはそのような動機があってのことですが、自分一人が理解したところで意味がないので、どうせなら自分も他の人も後から見返せる形で勉強した内容をまとめておこうと思った次第です。
では早速、スクラムとはなんなのか説明を始めていこうと思います。
スクラムとは
スクラムとはアジャイル開発技法の一つです。
ジェフ・サザーランドとケン・シュウェイバーによって1990年に作られました。
野中郁次郎と竹内弘高の共著で1986年にハーバード・ビジネス・レビュー誌に掲載された論文である "The New New Product Deelopment Game" から着想を得たそうです。
「スクラム」という用語もその論文に登場しており、ラグビーのスクラムが由来になっていると言われています。
スクラムのルールは公式に定義されており、1〜2年おきに内容が更新されています。
従来のウォーターフォール型が「要件定義→設計→実装→テスト」というふうに進むのに対し、スクラムでは スプリント という決められた期間内で以上の工程を行い、それを繰り返しながら開発を進めます。
スクラムの構成要素
スクラムは 軽量フレームワーク と呼ばれている通り、単純な要素で構成されています。
それが 3つのロール(役割)、5つのイベント、3つの作成物 です。
3つのロール
プロダクトオーナー
- プロダクトの責任者
- プロダクトバックログ（後述）を管理し、リストの並び順似ついての最終決定権を持つ
- ステークホルダーとの交渉や協業を行う
- プロダクトにつき一人
開発チーム
- プロダクト実装者
- 3〜9人で構成される
- 肩書などは無し
- プロダクトオーナーが決定したプロダクトバックログの内容を順に実装する
- 個人個人が複数のことを行えることが望ましい
スクラムマスター
- スクラムのプロセスがうまく回るようにプロダクトオーナーと開発チームをサポートする
- タスクの割り振りや進捗管理は行わない
- チームが妨害されないように防波堤の様な立ち回りをする
- スクラムに慣れていないチームではトレーナーのような役割を果たす
5つのイベント
スプリント
- 最大1ヶ月間の固定された期間
- 各スプリントはバラバラの期間には設定できない
- この期間で設計からテストまで全て行う
- 最終日に作業が残っている場合でも延長はしない
スプリントプラニング
- プロダクトバックログを元にスプリント内で何を行うか決定する
- スプリントバックログ（後述）の作成
デイリースクラム
- スプリントバックログの進捗と達成可能性を確認
- 毎日15分で行う
- 報告を主にして行い、問題解決のための会議は別途設定する
スプリントレビュー
- スプリントの最後に行う
- ステークホルダーも招待
- プロダクトについてのフィードバックを行う
- インクリメントをもとに、実際にプロダクトを動作させて内容を説明する
- 実施時間はスプリントの長さによって増減する
スプリントレトロスペクティブ
- スプリントレビューの後に行う
- うまく行ったことや改善点を整理
- 今後のアクションプランを作る
3つの作成物
プロダクトバックログ
- 実現したいものをリスト化したもの
- プロダクトにつき必ず一つだけ用意する
- 開発を通して常に最新に保つ必要がある
スプリントバックログ
- プロダクトバックログの項目を実際の作業タスクに分割したもの
- ひとつのタスクは1日で終わる程度
- タスク数は増減可能
インクリメント
- これまでのスプリントと今回のスプリントで完成したプロダクトバックログを合わせたもの
- 実装した部分は動作して検証可能である必要がある
スクラムの背景
以上の紹介した構成要素のには3つの背景的な要素があります。
スクラムを実施していくにあたっては以下の3つの原則を意識して行っていくことが重要です。
透明性
スクラムでは現在の状況や問題点が常に明らかになっている必要があります。
状況の確認はデイリースクラムやスプリントレビューによって、問題点の把握は前述の2つに加えてスプリントレトロスペクティブによって行われます。
もちろん、これらのイベント以外においても、問題点などに関しては常にチーム間で共有しておく必要があります。
検査
プロダクトの進捗はプロダクトバックログやスプリントバックログ、インクリメントによって常に明らかになっている必要があります。
問題などがあれば必ずチームやステークホルダーに対して共有しなければなりません。
適応
明らかになったも問題点や改善点は効果の高いものから解決策を実施していきます。
具体的な施策はスプリントレトロスペクティブにおいて考案されます。
まとめ
- スクラムはスプリントという単位で繰り返される開発プロセスである
- スクラムは3つのロール、5つのイベント、3つの作成物で構成される
- スクラムで重視されるのは透明性、検査、適応である
あとがき
いざ学び始めると、スクラムがこんな単純な構成要素で成り立っていることに驚きました。
馴染みのない用語も少々ありますが、原則や実施方法が具体的になっていて内容はそれほど難しく感じません。
調べ物中に スクラムマスター という資格があることを知ったので、どこか改めて調べて記事にしたいですね。
今回は概要をさらっと紹介した程度ですが、次回位はもっと具体的な内容に踏み込んでみたいです。
Discussion