こんにちは。
請求管理ロボシステムPMの田本（@tamotamo97）です。
前回はスクラム開発を導入する〜その1〜で、なぜ今スクラム開発を始めるのかについて書きました。
本記事はスクラム開発を始めるにあたって勉強してきたスクラム開発のオーソドックスについて書きたいと思います。
アジャイル開発って何？
スクラムの前にアジャイルについて少し触れます。
アジャイルとは変化に適応するためにチームが助け合ってより良い方向に向かっている状態のことです。
MVPアプローチという手法がアジャイルの本質と言われており以下の図の下がそれを表しています。
小さい単位でサービスを提供し、変化に適応して改善を繰り返すのがMVPアプローチです。
イラスト引用元 Agile も DevOps も銀の弾丸なんかじゃない
スクラム開発って何？
ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされる。
引用元 スクラム (ソフトウェア開発) - Wikipedia
スクラムガイドではスクラムを次のように定義しています。
スクラムは複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価 値の高いプロダクトを生産的かつ創造的に届けるためのものである。
スクラムは以下の3つを柱としています。
- 透明性
経験的プロセスで重要なのは、結果責任を持つものに対して見える化されていることである。
- 検査
スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない変化を検知する。 ただし、頻繁にやりすぎて作業の妨げになってはいけない。
- 適応
プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合は、プロセスやその構成要素を調整する必要がある。
スクラムの価値基準
スクラムは以下の価値基準を持ちます。
- 確約（commitment）
- 勇気（courage）
- 集中（focus）
- 公開（openness）
- 尊敬（respect）
スクラムチームのメンバーは、スクラムの役割・イベント・作成物に触れて仕事を進めるなかで、これらの価値基準を学習・探索します。 スクラムを活用するには、これらの5つの価値基準を上手に実践する必要があります。
個人は、スクラムチームのゴールの達成を確約し、正しいことをする勇気を持ち、困難な問題に取り組まなければいけません。
全員が、スプリントの作業とスクラムチームのゴールに集中しなければいけません。
スクラムチームとステークホルダーは、すべての仕事とそれらを遂行する上での課題を公開することに合意しなければいけません。
スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけません。
開発フローについて
スクラム開発の流れをざっくり理解するのに1枚の写真でまとめられたものがあります。
これを見ると流れがわかりやすいです。
イラスト引用元 スクラムの概要を1分で理解できるイラスト【2018版】
上記図から大きくスプリント、ロール、イベント、アーティファクトの4つの要素に分けることができます。
これをスクラムの4大要素としています。
スプリント
スプリントと呼ばれるタイムボックスをチームで決めます。（弊社は１週間としました）
このスプリントごとにスクラムイベントをこなしていきます。
ロール（役割）
スクラムを始めるうえでまずはチームメンバーの役割を決めます。
役割はプロダクトオーナー、スクラムマスター、開発チーム、ステークホルダーの4つに分類されます。
プロダクトオーナー（PO）
- スクラムチームに1人
- 何を作るのかを常に考える人で、ビジョンとアイディアの優先順位付きリストを作成する
- プロダクトの価値の最大化がミッションで価値の最大化＝投資対効果（ROI）の最大化を目指す
スクラムマスター（SM）
- スクラムチームに1人
- スクラムの促進と支援に責任を持つ
- スクラムの理論、プラクティス、価値基準を理解してもらうことで責任を果たす
- どうやって理解をしてもらうのか？
- スクラムイベントのファシリテーション
- スクラムをうまくできるようスクラムチームをコーチ
- 一緒にうまくいく方法を考える
- ....
- スクラムマスターはチーム全体で自己解決力をつけていくためにチームにこうしなさいとか、こうであるべきとかは言わない。サーヴァントリーダー
サーヴァントリーダシップ ⇔ コマンドアンドコントロール
支援型 命令型
開発チーム
- スクラムチームに3〜9人
- 毎スプリント、リリース判断可能なインクリメントを届ける責任を持つ
- 3人より少ないと相互作用が少なく生産が向上しない、スキル不足でリリース判断可能なインクリメントが作れない
- 9人より多いと調整の機会が多くなりすぎる
- どうやって作るか・進めるかを自分たちで決める、全部決める
- 改善が発生しやすい状態を作るため自己組織化を目指す。機能横断だと自己組織化しやすい
ステークホルダー
- ビジネスの責任
- 要求
- 仕様についての意見
- プロダクトの方向性の決定
スクラムイベント
スクラムには5つのイベントがあります。ある一定の期間（スプリント）でイベントをこなしていきます。
所要時間についてはスプリントを1週間とした場合の必要な時間を書いています。
バックログリファインメント
目的 中長期計画の見直し
実行のタイミング いつでもOK
参加者 PO/SM/開発チーム
所要時間 2時間
- プロダクトバックログを見ながら、POと開発チームがPBIの中身や優先順位の変更を行う
- 必要に応じてPBIの追加・削除・分割・明確化
- PBIの見積もり（見積もりは相対見積もり）
PBIの見積もりの例
- 相対見積もりなので、基準のPBIと比較しストーリーポイントをつける
- 高い精度を求めないで、フィボナッチ数列を用いることが多い→あまり時間をかけたくないが一番
- POと開発チームがPBIの認識合わせをする
- スプリントごとにベロシティで見通しがわかりやすい
スプリントプランニング
目的 短期計画の実施
実行のタイミング スプリントのはじめ
参加者 PO/SM/開発チーム
所要時間 1時間
- 次スプリントでやることを決める
- プロダクトバックログからPBIをスプリントバックログに移す
- 開発チームで実現方法を話し合う
- PBIをタスクに分解する
- タスクごとに時間見積もりをする
デイリースクラム
目的 コラボレーションとパフォーマンスの最適化
実行のタイミング 毎日
参加者 SM,開発チーム
所要時間 15分
- 次のデイリースクラムに向けた計画
- 昨日やったこと、今日やることを共有
- 課題、困っていることの確認をする。議論はしない
スプリントレビュー
目的 インクリメントの改善案をもらう
実行のタイミング スプリントの終わり
参加者 PO,SM,開発チーム＋ステークホルダー
所要時間 1時間
- スプリントで完成した製品（インクリメント）の共有
- 参加者からFBを受け、ブラッシュアップするための議論をする
- 改善案はプロダクトバックログに追加
レトロスペクティブ（振り返り）
目的 次スプリントの改善計画
実行のタイミング スプリントの終わり
参加者 PO,SM,開発チーム
所要時間 1時間
- 直近のスプリントの振り返りを行う
- 次のスプリントで実行するプロセス改善や生産性向上のためのアクションを決める
- 振り返りの手法は開発チームで決める
- スクラムマスターは課題顕在化のサポートをする
アーティファクト
成果物です。成果物ごとに定義があります。
スクラムでは3つの成果物を作成します。
プロダクトバックログ
- アイディアの一覧
- 優先順位順に並んでいる見積もりがされているユーザーストーリー形式
- 例えば、旅行に行きたいとしたら、
- テーマスポットに行きたい
- 美味しいものを食べたい
- ・・・
とリストで並ぶ。
プロダクトバックログアイテム
- 概要
- 受け入れ条件
- 見積もりポイント
- やらないこと
ユーザーストーリー形式とは、「誰が」「何を」「どうして」の3点にフォーカスして書かれているもの。
スプリントバックログ
- やりたいことの達成方法が洗い出されている
- そのスプリントの状況が一目でわかる
- 常に更新されている
- 開発チームによって管理
- そのスプリントのゴール
- 〇〇したい
- ☓☓したい
【PBI】
プロダクトバックログから選択した、そのスプリントで達成したいアイテム
【タスク】
そのアイテムを完了させるために必要な作業のリスト
インクリメント
- スプリントで完成した成果物
- リリースしようと思えばすぐ可能
- 「完成」されている
おまけ
DONE(完成)の定義
- チームごと異なる、決めるのけっこう難しい
- 何をもって完成したというのかをチームで定めて守る
- スケジュールを守るべきか、質を守るべきか
- 完成しなかったものは次のスプリントに回され
- チーム内で決めたスプリントは絶対に守らないといけないものではない
最後に
公式スクラムガイドや各書籍でも書かれていますが、基本的なスクラム開発の形はあれど、チームやサービスの特性によってアレンジしていくことが必要であり、それが是とされています。
色々なスクラムの形を作っていく難しさもありますが、スクラムは基本からすでに難しいと思っています。まずカタカナが多いし、学ばなければいけないことが多いからです。
スクラム開発が全てとは思っていませんし、我々のチームではこれが一番適している！と思っている開発手法でも状況によって最適な形は変化していくと思います。
大切なのは状況に応じて色々な形を検証して評価していく、ということだと思います。 これからも現状に満足せず、常に挑戦、検証をしていきたいですね。
これからこんな感じでやっていきますが、しばらく運用して気づきや学びがあればまた適宜共有していきます。
それでは今日はこのへんで。
