「リーン開発の現場」読書会
第二回に参加しました。この本の事例は手作り感が強くて本当に読んでいておもしろいです。
第八章 技術的課題をさばく
- 開発作業候補として、10機能と5つの技術課題をプールする。
8.2 リリースの前日
- リファクタリング、コードのクリーンアップを技術課題として行う。
8.3 7メートルのクラスファイル
- 肥大したクラスのソースコードをプリントアウトして、技術的課題が存在していることを実感した。
第九章 バグをさばく
- 従来のやり方は、システムテストで検出された障害をトラッカーに入れて管理し、全員で対応していた（普通のことに思えるけど、際限なく障害を貯められる＝バッチサイズが大きいことがポイントかな）
9.1 継続的システムテスト
9.2 直ちにバグをつぶせ
- バグトラッカーは使わず、テスターがプログラマーに直接話をする！そしてすぐその場で直す。
9.3 バグの登録数を制限している理由
- バグの数は30までと制限している（未修整のバグ数が30を超えたらテストを中止するということだろう）。
- ブロッキングバグはすぐ直す。トップ30に入るかどうか判断し、入るなら入れる（入れ替える）。入らなければ、「無視する」！
- 無視されたバグはどうなるのか。何度も再現すればランクが上がり対処されるのか。
9.4 バグを可視化する
- 次の10機能、次の5つの技術課題と同様に、次の5つのバグがボードに貼り出される。機能、技術課題、バグ(修正)の間のバランス取りの実践か。
9.5 繰り返し発生するバグを防ぐ
- 繰り返し発生するバグのためのキューと、欠陥防止ミーティングでの原因分析・対策検討と実施。
- 「プロダクトのバグはプロセスのバグの結果」
第10章 継続的プロセス改善
- 「プロセスは事前に定義したものではなく発見していったもの」「最初に導入したのはプロセス改善エンジン」
- 基本は、1) 明確さ、2) コミュニケーション、3) データ。
- これはScrumの1) 透明性、2) 検査、3) 適応、に影響されたものだろうか。
- しかし、事前にプロセスを決めずにプロジェクトを開始するなんてことが可能なのだろうか？にわかには信じがたい...理想的には、必要最低限のプロセスにしたい、それはその通りなのだが、いきなり迷走し、最初期の失敗が相互信頼を失わせる、というような事態にはならなかったのか？
10.1 チームのふりかえり
- 各チームは定期的にふりかえりを行う。よりうまくやるための変化を探る。
- エスカレーションポイントを見つけたら、クロスチームの改善ワークショップに持ち寄って解決する。
- 形式はチームごと、その回ごとにまちまち。あまり形式的にしない。
10.2 プロセス改善ワークショップ
- スクラムオブスクラム形式のふりかえり。
- 最初は週一、後に隔週。改善プロセスを小さなステップで進めるのに役立った。
- コラボレーションの質を上げるために会場のセッティングを工夫した。
- ふりかえりの構成は「アジャイルレトロスペクティブズ」にあるとおり。
- 寄り道：直感重要。
- 根本原因の分析を行う。必要に応じてリサーチを行う。施策の選択はメンバーの投票による。合意形成ができないのであれば、より深い分析が必要であることを意味する。
- 変化は意思決定に参加していない人の抵抗を受けるリスクがあるので、意思決定は１００%の合意を目指す。
- ワークショップの目的は仕事のやり方を明確にし、改善すること。明確にするためだけに時間を取ることもあった。
10.3 プロセス改善の度合いを調整する
- プロセス改善ワークショップ起点の変化が多すぎて現場が混乱した。変化の速度を緩めるためにプロセス改善提案書(A3一枚)を作成してもらった。変化の量の制限（ここでも流量制限が！）
第11章 WIPをマネジメントする
- ボードにはWIP(仕掛かり作業)の欄とバッファの欄がある。バッファが大きければそこで待っている時間は長くなる。
- 分析から開発までの間のバッファが大きすぎたので、バッファを減らした。
11.2 開発機能だけWIP制限する
- 技術的課題の解決はボトルネックを解消するので制限する必要がない。
- WIP制限によってタスクに着手できない人がでてくるが、その場合に行うべきタスクを決めるための指針になる「今日すべきこと」。
