スクラムを使う理由
ウォーターフォール（かつての一般的なプロセス）
- 定義されたプロセス
- 最初に計画を定義して、その計画に従って厳密に進める
- 計画のずれが最小である必要があり、そうでないと成功しない
- プロジェクト中に要求が変化する可能性は65%あり、ウォーターフォールプロジェクトが成功する確率は世界中で13%しかない。
ウォーターフォールの問題を解決したい
- ソフトウェアプロジェクトは常に遅れ、コストも増えていくもの
→もっといい方法があるはず！
→経験的プロセスに基づいて進めていけば上手くいくのでは。。。？
経験的プロセス
- 予測できない不確実なプロセスを制御するには、フィードバックのサイクルを回していく必要がある。
- 経験した結果を検査し、そこから学んだことを次のサイクルの計画へ適応させ、変更を加えていく
- プロダクトを繰り返しながら増分を積み上げる方法で作る。一つ一つの機能は短いサイクルで完成させる
- 検査と適応を通じて成功するためには、作業のプロセスを完全に見える化して、メンバー皆が分かっている必要がある。
アジャイルとは
- アジャイル＝マインドセット
- 具体的には、「アジャイル原則」に基づく考え方・マインドセット の事
- アジャイル開発とは、アジャイル原則に基づいて開発することを指す
- アジャイル開発の実践方法として、スクラム開発などがある
アジャイル原則
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との強調を
- 計画に従うよりも変化への対応を
スクラムとは
- 下記を実現するためのフレームワーク
- ムダを省き問題を取り除く事で、顧客に価値を早く届けるため
- 顧客と強調してすることで、より価値の高いものを届けるため
スクラムフレームワーク
フレームワークの方針
- シンプルなルールを設定することで、高度で知的な行動が生まれる
- スクラムは障害を一つずつ取り除くアプローチを取る
- スクラムガイドを元に、会社ごとにスクラムの進め方（プレイブック）を決める
スクラムの役割
- 開発者＋SM＋PO ＝ スクラムチーム
- それぞれの役割の責任を果たしつつ、互いに協力し、チーム一丸となってゴールを達成する
- スクラムチームが最小単位で、サブチームは存在しない
スクラムチームの特徴
- 仕事を成し遂げるために必要なすべてのスキルを持っている
- 1スプリントにどれだけの仕事ができるか、どのようにそれを進めるかを自分たちで決める
- 全員で協力してスプリントゴールを達成する
- スクラムマスターとプロダクトオーナーを含めて、通常10人以下
明確な責任を持つ役割について
- スクラムガイドには「プロジェクトマネージャー（PM）」の用語は出てこない
- 誰もがプロジェクトマネージャーの責任を果たす
プロダクトオーナー(PO)
- 「何をするのか」に責任を持つ
- 魅力的なビジョンを策定する
なぜ、このプロダクトは存在するのか、何のためにチームがあり、何を成し遂げるのか - いくつかのプロダクトゴールを設定する
一つずつ達成することでプロダクトビジョンに到達する - プロダクトバックログを作成する
プロダクトゴールを達成するために成し遂げる仕事のリスト - リリース計画を持つ
- プロダクトバックログを集めて整理する
必要なものを必要なときに必要なだけ - 顧客へ価値を届けることに責任を持つ
スクラムマスター
- 「プロセス（仕事の進め方）」に責任を持つ
- 開発者、POをコーチしてパフォーマンスを向上させる。コーチのような存在。
- スクラムイベントを効果的・繰り返し行われるようにファシリテートする
- 作業の見える化を行う
- プロセスの改善を行う
- 上記の結果、チームや組織のゴールを達成させる
効果的なスクラムマスターになるための鍵
- スクラムガイドを理解し、実行する
- チームに見える化する
- 測定可能なパフォーマンスの改善を継続的に行う
ファシリテーターとは何をするか
- ただの司会進行では無い
- 質問をメンバーにたくさんする
- 素晴らしい聞き手になる
- アイデアをまとめる手助けをする
- プロセスの外部にいる。
開発者
- 「どのように実現するのか」に責任を持つ
- スプリントの作業を計画する
- スプリントのゴールを達成するため、毎日の作業計画を状況に応じて適応させる
メモ
-
プロダクトの価値を高めるために行っていたこと
顧客のフィードバックと開発を短いスパンでどんどん回していく
優先度の高い重要な機能から実装していく -
プロダクトをより早く届けるために行っていたこと
直接顧客にヒアリングして、必要のない機能を実装するのを防ぐ
ラフなプロトタイプを作成し、フィードバックを回していく
フィードバック～実装までのスパンが短い
プロダクトバックログ
プロダクトビジョン
- プロジェクト、プロダクト、サービスにおいて、「達成したい将来の状態」を要約したもの
- 顧客が「なぜ」必要とするか から始める。
次に「何を」望むか、
そして、常に「誰が」その未来を実現したいのかを考慮する
プロダクトゴール
- プロダクトビジョンの達成に向けてチームを動かす具体的な成果物
- スクラムチームにおける長期的な目標
- 次のゴールに移る前に、一つのプロダクトゴールを設定しなければならない
プロダクトバックログ
- 誰でも、いつでも、どんなものでもプロダクトバックログに追加できる
誰でもとは、顧客、チームメンバー、他のチームの人も指す - POが優先順位を最終決定する
プロダクトバックログアイテム（PBI）
- バックログアイテムはスクラムチームが成し遂げたいことが、優先順に並べられる
- 顧客向け機能以外のもの（スパイク/リスク削減案/コミュニケーション施策等/バグなど)も含まれる。
- 誰でも追加していってよい
- アプリ内の文言変更等ごく僅かな変更から、大きなアイデアまで、様々な粒度のものが混在している
- POはプロダクトバックログを視覚的に整理して、長期・中期・短期の優先順位を決める
ユーザーストーリーマッピング
- 大きな粒度のバックログアイテムを上に、階層的に分割されたバックログアイテムを下に並べる。
- 顧客の行動の流れに従って左から右へと示す
- プロダクトの全体像を把握できる
ユーザーストーリーのテンプレート
- 【役割】として【行動】したい。それは【ビジネス価値】のためだ
- 対面での会話を通じて、何が必要か、なぜ必要か、を理解するもの
- その理解を確認できる受け入れテストを把握するため
バックログリファインメント
目的
- プランニング時に必要になるPBIの整備
- POとの会話を通じて、これから着手するPBIのコンテキストを明確にする
やること
- スプリントプランニングで、スプリントバックログを作成することができる「準備完了」のPBIを1~3スプリント分用意する
- PBIをスプリント内で完成できるサイズに分解し、必要に応じて優先順位を並び替える
- 各PBIを完成するために必要な労力を見積もる
良いPBIの条件
- ただちに着手できる
独立して提供できるか、外部要因で進まなくなったりしないか - 交渉できる
目的は明確でありながら、実現方法には幅があるか - 価値がある
顧客やビジネスにとって、目に見える価値があるか - 見積もれる
チームが見積もれるくらい明確になっているか - 適正な大きさ
1スプリントで終わる程度の大きさになっているか - テストできる
明確な受け入れ条件が分かっていて、過不足が無いと判断できるか
受け入れ条件
- PBIがテスト可能であるためには、完成の基準が必要
- PBIの一部として受け入れ条件を定義する
- スプリント内でのテストを完了させることを可能とする
- 過剰品質を避け、必要十分な機能性を実現することに集中できる
スクラムパターン
Readyのバックログ
- Readyの定義のチェックリストを作ると良い
安定したチーム
専任チーム
- チームのメンバーが不必要に入れ替わらない方が良い
- チームの専従率をあげると生産性が向上する
少人数のチーム
- 遅れたプロジェクトに人を追加すると更に遅れる
ブルックスの法則 - チームメンバーを増やせば良いわけでは無い
└チーム内のコミュニケーションの浸透度が悪化するため
ソーシャルな負債（新規参入時の教育、文化的ルール、チームのルールの共有等にコストが掛かる） - 最適な人数は3~7人とされている
昨日の天気
- 計画をするときのパターン
- プロダクトバックログからどのようにスプリントに取り込むか
- 前回の実績を計画の予測値に利用すること
└ベロシティを使用 - チームが安定しているとして、次のスプリントでどれだけできるか
- ベロシティー以上をやろうとして失敗すると士気が下がり、生産性も下がってしまう
- 期待値をそのままにして新しい戦略を上手く実現できたら、チームは加速して生産性の向上につながる
スウォーミングのパターン
- チームレベルでマルチタスクを回避すると、プロセス効率が劇的に向上しベロシティの向上につながる
- 複数のプロダクトを同時に進めると、プロダクトを切り替える際にコストがかかり、ムダが発生する
- 同時に進めるプロダクトは1つであるべき
割り込みのパターン
- 割り込み/予期せぬ事態に対する計画をすると43%高速化される
- ベロシティに対してバッファを設けてスプリントバックログに入れると良い
- POが割り込みを行うかどうかを決める
- バッファの大きさは、過去3スプリントの割り込みの量を平均する
- バッファが溢れた場合、スクラム緊急手順を行う
スクラム緊急手順
- 工夫
なにか違うやり方が無いか、チームの作業方法を変更する。 - スプリントバックログを肩代わり
複数のチームが同じプロダクトに取り組んでいる場合、他のチームで対応できないか - スコープを減らす
POと協力してスプリントバックログのスコープを削減する。 - スプリントを中止して再計画する
スプリントを中断した後、可能な限り多くの価値を提供するために、短縮されたスプリントプランニングを開く
あるいは、レトロスペクティブを行い、問題を修正してから再計画する。
尚、スプリント中止はPOのみが判断できる
ハウスキーピング
- 不具合や欠陥は見つけたときに直した方が良い
- 現在のスプリントでの欠陥について、見積もりはせずに直す
- 以前のスプリントでの欠陥の場合、POに確認した後、チームが労力を見積もりしてバッファ内で対応
スクラムをスクラムする
- レトロスペクティブで出たアクションをプロダクトバックログにあげる
幸福指標
- 幸せだとパフォーマンスが向上する
- 幸福度の指標化を行う
- 1~5で幸せ度をスコア付けし平均をとる
- 役割、チーム、会社についてそれぞれスコアをつけていく
- 幸福度が急に低下、下がり続けると、ベロシティも以降のスプリントで下がることが多い
- 幸福度の兆候に早期に対応すると問題を避けられる
スプリントレトロスペクティブ
- プロセスを検査するのが目的
- 次のスプリントで試してみる1つの改善を特定する
- 長期的な視点でのパフォーマンスのため最も重要なイベント
- ここでのファシリテートはスクラムマスターの最重要事項
スプリントプランニング
- スプリントゴールとスプリントバックログを作成する
- スプリントゴールを達成するために、必要となる全てのPBIを含んでいる必要がある。
- PBIはリファインメントされ、「Ready」であること
- スプリントゴールは、スプリント中に現実的に達成可能であること
進め方
- ベロシティのレビューと次のスプリントのキャパシティを決める
この際、休暇や祝日などを考慮する - スプリントゴールを設定する
- ベロシティ上限まで、スプリントバックログに「Ready」のPBIを追加する
バッファも考える - 受け入れ条件を改めて確認して、最終決定する
- 完成の定義を全員が把握していることを確認する
- 作業を開始する
ベロシティ
- 過去スプリントで完了した分のポイントから算出する、次Sprintで達成できるであろうポイントのこと
- 3スプリントの平均を使用する
- キャパシティも考慮する
スプリントゴール
- POがスプリントで達成したいことについて、チームにフォーカスを生み出す
- このスプリントに何の価値があるのか、何を達成しようとしているのか1,2行で記述する
- 「スプリントレビューでは何を見せたいか」の回答を設定すると良い
- POがゴールを提案し、チームがゴールを達成するためのPBIを選択するパターンが一つ
- プロダクトバックログの優先順位が高いものから取得していき、達成するゴールを定めるパターンが一つ
受け入れ条件と完成の定義
受け入れ条件
- 受け入れ条件は、PBIの目的が満たされたことを確認するために、個々のバックログアイテムに適用される
- PBIが完成して目的を満たすものだとPOが確認するための、簡潔なアウトプットの説明のこと
- 通常はPOが記述するが、改善や技術的なものはチームがサポートする事が多い
完成の定義
- 複数のPBIに共通的に適用される基準
- リリースする際の品質マークとも言える
- 部門全体、会社全体に適用することも可能
デイリースクラム
- スプリントゴールの達成に集中できるようにするために行われる
- 開発者はスプリントゴールの達成に向けた進捗状況を検査し、必要に応じてPBIの調整・再計画を行う
- ステークホルダーに対する達成に向けて、進捗の議論、障害物の特定を行う
- 必要に応じて、デイリースクラム以外での詳細な議論必要であるかを特定し、整理を行う
- 基本的には下記について話す
進捗報告
障害物が無いかの確認
スプリントゴールを達成するために次に何をするべきか
パーキングロット
- 議論を掘り下げる必要があるが、タイムボックスから溢れてしまう時に使用
- 議論に参加する必要がある人のみ参加し、他の人はスプリントバックログの仕事に戻る
PBIの見積もり
- ベロシティを知り、適切な量をスプリントバックログに入れるために行う
背景
- 時間見積もりは間違いも多く、変動も大きかった
- 人間は相対的な大きさで評価するのが得意だと分かった
- 他の意見に左右されるのを防ぐため、一人で見積もる必要がある
- 実験によると、時間見積もりよりポイントの方が50倍早く見積もれる&正確さは同等かそれ以上と分かった
基本的な手順
- 時間を見積もらない
- バックログアイテムを完成させる労力の相対的なサイズを見積もる
- スプリントごとにベロシティを測定し、リリース計画をたてる
- 見積もりは、依頼者ではなく、実際に作業をする人が行う
- プロジェクトの開始前だけでなく、期間を通じて常に見積もりを行う
- 詳細に記述したドキュメントよりも口頭での会話を用いる
リファレンスストーリー
- 様々なポイントの基準を作ること
- 新しいPBIを見積もる時は、リファレンスストーリーの「ものさし」と比較することにより、より相対サイズの見積もりがしやすくなる
- リファレンスストーリーが時間の経過とともに古くなったら、チームが良く知っている新しい仕事に置き換え、常にメンテナンスする
- 同じような仕事をしているチームがあれば共有するのも良い
プランニングポーカー
- 開発者はフィボナッチ数列のカードから一つ選ぶ
- 全員が同時にカードを見せる
- 全員が数字の連続する3つの数の範囲に収まっていれば、平均値をポイントとし、次の見積もりに移る
- 4つ以上にまたがっている場合、最大値・最小値を出した人がその根拠を説明する
それを踏まえて再度全員でカードを選び直す
結果3つの連続するカードにおさまったら、平均値をポイントとして、次の見積もりに移る
注意点
- 決してチーム間で見積もりを標準化しない
- 決してチーム間でベロシティを比較しない
- ベロシティの傾向（加速・減速・平になっているか）はチーム間で比較できる
- 傾向を比較することで、コーチが集中すべき領域が見つけられる
リリースプランニング
リリースバーンダウンチャート
- プロダクトのバックログの進捗状況をスプリントのリアルタイム性で可視化するためのツール
- 縦軸にスプリントでこなす総ポイント数、横軸をスプリント単位（日程）とする
考慮点
- リリースするために費やすことができるベロシティの割合を把握する
- PBIの見積もりの他、下記のような必要な作業も考慮する
- Undone作業（ユーザーの受け入れテスト）
- 後発的な要求
- リリース後の顧客側イシュー
スプリントボード
- 目で見る管理によりフローを改善するとされている
- スクラムの作成物＝目で見る管理ツール
必要な情報
- スプリントゴール
- スプリントバーンダウンチャート
- チームのスプリントコミットメントに向けた進捗がわかる
- 割り込みバッファの状況が分かる
- 追加される提供価値の見える化ができる
- スプリントバックログ
- 進捗状況
- 障害物の見える化
- プロジェクトレベルの障害物
- チームレベルでの障害物
- 割り込み
良いスプリントボード
- 優先度の高いものから順に完了させていく
バリューストリーミングマッピング
- プロダクトのリリースまでを通じて価値がどのように創出・流用するかを視覚的に表現する手法
- 待ち時間と実働時間をフロー図などでまとめる
- リードタイムとプロセスタイムからプロセス効率を計算する
プロセス開発でのコツ
- プロダクト開発の高速化は、要因追加よりもプロセス改善で達成できることが多い
- スクラムはボトルネック除去の優れたツール
スプリントレビュー
- プロダクトのインクリメントをステークホルダーにデモし、プロダクトバックログに適応できるフィードバックを求める
- ステークホルダーの反応と、プロダクトのフィードバックを収集することが重要な成果
- 最優先の成果はフィードバックを得ること
- プロダクトバックログの優先順位変更の議論は２番目の優先事項
インクリメント
- 最終的な作成物
- プロダクトに追加される一部
- 完成の定義を満たしている必要がある
- 価値がある・検査できるもの
- 各インクリメントは、以前全てのインクリメントに追加された状態でプロダクト全体としてテストされる必要がある。
- インクリメントはリリースの有無に関わらず、動作可能な状態でなければならない