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

参加しました。今回は第一回で1章から7章まで読みました。思うにこの本で紹介されている事例は、典型的なスクラムでいきなり始めたのではなく、ウォーターフォール的プロセスから少しずつカンバン方式に変えていったのかなと思われ、大変興味深いです。

  • 第一章
      • プロジェクトの紹介
    • 1.1 タイムライン
      • スケジュール概要の説明
      • 最初のリリースまで1年！？プロジェクト開始から第一リリースまでの期間はウォーターフォールだったのか？と思ったけど、単にリリースをしなかっただけで、potentially shippable product incrementはタイムボックスで作られていたかもしれない。読み進めていけば分かるか。
    • 1.2 巨大な像を分割せよ
      • インクリメンタルリリースの概要の説明
      • この図は分かりやすい。
    • 1.3 顧客を巻き込む
  • 第二章 チーム編成
      • 「どのようにプロジェクトを運営していくかという実験をとても簡単に行えた。」既に決められた管理方法を守るだけではなかったということ。素晴らしい。
      • 当初は作業（＝工程）毎にグループを分けていたが、断絶が起こるので止めたと。
  • 第三章 カクテルパーティ
      • タスクボードの前で行われる朝会の解説。60名の巨大プロジェクトにおけるコミュニケーション手法。
    • 3.1 第一段階：機能開発チームのスタンドアップミーティング
      • まず、機能開発チームが朝会を行う。「昨日やったこと、今日やること、問題点」フォーマット
    • 3.2 第二段階：スペシャリティ同期ミーティング
      • 担当毎に集まって状況を共有。担当毎のボードがあり、その前で行う。
    • 3.3 第三段階：プロジェクト同期ミーティング
      • 各開発チーム、仮想チーム、チーム代表のミーティングを順次実施
      • 各チームの代表が集まって共有。全体の視点。
      • 15分のタイムボックス。長くなる時は関係者でフォローアップミーティングを別途。
  • 第4章 プロジェクトボード
      • ボード上にワークフローを表現。優先順位に基づく要求の絞り込み。
      • ウォーターフォールのように見えるが、複数のストーリーを平行して処理している点が異なる。
      • 絶え間ない価値の流れ。
      • 受け入れテストが二ヶ月に一度しか行われないのでJust In Timeには道半ば。
    • 4.1 僕達のリズム
      • ふりかえり、計画ミーティング、デモ＆システムテスト、リリースのリズム。
      • 「スクラムに近いやり方に向かって、徐々に進化していっている」最初からスクラムでやっていたわけではない。この進化はプロセス改善の結果。
    • 4.2 緊急の課題に立ち向かう
      • 緊急度が高く特別扱いで早急に処理すべきストーリー/タスクが存在しうること、その識別
      • 問題があってブロックされたストーリー/タスクの識別
  • 第5章 カンバンボードをスケールさせる
      • プロジェクトが大規模になり全体像が見えなくなったので、チームボードとは別にプロジェクトボードを作成した。
      • アバターの個数によって、ひとりが担当できるタスク数を制限
  • 第6章 プロジェクトのゴールを追え！
      • ゴールを明確に意識することで、集中できる。大きなゴールとマイルストーン。定期的に現実とゴールのギャップをチェックする。簡単な質問でいい。
  • 第7章 準備OKを定義する
      • プロジェクトボードの各ステージにはそのステージの完了の定義を書いてある。
    • 7.1 開発の準備OKとは
    • 7.2 システムテストの準備OKとは
    • 7.3 チームがひとつになる
      • 開発の準備OKの定義とシステムテストの準備OKの定義を明確にすることで、チーム間のコラボレーションが改善した。