スクラムはじめようって何からはじめればいいの？

スクラムやりたい！
いきなりスプリント開始～！
なんてうまくいくはずがありません。
走りながらにも限界があると思いますし、途中で疲れちゃいます。
スクラムは、実は事前の準備が本当に大切です。スクラムガイドなどには謳われていませんが…。

ここでは、今までスクラムを導入したことが無い組織でスクラムを導入するための道標を記載してみました。
真っ白な状態からスクラムをやりたいのであれば、一番最初にスクラム・マスターが必要だと思います。スクラム・マスターが、「スクラムやろうぜ」の発起人になっていないとうまく回らない可能性が高いです。チームとプロダクト・オーナーをうまく導けないからです。

今までスクラムを導入したことが無い組織の場合、スプリントの開始までに、２～３週間ぐらい必要です。
ここで述べるのはあくまで私個人の経験・学習の結果からくるものですので、すべてマストではありません。
スプリントを始めてしまって、１スプリント目で様々な整合を取りつつ行う手法もあるとは思います。（大変だと思いますが…）

以下、おおまかなTODOリストになります。

プロダクト・オーナーとスクラムマスターを決める
マネージャー（経営層）を味方につけ、共有する。
チームメンバーを集め、スクラムの説明をする。チームがやりたがらない場合は、ここで終了。
ステークホルダーを味方につけ、共有する。
プロダクト・バックログ作成
ぼんやりとでもアーキテクチャを決める(後から変更可能）
リリースプランニングとリリース計画作成と共有
想定される成果物を洗い出し、必要かどうかを確認する
チームは、完了の定義(Done of Definition)を検討し、プロダクト・オーナーと合意を取る。
スプリント計画作成（時間と場所の確保、集計方法検討）
スプリントの開始！

プロダクト・オーナーとスクラムマスターを決める

特にスクラムマスターはプロダクト・オーナーにスクラムとはこうゆうもんだと説明し、納得頂く。
プロダクト・オーナーがすでにスクラムに詳しい場合は割愛可能。
アンチパターンとしては、同一人物が兼任してしまうパターン。うまくいかないと思います。
そんなに甘くないです。スクラムマスターもやることは山積みです。

マネージャー（経営層）を味方につけ、共有する。

味方にできるかどうかは、マネージャーの性格や、組織文化にも依存しますので、非常に難しいとは思いますが、経営層の誰かを味方につけたほうがいいです。
理由は、優秀なチームメンバーや物資リソースを集めやすくなるからです。
ホワイトボードや付箋の調達や、どの壁を使っていいかなども相談する必要が出てきます。
また、困ったときに相談できる偉い人がいると非常に安心です。
Fearless Changeの経営層の支持者パターン(28)ですね。

Fearless Change アジャイルに効くアイデアを組織に広めるための48のパターン

作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
出版社/メーカー: 丸善出版
発売日: 2014/01/30
メディア: 単行本（ソフトカバー）
この商品を含むブログ (16件) を見る

チームメンバーを集め、スクラムの説明をする。チームがやりたがらない場合は、ここで終了。

マネージャーを味方につけたら、こんなメンバーが欲しいと相談します。
チームメンバーの素養としては、

選択肢を与える力（代替案の提案）
実現力
ちょっとした社交性

が必要かと思います。上２つは認定スクラムマスター研修で習いました。
スプリントレビュー等ではチームがプロダクト・オーナー含めステークホルダーにインクリメントを説明しますので、少し話せる人が必要かと考えています。

説明をした結果、チームがやりたがらない場合は、ここで終了です。
無理強いはよくないと考えます。結局うまくいかないです。
チームをやる気にできるかどうかはスクラムマスターにかかっています。

ステークホルダーを味方につけ、共有する。

これも非常に大切です。特にプロダクト・バックログ作成とスプリント毎のスプリント・レビューには出席して頂いたほうが価値のあるものが出来上がりやすいです。
海外ではどうか知りませんが、プロダクト・オーナーが全て一人で何でも決められるっていうのは日本だと考えづらいです。特に企業が大きくなればなるほどその傾向は強いと考えます。
プロダクト・オーナーに全責任を背負わせてしまい、病んでしまう可能性もあるので…。
もちろん、最終決定権はプロダクト・オーナーにありますが、プロダクト・オーナー自身が間違っていることに気づくためには、ステークホルダーの意見も大切だと思います。
なので、プロダクト・バックログ作成とスプリント毎のスプリント・レビューにはステークホルダーに出てもらって、ちょっとした議論も入り交えつつ
本当の「セレモニー」という形で華々しくやっていくと良いと思います。特別感を出しましょう。

また、ここで大切なのが、ステークホルダーにスクラムの価値をわかっていただくことです。
計画はあくまで計画です、とか、やるべきことはどんどん変化します、ということは腹を割って話したほうがいいと思います。

プロダクト・バックログ作成

プロダクト・バックログを作成します。
ペルソナを決めて、ユーザーストーリー・マッピング手法を使うと、ストーリーの全体像が見えます。

qiita.com

なるべく、ステークホルダーにも参加してもらいます。もちろん、チームとプロダクト・オーナーも一緒にやるのが良いです。
丸１～２日缶詰になれる場所で、大きな壁に向かってストーリーを貼っていきます。

ユーザーストーリーマッピングも非常に効果的ですが、巨大なストーリーの場合は、スクラム現場ガイドの２９章「巨大なバックログの見積もりと優先順位付け」に参考になる手法が書かれています。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
出版社/メーカー: マイナビ出版
発売日: 2016/02/27
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

ストーリーのサイズと優先順位を４象限マトリクスにしてプロダクト・バックログを作成します。

f:id:kshimizu1226:20160505162553p:plain

プロダクト・オーナーは、受け入れ条件を作成し、チームと共有する。

プロダクト・バックログを作成したら、プロダクト・オーナーは、各ストーリーもしくはストーリーの束において、受け入れ条件を作成します。
ただ、この段階で詳細まで書いてしまうとあとからストーリーが変わったりすると意味がなくなるので、
優先順位が高く、ストーリーが小さいもの（近いスプリントで行うもの）の受け入れ条件を作成したほうが良いと思います。

ぼんやりとでもアーキテクチャを決める(後から変更可能）

この段階で優先順位が高く、細かいストーリーが揃っているはずです。
全体像から、ソフトウェアのアーキテクチャをチームと一緒にぼんやりと決めておいたほうがいいです。
もちろん後から変更可能ではありますが、スプリントが開始した時点でアーキテクチャどうしよう？となると
スプリントプランニング時に正確なタスク分割もできないので、スプリント内で動くものが出来る確率は非常に低くなります。
データベースが必要なのか、WEBなのか、ネイティブアプリなのか、ネイティブの場合はOSはMacなのかWindowsなのか…など。

リリースプランニングとリリース計画作成と共有

プロダクト・バックログが出来上がると現時点での総ストーリーポイントがわかります。
総ストーリーポイントと、１スプリントでどれくらいのベロシティが出せるかを仮定で良いのでチームと話してみましょう。
最低のベロシティと最大のベロシティが出ると、全部でどれくらいのスプリント回数が必要か、どのストーリーがいつごろ出来上がるかというリリース計画が立てられます。
（あくまで変わるという前提付きですが）
リリース計画に関しては以下に書きました。

kshimizu.hatenadiary.jp

想定される成果物を洗い出し、必要かどうかを確認する

組織の文化や、法規制等によって、必要な成果物があらかじめ決められているケースもあります。
その場合には、単に「動くソフトウェア(Potentially Shippable Product Increment )」以外にも成果物が必要な場合があります。
その辺りを洗い出しておいて、スプリントプランニング時にチームにインプットします。プランニングのタスクの一つになるので、ここで抜け漏れは結構厳しいです。厳密に行きましょう。（チームにどやされる（汗

チームは、完了の定義(Done of Definition)を検討し、プロダクト・オーナーと合意を取る。

成果物と似ていますが、スプリントプランニングで洗い出されるタスクの完了の定義を、プロダクト・オーナーと合意を取ります。
例えば、Unit Testの作成は必須、コードレビューは必ず行う、
定量的にいうと、コードカバレッジが80%以上とか、Unit Test Failが0件であるとか、テストケースが何件以上あるとか、
各ストーリーのユーザマニュアルの作成が完了しているとか、（必要であれば）設計書を記載している、そのレビューが終わっている、など各タスクやスプリントの完了の定義をプロダクト・オーナーと合意を取ります。
完了の定義はプロダクト・オーナーとの合意が必須です。

スプリント計画作成（場所と時間等、バーンダウン集計をどうするか。Excelのテンプレート探し）

スプリントを1～4週間どの単位で行うのかをチームと議論をして決めます。議論した結果プロダクト・オーナーとも合意します。
また、各セレモニーをいつどこで行うかを決めます。
例えば、2週間1スプリントであれば、以下の様なチャートを作るといいと思います。
f:id:kshimizu1226:20160505162550p:plain
スプリントプランニングは丸１日かけますが、１日で終わらないことも多々あります。予備枠を設けておくと安心です。

バーンダウンチャートはスクラムの必須要素ではありませんが、チームの進捗を見る上では便利なツールです。
作り方等は予め考えていたほうが良いと思います。
バーンダウンやチケットはいきなり電子化しないことをお薦めします。
スプリントの振り返りでチームメンバーから電子化が必要だと出てくるまで待ったほうがいいと思います。
世界のスクラムマスターたちのディスカッションをまとめてくれたサイトがありました。
JIRAやTFSが優勢ですが、チームが必要だと思ったら、チームが導入するというスタンスで。