「リーン開発の現場」読書会
今回の第4回で最後まで読み切りました。KANBANという新しいアジャイル開発の形を現場で実践するための具体的な手引きであり、また、その背後にあるアジャイルの考え方を整理できる、良書でした。
第II部 テクニックを詳しく見る
第17章 アジャイルとリーンの概要
17.2 リーンの概要
- リーンの7つの原則
- 全体を最適化する
- いわずもがな
- 全体を最適化する
- ムダをなくす
- 顧客に価値を提供しないコト・モノはムダ
- 品質を作り込む
- 後から品質を高めるのではなく
- たゆまぬ学び
- フィードバック
- 早く提供する
- ムダの排除、品質の作り込みと関連する
- 全員を巻き込む
- 自律、熟達、目的
- 改善を続ける
- いわずもがな
17.3 スクラムの概要
17.4 XPの概要
17.5 カンバンの概要
- ワークフローの可視化
- WIPの制限
- サイクルタイムの管理
第18章 テスト自動化の戦略
- アジャイルであるためには、テストの自動化は欠かせない
18.1 テスト自動化の方法
- 少しずつテストカバレッジを上げていく
18.2 少しずつカバレッジを上げる
18.3 ステップ1：テストケースを一覧にまとめる
18.4 ステップ2：テストケースを分類する
- リグレッションテストとして残したいテスト
- 手動テストのコスト
- 自動化のコスト
18.5 ステップ3：優先順位をつけて並べ替える
18.6 ステップ4：少しずつテストを自動化する
- テストの自動化にかける工数を決める（顧客と合意する）
18.7 問題は解決するのか？
第19章 プランニングポーカーによる見積り
19.1 プランニングポーカーを使わない見積り
- 他人の意見に引きずられる
- 根拠を共有できない
19.2 プランニングポーカーを使った見積り
- 誰もが自分の判断を示せる
- 話し合いを持てる 根拠を共有できる
19.3 特別なカード
第20章 因果関係図
20.1 真の問題を解決する
- 多くの場合システムに問題がある
- 対症療法は解決にならない場合が多い
20.2 A3シンキング
- 問題の分析
- 対策と確認方法、長期的なフォロー
20.3 因果関係図の使い方
- 対策は実験であって、解決策ではない
- 実験後の追跡が重要
20.4 例1：リリースサイクルが長い
- なぜなぜ五回
- 根本原因
- 入ってくる矢印がない
- 問題を掘り下げる必要がない
- 対処可能
- 状況を改善する可能性がある
20.5 例2：本番環境に欠陥がリリースされた
- 根本原因は一つ以上の問題の原因になることが多い
20.6 例3：ペアプログラミングをしない理由
20.7 例4：たくさんの問題
20.8 実践課題：因果関係図の作り方
20.9 落とし穴に気をつけろ！
- すべてを描こうとしない。重要なものに絞る。完璧を求めない
- 問題領域が広すぎないか。問題を絞り込めないか
- 簡略化しすぎる
- ちょっとわからない
- 個人攻撃しない
20.10 なぜ因果関係図を使うのか
- 共通理解を形成する
- 問題を明確にする
- 根本原因を見つける
- 悪循環を取り除く
第21章 最後に伝えたいこと
- すべては実践のため
