fuji70さんの感想・レビュー

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

著者 : 貝瀬岳志 原田勝信 和島史典 栗林健太郎 柴田博志 家永英治

• 技術評論社 (2015年3月18日発売)

スクラムを実践するときの経験談が一通り入っていて参考になる。

[more]

- スクラム
- アジャイル開発手法のひとつ。
- 「理解は容易だが習得は困難」と言われる。解決策そのものではなく手助けだから。

- 構成
- 1-4章 スクラムの背景・基本ルール
- 5章 汎用的プラクティス
- 6-8章 事例：GMOパペポ、mixi,DeNA
- 9-12章 問題と解決策

## 1-4章 スクラムの背景・基本ルール
### ソフトウェア開発の困難
- ソフトウェアの不可視性。
- 問題の分解・整理： 5W1H (Who,What,When,Where,Why,How)
- スクラムの定義： 複雑で変化の激しい問題に対応するフレームワーク
- ラグビーのスクラムに由来
- 野中・竹内の論文1986に由来
- 野中・竹内の論文1986 The New New Product Development Game
- 新製品開発の手法は２種： リレー競争型、ラグビー型
- スクラム
- 問題に経験主義で対処する
- スプリント：一定期間で区切って反復
- リーダーシップは２種： プロダクトオーナー（What）、スクラムマスター（How）
- まとめ

| | 意味 | 性質 | 領域 | 検査 | 役割 | リーダーシップ特性 |
|----|---------|-----------|---------|----------------------|----------|--------------------|
|What|何を |複雑 |プロダクト|スプリントレビュー |プロダクトオーナー|課題達成志向|
|How |どうやって|変化が激しい |プロセス |スプリントレトロスペクティブ|スクラムマスター |人間関係志向|

### スクラムチーム
- 自己組織化 Self-organization
- 外からの指示ではなく自分たちで最善策を選択する。
- 自分たちで能動的に学習と成長をし続ける
- ３つのロール
- プロダクトオーナー ： プロダクトの責任者。優先順位付け。チームに一人。本来チームから独立。
- 開発チーム ： ３〜８人が望ましい。職書の違いによっては区別されない。サブグループなし。
- スクラムマスター： サーバントリーダー。チームに一人。
- ステークホルダー ： チームには属さないが影響を及ぼす関係者

### スクラムイベント
- ５つのイベント

1. スプリント
- 開発期間の1単位。XPならイテレーションと呼ぶ。
- 1週間から1ヶ月。 Webサービス系だと1or2週間が多い。
- 一度決めたら延長しない。
- 理想的にはスプリント毎にリリースできるように。
2. スプリントプランニング
- スプリント開始時のMTG。何ができるか、どうやって達成するか。
- タイムボックスは、1週間スプリントでも1-2時間。Max8時間。
- リファインメント（グルーミング）： バックログの整理
- ベロシティ： チームがスプリントで達成できる仕事量。
3. デイリースクラム
- 1日1回15分のMTG。朝会、スタンドアップMTG。
- 昨日したこと、今日やること、困っていることを話す。
- 15分で終わらなければ関係者を絞って二次会
4. スプリントレビュー
- プロダクトインクリメントの確認とフィードバックを得るMTG
- 動くデモ。
5. スプリントレトロスペクティヴ
- 振り返りMTG。1時間程度。
- KPT（ケプト） Keep Problem Try

- スプリント・ゼロ
- 開発の前段階
- ビジネスモデルの仮説。リーンキャンバス。
- プロダクトを作る理由と実現方法
- インセプションデッキ。プロジェクト憲章。
- チーム作りのワークショップ。マシュマロチャレンジ。
- 開発環境の準備。Git,CI,Chat,など
- プロダクトバックログ
- リリーススプリント
- リリース前の仕上げスプリント

### スクラムの作成物
3つの作成物
1. プロダクトバックログ
- プロダクトで実現したいことを優先順位付けしたリスト
- ユーザストーリーで表現すると簡潔。 Who, What, Why
2. スプリントバックログ
- スプリント期間内で行うと判断したプロダクトバックログアイテムとタスク
- タスクボードで可視化。
- ToDo（未着手）、Doing、Done
3. インクリメント
- リリース可能なプロダクト

## 5章 汎用的プラクティス
- インセプションデッキ： 10の課題への回答を通じて、プロダクトへの共通理解を得るプラクティス
- 我々はなぜここにいるのか？ ：プロダクトの作成に取り組む理由を明らかに
- エレベータピッチを作る ： ターゲットユーザや競合を明らかに
- パッケージデザインを作る
- やらないことリストを作る
- 「ご近所さん」を探せ ： ステークホルダーの中から依頼しそうな人物を洗い出す
- 解決案を描く
- 夜も眠れなくなるような問題は何だろう？
- 期間を見極める
- 何を諦めるのかをはっきりさせる
- 何がどれだけ必要なのか
- リーンキャンバス
- ユーザストーリー
- 良いユーザストーリーには、INVEST を満たす
- Independent :独立している
- Nogotiable ：調整可能である
- Valuable ：ビジネス価値がある
- Estimable ：見積もり可能である
- Small ：手頃なサイズ
- Testable ：テスト可能
- ユーザストーリーマッピング
- ユーザストーリーを「時系列にそったユーザ行動」「実装の優先順位」の２軸で整理
- プランニングポーカー
- 見積もりを行うプラクティス
- フィボナッチ数列のカードを用いる。 0,1,2,3,5,8,13,...
- 全員が詳細までイメージできるバックログアイテムに「2」を割り当てる。※ 絶対値の正規化
- アイテム毎にカードを出す。一致ならOK
- 不一致なら、最大値と最小値の人が見解を述べる。
- ３回繰り返してもまとまらなかったら、平均値 or 最大値を採用する。
- スパイク
- 見積もりできない項目の事前調査をスパイクと呼ぶ。
- 数日間を上限に調査を行い、その後にバックログ更新や新計画へ
- KPT
- レトロスペクティブの方法の一つ
- Keep 良かったこと。続けたいこと
- Problem 困ったこと。改善したいこと
- Try より延ばす案や改善案。

## 6-8章 事例：GMOパペポ、mixi,DeNA
### GMOパペポ
- 作業の属人化を防ぎたい
### mixi
- 作業の属人化を防ぎたい
### DeNA
- 優先順位を決めたい。
- 大規模スクラム開発へ。
- スクラムマスターは専任化（複数のチームをみる）

## 9-12章 問題と解決策
- 適切な優先順位を付けるには
- ポイントを絞る。AとBのどちらを先に終わらせるか？
- 投資対効果で決める（ROI）
- サポートチームをつける。優先順位付けの材料集めのサポート
- スクラムマスターがスクラムの奴隷化
- 次の発言が増えたら注意。
- 「○○はスクラムではないのでダメだ」
- 「スクラム的には○○であるべきだ」
- 目的の整理フレームワーク GR(R)OW モデル
- G Goal 目標 目指したいゴールは？
- R Reallity 現状 ゴールと現状とのギャップ
- R Resources 資源 手を貸してくれる人や情報源は
- O Options 選択肢 とれる打ち手は
- W Will 意思 すぐにやった方が良さそうか
- ロールの兼任による問題
- スクラムマスターとプロダクトオーナーは兼任するな
- スクラムマスターと開発チームの兼任するな
- スクラムマスターのリソース活用なら複数チームのマスター兼任
- 1-3チームの兼任
- こなせる作業量を見積もれない
- ベロシティを測定する
- １日5-6時間使えるとして見積もるチームが多い。

eof

感想投稿日 : 2018年10月20日

読了日 : 2015年12月27日

本棚登録日 : 2018年10月20日