物理的に離れた拠点でアジャイル開発プロセスを実施すること、についてちょっと調べた際のメモ。なお、本によっては「スクラム オブ スクラムでやれば問題ない」といった乱暴な説明もあったのだが、そういった精神論はとりあえず無視。
ディシプリンド・アジャイル・デリバリー
DAD本では「第5章 ディシプリンド・アジャイル・デリバリー・チームを組織する」で複数チームの構成について詳しく説明している。が、ここはあくまで「一緒にいる」チーム中心の記述であり、地理的に分散／拡散したチームについては詳しく取り上げていないようだ。
地理的に分散したチームについてはここで議論してきたことよりも扱わなければならないことが多数ある。幸運なことにこのテーマについては、より深堀りした『A Practical Gude to Distributed Scrum』という本があるので参考にしてほしい。
ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド
というわけで、『A Practical Gude to Distributed Scrum(分散スクラム運用ガイド)』について調べてみるとするか・・・
分散スクラム実用ガイド
日本語に翻訳されたものはなさそう。Google Booksで目次が読めたのでざっと(適当かついいかげんに)訳してみた。
- 目次
- Ken Schwaberによるまえがき
- Scott Amblerによるまえがき
- Roman Pichlerによるまえがき
- Matthew Wangによるまえがき
- 序文
- 第1章 スクラムの進化
- 第2章 分散したチームが直面する課題
- 分散チームのメンバーととのコミュニケーション
- タイムゾーンと労働時間
- 文化の違い
- 言語の違い
- 言語をシンプルに
- みんなに話す機会を与える
- 会議中にグループチャットを使用する
- 翻訳の提供
- チームメンバーの理解度を確認する
- ツール
- ファイル共有
- ソフトウェア工学のプラクティス
- スケジュールの違い
- チームダイナミクス
- 電話のダイナミクス
- 電話を使えるようにする
- 会議室で電話を使う
- スピーカーの識別
- 視覚的な手がかりの取り扱い
- 参加を奨励する
- ひそひそ話の制限
- ラインのミュート
- 合意、非合意の確認
- リモートチームの代弁者を識別する
- 何をやってもだめな時はみんなで電話会議
- リマインダー
- コミュニケーションの問題の影響
- スクラムはどのように役立つのか？
- まとめ
- 第3章 スクラムプロジェクトの開始
- 製品が解決する問題を特定する方法
- ステークホルダーは誰か？
- 解決すべき問題は何か？
- 問題に対するソリューションは何か？
- 投資収益はどうか？
- ビジョンを定義する
- 製品のロードマップを作成する
- スクラムチームを編成する
- バックログを作成し、優先順位を付ける
- リリース計画の作成
- スプリントの長さを決める
- チームのベロシティを見積もる
- 依存関係は何か？
- リスクは何か？
- 複数プロダクトオーナー間の調整
- アジャイルプロジェクト管理ツールを使う
- スマートな開発に投資する
- 非アジャイルチームとの調整
- リリースステータスの報告
- リリース計画とビジョンの継続的な更新
- フェイスツーフェイスの会議に関する重要な注意点
- まとめ
- 第4章 「プレ」スプリント計画の準備
- 「プレ」スプリント計画
- ユーザーストーリーの明確化
- ユーザーストーリーのブレークダウン
- ユーザーストーリーの見積もり
- 依存関係の取扱い
- プロダクトバックログのクリーンアップ
- 「プレ」スプリント計画会議の実施
- フルチームで行う
- 「プレ」計画チームで行う
- バランスのとれたチームで行う
- 分散チームのための考慮点
- まとめ
- 第5章 スプリント計画
- 第6章 分散デイリースクラムミーティング
- 第7章 スプリントでの効果的なコラボレーション
- スプリントでのコミュニケーション
- 距離を克服するためのドキュメント
- 適切なツールを使用する
- チーム全体を大切にする
- 透明性
- スプリント途中での新しいリクエストの処理
- 入り口はひとつに
- 手入れの行き届いたバックログの価値
- スプリントの短縮
- 不具合への対処
- チームメンバーレベルの混乱
- スプリント内で完了できないストーリーの取り扱い
- スプリント内でのブロッカーの取り扱い
- スプリント内での質問への対応
- 持続可能なペース
- タイムゾーンの課題を共有する
- 倍の作業日とならないようにする
- 継続的インテグレーション
- ビルド障害をチームにレポートする
- コード統合のリスクを低減させる
- 製品の高い信頼性を確立する
- 統合の問題を発見する時間を短縮する
- チームの効率を向上させる
- 異なる頻度でビルドは実行できる
- テストの自動化
- 専任の自動化チーム
- 高価値な自動テストを特定する
- 安定かどうかを自動的に図る
- 自動テストはいつでも実行することができる
- 自動テストはソフトウェアの品質を向上させる
- テスト駆動開発
- ドキュメントと動くコードのサンプルを提供する
- 欠陥を修正する時間を短縮させる
- コード品質を向上させ、修正のためのセーフティネットを提供する
- チームメンバーが一緒に共同作業することを助ける
- チームをBDUFから解放する
- ユニットテストと継続的インテグレーション
- 基盤プロジェクトの取り扱い
- まとめ
- 第8章 スプリントレビュー
- 勤務時間が重複するチームのスケジューリング
- 勤務時間が重複しないチームのスケジューリング
- 交流会
- 複数回スプリントレビュー
- 痛みを共有する
- 痛みを感じる
- スプリントレビュー会議全体の記録
- チームが直面する課題
- 利害関係者のコメントを追跡できない
- デモが完成という誤った感覚を提供する
- チームが説明するものがないとき
- 分散したチーム固有の課題
- 一部のチームの成果のデモを怠る
- スプリント長の異なるチーム間の調整
- リモートデモンストレーション
- ネットワーク遅延とパフォーマンス低下
- 場所によってサービスが異なる場合
- 時間外デモ
- まとめ
- 第9章 レトロスペクティブ
- スプリントレトロスペクティブ
- レトロスペクティブに何を期待するか
- レトロスペクティブ実施のタイミング
- 必要なときにやる
- 定期的にやる
- スプリント長の異なるチーム間のレトロスペクティブ
- 同じ製品ファミリのチーム間のレトロスペクティブ
- レビュー後にふりかえりを実施する
- 大きなふりかえり
- 信頼関係を築く
- 距離の影響
- レトロスペクティブの準備
- 期待の設定
- チームメンバーのパーソナリティを理解する
- 文化の違いを尊重する
- 匿名性の提供
- レトロスペクティブの前にコメントを求める
- うまくいったことと、改善できることは何？
- 議論の焦点を合わせるための質問を提供する
- コメントを統合することは余計な作業
- レトロスペクティブの実施
- 報告された問題を議論する
- 全員に発言するチャンスを与える
- 一般的な用語を使用する
- 明白な状態
- トラックでの会話をする
- 効果的に時間を管理する
- リリースふりかえり
- まとめ
- 第10章 考察
Practical Guide to Distributed Scrum, A (IBM Press) (English Edition)
中身まで読む気力は今のところ無いけれど・・・
組織パターン
第5章の組織構築パターンに「組織は拠点配置に従う」「離れて作業する前の顔合わせ」というパターンはあったけれども、あまり語りかけてくるものはなかった。
組織は拠点は位置に従う（5.1.8）
作業を地理的に分散させる必要があるとすると、コミュニケーションが取りにくくなる。しかし、作業を仕切ることができるなら、その被害を制限できる。それゆえ、一緒に作業する人が同じ場所にいられるように、作業をまとめよう。
組織パターン
それはそうだけど・・・
