認定スクラムマスター研修のメモ書き

認定スクラムマスター研究を受けてきたのでそのメモ書きです。

スクラムマスター研修記録

研修内容については、ページ上へ
それ以外の情報については、ページ下に記載しています。

初めに

この記録は、記憶のフックであり何が良いのか？
どうしたらいいのか？をまとめたものではありません。

1日目のノートのメモ書きより

アジャイル(Agile)とは　（スクラムを知るうえで...

アジャイルソフトウェア開発宣言

1. 顧客満足度を最優先
2. 要求の変更は開発後期でも歓迎し顧客の競争力を引き上げます
3. 動くソフトウェアを短い間隔でリリース
4. ビジネス側の人と開発者は一緒に働く
5. 意欲に満ちた人々を集め環境と支援を与え彼らを信頼する
6. 情報を伝える時は、フェイス・トゥ・フェイスで話をする
7. 動くソフトウェアこそが進捗の最も重要な尺度
8. 持続可能な開発を促進(一定のペースを維持する)
9. 技術的卓越性と優れた設計に対して不断の注意が機敏さを高める
10. シンプルさが本質　(無駄なく作れる量を最大限にすること)
11. 最良のアーキテクチャ要求、設計は自己組織的なチームから生み出される
12. チームがもっと効率を高めることができるかを定期的に振り返り　それに基づいて自分たちのやり方を調整する

上のような12のルールが宣言されています。
で、勘違いされやすいのが上の宣言を行うことがアジャイルでは無く
常に良い方向への変化を求め　変化した状態になった瞬間(状態)がアジャイルであると言えるということです。

アジャイルは「する」のではなく「なる」物です。

それに対してスクラムは「する事」です。ウォーターフォールも「する事」です。
そしてウォーターフォールだろうとスクラムだろうとより良い方向へ変化した瞬間はアジャイルになる瞬間はあるという事です。

*Don’t do agile, be agile *
アジャイル開発をするな、アジャイルであれ

要求と要件

要求は顧客が本当に求めている物
要件は要求をかなえるためにしなければいけない事
要求と要件の違いを理解するのは本当に難しい

ヒエラルキーの渇望

ヒエラルキーが全くない環境で合意形成を行うのは、本当に難しく
休憩時間をいつ、何分行うのかさえ決められないという状況へと陥りました。
※スクラムマスター研修という場においても全く決める事が出来なかった。

自律的なチーム

スクラムマスターは「自律的なチーム」作りをサポートします。
自律的なチームは以下の3つの要素を持ちます。
1. チームのゴール
2. チームのバウンダリー
3. 個人がゴールを実現するために判断、行動を起こしている

チームのゴール

明確なゴールを持ち、メンバー全員のゴールにブレが無い状態

チームのバウンダリー

メンバー同士が一定のルールに基づき行動し、
そのルール自体が正しいのかと反省し改善への行動を行っている状態

個人がゴールを実現するために判断、行動を起こしている

メンバー一人一人が現状を把握し、次の行動を0.1秒以内に決断できている状態

チームのメンバー構成

７±2人が最も優れたアウトプットを出す。という論文があります。

2日目、3日目のノートのメモ書きより

スクラムは現状把握の為のフレームワーク

スクラムは現状を把握する為のフレームワークです。
現状を把握すると問題点を見つけられるのでそこを直そうとすることでアジャイルの状態になる事ができるよう促せます。

なので、スクラムは生産性向上、人の成長、良い製品を保障するものではありません。

現状把握のための3つの要素

• Transparency(透明性)
• Inspect(検証)
• Adapt(適応)

現状の状態に透明性があり検証する事ができ、より良い方向への変化の適応がなされている
この3つがスクラムには必ず必要

現状把握を担保するための16のルール

Transparency,Inspect,Adapt　この3つを担保するために16個のルールがあり
4つのカテゴリに分けられます。

• Time(2)
  • Sprint
  • Sprint Stop
• Ceremony(5)
  • Sprint Planning
  • Daily Scrum
  • Product Backlog Refinement
  • Sprint Review
  • Sprint Retrospective
• Role(3)
  • Product Owner
  • Scrum Master
  • Team
• Artifact(6)
  • Product Backlog
  • Sprint Backlog
  • Definition of Done
  • Acceptance Criteria
  • Potentially Shippable Increment
  • Impediment List

ここではRole Ceremony Airtifact Timeの順番でメモを記載しています。

Role 役割

Product Owner(PO)

役割
チームのReturn on Investment(ROI:かけたコストに対しての得られる対価)を最大化させる役割

責任
ROIを最大化させる事に責任を持ちます。

質問に対して0.1秒以内にROIを最大化させる為の決断が出来なければなりません。
何が出来ているのか聞かれたらすぐ答えられなければいけません。

持つスキル
決断するための情報を集めるスキル

管理する物
Product Backlog(PBL:要件リスト)とAccept Criteria(AC:受け入れ条件)を管理します。

Scrum Master(SM)

役割
スクラムの状態に導く役割
スクラムを理解しスクラムが合わないと判断しなたらスクラム以外の方法に進められなければなりません。

責任
良い点を作り出す事に責任を持ちます。

持つスキル
SMは5つのスキルを持ち　伸ばしていかなければならない

• ティーチング(良い方向を教え)
• ファシリテーリング(円滑に進むよう導き)
• メンタリング(時にケアし)
• コーチング(立ち止まった足を1歩前へ進ませるための助言を与える)
• シチュエーショナリング(その為に現状を把握する)

管理する物
Impediment List(IPL:障害リスト)を管理します。

Team

役割
スプリントで約束(マニフェスト)した事を実現するための役割

責任
出荷可能な製品を作ることに責任を持ちます。
スプリントでしたマニフェストを達成しなければなりません。

持つスキル
断る力を持ち出来ないものは出来ないと断らなければいけません。
実現する力（開発力）を持ちます。

管理する物
Sprint Backlog(SBL:スプリント内で行うと約束したタスク), Definition Of Done(Doneの定義:終了条件)を管理します。

Ceremony 儀式

Sprint Planning

目的
Product Owner(PO)が要求を説明し、TeamがProduct Backlog(PBL:要件リスト)を作りProduct Owner(PO)と共有する事を目的としています。

Product Backlog(PBL)は、工程が書かれる事はありません。
設計は出来ておりこなすだけの状態になってなければいけません。

情報や技術が足りず設計できないならばリスクがあることをProduct Ownerと共有したうえでTeamが調査、研究する事をProduct Backlogに追加しProduct Ownerは
ROIを最大化するためにそのProduct Backlog Item(PBI:プロダクトバックログにある1要件)をやる事を決断し　優先順位をつけなければいけません。

留意点
Product Backlog Item(PBI)はSprint Backlog(SBL:1スプリントで行うタスクリスト)に入らなければ分割しなければならず1PBIは、スプリントの期間が1週間なら1～2h 2週間なら2～4hの作業時間になるのが望ましい。
また、Minimum Marketable Feature(MMF:市場性のある最小限の未来、製品価値のある物)になってなければならない。

Product OwnerがProduct BacklogをTeamと共有する際はProduct Backlogの全Itemに対してROIを最大化させる為の優先順位がついてなければいけません。

Product Backlog Item(PBI)はAcceptance Criteria(AC:受け入れ条件)とDefinition Of Done(Doneの定義)の両方が達成できた時　初めてステータスを完了とすることが出来ます。

やってはいけない事
PBIの優先順位をTeamが勝手に変えてはならない。
もし変更しなければいけないとTeamが判断したならばProduct Ownerに決断してもらい変更してもらわなければいけません。

要件がおおきいProduct Backlog Item(PBI)の分割の仕方

データベース構築。作業量2Weekといった感じの大きなProduct Backlog Item(PBI)を作ってしまいがちですが、
サーバー用意2h、OSインストール2h、ツールインストール2h ... っといった感じで分割していけば分割できます。
PBIの中で依存関係が出来ていればいいだけです。

時間
Product OwnerとTeamで共有されたProduct Backlogが出来る迄

Daily Scrum

目的

学習の共有を行う事を目的としています。

留意点

共有を行う上で　Sprintのスケジュールの状況や障害、問題、メンバーの状態(欠席とか)、モチベーションの状態　を確認しあい

現状のままで行くのか決断し
問題があるなら解決の為に　別のチームに相談しにいく Product OwnerとSprint Backlog Itemについて相談しにいくといった行動を起こす決断します。

やってはいけない事
議論をする事とアクションを起こさない事(変化が全く起きたない事)

議論をするという決断をするのは問題ありません。

時間
Teamメンバーが何人いようと15分

Product Backlog Refinement

目的

プロダクトバックログを確認し、中長期の計画を立てるのを目的としています。

留意点

プロジェクトの開始から終了迄の間に１度は行ってください。
Product Backlog Refinement内で何があろうとも影響を与えるのは次のSprintからです。
プロジェクト末期にはやらないでください。中長期の計画を立てるのが目的ですので
終了が見えたタイミングでやっても無駄です。

ステークホルダー以外のだれが出てもかまいません。

''やってはいけない事''
だらだらやってはいけない

時間
プロジェクト全体の5～10%の時間

SprintReview

目的

Sprintをレビューし要求に対してより良いアウトプットを行う方法を出すのが目的です。

留意点

Sprint Backlog ItemがどれだけAccept CriteriaとDefinition Of Doneをクリアしたかを確認してください。
マーケットとの唯一の接続点であることを認識してください。

やってはいけない事

時間
１～２時間

Sprint Retrospective

目的

Sprintを振り返るのが目的

留意点

1 SprintはSprint Retrospectiveにより終了します。
生産性を向上させる為の障害を見つけProduct Backlogに追加します。

Product Owner(PO)は追加されたProduct Backlog Item(PBI)を確認し
Teamのreturn on investment(ROI)を最大化させる為にProduct Backlog Item(PBI)のいつやるか決断し優先順位を変更しなければいけません。

Retrospective時に調査しないと先に進めないといった　スプリントできないような事柄が出てきた場合、その調査することをSpikeと呼びます。

やってはいけない事
生産性を向上させるアイデアを出さない　という事をやってはいけません

時間
１～２時間

Sprintの一連の流れ

Artifact

Product Backlog

指すもの
Product Owner(PO)が挙げた要求を要件に落とし込み
Product Owner(PO)がTeamのReturn on Investment(ROI)を最大化するために
要件毎の優先順位を明確にし、達成するための戦略を明らかにするための物を指します。

Product Backlog(PBL)はProduct Backlog Item(PBI)で構成されます。

Product Backlog Item(PBI)の鉄則
・SprintBacklogに入る大きさになっていなければいけません。
※ベストはSprint期間が1週間なら1～2時間 2週間なら2～4時間で終わる大きさ
・相対見積もりがされていなければいけません。
※相対見積もりが必要な理由は別途記載します。

Product Backlog Item(PBI)の達成条件
Product Backlog Item(PBI)はProduct Owner(PO)が定めたAcceptance Criteria(AC:受け入れ条件）をクリアし
Teamが定めたDefinition Of Done(Doneの定義:全てのPBIで共通の終了条件)をクリアした時初めてステータスが達成(完了)となります。
特定のPBIのみに適用されるDefinition Of DoneはUndoneと言われます。
※Undoneについては別途記載します。

Sprint Backlog

指すもの
Product Backlog(PBL)からProduct Backlog Item(PBI)を取り出し
Sprint終了時に出荷可能な機能をTeamが公約(マニフェスト)したタスクの一覧を指します。

Sprint Backlog(SBL)はSprint Backlog Item(SBI)で構成されます。

Sprint Backlog Item(SBI)の鉄則
・絶対見積もりがされていなければいけません。
※絶対見積もりが必要な理由は別途記載します。

Sprint Backlog Item(SBI)の達成条件
Sprint Backlog Item(SBI)はProduct Backlog Item(PBI)をSprint内にもってきた名前なので
達成条件はProduct Backlog Item(PBI)で定められた条件となります。

達成時にはProduct Backlog Item(PBI)となりステータスが達成(完了)に変更されます。
未達成時にもProduct Backlog Item(PBI)となりProduct Owner(PO)がTeamのROIを最大化させる為に再度優先順位を設定します。

Definition of Done

指すもの
Teamが定めた全てのProduct Backlog Item(PBI)に共通の終了条件を指します。

Definition of Done(Doneの定義)の鉄則
・特定のProduct Backlog Item(PBI)にのみ適用される終了条件はDefinition of DoneにはならずUndoneとなります。
・UndoneはProduct Backlog Item(PBI)をDoneするためにやらなければいけない作業なので
Product Backlog Item(PBI)としてProduct Backlog(PBL)に追加されProduct Owner(PO)がTeamのROIを最大化させるために優先順位を設定します。

Undoneの注意点
Undoneは借金で利息があることを理解しなくてはいけません。
Project初期にあったUndoneはSprintが進むにつれ積み重なれ最終的には無視できない負債となり
リリース前に炎上しながら修正する事になります。

Acceptance Criteria

指すもの
Product Owner(PO)が定めた受け入れ条件を指します。

Acceptance Criteria(AC)の鉄則
Acceptance Criteria(AC)はProduct Owner(PO)が管理しProduct Backlog Item(PBI)が
ステータスを完了にするためにはAcceptance Criteria(AC)を達成していなければいけません。

Acceptance Criteria(AC)の注意点
Acceptance Criteria(AC)は言語化されていなければいけなく
たとえば「面白く」とか「楽しげに」とか抽象的な言葉ではなく
ジャンプ挙動でいえば○○以上飛び上がり○○の速度で降下し着地する。
といったように厳密に規定されメンバー毎の品質に依存しない形の条件を定める必要があります。

Potentially Shippable Increment

指すもの
市場価値の価値のある製品をリリースする事を指します。

Impediment List

指すもの
Teamに対してのあらゆる障害がリスト化されたものを指します。

Impediment Listの鉄則
Impediment ListはScrum Master(SM)が管理しScrum Master(SM)は障害を取り除く事に努めます。

Time

Sprint

タイムボックス、規定の区間　1～2 Week

Sprint Stop

Sprintそのものを止める事

各種補足

ここでは研修で行った　○○を理解するためのエクササイズの内容を記載します。

相対見積もりと絶対見積もり ビルの長さを図る

Product Backlog(PBL)とSprint Backlog(SBL)の中でPBLは相対見積もり、SBLは絶対見積もりで見積もりを行う。
と記載したと思います。これは人が何かを見積もる際　絶対見積もりよりも相対見積もりの方が精度が高くなる特性を利用したものです。

この特性を体感するためにビルの長さ比べを絶対見積もりと相対見積もりで行いました。

30人でそれぞれの見積もりを比べてみると、相対見積もりの方が誤差が少なくなります。
これが人の特性で、時間や距離が離れれば離れるほど相対の方が見積もり誤差が少なくなります。
ですので直近の作業であるSprint Backlog Item(SBI)は絶対見積もり
時間が離れた作業であるProduct Backlog Item(PBI)は相対見積もり
で行ったほうが見積もり誤差が少なくなります。

※参考素材は素材goodさんより借りました

その他の情報

講師について

江端　一将さん

著書
スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発

アジャイルなゲーム開発　スクラムによる柔軟なプロジェクト管理

期間について

2016年2月18日～2016年2月20日
東京秋葉原CIVIセンター

費用について

約35万程かかりました。
内訳は下になります。

項目	費用
研修費	30万2400円
宿泊費	1万8900円
交通費	1500円
食事費	約2万
事前学習資料費	約1万

基本的な研修費用は30万(税抜) ペアで申し込むと2万円割引されます。
税を入れると28万*1.08となり30万2400円となります。

3日間の宿泊費(9時開始なので前日から宿泊しました)
秋葉原　FastCabin 3泊分で18900円

食事費が異様に高いのは毎日飲みに行っていた為

スクラムマスター研修受けてみたいなぁっという方は35万ぐらい用意すれば十分だと思います。