スクラム実践入門, 技術評論社
スクラムとは
複雑で変化の激しい問題に対応するためのフレームワーク
価値の高いプロうグラムを生産的かつ創造的に提供するためのもの
ソフトウェア開発の問題
ソフトウェア開発は複雑
要求が複雑だったり、現実が複雑だったりするので
スプリント
1週間から1ヶ月程度の期間
最初にスプリントプランニング
スプリントレビュー
スプリントでなにができたのか、何ができなかったのかを「検査」する
つまりWhat
その解決を検討する
スプリントレトロスペクティブ
開発プロセスに問題があったとしたらそれは何かを「検査」
いずれも「検査」と「適応(解決)」がある
つまりHow
スクラムでは何を作るべきか明らかになっていない
ちょこちょこ作っていって最終的なプロダクトを完成させる
内容によって工期を区切るのではなくて時間で区切る
役割
プロダクトオーナー
Whatについて責任を持つ
つまりプロダクトについて責任を持つ
スクラムマスター
Howについて責任を持つ
チームがスクラムの理論などを守るようにする
どうすれば開発が効率よく進むか
人間関係やコミュニケーション
課題達成指向と人間関係指向
この2つと「開発チーム」のあわせて3つのロール
プロダクトオーナー
システム実装の優先順位を交渉したりとかもこの人がやる
チームに一人
プロダクトオーナーとだけが外部とのやりとりをする
スクラムチーム外からの過度な介入を防ぐ
自己組織化のため?
自己組織化: スクラムチームがそれ一つで完結していて、そのチーム内だけで意思決定できたりすること
ゴールがブレる
要件の決定や優先順位の管理をする
開発チーム
3〜8人が良いとされる
デザイナとかインフラとか職種によって区別はしない
スクラムマスター
スクラムの勉強会を開いてチームへの指導なども行う
ステークホルダーの過度なチームへの介入を防ぐ
プロダクトオーナーとのファシリテート(会議を開いたりだとか)ちゃんとコミュニケーションがルール通り行われるようにする
スクラムイベント
スプリント
開発期間の1単位
1週間〜1ヶ月程度が良い
1週間 or 2週間を採用しているところが多い
僕は1週間、周りでも1週間か2週間を採用している
プロダクトや状況による
スプリントプランニング
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ
スプリントゼロ
開発が始まる前のこと
ビジネスモデルの仮設を建てる
プロダクトを作る理由とどうやって作るかを明らかにする
プロダクトを作る理由
目標
コミュニケーション手段(チャット、ビデオ会議)
予算とスケジュール
ざっくりしたアーキテクチャ
リスクと対策
チーム作りのワークショップ
初めて結成されたチームの場合
顔合わせ、相互理解
開発環境のじゅんび
リリーススプリント
スプリントプランニング(プルダクトオーナーと開発者のやりとり)
以下を決める
スプリントの期間で何をやるのか
どうやってやるのか
スプリントプランニングの前にリファインメント
バックログの整理
優先順位の整理など
バックログの見積もり
プランニングポーカー
ゴールを決定する
バックログの中から優先度の高い順に、期間内にできそうなものを選ぶ
ベロシティを測っておく
1期間にどれだけできるのか?というのを知る
ベロシティには以下の指標を使う
期間内に完了したバックログのアイテム数
期間内に管領したバックログのアイテムの見積もり値の合計
ベロシティを参考に「期間内にできそうなもの」を選ぶ
たぶん最初はカンになるだろうが
タスクの洗い出し
選択したバックログを実現するために何が必要なのかを洗い出す
タスクのサイズに制限を設けておくとわかりやすい
「1日以内に終わるタスクに分割」
タスクがでかいを何やっていいかわからんくなるので
慣れればこの限りではないと思う
スプリントゴールの同意
達成可能かどうかプロダクトオーナーと
デイリースクラム
デイリースクラムとは
1日15分の会
進捗や予定の共有や問題点が起こったら共有を行う
やること
スプリントの状況確認
スプリントゴールが達成できそうなのか確認
もし何か問題とかがあったら人を絞って、追加の「デイリースクラム二次会」を改めてやっても良い
スプリントレビュー
「何が達成できたか」を報告
動くソフトウェアのデモ
受け入れテスト
プロダクトオーナーから開発者へのフィードバック
今後のスプリントで何を開発していくかの議論
スプリントレトロスペクティブ
仕事のススメ方の見直し
KPTみたいな
スクラムで何を作るのか
プロダクトバックログ
プロダクトで実現したいこと
〇〇を実装したい。こういう人がいる。こういう理由のため。
何故プロダクトバックログを作るのか
全体像を明らかにする
必要な機能から順番に完成できる
限られた期間の中でできる機能を厳選する
プロダクトバックログの作り方
「何を作るのか」「誰のために作るのか」「何故作るのか」を明らかにする
見積もりを記載する
優先順位順に並べる。ちゃんと優先順位つけられてる?を確認
バックログの内容を見直す。バックログが多くなりすぎると優先順位をつけられなくなる
スプリントバックログ
このスプリントで何をするのか
進みの良し悪しを判断できる
インクリメント
スプリントでつくったもの
インクリメントを何故作るのか
進捗が明確になる
プロジェクト開始時に不明だったことの実現方法が明らかになる
現時点のプロダクトがリリース可能なものかどうかの判断ができる
インクリメントの作り方
常に動く状態を保つようにする
完成の定義を守る
こういうものが完成だというものを定義する
「プロダクトオーナーとともに動作を確認して、OKと判断されたもの」など
「ユニットテストが5分以内に終わること」
「ブラウザのレスポンスが1秒以内であること」
スクラムをさせるプラクティス
パターン(組織パターン)
スクラムにもいパターンがある、パターンを構成しようとしている
パターンのフォーマット
どういった状況で問題が発見されるのか
解決されるべき問題
問題が解決されないままになている要因や、場の空気
このパターンがどう解決してくれるのか
このパターンに則ってプラクティスを紹介していく
プラクティス
インセプションデッキ
10の質問への回答を通じて、プロダクトへの理解を深める
状況
新サービスの開発
チームは新サービスの概要はしっているが、その内容についてメンバーで議論したことはない
問題
プロダクトオーナーが想像するサービスが何なのかよくわからん
目的や実現方法が想像できん
空気
開発チームは成果物へのイメージなどを理解したいが、チームが結成されたばかりなので話し合いの機会が作れない
このままだと見当違いのものを作ってしまう可能性がある
解決
スプリントゼロで「インセプションデッキの10の課題」に対する答えを作成する
我々はなぜここにいるのか
プロダクトの作成に取り組む理由など
パッケージデザインを作る
これから作ろうとしているターゲットユーザーや競合を明らかにする
「やらないことリスト」を作る
「ご近所さん」を探せ
プロダクトをリリースするために何かしらの作業をお願いする可能性があるステークホルダー(チーム外の関係者)を洗い出す
第三者にお願いすることになりそうなバックログを見つけるのに使う
解決案を描く
夜も眠れなくなる問題はなんだろう?
期間を見極める
何を諦めるのかはっきりさせる
何がどれだけ必要なのか
リーンキャンパス
状況
比較的規模の大きいプロダクトを作っている
問題
このプロダクトの企画について、どの点に焦点を絞って考えていくべきか、最小限考えるべきことがよくわかっていない。
空気
企画について議論はしているが、アイデアが発散しており、チーム内で意見がまとまっていない。
解決
リーンキャンパスを埋めていくことで、プロダクトのビジョンを定義する
ソフトウェア開発の一番のリスクは、「誰も欲しがらないものを時間をかけて作ってしまう」こと。
いかに優れたソフトウェアだとしても顧客に受け入れられなければ意味がない
これを避けるために徹底的に顧客視点で考える必要があります。具体的には、
誰のどんな問題を解決するのか
顧客にどんな価値を提供できるのか
それをどのようにして顧客に届けるのか
それが顧客に届いているかどうかを確認する方法は?
など。
リーンキャンパスを埋めていくことで、自然にこれらの問いへの答えが出る
ユーザーストーリー
「<ユーザー>として<達成したいゴール>をしたい。なぜなら<理由>だからだ」というフォーマットで要求を記述する
プロダクトバックログを表現するのに使う
Who, What, Why
状況
期限や達成したいゴールが決まっているので、追加機能や修正内容を整理している
問題
プロダクトオーナーが追加機能の詳細について集中しすぎて、ユーザーの視点が抜け落ちてしまっていることがある
空気
プロダクトオーナーの作りたい機能が、必ずしもユーザーに必要とされているかわからない。
不要な空気が追加されないか開発チームが不安に思っている。
解決
「<ユーザー>として<達成したいゴール>をしたい。なぜなら<理由>だからだ」というフォーマットで実現したい機能を書く
ECサイトのユーザーとして、サイトにログインしたい。ログインしないと買い物ができないからだ。
ブログサービスの閲覧者として、ブログエントリにコメントしたい。ブログの持ち主とコミュニケーションを取りたいからだ。
サービスの管理者として、ユーザーの増加傾向を確認したい。なぜなら今後の機能開発の取捨選択に役立つからだ。
ユーザーストーリは、機能の細部を表現するだけの情報量は持たない
実際に開発をするにはユーザーストーリの情報だけでは足りない
良いユーザーストーリーを作るには
いかが満たされているとよいと言われているる
独立している
調整可能である
ビジネス価値がある
見積もり可能である
手頃なサイズである
テストが可能である
この本
スクラムはアジャイルの一種
アジャイルはとりあえずウォーターフォールではないもの、くらいの認識で
前提
僕はこの本以外のアジャイルやスクラム本は読んでません
紙の書籍で読みました
本当はアジャイルザムライを読もうかなと思っていましたが、会社の本棚にはみつからず、代わりにこれがみつかったので読んだ
技術評論社の本は見た目が読みやすいのが多いので僕は好き
よかった点
内容が平易でわかりやすい
とはいえ、スクラムの難しさは実践にあるわけで、スクラムのやり方自体は難しくないので、こんなもんなのかもしれません。
開発のヒントがいろいろ転がっている
平易でありながら様々なプラクティスが載っているので、スクラムを導入しなかったとしてもヒントになることが多い。
いくつか事例が載っていて、小規模開発から大規模開発まで載っている
図が適切な頻度で入っていて読みやすい
微妙だった点
本題に入るまで長い事がある
一番印象的だったのは「スクラムのプラクティス」のの部分
「このようなフォーマットでプラクティスを紹介していきます」の説明が長く、何を説明されているのかよくわからなくなる。
良い文章構成ではないな、と思うことがそこそこある
まとめ
スクラムを知らない人だったら十分おすすめできる本です
アジャイルザムライ(2011)より4年新しい(2015)なので、そこはアジャイルザムライより良い点かと思います