はじめに
「スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス WEB+DB PRESS plus まとめ」の内容を基調としてスクラム開発についてまとめました。
スクラムとは？
・複雑で激しい問題に対応するためのフレームワーク
＝開発を1週間など期間で区切って回す。開発状況を可視化して、柔軟に対応しながらプロジェクトを進めるフレームワーク
・アジャイル開発を実現するフレームワークの一つ。他にもアジャイルを行うにはXP（エクストリームプログラミング）なのフレームワークがある。
スクラムが向く開発
・仕様が決まりきっていない場合
・開発メンバーが8人以下(それ以上だと管理コストがかかりすぎる)
・「継続的に維持・発展させる必要のある内製プロダクト」向き。SI案件はウォーターフォールが向いている。
スクラム導入の目的
・自己組織化されたチームの実現（生産性が向上）
・開発状況が可視化される（問題発見が早く出来てリスク回避が可能）
・チームの開発パフォーマンスが定量的に測定できる（スケジュールの最適化が計れる）
・他メンバーが何をやっているか把握できる（一体感が生まれる）
・レトロスペクティブ（ふりかえる）を行うことで問題を解消出来る。（チーム体制の最適化、心理的安全性が上がる）
・スプリントで区切ってインクリメントをリリースするので定期的にプロダクトの状態を確認出来る。急な仕様変更にも比較的対応が出来る。
スクラムイベントまとめ
【スプリントゼロ】
・下記をメンバー全員で共有する(後述のインセプションデッキを使うのも手)
・プロダクトを作る背景や理由
・期間内に達成の定義
・スプリントバックログアイテムの完了の定義
・開発環境を整える(GitHub環境,自動テスト環境,CI環境,Slack,開発環境構築)
・プロダクトバックログの作成。
Trelloなどの管理ツールを使用してプロジェクターで社内に投影しておくのも手
【リファインメント】
・プランニングポーカーでバックアップログアイテムの工数を見積る
・見積りが出来ない場合は先にスプリントバックログアイテムを作成して、その工数を見積り逆算する
＊ここからがスプリント工程
【スプリントプランニング】 1weekなら1-2h程度。全員参加（ステークホルダー除く）
・やると決めたプロダクトバックログからタスクを抽出してスプリントバックログを作成する。
・スプリントバックログは書き方のルールを決める（「リリース作業」「不具合対応」など属人化した書き方はNG）。
・スプリントバックログ（タスクボード）はTrelloで管理。プロジェクターで社内に投影しておく。
【デイリースクラム】 毎日15min。開発チーム＋スクラムマスター
・1人づつ「昨日やったこと」「今日やる事」「困っている事」を話す。
・Doneになったタスクがあったらみんなで褒める文化を作る
・バーンダウンチャートを使ってスプリントゴールが達成出来そうかを確認する。
・15分で終わらなければ関係者だけで二次会を行う
・タイマーを使って長くなるのを制御。
【スプリントレビュー】 1weekなら1-2h程度。全員参加（ステークホルダーは参加推奨）
・インクリメント（リリース可能なプロダクト）のレビューを行う。
・スプリントレビュー前でも本番リリースしてOK。レビューでは実装された機能の共有が目的となる。
・場の空気が悪い場合がある。高圧的な態度、睨みを聞かせるステークホルダー、レビュー中に自分のPCしか見ない、雑談する。など。
・率先してアイスブレークをする。
・上記、行為は無しと事前に伝える。
【スプリントレトロスペクティブ】 1weekなら30min〜1h程度。スプリントの最終日に行う。開発チーム＋スクラムマスター
・KPTを行う。仲間への感謝は積極的に伝える。
・一人づつ 問題を付箋に書き出してもらう。問題をグルーピング。それぞれ対応策を考える。
・メンバーそれぞれ課題へのチャレンジを表明することもオススメ
・改善案は具体的に決めること。フワッとさせない。
・ここで出た改善案はスクラムチームのルールとして付箋などで可視化しておくのも有効
・注意しないと特定の人の批判や上下関係による一方的な指示命令になってしまうのでファシリテートをしっかりする
・人ではなく原因に焦点をあてるべき。その意識、姿勢をメンバーで共有する。
・割り込みタスクがあった場合は内容、対応工数などを確認。発生頻度を計測しておく。
・割り込みタスクについては依頼フローを作成。スクラムチーム外にも周知。
・個別の依頼は即答を避ける。ステークホルダーからの直依頼の場合「柔軟性に欠ける」など言われるがプロダクトオーナーやスクラムマスターはスクラム導入の背景、目的をキッチリ説明して理解してもらう必要がある。
・開発チームの実作業時間を計測する。割り込みタスクが把握できればそれが出来る。
大体1日5-6hとなるのが相場。
・レトロスペクティブのルールを作る
・積極的に参加する
・当事者意識を持つ
・議題に集中する
・人で話しすぎない
・人の発言をさえぎらない
・話していないにとにも思いあり
・原因を追求する。責任は追求しない。
・問題 Vs 私たち の構図をつくる
・参加出来なかった人へのフォローが必要。結論だけでなく「なぜ」の共有まで。
スクラム開発におけるロール
スクラムチーム
・プロダクトオーナー
・プロダクトの最終責任者
・開発チームの作業とプロダクトの価値の最大化に責任を持つ人
・「課題達成思考」何を作るべきかを明確に定め、責任を持つ。Whatの部分を担う人。
・ユーザーや取引先関係者と積極的にコミュニケーションをとり、課題や要求を的確に捉える。
・プロダクトオーナーは一人
・開発チームからは独立した存在
・要件を決定する人
・ステークホルダーと交渉してプロダクトバックログの優先順位を決める人
・あまり細かい指示を開発チームに出す事はしない方がベター。自己組織化を阻害する可能性がある。
・スクラムマスター
・スクラムの理解と成立に責任を持つ
・「人間関係思考」コミュニケーションを円滑に進めるかに責任を持つ
・スクラムの実行を支援するスクラム推進者
・プロダクトには直接関わらない
・スクラムマスターは一人
・プロダクトオーナーの仕事をサポートすることもある
・スクラムの方法を勉強会を開きステークホスダー、スクラムチームのメンバーに啓蒙を行う
・スクラムマスターとプロダクトオーナーは兼任できない。
理由：スクラムマスターがプロダクトの最終責任者となる(権力を持つ)事で開発チームの自主性が失われる可能性がある為。
開発チームから独立した視点が失われてプロダクトの質が低下する懸念がある。
・スクラムマスターは開発メンバーにならない方がいい。両者では取るべき振る舞いが違うので兼任しても成果が出ずらい
http://enk.hatenablog.com/entry/2016/11/10/234524
開発チーム
・3〜8人程度
・メンバーはプログラマ、デザイナ、インフラなどの職種の違いによって区別されない。
＊上記三つの間に上下関係はない。対等な立場。
ステークホルダー
経営者など
スクラムの作成物まとめ
プロダクトバックログ
・【管理方法】ホワイトボードと付箋。or スプレッドシート or Trello
・実現すべき機能、要件に優先順位をつけて一覧化したもの。
・優先順位を操作できるのはプロダクトオーナーのみ
・ユーザーの要望、昨日の追加や修正も含まれている
・各機能、要件の事をプロダクトバックログアイテムと呼ぶ。
・下記が例
・読者として本を買いたい
・著者として電子書籍を出したい
・プロダクトバックログアイテムの内容はユーザーストーリーで簡潔に書く
Who,What,Whyと意識する。
・プロダクトバックログアイテムに見積りを記載する。見積の責任は開発チームにある
スプリントバックログ
・【管理方法】ホワイトボードと付箋で管理。か、JIRAなどのイシュー管理システムで管理する。これらはタスクボードと呼ばれる。
・スプリント期間中に行うタスクの一覧。
・プロダクトバックログアイテムがそのまま移動してくる。その子要素として分解されたタスクが配置されている。
・ToDo,Doing,Done で管理
インクリメント
・リリース可能なプロダクト
・完成の定義に沿っている必要がある。技術的負債がたまらないように設定するのも良い手。
・完成の定義の例
・テストコードを書いている
・特定のサーバ上でプロダクトオーナーと共に動作が確認出来た状態
・構文チェックツールを通して問題ない状態
・完成の定義には余裕が出来てきたら非昨日要件も入れると良い。下記は例。
・ブラウザ表示は1秒いない
・セキュリティに配慮されている
スクラムを支えるフレームワーク
・インセプションデッキ（10の問に答えるフレームワーク）
・チーム全体でプロダクトオーナーの考えや自分たちが本当に作るものを理解し、認識を共有する。
・なぜ我々はここにいるのか？
・エレベーターピッチを作る
・パッケージデザインをつくる
・やらない事リストを作る
・ご近所さんを探せ
・解決案を描く
・夜も眠れなくなるような問題は？
・期間を見極める
などなど、、、、
・リーンキャンパス（プロダクトを一枚で定義する）
・参考画像の表を埋める。
・ユーザーストーリー（ユーザー視点での要求を簡潔に記す）
・Who,What,Whyと意識する。
・例えば「カスタマーとしてお気に入りの本一覧を管理したい。なぜなら気になった本を後から購入検討するために」
・ユーザーストーリーマッピング（ユーザ体験を時間軸で整理する）
・参考画像のように時系列と優先順位をつける
・プランニングポーカー
・フィボナッチ数列（0,1,2,3,5,8,13,21....）のカードを準備
・プロダクトバックログアイテムの中で比較的規模が小さいものに「2」を割り当てる
・この「2」と他のプロダクトバックログアイテムを比べて各自のイメージを一斉にカードを出す。
・ずれが大きければ一番大きい人と一番小さい人の意見を聞く
・再び全員でカードを出す。
・3回繰り返してまとまらなかったら平均値か最大値を採用する
・スパイク（技術的不確実性をとりのぞく）
・技術的な事前調査
・バーンダウンチャート（進捗の見える化）
・参考画像の通りベロシティで進捗を可視化する
・パーキングロット（アイデアを一時退避する）
・混乱した議論を収集するためのテクニック
・スプリントレビューなどでアイデアを募集するミーティングを行う場合、目立つところにパーキングロットのコーナーを作っておく。
・あらかじめ参加者に「今日はこの議題に集中したいので、それ以外のアイデアはパーキングロットにメモとして残す事にします」と伝える。
・KPT
・Keep,Problem,Try を振り返る。
GMOペパボの事例
・作業の属人化が問題となっていた。
・まずはスクラムをみんなで学ぼうということで勉強会、ワークショップを行った
・まずここで抱えている作業が把握できていなかったので洗い出しからスタートした。
膨大な量で優先順位が付けられなかったが、その状況が可視化されただけても意味があった。
・スプリントは1週間。実作業日は4日と設定。
・スクラムチームが複数ある場合はスクラムマスター同士での定期的な意見交換を行った。
属人化の解消方法
・開発メンバーのスキルシートを作成して、お互い教えられる部分を可視化する。
・ペアプログラミングなどでサポートしながら簡単なタスクからこなしていく
・時間は掛かるが属人化を解消したいなら仕方がない。ケースバイケースで。
mixiの事例
・作業の属人化が問題だった。特定の人に負荷がかかる、休むと進捗が悪くなる。＝属人化はよくない。
・「なぜ、その作業をするのか？」が共有されていなかったのでモチベーションが低下していた
・スクラムとはチームスポーツのようにプロジェクトを進めていく事
・スクラムマスターとして、下記を成果とした
・まずスクラムの仕組みをメンバーに浸透させる
・属人化などの課題を解決する
・属人化の解消
・いきなりやれといわれても出来ないのは当然。そこはチームメンバーのサポートが必要。
・それぞれの専門が作業するより、はじめは工数が掛かり進捗は遅くなりがち。
・専任のスクラムマスターはいない場合が多い。
DeNAの事例
・専任のスクラムマスターは一人で複数のスクラムチームのマスターを担当
・アジャイルコーチや経験豊富なスクラムマスターと相談しながら進めるのが良い。
・大規模になるとスクラムはツールでの管理やコミュニケーションコストが非効率となる
・そこでプロダクトオーナーとスクラムマスターは一人のまま、チームを分割してスクラムチームを2つ作った。
・業務委託メンバーを含むスクラムの進め方事例
スクラム導入時によくある問題と解決策
・寄せ集めメンバーなのでビジョンが共有できていない
・プロダクトに関してはスクラムチーム全員、開発方針に関しては開発メンバーで、などでビジョンを共有する。
・みんなで考える。
・理想の状態はどんな状態？
・それに比べて現状はどう？
・ギャップを埋めるにはどんな方法がある？
・今やれることは？
・その中でチームでやるべきことはあるか？担当者を決めた方が良いことはあるか？
・開発チームの強みと弱みを可視化すると良い
・参考画像のようにメンバーが保有しているスキル、関心があるスキルをマッピングすると良い
・スクラムへの理解不足
・お試しで１スプリントだけやってみてメンバーからフィードバックをもらう。
・スクラムを使う理由が不明
・トップダウンで進める場合特に「面倒くさい」「効率悪くない？」など悪い印象が先行する。
・スクラムを導入する目的を明らかに提示する。
・意欲がわかないメンバーがいる場合には、その理由を明らかにする。
・最終手段はスクラムチームから外れてもらう
・スプリントは延長しない
・残ったスプリントバックログは終わった％をベロシティとして計上して残りは次のスプリントへ繰り越す。
・限られた期間内でどれだけアウトプットを出せるかを計測しましょう
・イベントは火曜、水曜あたりが良い。月曜は祝日が多い、金曜は休みに入るので不向き。
スクラム導入時によくある問題と解決策
・プロダクトオーナーの問題
・ステークホルダーによって意思決定が覆される
・割り込みタスクの多発
・優先順位変更が多発
→解決方法は「プロダクトオーナーに権限移譲してもらう」「スプリントプランニング、レビューにステークホルダーを巻き込む」
また、権限ごとにステークホルダー・プロダクトオーナーどちらに権限があるかを決めておく。
・リリース日の決定
・プロダクトバックログの優先順位の決定
・継続、中止の決定
・優先順位が決められない
・ROI（Return Of Investment）によって決める。
・本来はプロダクトバックログアイテムに実現することで得られる利益や売上を算出して価値とすることが望ましいが
そこまで出来なくてもプランニングポーカーで価値を見積るでも良い。
・インクリメントを全部受け入れてしまう
・技術的知識がない人にも伝わるように説明する。
・プロダクトオーナーだけでは評価出来ない場合は別のレビュアを立てることも考える
・受け入れ条件を作る
→ようはテスト一覧？これなら単体テストを書いて通ればOKで良いのでは？シナリオテストを書くってことかも。
・開発チームの問題
・メンバー間で知識の差が大きい
・ペアプログラミングを行う。30分でもいいのでやってみて、フィードバックして必要であれば継続する。
・スクラムマスターの問題
・スクラムの奴隷になってしまう。
・そのような時はコーチングで使われるGROWモデルというフレームワークになぞらえて、次のような質問に答えることで、スクラム導入の目的を明らかにしていきます。
・Goal（目標）スクラムを導入することによって目指したいゴールは何ですか？
・Reality（現状）ゴールと現状を比較するとどのようなギャップがありますか？
・Resources（資源）ゴールを達成するために手を貸してくれる人や情報源はどこにありますか？
・Options（選択肢）ギャップを埋めるためにとれる打ち手にはどのようなものがありますか？
・Will（意思）その打ち手は今すぐにやったほうがよさそうですか？
・相談する。
相談できるスクラムマスターが周囲にいない場合は、スクラムコミュニティにやイベントに参加して、経験者どうしで意見交換をしましょう。
日本のスクラムコミュニティやイベントには次のようなものがあります。
・すくすくスクラム（注2）
・スクラム道（注3）
・POStudy（プロダクトオーナーシップ勉強会）（注4）
・ScrumMastersNight（注5）
・RegionalScrumGatheringTokyo（注6）