scrum 関連の本からの抜書きメモ
2016年頃
- アジャイル開発とスクラム
- SCRUM BOOT CAMP THE BOOK
- カンバン ソフトウェア開発と変革
- TODO アジャイルな見積と計画づくり
- 非常に薄い「マネジメントの枠組み」
- チーム全体が協働するためのコミュニケーションのルールの取り決め
ウォーターフォールでは仕事を渡す側と受ける側の間に敵対関係を生み出す傾向がある。
- 「仕様に書かれていないことをやってほしいというのです」
- 「簡単に気を変えないで欲しい」
- 「自分にコントロール出来ないことに対して、私は責任を負えません」
のように、仕事が楽しくなく、モチベーションをそぐ原因になる。
- 15分ミーティング
- product backlog (backlog=在庫、仕事などの未処理分、残務)
- sprint backlog: 上のリストから抜き出された1回のスプリント分の機能リスト
- sprint (1〜2週間): 割り込みや中断開く、必ず終了するタイムボックス
- increment: スプリントの終了で、出来上がった機能をデモする
-
product owner: (*1の位置No.430) (*2の位置No.254)
- 個人。製品の機能の定義と優先順位付け。
- プロダクトの結果責任を取る
- 開発チームに相談できるが、干渉はできない
- プロダクトのビジョンを明らかにし、周りと共有する
- backlog の内容を最新の状態にする
- backlog の内容を関係者が理解できるように説明する
- 予算を管理する
-
開発チーム (*1の位置No.438) (*2の位置No.268)
- プロダクトを作る
- 要求分析、設計、コーディング、サーバ構築、テストなど全部できる機能横断的なチーム
- 年齢や役職などによる上下関係はない
- 自己組織化されたチーム
-
scrum master (*1の位置No.438) (*2の位置No.384)
- チーム全体が自律的に協働できるように、場作りをする facilitator, 進行役、世話役
- チームメンバーの相談に乗ったり、問題を取り除いたりするコーチ
- 開発チームを外部の割り込みから守る
- チームの障害を取り除くために外部との交渉を行う
- バックログの良い管理方法を探す
- オーナーやチームにアジャイル開発や scrum について説明
- 製品のビジョンづくりやバックログ管理について、プロダクトオーナーを支援する
- わかりやすいバックログの書き方をオーナーや開発チームに教える
- マネジメントをするが、指揮命令するのではなく、チームを支援する奉仕型のリーダ
- 開発のやり方に関する決定はスクラムマスターではなく、開発チームが行う
- 自分たちで決めながら動く自立したチームを作ることが、生産性を上げる鍵
-
順位付けされた機能のリスト
-
顧客の言葉で書かれているユーザーストーリ
- (Who) ユーザの役割 として、
- (What) 機能 がほしい。
- (Why) なぜなら、 機能の価値や目的 だからだ。
- 例: 図書館のユーザとして、蔵書検索機能がほしい。なぜなら、借りたい本があるか知りたいから。
-
その他の記述: 制約や条件、 UI の絵、受け入れの基準、デモ手順(受け入れテスト手順)など
-
ユーザの役割りが書かれているので、使う文脈を想定でき、 UI を考えたりできる。
-
価値や目的が書かれていることによって、書かれている機能よりスマートで低コストな機能を思いつけるかもしれない。
-
実現したいことの意図を明らかにする
-
単なる思いつきのような漠然とした物も書かれていたほうが良い。プロジェクトの方向を微調整しやすくするため (*2 No.2065)
-
状況の変化を見逃さないようにするため、開発チーム、実際に使う人、誰でもいつでも書けるようにする (*2 No.1993)
-
重要な事を見逃さないため、プロダクトオーナーが優先順位を見直す
-
見積りを最新にする
例: (*2 No.1786)
| ストーリー | デモ手順(受け入れテスト手順) | 見積り |
|---|---|---|
| 外出先の営業マンとして訪問先の状況を記録したい | XXX社の記録ページを表示して編集保存 | 5 |
| 営業マンとして取引先を探して内容を知りたい | トップページの検索フィールドから検索して結果表示 | 7 |
- スプリント計画ミーティングで作る
- 直近のスプリントの分
- product backlog と違って、曖昧なことはなくす
-
完了の定義によって、何をもってリリース判断可能かを定める
-
例
- code review, check-in, unit test, coverage, document, security, performance, deploy
- デモ手順のとおりに動作する (受け入れテスト)
- public メソッドのテストコードがある
- 調査した内容は Wiki にまとめてある。
- 最新の仕様が Wiki にまとめてある。
- リポジトリからいつでも最新のデモ可能でテスト済みのソフトウェアが取得できる。
- template https://github.com/agile-samurai-ja/support/blob/master/blank-inception-deck/blank-inception-deck1-ja.pdf
- プロジェクトを始める前に明らかにしておくべきこと
- 10個の質問
- ゴール: どういう物を作らないといけないのか。
- ライバル製品と同じような機能は最低限揃えたい、など。
- ビジネス上のゴールに着いての質問「エレベーターピッチ」
- 今から作るものに予算がつくほどの大きな期待が書けられている理由
- どんな人に向けたもので、どんなことができるか
- それはすでにある他のものと違って、どういう利点があるのか
- これによってどんな期待がかけられているのか
- ミッション: プロジェクトで絶対に達成しないといけない事は何か
- 半年後にリリースしないと大々的にアピールするチャンスを失う、など。
- 我々がなぜここにいるのか
- 達成しないとプロジェクトの意味が失われてしまう理由
- 様々な期待のうち、重要と思われることを3つに絞り、
- その中でも絶対に死守したい最も重要な事を1つ明らかにする。
-
backlog の曖昧な点をなくして、タスクに分割する
-
paper prototyping で UI を決める
-
実現すること理解する
-
仕様を決める
-
どう技術的に実現するか確認する
-
プロダクトオーナーが使用を決められないものや、 UI が定まらないものは、次のスプリントで着手できない (*2 NO.2132)
-
準備ができていない項目は、スプリント計画ミーティングで扱わない、としてもよい
スプリント内で行う開発を決定するミーティング
- sprint backlog の作成
- (第一部 what) プロダクトオーナーがバックログを選ぶ
- (第一部 what) チームでそれらを理解し見積る
- 何を実現したいかを明確にする
- 今までの開発実績 (velocity) から1スプリントに収まるようにする。
- (第二部 how) チームはどうやってそれを実現するか
- planing poker (*1 の位置No.618)
- backlog をタスクに分割する
- 例: 「最初に画面の構成や項目などの UI を考えてから、設計と実装とテストを進める」
-
- UI 設計、2. 設計、3. 実装、4. テスト、 5. デモの準備
- タスクは2〜3時間、少なくとも1日以下の単位にする
- 立ったまま15分でする
- 昨日やったこと、前回の daily scrum からやっていたこと
- 今日やること、次回の daily scrum までにやること
- 問題点、障害になっていること
- sprint のゴールを守るために、問題点がないか検査する
- たとえば、いくつかのタスクが漏れていた
- 簡単に見えたタスクがなかなか終わらない
- どんなことでもいいから、困っていること
- 個別の議論は、朝会の後に関係者だけが参加する二次会でやる。
- 進捗報告会ではない。特定の誰かに報告するのではない。
- 報告を意識すると、問題が見つけづらくなる。
- 問題解決の場ではない。詳細は二次会でやる。
- 関係者を集めて製品のデモをする
- デモの準備もタスクの一つ
- 開発チームは成果のアピール
- 関係者はスプリントがうまくいっているチェックできる
- スプリントの最後に行う改善活動
- スプリントでうまくいったこと、
- うまくいかなかったこと、
- 銅やったら次のスプリントでよりうまく出来るか
- PDCA (Plan 計画 - Do 実行 - Check 検査・評価 - Action 適応・改善)
- KPT
- Keep: やってみて良くて継続したいこと
- Problem: 問題だったこと
- Try: 問題に対する解決策とか、新たな改善など、次で試すこと
- 15分以上悩んだら誰かに相談するなど (*2の No.1615)
- 技術的負債が日々の作業で返済できないなら、オーナーと相談してスプリントを一旦止めるなどする (*2 No.2578)
- 問題を見つけあらすぐにタスク化してボードに貼る (*2 No.1929)
問題の例
-
最近のコードが以前より汚くなっている
-
調べていることがなかなか見つからなくてまずい
-
コードが読みにくいせいで、該当する箇所が見つけられない
-
対応のための修正が別の箇所に影響して、思ったより作業が終わらない
-
「こうすればもっと良くなるのに」と思うことを見つけ、「妨害リスト」にまとめる (*2 No.1942)
- スクラムイベントで一方的に話している時間が長い
- 開発チームが使いにくいツールを文句も言わずに使っている
- カードの粒度: 2〜3時間の粒度にする。それ以上のタスクは分割する。毎日カードが動くようにしたい。
- ドライバ: キーボードを打っている方
- ナビゲータ: 横で一歩引いた支店から助言や質問を投げる
- ペアの交代は15分位で交代
- プログラミング作業だけでなく、リスクが大きい作業や、クリエイティブな作業もペアで。
- ペア開発 Developing In Pairs
- ソフトウェアの内部品質の一つの視点
- テストしやすい設計が良い設計
- テスト可能な設計、テスト容易性
- テストがあれば「壊れていないものを直すな」の原則に反することができる
- 週40時間労働
- ワークフローの見える化
- 仕掛り (WIP: work in progress) の制限
- フローの測定と管理
- プロセスポリシーの牝鹿
- 改善機会を導入するための仕組み
開発マネージャやテストマネージャ、あるいはその上の技術部長などにとって、直接管理できるのは品質だけ
- 欠陥の修正に90％以上の時間を費やしている。
- 品質向上を進めれば、欠陥率の高いチームの生産性が10倍改善する。 (*3 No.768)
- コードインスペクションは品質を向上させる
- ペアプログラミング
- ピアレビュー: 同僚や仲間同士でプログラムコードのレビューや点検を行うこと
- コードウォークスルー: 複数の参加者を募り、プログラムコードのレビューを行うこと。
- 共同での分析設計が品質を向上させる
- チームが一体となって問題分析とソリューション設計をする
- 設計モデリングは毎日小さい単位で行う
- デザインパターンの使用
- 最新の開発ツールの使用
- 作業中の設計の量を減らせば、品質が飛躍的に向上する
- 品質で30倍の差が出る (*3 No.883)
- ゆとりがうまれる
- 絶えず改善をするにはゆとりが必要
成熟度の構築 (*3 No.1007)
- 品質を上げ、仕掛りを減らし、リードタイムを短縮し、頻繁にリリース
- 要望とスループットのバランスを取り、仕掛り制限し、改善を可能とする「ゆとり」を作成する
- デリバリーされる価値を最適化するために、優先順位付けを改善する
- ビジネス価値の最適化
-
実質作業時間は11日間。リードタイムは140日間。90%は待ち行列に入っている時間または他の形態でムダ。
-
リードタイムを140日から25日にする。25日以内のデリバリーを保証する。
-
見積りの廃止
-
カンバン8枚 (3WIP + 5バッファ)
-
6ヶ月が過ぎた項目は、未処理項目から消すというポリシー (*3 No.1245)
- ほんとうに重要ならば、再度要求がなされるだろう
-
明示化されたポリシー、透明性、見える化
-
チームメンバーは自分で決定を行い、リスクを自分で管理するようになる
-
マネジメント層はプロセスがポリシーで構成されていることを理解するので、システムを信頼するようになる
-
結果
- 未処理項目の完全消化
- 11日の実質作業時間に対し、リードタイムを平均14日まで短縮
- 25日間のデリバリータイム目標に対する納期パフォーマンスは98%
- 変更要求を処理するスループットは3倍、リードタイムは90%以上減少
-
変革は、十分な効果が現れるまで時間がかかることがある。この事例では15ヶ月かかった。
カードウォールによるワークフローの表現 (*3 No.1678)
| 入力キュー | 分析 | 開発 | テスト | ステージ | 本番 |
| 入力キュー | 分析(実行中) | 分析(完了) | 開発準備完了 | 開発(実行中) | 開発(完了) | ビルド準備完了 | テスト | リリース準備完了 | ステージ | 本番 |
-
需要分析 (*3 No.1707)
-
需要に基づく作業容量の割り当て
- スイムレーン(横列)の追加 (*3 No.1727)
-
カードにつける目印
- 必須納期
- 納期からその項目が遅れている場合
- 優先度分類
問題点が明らかになるようにする
同時実行されるアクティビティ用に分割されたカードウォールの例 (*3 No.1832)
順不同アクティビティ用のカードは、下のようなチェックボックスを含んでいて、すべてにチェックが入ったら、完了の列に移す。
- UI設計
- セキュリティ
- 永続化
- ビジネスロジック
日次 スタンドアップ ミーティング
- 数日間動いていないカードについて質問をする
-
開発者とテスト担当者が、1度に1つの項目だけに取り組むことを決定した
-
作業タスクの制限
-
キューの制限
-
ボトルネック用バッファ
-
入力キューのサイズ
-
ワークフローの無制限セクション
-
仕掛り制限にかかって、待ち時間が発生するのはしょうがない
- その間は待つ。 Emacs とか Git の本でも読むとか。
- 特急(銀の弾丸): 白いカード
- 必須納期: 紫のカード
- 標準: 黄色のカード
- 無形: 緑色のカード
-
仕掛りの追跡 (*3 No.3171)
- 累積作業項目数
- 日次
- 平均リードタイム
-
リードタイム
-
納期パフォーマンス
-
スループット
-
問題時効と停滞している作業項目
-
フロー効率
- 欠陥がムダの大きな原因であれば、開発チームは、欠陥を減らし、プログラムコードの品質を向上させる技法のトレーニングを受ける必要があるだろう
- 常時結合、ユニットテスト、ペアプログラミング
- 既存プロセスの最適化
- 高品質でのデリバリー
- リードタイム実現比率の工場
- 従業員の満足度向上
- 改善を可能とする「ゆとり」の提供
- 優先順位付けの簡易化
- システム設計と運用への透明性の提供
- 「高成熟」組織の出現を可能とするプロセス設計
カンバンシステムの開始をするための手順の説明がある