スクラムマスター認定
一日目午前 : スクラムとは?
小さなチームが新製品を開発する際に、素早くイノベーションを行うこと。
by ジェフ、サザーランド
これらのフレームワークはソフトウェア開発だけでなく、仕事の仕方そのものに影響を与えることができる。
スクラムは、チームビルディングからスタートする。
この時に、ワークショップを行う。
そのうちの一つが、ワーキングアグリーメント。
働き方などの決めごとを用意する。
ex)
エクササイズ 役割分担
POを一人選ぶ
AMを一人選ぶ
そのほかは複数の開発者
面白くてかっこいいチーム名を決める
主な役割：ファシリテーション
PO
意思決定
メンバー全員の参加
- すべてのメンバーがバックログアイテムの作成に参加している状況を作る
クラスへの共有
開発者
そのほかのメンバーは開発者となる
スプリントとは
スプリントはスクラムにおける⼼臓の⿎動であり、スプリントにおいてアイデアが価値に変わる。
⼀貫性を保つため、スプリントは 1 か⽉以内の決まった⻑さとする。前のスプリントが終わり次第、新しいスプリントが始まる。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペク
ティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で⾏われる。
スプリントでは、
スプリントゴールの達成を危険にさらすような変更はしない。
品質を低下させない。
プロダクトバックログを必要に応じてリファインメントする。
学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要に
なる場合がある。
スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり、予測可能性が⾼まる。
スプリントの期間が⻑すぎると、スプリントゴールが役に⽴たなくなり、複雑さが増し、リスクが⾼まる可能性がある。
スプリントの期間を短くすれば、より多くの学習サイクルを⽣み出し、コストや労⼒のリスクを短い時間枠に収めることができる。
スプリントは短いプロジェクトと考えることもできる。
進捗の⾒通しを⽴てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。
これらの有⽤性は証明されているが、経験主義の重要性を置き換えるものではない。
複雑な環境下では、何が起きるかわからない。すでに発⽣したことだけが、将来を⾒据えた意思決定に使⽤できる
定義されたプロセス
伝統的なウォーターフォールプロセスは最初に計画を定義し、減未tにその計画に従って最後まで進める。
このアプローチは、計画からのずれが最小である必要がある。そうでないと、計画は成功しない
しかし、プロジェクト宙に要求が変化する可能性は6%%であり、その結果ウォーターフォールプロジェクトが成功する確率は13%
内訳は以下の通り。
成功率:13%
遅延、予算超過：59%
失敗：28%
これを解決するのが、スクラムであり、ジェフ、サザーランド博士が1993年に開発した。
スクラムは、経験的プロセスに基づいている。
化学工学では、経験的プロセスを用いていた。
ex) 結果がわからない実験を、仮設し、実行するプロセス。
経験的プロセス
予測できない変化が起きるプロセスを制御するには、フィードバックループを導入しなければならない。
経験した結果を検査しそこから学んだことを、次のサイクルの計画へ定期往査せ、変更を加えていく
スクラムの経験的プロセスとは、透明性、検査、適応の三本柱で成り立っている。
アジャイルは日本企業の働き方から生まれた
日本では新製品を開発するときの手法研究を、野中幾次郎、竹内博隆さんが論文として作成した
...
アジャイルとは考え方
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くプロダクトを
契約交渉よりも顧客との協調を
計画に従うよりも変化の対応を
価値とする。
左の部分に価値があると認めながらも、右側のことがらにさらに価値を置く。
ちなみに、アジャイルの語源は「アジャイルな競争相手とバーチャルな組織 - 顧客を豊かにする戦略」からきている。
デリバリーのフレームワーク
コラム
日本の「トヨタ生産方式」がもとになったにもかかわらず、なぜ日本にスクラムの考え方がないのか?
1950では「トヨタ生産方式」はあった
しかし、1980のバブル崩壊で、「業績偏向型」に変わってしまった
その結果、分社化が進み、「ソフトウェア」「ハードウェア」等の役割ができる。
最終的には「受発注」の考え方が進み、ウォーターフォールが強くなってしまった。
フラッシュビルドの実装。
フラッシュビルドの実験として、
サングラスを売るお店で、サングラスを選ぶためのiPadアプリを作成する。
「サングラスを選ぶipadアプリ。
機能は決まっていない。
ユーザーストーリーマッピングの構築
行動やプロセスを知る。
ラフなプロトタイプを見せる作業で、捨てたり変更できたりする。
ペーパープロトタイプを作る。
アナログなやり方でも、Ipadアプリと同じものを作る。
エンジニアはペーパープロトタイプを動かして、
フラッシュビルドを行う。
最終的なアイデアは、サングラスを欠けている写真を比較する。
アプリを横向きに固定する。
スクラムガイドは、10ページ
スクラムの単純なルール
5つの会議
スプリントプランニング
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ
バックログリファイメント
3つの役割
3つの成果物
The Rule Book という名前で、スクラムのルールを定めている。
- -> これは世界共通
しかし、これはあくまでスクラムのルールであり、実運用はチームによってカスタマイズされており、自己組織化されている必要がある。
また、スクラムフレームワークに戦術を取り入れるため、Scrum Play Bookという名前で作る。
- -> Scrum Play Bookはチームごとにことなる
メンバーの3つの役割
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキル
を備えている。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチー
ム内で決定する。
スクラムガイドには、プロジェクトマネージャーは出てこない。
その代わり、本来プロジェクトマネージャーが負うべき責任を、3つの役割に分けている。
プロダクトオーナーの役割
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること
の結果に責任を持つ。
いわば、何をに責任を持つ
組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。
いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重し
なければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリン
トレビューでの検査可能なインクリメントによって⾒える化される。
プロダクトオーナーは 1 ⼈の⼈間であり、委員会ではない。プロダクトオーナーは、多くのス
テークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダー
がプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。
スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラム
チームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任
を果たす。
スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。
スクラムマスターは、さまざまな形でスクラムチームを⽀援する。
l ⾃⼰管理型で機能横断型のチームメンバーをコーチする。
l スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できる
よう⽀援する。
l スクラムチームの進捗を妨げる障害物を排除するように働きかける。
l すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックス
の制限が守られるようにする。
l 効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀
援する。
l 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解
してもらう。
l 複雑な環境での経験的なプロダクト計画の策定を⽀援する。
l 必要に応じてステークホルダーとのコラボレーションを促進する。
スクラムマスターは、さまざまな形で組織を⽀援する。
l 組織へのスクラムの導⼊を指導・トレーニング・コーチする。
l 組織においてスクラムの実施⽅法を計画・助⾔する。
l 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施しても
らう。
l ステークホルダーとスクラムチームの間の障壁を取り除く。
それ以外の作業は以下の通り
対立の解決
仕事の無駄の見えるか
イベント成果物の集中
POとSMは「絶対に兼任してはいけない」
そもそも、POとSMは目的が異なる。
POは「プロダクトの価値」に重きを置く
SMは「チームのパフォーマンス」に重きを置く
この二つの目的は対立する場面が多く、一人の人間ではまかなうことができない。
開発者の役割
開発者は「どのように」に責任を持つ
まとめ：開発者とSMとPOでスクラムチーム
それぞれの役割の責任を果たしつつ、お互いに協力し、チーム一丸となってゴールを達成する
スクラムチームが最小単位。サブチームは存在しない
3つの成果物
プロダクトビジョン
プロダクトビジョンは、プロジェクト、プロd買うと、サービスにおいて、「達成したい将来の状態」を要約したもの
顧客が「なぜ」ひつようとするか、から始める
次に顧客が「なに」を望むかを含める
そして常に「だれ」が使うかをかんがる
プロダクトゴール
チームにとっての長期的な目標
プロダクトバックログは、スクラムチームによって成し遂げたい仕事の集まりで、ビジネス価値の順番に並べられている。
誰でも、いつでも、どんなものでもプロダクトバックログに追加できる
しかし、最終的にはプロダクトオーナーがプロダクトバックログの優先順位付けを行う。
プロダクトバックログアイテム（PBI）
スクラムチームがやりたいことの「最小単位」
ex)
顧客向け機能
アーキテクチャ
チームのインフラ
調査研究
リスク削減策
これは、「技術的な側面」ではなく 「顧客にとっての価値、機能単位」である必要がある。
これらのPBIを探すためには、「直接顧客とはなして、必要な機能をリストアップする」ということが大事である。
ユーザーストーリーマッピングの、テンプレートはこれ
「役割」として「行動」がしたい。
それは「ビジネス価値」のためだ。
スプリント
- 目的：スプリント終了時に、顧客やステークホルダーに提供することができる、価値があり達成可能な目標にコミットする。
イベント中に、その成果を達成するために必要な特定のバックログアイテムを選択する。
推奨されるタイムボックスは、スプリントの長さが1週間あたり最大2時間。
- 注意：スプリントプランニングのすべての時間がバックログリファイメントに費やされると、ゆっくりとした非生産的なミーティングになる。
ミーティングの前にできる限りバックログアイテムの内容を明確にして、チームが優先順位付けに集中できるようにし、仕事をどのように終わらせるかを考えられるようにしておく。
必要なもの
成果物
数プリントバックログ
スプリントゴールを達成するための計画
チームのコミットメント
プロセス
過去のベロシティとチームメンバーの稼働率からチームのキャパシティを産出する
POはゴールの候補を提案する
スプリントバックログに、改善とスプリントゴールを達成するために必要なリファインメントされたプロダクトバックログアイテムを入れる
スプリントゴールを達成するために、どのように作業を進めるかの計画を作成する。
あらためて、今スプリントのゴールを決める。
スプリントプランニング
スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。
結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。
プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。
スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよい。
スプリントプランニングでは、次の3つの問いに応えられるようにしておく必要がある。
- トピック 1：このスプリントはなぜ価値があるのか？ :
スプリントゴール
プロダクトオーナーは、プロダクトの価値と有⽤性を今回のスプリントでどのように⾼めることができるかを提案する。
次に、スクラムチーム全体が協⼒して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。
スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。
- トピック 2：このスプリントで何ができるのか？ :
どれくらいできるのか? : 稼働時間と能力
開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを
選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバッ
クログアイテムのリファインメントをする場合がある。それによって、チームの理解と⾃信が
⾼まる。
スプリントプランニングで、PBIの内、「準備完了」となるものを1~3スプリント分用意する
リファイメントとは「洗礼させる」という意味
1. ユーザーストーリーマッピング(PBI)のエピックを分割する
エピックは、長編物語、大きなストーリのこと
次のPBIは「エピック」と呼ばれる単位「マイレージ会員として、航空券の予約を自分向けにカスタマイズしたい。なぜなら時間の節約になるから」
-> これを、分割すること
マイレージ会員として、マイルを使って予約したい。節約できるから
マイレージ会員として、よく使う路線を簡単に予約したい。なぜなら時間の節約になるから
プレミアムマイレージ会員として、ラウンジを予約した。ゴージャスな生活がしたいから
2. 優先順位をつける
ユーザーストーリーマッピングから分割した後、
3. READYなPBI
INVEST
I Immediately 直ちに着手できる
N Negotiable 交渉できる
V Valuable 価値がある
E Estimateable 見積もれる
S Small 小さい
T Testable テスト可能である。
Testable : 受け入れ時要件の作成
バックログアイテムがテスト可能であるためには、完成の基準が必要である。
PIBの条件としては受け入れ条件を定義する
メリットとしては以下の通り。
テスト駆動開発を促進する
過剰品質を避け、必要十分な機能性を実現する
例
title
- 【運用者】従業員情報csvファイルアップロード状況を一覧で確認できる
<ストーリーポイント>
<理由>
- お客様がまとめて福利厚生サービスを契約した後、csvをアップロードしなければ契約状況を管理するサービスとならない
<受け入れ条件>
- 画像イメージは添付資料のまとめで福利厚生従業員登録情報の通りであること
スプリントレビュー
スプリントレトロスペクティブ
スクラムチームは作業の品質と有効性を高めるためにプロセスを検査する。
レビューでは、デモなどを行いフィードバックを得るのが目的であり、POが主役である。
しかし、スプリントレトロスペクティブではSMが主役となり、生産性向上のためにできることを探す場となる。
スクラムチームは、もっと良くなるために次のスプリントで試してみる一つの改善を特定する。
スクラムチームの長期的な視点でのパフォーマンスのために最も重要なイベント
このイベントの効果的なファシリテートは、スクラムマスターの最優先事項 : なぜなら、チームの生産性の向上に責任を持つのはスクラムマスターの優先事項だから
スプリントレトロスペクティブでは、正しい進め方はない。
ネットでも多くの手法がある（KPTなど）
共通しているのは以下の通り
場を設定する
データを集める
アイデアを出す
次に何をすべきかを決める
一例 :
タイムライン : 今週のスプリントで何が行われたのか?
次のスプリントでは、どこを違うようにやってみるか?
- スプリント レトロスペクティブで出てきた改善点は、必ず優先事項の一番上に追加すること*
幸福指標を図る。
自分のパフォーマンスを1~5で表明する。
あなたの役割についてどう感じるか?
チームについてどう感じるか?
会社についてどう感じるか?
もっと良い感じになるにはどうすればよいか?
内発的なモチベーションを促すことで、仕事の効率をあげることができる。
外発的なモチベーションは、お金や権力や地位のことであるが、持続性は低い。
スクラムマスターにとって、チームの幸福指標は、パフォーマンスの先行指標 である。幸福指標をみれば、チームに何が起きているかわかる。
プロダクトインクリメント
スクラムマスターが取り入れることができる、ベストプラクティスがスクラムパターン。
あくまでベストプラクティスなので、取り入れるかどうかは自由。
1. どのように始めるのか
Readyのバックログ。
2. 安定したチーム
チームメンバーのパフォーマンスを安定させるためには、以下の二つを意識すること
3. 昨日の天気
スプリントが完了した後、スクラムマスターは直近のベロシティだけを計測するべきではない。
可能であれば、「直近3スプリント分の平均」を設定するべきである。
また、外部からの期待値をそのまま受け入れて、その通りにPBIを追加してしまうと自分でハードルを上げてしまうことになる。
基本的には「直近3スプリント分の平均」で対応するべきである。
4. スウォーミング
タスクは集中するべし。
同時に複数のサービス調査するべきでないし、同時に複数の昨日の実装をするべきではない。
※スウォーミングとは、「ソフトウェア開発の文脈では，一つのタスクや開発トピックにチームの全員 (全員ではなくても，多人数) で取り組むことを指します．」
スウォーミングのメリットとして、
それぞれのメンバーが別々の開発アイテムを勧めていると、知識の共有化ができない、その人間の能力がボトルネックになる
タスクの切り替えの発生による、切り替えのムダ、待ちのムダを防止することができます。
ソフトウェア開発は課題にぶつかることの連続であり、誰かが知っているということは多いので、わからない→迷う→調べる→悩む→相談する という長いリードタイムよりも、その場に知っている人間が全員揃っていれば、チームの最大速度でアイテムを消化することができます。
5. 割り込みのパターン
予期せぬ事態。計画できない仕事のことを「割り込み」と呼んでいる。
スプリントでは、1週間で計画を建てて実行するため、この「割り込み」は致命的になる。
この「割り込み」が発生するときの対策としては 「割り込みが発生することを見越して、空のバックログを作っておく」 のがよい
名前は「Buffer」と呼ぶ。
割り込みの予測の方法は「過去に発生した割り込み」の平均を出す。
-> POはチームがやることの優先順位をつける責任をもつため、割り込みが発生しそうになった時に優先順位をつけるのは「POがやる」
スプリントの途中で、スプリントが失敗するのが明らかになったとき
工夫 : まずは何か違うやり方がないか、チームの作業方法を更新sるう
肩代わり : 他のチームで対応することができないか
スコープを減らす : プロダクトオーナーと協力してスプリントバックログのスコープを削減する。
スプリントを中止して再計画する
7. ハウスキーピング
欠陥のないプロダクトを作るスクラムパターンが「ハウスキーピング」
バグを直す最高のタイミングは「発見したとき」である。
