内容
社内の新規プロダクト開発メンバーとしてプロジェクトを進めていく中で、アジャイル開発手法の１つであるスクラムを取り入れていくことになり、自学のためにもスクラムの基本的な考え方や用語をまとめていきたいと思います。
目次
スクラム開発の目的
ソフトウェア開発の困難に立ち向かう
ソフトウェアの開発は何度でも繰り返し立ち現れる現象を解決していく。
困難な問題に対して、まずは何らかの方法で分解、整理していかなければならない。
ソフトウェア開発における5W1H
- Who
- 誰にとって最高なのか
- What
- 何がその最高さをもたらすのか
- When
- いつ、どういうタイミングでその最高さは発揮されるのか
- Where
- どこで、どういう状況でその最高さは発揮されるのか
- Why
- なぜそのような最高なソフトウェアが必要なのか
- How
- どのようにしてその最高さをもたらすのか
その中でもWhat（プロダクト）とHow（開発プロセス）に重きを置いて、スクラムでどう解決していくかを考えていく。
スクラムにまつわる用語
スクラムとは
スクラムとは
複雑で変化の激しい問題に対応するためのフレームワーク。
可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのもの。
開発をリードする２つの役割
- プロダクトオーナー
- Whatを担う
- スクラムマスター
- Howを担う
スクラムチームとは
スクラムイベントを通じて自己組織化（学習と成長）していく組織。
ロールとして以下３つがある
- プロダクトオーナー
- スクラムチームが作ろうとしているプロダクトの最終責任者
- スクラムマスター
- プロダクトオーナーと開発チームによるスクラムの実行を支援し、組織へのスクラム導入の支援を行うスクラムの推進者
- 開発チーム
- プロダクトオーナーが決めた要件を、プロダクトオーナーが要求する順番に従ってプロダクトとして実現する専門家
スクラムイベント
複雑なサービスやプロダクトをうまく開発し、メンテナンスを続けるための５つのイベント
- スプリント
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
スプリント
スクラムでの開発の１単位。（１週間〜１ヶ月で設定）
一定の期間のスプリントを繰り返し、その中でスクラムイベントや開発を行う。
期間内はスクラムチーム全員がゴール達成に向けて集中することが重要。
スプリントを繰り返しながらプロダクトとスクラムチームをステップバイステップで成長させる。
スプリントゼロ
開発が始まる前段階。
以下のようなものをまとめる。
- ビジネスモデルの仮設を立てる
- プロダクトを作る理由と実現方法を明らかにする
- プロダクトを作る背景や理由
- 期限内に達成したい目標
- プロジェクトの関係者とのコミュニケーション手段
- 実現するためのアーキテクチャ
- 目標を達成するための体制
- おおよその予算とスケジュール
- リスクと対策
- チームづくりのワークショップを行う
- 開発環境の準備
- GitHubやBitbucketを使ったプルリクエストベースの開発環境
- ユニットテストからE2Eまでの自動テスト環境
- JenkinsやTravisCIなどを使った、ビルドや自動テストでエラーがあればすぐに通知する継続的インテグレーション環境
- HipChatやSlackなどを使ったコラボレーション環境
- ChefやPuppetなどを使ったインフラ環境の自動化
- CapistranoやFabricを使ったデプロイの自動化
- プロダクトバックログを準備し、完成の定義を決める
スプリントプランニング
スプリント開始時に「スプリント期間内で何ができるか」「どうやって達成させるか」の２点を明らかにするミーティング。
１人の管理者によって計画を建てるのではなく、スクラムチーム全員が参加しみんなで計画を立てる。
（スプリント期間が１ヶ月なら最大８時間、１週間なら１〜２時間が目安）
- リファインメント
- スプリントプランニングの準備
- 次のスプリントで開発に着手できるようにプロダクトバックログを整理する
- スプリントゴールの設定
- スプリントで達成したい目標やプロダクトバックログアイテムを決める。
- 優先順位の高いアイテムから順に、スプリント期間内に完了できそうな範囲を選ぶ。
- スプリントゴールを設定する際の参考値として、ベロシティ（１スプリントにスクラムチームが完成させることができる仕事量）を利用する。
- タスクの洗い出しとスプリントバックログの作成
- スプリントバックログとは、スプリント期間内で行うと判断したプロダクトバックログアイテムと、それらのプロダクトバックログアイテムを実現するためのタスクを俯瞰できるよう一覧化したもの。
- スプリントゴールの合意
デイリースクラム
１日１回１５分間のタイムボックスで、進捗や予定、問題の共有を行うミーティング。
開発チームとスクラムマスターが参加。
開発チームからの相談に即時対応できるようにプロダクトオーナーが参加することもある、
- スプリントの状況確認
- 明るく元気な声で挨拶する
- 昨日したこと、今日やること、困っていることを話す
- スプリントゴールが達成できそうかの確認
- 時間内に終わらなければ二次会を開催する
- 達成が難しい場合はプロダクトオーナーに相談する
スプリントレビュー
スプリント期間中に作成したリリース判断可能なプロダクトであるインクリメントの確認を行い、フィードバックを得るためのミーティング。
プロダクトが市場に受け入れられる状態に成長しているかを定期的に検査する。
スクラムチーム全員で開催する。
（スプリント期間が１ヶ月なら最大４時間、１週間なら１時間が目安）
- スプリントで達成できたことを報告
- 動くソフトウェアでデモをする
- インクリメントの受け入れ確認
- インクリメントに対するフィードバックの取得
- 今後のスプリントで作るものの議論
スプリントレトロスペクティブ
スクラムチームが自分たちの現状を見直し、次回以降の仕事の進め方を改善するためのミーティング。
日本では「ふりかえり」と読んでいるところもある。
（スプリント期間が１ヶ月なら最大３時間、１週間なら３０分〜１時間が目安）
- 仕事の進め方の見直し
- KPTのフォーマットに沿ってやるとよい
- Keep：よかったことや続けたいこと
- Problem：困ったことや改善したほうが良いこと
- KPTのフォーマットに沿ってやるとよい
- 仕事の進め方の合意
- 話し合いで挙がったよかったことや困ったことを受けての改善案
- いつ・どこで・誰が・何のアクションを取ると困りごとを解消できるか？具体的に考える
スクラムの作成物
スクラムイベントを通じてスクラムチームが作り上げるアウトプット
- プロダクトバックログ
- スプリントバックログ
- インクリメント
プロダクトバックログ
プロダクトで実現したいことを優先順位を付けて一覧にしたもの。
機能の追加や修正、ユーザーの要望など。
プロダクトオーナーがその内容と優先付けに責任を持つ。
作り方
- プロダクトバックログアイテムの内容を簡潔に表現する
- Who（誰のために）・What（何を作るか）・Why（必要とされる背景や理由）を記述する
- プロダクトバックログアイテムの見積もりを記載
- プロダクトバックログアイテムを優先順位をつけて１列に並べる
- 以下の要素を総合的に勘案
- 内容
- 見積もり
- ビジネス価値
- リスク
- 開発チームの能力
- 他のプロダクトバックログアイテムとの依存関係
- 以下の要素を総合的に勘案
- プロダクトバックログの内容を見直す
- プロダクトバックログアイテムの追加・削除・順序の入れ替え
優先順位付けなどに迷ったときは、プロジェクト憲章やリーンキャンバス、インセプションデッキで明らかにした目標に立ち返る。
スプリントバックログ
スプリント期間内で行うと判断したプロダクトバックログアイテムと、それらプロダクトバックログアイテムを実現するためのタスクを俯瞰できるように表したもの。
開発チームがその内容に責任を持つ。
作り方
- プロダクトバックログアイテムを実現するためのタスクを洗い出す
- 誰もが理解出来、具体的な行動が取れるほど詳細で課題に対処する際に議論可能な内容にする
- タスクの進捗を可視化する
- 担当者・いつ終わるのか・進捗を妨げる障害は何かを明確にする
- スプリントバックログの内容を見直す
インクリメント
開発チームがスプリントごとに作成するリリース判断可能で利用可能な動作するプロダクト。
作り方
- 常に動く状態を保つ
- 継続的インテグレーションノ考え方を用いることで常に動作する状態を保つことが可能になる
- 完成の定義を守る
- 個人のローカル環境ではなく、特定のサーバー上で動作が確認できる状態
- 動作することに加え、包括的な自動テストが用意され、自動テストが乾燥する状態
- プロダクトオーナーによる確認と、HTML構文チェックを通した状態
スクラム作成物によくある問題と解決策
プロダクトバックログ
- 夢見がちなプロダクトバックログ
- 問題
- プロダクトバックログアイテムが大量に作られすぎる
- プロダクトバックログがメンテナンスされず放置される
- 解決策
- ビジョンに基づいて整理する
- 数と粒度を定期的に整理する
- 問題
- 隠れたプロダクトバックログアイテム
- 問題
- 忘れていたり、外部や組織の事情で突発的に発生するプロダクトバックログアイテム
- 優先度が高いことが多く、取り扱いに困る
- 解決策
- プロダクトバックログを管理する媒体を変える
- 突発的なプロダクトバックログの発生をある程度は許容する
- 問題
スプリントバックログ
- 管理がうまくいかない
- 問題
- ノウハウがない
- 解決策
- タスクボードを工夫する
- デジタルツールと組み合わせて使う
- 問題
- 進捗がわかりにくい
- 問題
- 人数が多いスプリントチームや、スプリント期間が長いチームは１スプリントあたりの作業量が多く、進捗がわかりにくくなる
- 解決策
- バーンダウンチャートでトラッキングする
- 問題
インクリメント
- 完成したと思っていなかったのにしていなかった
- 問題
- ユニットテストの実装まで完了できていない
- デザインの組み込みが完成していない
- エミュレータ上で動作する状態にない
- 解決策
- 完成の定義を言語化する
- 完成の定義を見直す
- 問題
最後に
ここまで記述したことはあくまで基本的な内容で、途中にも記述したとおりスクラムはプロダクト・スクラムチーム双方がステップバイステップで成長していくためにも、取り組みを形骸化させずに継続的にブラッシュアップを進めていくことが大切だと思います。
個人的にもスクラムを推進することが目的ではなく、あくまでスクラムはプロダクト開発における困難を解決し、より質の高いプロダクトを世に送り出すための手段であることを肝に銘じ、チームメンバーにとっても習慣としてなじんでいけるよう今後もトライしていけたらなと思います。