「リーン開発の現場」読書会

第三回に参加しました。

第12章 プロセスメトリクス

リリース後の障害発生数なんかは計測していなかったんですかね。

12.1 ベロシティ
  • 週の終わりにこの一週間で開発した機能の数を記録し、バーンアップチャートにしている。
  • バーンアップチャートは問題の存在を可視化する。
  • バーンアップチャートはプロセス改善の効果を示す。
12.2 ストーリーポイントを使わない理由
  • 予測にはかならず幅があり、精度を上げてもそこに吸収されてしまい意味がなかったので。
12.3 サイクルタイム
  • 開発候補に上がってから受け入れテスト可能になるまでの期間を計測。
  • 問題の見える化にはそれで十分。
  • WIPを制限することで、サイクルタイムを短縮した。
12.4 累積フロー図
  • 日毎に、ボードの各ステージに貼り付けられていたカードの枚数を表したもの。
  • 今のところうまい使い方を見つけられていない。
12.5 プロセスサイクル効率
  • 正味作業の割合。これを高めたいので、できれば計測したいが面倒なのでしていない。

第13章 スプリントとリリースの計画

  • スプリントタイムボックスを採用していないので、次に開発する機能の優先順位付けだけ。
  • スプリント計画ミーティングは二部構成
    • 第一部はバックログの手入れ
    • 第二部は次の10機能の選択
13.1 バックログの手入れ
  • 機能を「開発準備OK」な状態にする
    • 職能横断的なグループを組んで検討
    • 規模の見積り（L, M, S）
    • 受け入れテスト内容の検討。
13.2 次の10機能の選択
  • 重要なのはなにを選択しないか
  • 評価の観点。ビジネス価値、知識、資源の活用、依存性、テストのしやすさ
13.3 できるだけ前にバックログの手入れをする
13.4 リリースを計画する

第14章 バージョン管理の方法

14.1 ゴミのないトランク
  • 機能テストを完了した（＝システムテスト準備OKの）ものをトランクにコミットする
14.2 チームブランチ
14.3 システムテストブランチ
  • システムテスト開始時にテスト対象を切り出したブランチを作る
  • バグ修正があれば行い、確認が取れればトランクにマージする

第15章 アナログなカンバンボードを使う理由

  • 変更しやすさ
  • 対話を生み出す

第16章 僕たちが学んだこと

16.1 自分たちのゴールを知ろう
16.2 実験しよう
  • 仮説と検証
  • 継続的改善
16.3 失敗を抱擁しよう
  • 失敗から学びを得る
16.4 現実の問題を解決しよう
16.5 チェンジエージェントを変化に集中させよう
  • 内部のCAと外部のCA
16.6 関係者を巻き込もう

この本も次回で最終会の予定です。