認定スクラムマスター研修を受けたのでその整理
認定スクラムマスター研修とは？
認定スクラムマスター研修（CSM）は、認定スクラムトレーナー（CST）によって開催される Scrum Alliance 認定研修です。
本研修を通じて認定スクラムトレーナー（CST）に認定スクラムマスター（CSM）の能力を認められたら、Scrumm Alliance に登録されます。
Scrumm Alliance に登録されるとオンライン試験の受講資格が与えられ、このオンライン試験に合格すると認定スクラムマスター（CSM）と認定されます。
認定スクラムマスター （CSM） は、スクラムマスターとして必要なスクラムの基礎を理解していることを示します。
受講するにあたっての自分の中の疑問をこの研修で解決できたらいいと思ったこと。
- 全員がなっとくして、共有の理解を得るには？
- 設計は、いつやるのか？
- ゴールを意識するには？
- 生産性とは？
アジャイルとは？
アジャイルソフトウェア開発宣言
アジャイル宣言の背後にある原則
アジャイルとは、価値があるものを生み出す為に、より良い開発方法を見つけ出そうとしている時のことをさす。
それ以外の時は、それはアジャイルではない。
スクラムだろうがXPだろうがWFだろうが、 より良い開発方法を見つけ出そうとしている時はアジャイルであり、それ以外はアジャイルではない。
スクラムは何を解決してくれるフレームワークなのか？
- 開発効率向上
- 状況の変化に強い
- 成長できる
そういったフレームワークではありません。
そういった効果があったとしてもそれは、そのチームが努力した結果でしかありません。
スクラムは下記のことしかできません。
スクラムが有効なのは？
スクラムは、下記のような単純なものや既に実現方法が明確に決まっているものには向きません。
- 実現内容が単純な場合
- 実現内容が変化しない場合
- 実現方法が明確に決まっていて、失敗する可能性が小さい場合
そのプロジェクトが単純なほどウォーターフォールなどが向いています。
また、スクラムチームの生存期間が３ヶ月以下の場合はスクラムで進めても効果が薄い（統計データー的にスクラムチームが学習したものが活用されるのが3ヶ月経過してから）。
上記以外ならスクラムはほぼ有効に活用できる。
Working Agreement
チームルールを全員で議論して、その決めたルールを明文化します。
このルールは、全員が納得した内容でなければなりません。
スクラムマスターは、この時、議論がカオス化しないようにきをつける必要があり、
議論内容の質と時間のバランス（指標的なもので判断）をとりながら全員が納得した内容になるようにしなければなりません。
Working Agreementを作成する時の注意事項としては、下記のようなものがあります。
- アクションに繋がらないスローガンのようなものはダメ。（例：相手を尊重する、等）
- ルールは具体的に、判断できるようなものを目指す。計測できることが望ましい。
- ルールを決めるためのルール、ルールを変更するためのルールなども決めておく。
スクラムのルールとしては、まだ入っていませんが、現在、ルールとして入れるか検討中だそうです。
スクラムのルール
３本柱
透明性
現在の状況が全員に対して可視化されていること。
また、チームルールや開発手法なども全員が納得して共通理解を持っていること。
- 進捗状況を全員が共有している（完了/未完了？完了の場合は作成物は？）。
- プロセスの用語を全員が理解している（誰に聞かれても明確に説明できる状態）。
- 開発手法に関して全員が納得して共通理解を持っている（誰に聞かれても明確に説明できる状態）。
- チームルールに関して全員が納得して共通理解を持っている（誰に聞かれても明確に説明できる状態）。
- 作業内容に関しての完了の定義を全員が共有している（誰に聞かれても明確に説明できる状態）。
下のような曖昧な状態は、認められない。
- もうすぐできます。
- 90%ぐらいです。
- こんな感じで開発するんですよね。
検証
成果物やプロセスを検証することで、変化を検知します。
また、 新しい開発手法や改善などの取り組みに関しても検証します。
- 成果物は、想定通りなのか？
- 取り組んだ改善方法は、想定通りの効果が出たか？
- 新しい開発手法は、想定通りの効果が出たか？
適応
プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと判断された場合、
プロセスやその構成要素（仕様や開発手法及び改善への取り組みなど）を調整する必要がある。
調整はできるだけ早く行い、これ 以上の逸脱を防がなければいけない。
- 実実を元になんらかの調整や改善を行います。
- 誰にでも明確に理解できるもの（数値化されているなど）で、全員が納得し共通理解を持っているものを適応させて行きます。
- 根拠が曖昧なものを元に適応することはありません。
役割（ロール）
プロダクトオーナー
- チームのROIを最大化する。
- 誰にでも費用対効果を説明できる。
- 手法やコストなどを総合的に判断できる。
- チームのコストを最小化（下げる）する。
- チームが誤った方向に行かないようにする。
- 多くの情報を収集できる。
- 内外の状況を察知できる。
- 他のチームや組織などと交渉できる。
スクラムマスター
- スクラムが適切に活用される状態を作る。
- スクラムが適さない場合は別の方法を提案できる。
- チームの生産性を3ヶ月で46%以上向上させる。
- 自律的なチームを2ヶ月で作る。
- 自律的なチームを維持（守る）する。
- ベロシティを最大の部分で安定させる。
- 曖昧なことは明確化（数値化）する。
チーム
- 約束されたことを必ず実現する。
- チームの生産性を高める努力をする。
- 個人の能力を高める努力をする。
- 出来ないことは出来ないと主張する。
- ベロシティを最大の部分で安定させる。
アーティファクト（成果物）
プロダクトバックログ
プロダクトに必要なフィーチャ・機能・要求・要望・修正がすべて並べられた一覧です。
プロダクトオーナーは、プロダクトバックログの内容及び、並び順に責任を持っています。
プロダクトバックログの見積もりは、チームが行います。
プロダクトバックログのアイテムはユーザーストーリー形式で書く必要はありませんが、ユーザーストーリー形式で書かれるケースが多いです 。
- ユーザーストーリー（
として が欲しい。なぜなら だから） - １つのアイテムにアクセプタンスクライテリア（受け入れ基準）を１つ以上定義する。
- １つのアイテムにやらないことも必要なら定義する。
WHO
WHAT
- どういった機能を明確に定義します。
- 曖昧な表現や言葉はNGです。
- 誰でも理解できるものでなければなりません。
WHY
- 価値を明確に定義します。
- 曖昧な表現や言葉はNGです。
- 誰でも理解できるものでなければなりません。
ユーザーストーリーを適切なサイズ（機能の最小の単位）にまとめるのは難しく、慣れが必要です。
ユーザーストーリがINVESTの条件を満たしているならそれは良いユーザーストーリです。
INVESTとはユーザーストーリーの条件を満たす略語です。
Independent（依存がない又は少ない） アイテムがそれぞれ独立していること。
- 依存関係（前後も含む）は排除。
- 依存度が高いと見積が難しい。
Negotiable（交渉可能）
Valuable（価値がある）
- ステークホルダーにとって価値がある。
- ビジネス（会社）にとって価値がある。
- チームにとって価値がある。
Estimable（見積可能）
- 見積可能。
- 見積できるぐらいの粒度。
Small（最小単位）
- 適切な大きさ。
- 十分に分割されている。
Testable（テスト可能）
- テスト可能。
- 受入テストを定義可能
ストーリーは、INVESTの条件を満たして、幾つかのストーリーを組み合わせると１つの機能になるようにする。
スプリントバックログ
スプリントで達成するプロダクトバックログのアイテムを決定後、チームは、それをインクリメントに実現する為の方法を決めます。
決めた方法を実際の作業（タスク）に細分化します。
チームはどのようにスプリントゴールを達成し、どのように期待されるインクリメントを作成するかをプロダクトオー ナーとスクラムマスターに説明できなければなりません。
スプリントが停滞するようなもは、スプリントバックログには入れません。
そのスプリントで達成しなければならないプロダクトバックログのアイテムの設計や検討などは、
スプリント開始前に明確なっている必要があります。
インペディメントリスト
プロジェクトでのポジティブ、ネガティブなことを記載するリスト。
但し、個人攻撃をするようなデリケートな問題は慎重に扱う必要があります。
スクラムマスターは、インペディメントリストの内容の内容及び、並び順に責任を持っています。
セレモニー
スプリントプランニング
- スプリントでなにを実現するかを明らかにする（チームとPOがそれをコミットしている状態）。
- 実現方法が明確になっている（設計が完了している）。
デイリースクラム
- チームが学習したこと共有する。
- 前回から今回までの間の内容を共有する。
- 今回から次回までに何を行うのかを共有する。
- スプリント内外の気になることを共有する。
スプリントレビュー
- スプリントで約束されたことが実現出来たか？
- プロダクトを実際操作しさらに良くできないかを議論する。
スプリントレトロスペクティブ
- 今回のスプリントはどうだったか？
- 次回のスプリントでチームが生産性を向上させる為の改善を１つ以上決める。
プロダクトリファイメント
- 追加や変更されたもの内容確認や見積もりなど。
- スプリントの中長期的な話。
- スプリントの5%～10%ぐらいのコスト。
その他
スプリント
スクラムの中心はスプリントである。
スプリントは、利用可能なリリース判断可能なプロ ダクトインクリメントを作るための、1 か月以下のタイムボックスがある。
スプリントは、開発作業を 行う連続した期間である。
スプリントが終了すると、新しいスプリントが開始される。
- スプリントゴールに悪影響を及ぼすような変更を加えない。
- 品質目標を下げない。
- 学習が進むにつれてスコープが明確化され、プロダクトオーナーと開発チームの交渉が必 要になる可能性がある。
スプリントストップ
スプリントが停止すること。
競合他社が同様のプロダクトを先にリリースして、優位性が確保できない場合や資金が尽きてしまった場合などがある。
プロダクト
スプリント終了後には、出荷可能な製品を必ず作ること。
但し、このルールを完璧に守れているチームは世界に存在しないらしい。
アクセプタンスクライテリア
プロダクトバックログに記載されているアイテムの1つに対して必ず1つ以上定義する。
チームに開発したプロダクトがユーザーやクライアントに受け入れてもらえるかを考える機会を与える為に存在する。
また、やってはいけないことを必要なら記載することもできる。
Done
プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の 意味を理解しておかなければいけない。
スクラムチームによってその意味は大きく異なるが、 作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。
これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。
スクラムチームのDoneの定義の例としては、下記の様なものがあると思います。
Doneの逆のUndoneというものがあります。
Doneは、毎スプリント完了しているものなので、例えば、初期の頃のスプリントでは、単体テストと結合テストしか完了できたいとしたら、
それ以外は、すべてUndoneとなります。
Undoneは、未完了の作業のことを指します。
Undoneが多いとスケジュールが遅延したり、想定しないリスクが増大します。
Undoneを通常のスプリントで解消できなくなる状況になってしまったら、
Undone作業のみを実施するためだけのリリーススプリントという特殊なスプリントを実施しなければならくなります。
このUndoneは、技術的負債と言われます。
Undoneを解消するとその項目は、Doneに入りますが、毎スプリントごとに最小のコストで解消できてないとDoneには入れられません。
このUndoneを戦略的にどうするかの責任は、プロダクトオーナーになります。
スクラムマスターは、プロダクトオーナーをサポートしながら、Undoneを減らせるようにチームに働きかける必要があります。
見積に関して
人間の特性
- 未来を予測する能力は低い
- 絶対値での見積をする能力は低い
未来を予測する能力は低い
- 未来になればなるほど予測する精度が落ち当たらない。
絶対値での見積をする能力は低い
- 床から天井まで何センチメートールですか？
- この紙は何平方メートルですか？
- 床から天井まで、このダウンボール箱何個分ですか？
- この紙は、あの紙の何倍ですか？
絶対値での見積より相対値での見積の方が誤差が少ない。
スクラムでの見積方法
見積は、未来になればなるほど見積精度が落ちます。
また、時間をかなり掛けても見積精度が100%になるようなことはありません。
逆に見積精度が落ちる場合もあります。
スクラムでの見積もり方法は２つあります。
- 相対見積
- 絶対見積
プロダクトバックログの見積方法
プロダクトバックログには、見積方法は、相対見積（ポイント）になります。
プロダクトバックログの１つ１つのアイテムにポイントを付けていきます。
ポイントは、そのアイテムの難易度などではなく、作業量によって決定されます。
プロダクトバックログは、３つのエリアを定義します。
- 詳細なエリア
- 荒いエリア
- その他のエリア
プロダクトバックログに設定した詳細なエリアと荒いエリアの２つエリアは、2:8法則で最大ポイントを設定します。
2:8の法則 ほとんどの現象は、2:8ぐらのばらつきがあります。 全体の２割が優れたものなら、残りの8割の状況で優れた効果が出るといったものです。
詳細なエリアは、スプリントで達成していくアイテムが入るエリアです。
荒いエリアは、詳細レベルまで落とし込めていないアイテムが入るエリアです。
その他のエリアは、見積できるレベルになっていないか？気にしないものが入るエリアです。
詳細なエリアの最大ポイントの設定と基準となるアイテムを決めます。
見積は、基準となるアイテムと比べて他のアイテムはどれぐらいか？で相対的に見積をします。
また、詳細なエリアが最大２ポイントの場合、荒いエリアは、その４倍の８ポイントが最大になります。
プロダクトバックログのアイテムの中で、その粒度を超えているものは、この時点で分割してどちらかのエリアに入れるか、
分割できない場合は、その他のエリアに入れるか判断します。
プロダクトバックログのアイテムの見積（ポイントを設定）の方法は、いろいろありますが、プランニングポーカーでやることが多いです。
プランニングポーカーは、あるアイテムのポイントを全員がカードを出し合いポイントを決定するやり方で、
出したポイントに差異があった場合、最大の人が理由を発表後、最小の人が差分を発表して、認識の違いを確認します。
最大と最小の人以外は、発言することはできません。
認識の違いを確認したら再度、全員がカードを出し合い、全員が一致するまで行います。
スプリントバックログの見積方法
直近のスプリントで達成しなければならないプロダクトバックログのアイテムに関して、
それを達成する為の作業内容を洗い出し、絶対見積で見積を行います。
直近の作業内容が詳細になればなるほど見積精度が良くなると言われているので、
スクラムマスターは、１つのタスクが0.5時間から1時間以内に収めることを目指します。
自律的なチームとは？
自律的なチームとは、下記の特性を持っています。
- 明確なゴールを持ち、ブレない方針を持っている。
- チームの方針について議論できる。
- チームに個人として結果をフィードバックできる。
- どの領域で自分が役立つか考え（バウンダリー）行動する。
- 一瞬（0.1秒）で現状を把握して、判断して行動する。
- チームがチームを管理する（スクラムマスターは管理者ではない）。
- 個人は、生産性を向上する為、自ら考え努力する。
チームがチームを管理しながら改善を行いチームとして成長して行きます。
また、個人としても成長します。
スクラムマスターは、そのような自律的なチーム２ヶ月で作り上げなければならない。
スクラムマスターは、自律的なチームを維持（守る）する必要があります。
自律的なチームを維持（守る）するということは？
- スクラムマスターは、なんらかの理由で、メンバーがいなくなったりしても安易にチームに人を追加しません。
- スクラムマスターは、誰かが新たしく入って来たとしてもその人を安易にチームに追加したりしません（プロジェクトは一緒でも自律的なチームとその人と分けて考える）。
スクラムチームに人を追加するということは、一度、スクラムチームが解散したことを意味します。
その場合、新しいスクラムチームになるので、自律的なチームが持つ特性を最初から構成しなおします（２ヶ月ぐらいかかる）。
- 明確なゴールを持ち、ブレない方針を持っている。
- チームの方針について議論できる。
- チームに個人として結果をフィードバックできる。
- どの領域で自分が役立つか考え（バウンダリー）行動する。
- 一瞬（0.1秒）で現状を把握して、判断して行動する。
- チームがチームを管理する（スクラムマスターは管理者ではない）。
- 個人は、生産性を向上する為、自ら考え努力する。
プロダクトオーナーやスクラムマスターは、そのコストを掛けてもチームに人を追加するか判断しなければなりません。
ベロシティに関して
スクラムチームは、ベロシティは測定します。
それは、スプリントで、スクラムチームがどれくらいの量の作業を行えるかわかるからです。
その情報があるとプロダクトオーナーは、そのプロダクトの見通しが立てられるし、
チームの状況を把握したり、どれだけのものを達成したか把握できるなどのメリットがあります。
スクラムマスターは、チームのベロシティが最大のところで、安定するようにしなければなりません。
チームのベロシティが最大値を基準に-2ポイントまでの範囲に収まっているなら安定していることを意味します。
また、チームメンバーがなんらかの都合で、数日いない場合でもチームは、ベロシティを下げないように考え行動しなければなりません。
スクラムマスターとチームは、ベロシティを最大のところで安定させる責任があります。
ベロシティで生産性を測れるのか？問題
ベロシティは生産性（パフォーマンス）を測る指標ではないということがSCM達の見解となっている。
また、いろいろなスクラムの書籍等にもベロシティの誤用やアンチパターンとして記述されています。
認定スクラムマスター研修でも生産性ではないとの認識。
- ベロシティは見積のサイズで、なんらかの単位があるわけではない。
- チームによりストーリーでつけるポイントの粒度が違う。
- チームにより粒度が違うポイントを元に他チームと比較しても意味がない。
もし生産性を測定する必要があるなら、多くのパラメーターを取る必要がある。
- ベロシティ
- タスクの状態（タスク別にToDo/Doing/Doneの数）
- Done率
- リードタイム（機能ができるまでの時間）
- リリース数（新機能とバグ対応のリリース数及び、その時間）
これ以外にも数値する必要なものがあるかもしれない。
