組織パターンのジム・コプリエン(James O Coplien)氏と、スクラムの共同開発者のジェフ・サザーランド(Jeff Sutherland)さんが中心になって、スクラムを組織パターンで説明する取り組みがありました。その成果であるパターンの概要を日本語にしてみました。内容に変なところ等がありましたらぜひご指摘ください(GitHubにホストしました)。
原文はこちらにあります。
スクラムパターン概要
スクラムが効きそうにないところを除いたパターン
これらのパターンがスクラムそのものだ。2008年6月、スクラムの創立者(訳注:ジェフ・サザーランド氏)と組織パターンの開発者(訳注: ジム・コプリエン氏)が、数名のエキスパートとともに、組織パターンの本に記述されたパターンを、スクラムフレームワークの中で適用する際の、全体像(マップ)を作成した。これらのパターンは、スクラムフレームワークの代表的な要素であり、フレームワークを分解して基礎となるコンポーネントに解剖した基礎プラクティス集でもある。パターンというものは単なる原因-結果ではなく、階層構造を持つ。ここにあるパターンは第２階層のパターンと読んでいる。後で説明する第１階層および第３階層のパターンと比較することができる。
これらのパターンは、本質的にソフトウェア開発以外にも適用可能だ。作成グループでは、スクラムではうまく行かなさそうな部分のパターンを除くこと、ジェフ・サザーランドが導入支援を行ったスクラムの事例に沿ったものにすることとした。各パターンの詳細は、Software Scrum Patterns のページで見ることができる(訳注: まだこの資料はありません)。
一番下に掲載している図は、ビードルらによるパターンランゲージである。スクラムの原因-結果の構造を示している。第一階層のスクラムパターン ( First-Level Scrum Patterns ) のページに概要がある。
パターンランゲージ全体図
各パターンの説明
パターン名 : 信頼のコミュニティ
説明 : 不都合な真実に直面することに対して、人々が十分にオープンである
スクラムメモ :スクラムは、尊厳・オープンネス・透明性に基づいている。
パターン名 : ワークキュー
説明 : (なし)
スクラムメモ : プロダクトバックログとスプリントバックログを持っている。
パターン名 : 名付けられ、安定した基盤
説明 : 継続的インテグレーション(CI)を使ってはならない。なぜなら、基礎となるビジョンをチームで共有する事が難しくなるからだ。(中途でなく)公開した部分の統合を行うべきだ。
スクラムメモ : 継続的インテグレーションがノルマになると、スプリントの終了時に、宣言・合意されたカバレッジ目標まで到達しなければならなくなる。また、アーキテクチャ上の変更を段階的に行う事ができなくなる。アーキテクチャ上の変更は、ソースコード管理システムのブランチを用いて、オフラインで行うのが最もよい。
パターン名 : 顧客を巻き込む
説明 : 顧客と開発組織は密接に連携する必要がある。
スクラムメモ : スクラムには顧客というロールは存在しない！しかし、顧客なしにスクラムを完成させる事はできないだろう。プロダクトオーナーは顧客ではないことに注意すべきだ。プロダクトオーナーは企業のROIを最適化する責任がある。顧客からの情報を得るが、顧客の興味を引くのが仕事ではない！一方、"顧客の代弁者" パターンも参照のこと。
パターン名 : 適切なサイズの組織
説明 : 小さく始めて、徐々に成長させよう
スクラムメモ : 小さなチームは最もうまく機能する。スクラムでは、７名±２名のチームを推奨している。長い年月の中で、小さなチームは大きなチームに勝利してきた。
パターン名 : ロール(役割)は少なく
説明 : ロール(役割)の数は少なく保つ
スクラムメモ : もちろん、スクラムはもともと３つしかロールがない。しかし、"業務専門家のロール" は重要だ。私たちは、いくつかの特殊ロールの一つとしてこれを認めている。もし、多すぎるロール(専門分野)が存在する場合、急いで知らなければならない事を探すのが難しくなってしまう。
パターン名 : 非公式な作業計画
説明 :開発者が、いま最も重要な事を行うためには、開発者たち自身で調整するか、短期計画を通じて、「今やるべき事を"表現"」する必要がある。マスタープランに殉ずるのではなく。
スクラムメモ : これはスクラムにおける自己組織化チームの基本である。スプリントバックログのタスクに関する部分。チーム自身がリソースを最適化するような作業計画を組む事をトップダウンで承認し続ければ、チームメンバーが時間を持て余す事はなくなる。
パターン名 : 一話ずつ構成する
説明 : 固定期間のスプリントを持つ。
スクラムメモ : このコンセプトはスクラムの中心的なものだ。固定期間のスプリントは、スケジュールの微調整の大量発生が引き起こす深刻な危機から、チームを守ってくれる。
パターン名 : スタンドアップ・ミーティング
説明 : いつもの短時間ミーティングで、チームの各自の状況を共有する。
スクラムメモ : デイリースクラムそのものだ。
パターン名 : 顧客の代弁者
説明 : 実際の顧客にリアルタイムに話す事が難しいときは、身代わりを立てる必要がある。
スクラムメモ : プロダクトオーナーは顧客がチームに要望している事を収集し、チームに伝える。
パターン名 : 品質保証を確約する
説明 : 品質保証は後付けの考えであってはならない。
スクラムメモ : テストチームを作らず、テスターはチームの一員である。チェックイン時の自動テストも必要になる事がある。これがないと、作り直しやムダが発生する。
パターン名 : 自ら選択したチーム
説明 : 指名で集めたチームは機能しない。メンバーは自らどのチームで働くべきかを決めるべきだ。
スクラムメモ : ケン・シュウェイバーは最近、自ら選択するチームの結成に否定的だった顧客の仕事を断った。
パターン名 : プロデューサー役
説明 : もしあなたの組織が多すぎるロールを抱えており、どれをなくしたらいいかわからない場合、プロデューサー、サポーター、ムダの３つに分類しよう。ムダを廃止し、複数のサポーターを一つに統合しよう。
スクラムメモ : スクラムは、リーンにおけるムダなロールをなくすことに相当する。スクラムは製品を産み出すチームに常にフォーカスしている。製品に貢献しないものは全てゴミだ。
パターン名 : 組織は場所に従う
説明 : 同じ羽毛の鳥は一カ所に集まる(類は友を呼ぶ)。組織は場所を共有する。
スクラムメモ : 生産性の高い分散スクラムチームは存在するが、「おうちでは真似しないでください」。スクラムはチームを基本としており、チームは目的を共有した７名以下の人々が全員同席するのが前提だ。
パターン名 : 開発者がプロセスをコントロールする
説明 : 開発者が、射撃指令を出す。
スクラムメモ : チームは自己組織化する。そこにはプロセスに関する規定書はなく、チームリーダーもマネージャーもタスクの優先順位を勝手に入れ替えてはならない
パターン名 : 一人でも前に進む
説明 : 混乱が常にチームの進捗を妨げる状況においても、なにがあっても、誰か一人は第一の目標に向かい前に進む。"一人を犠牲にする" や "介護人" などのパターンを使って、混乱に対応しよう。
スクラムメモ : 誰か一人でも前に進めるような状況を作れないことを、一つの障害と考える。スクラムマスターはそのような障害を真っ先に見つけるよう、毎日、心がけなければいけない。
パターン名 : 小さなスケジュール変更をしない
説明 : もうちょっと時間が必要なとき、小さなスケジュールの追加をせず、大きくはっきりと変更する。
スクラムメモ : スクラムにおけるスプリントの異常終了だ。
パターン名 : プロデューサーを中心に置く
説明 : 開発者が道に迷ったときは、組織の中心の、目立つところにプロデューサー役を配置する。
スクラムメモ : 売り上げを生む製品の作り手である、プロデューサーと開発者を中心に考える必要がある。マネージャーをプロセスの中心にするべきではない。待ち時間と、部分最適スケジュールを生むだけだ。
パターン名 : ツマリを取り除くために立ち止まる
説明 : XPのパターン "製造ラインを止める"を小さく行うものだ。誰かが詰まっていたら、流れを正常に戻すためにリソースを使う。
スクラムメモ : これはリーンの"流れ"の概念である。チームは常にスプリントバックログの項目をこなし、ベロシティを最適化し、スプリント失敗のリスクを下げる。
パターン名 : 完了へのゆとり期間
説明 : 大変な時期に仕事を進めているなら、一番大きなタスクの完了日と必達リリース日との間にゆとり期間を設ける。
スクラムメモ : スクラムチームは、見積もりの際に常に計画できないものも計画する。これはベロシティに障害として現れるか、もしくは、スプリント開始時の計画において、チームがなにか対策を打つ。バーンダウンチャートは残りのゆとり期間を示す、よいリアルタイム指標だ。
パターン名 : 再コミットメント・ミーティング
説明 : チームが自ら行ったコミットメント(公約)を達成できない場合は、組み立てラインを停止する
スクラムメモ : 各スプリント終了後に、チームはプロダクトオーナーへ再度コミットメントを行う。スプリントが強制終了になった場合も、コミットメントを再検討する。
パターン名 : 防火壁
説明 : 誰かが、開発者の背後から猿を遠ざけなければならない。
スクラムメモ : スクラムマスターは「助けて！」と言ってくる人々からチームを守る。
パターン名 : 一貫した目標
説明 : チームとして働き始めるとき、チームの目標について、全員で確認する。そしてその合意がずっと続くようにする。
スクラムメモ : スクラムはチームを基盤としている。目標の合意がなければチームは成立しない。
パターン名 : パトロン役
説明 : 企業レベルで開発者を守る人。(スクラムでは、プロダクトオーナー)
スクラムメモ : チームには、障害を排除し、リソースを提供してくれるスポンサーが必要だ。スクラムマスターは単なる "たかり屋" で、必要になったときにリソースを探しにいく。チームにはパトロンが必要。パトロンはスクラムの活動全般を保護し、養う。
パターン名 : 全体の多様性
説明 : あるサブシステムの開発に多様なスキルを要するが、人々は専門分化してしまっている場合、複数のスペシャリストを集めた一つのチームを作る。
スクラムメモ : これはスクラムのクロスファンクショナル(職能横断)チームである。
パターン名 : 仕事を均等に分ける
説明 : 仕事のほとんどをやっつけてしまうスーパーマンは存在しない。全員が等しく忙しく、リラックスしている。
スクラムメモ : ヒーロー達に依存しっぱなし、ではないチームが必要だ。スクラムでは、チームは自己組織化している。これは、不公平な負荷が一人にかかることがない、ということも意味している。
パターン名 : 責任を約束する
説明 : 人々は、いつも組織の中核とつながっている。自らつながりを維持する役を演じる。スクラムにおいては、コミットメントがこれにあたる。
スクラムメモ : これは負荷分散( "仕事を均等に分ける" を行う)のために必要になる。また、チームが、自分たち自身にタスクのコミットメントを行う事とも関係している。
パターン名 : 責任範囲を絞る
説明 : コミュニケーションネットワークが同レベルになるように、メンバーに責任と権限を与える。組織があなたの望む体制になるためには必要なことだ。チームの全員に責任があるのだから、そうするのが正しいと思えるだろう。
スクラムメモ : スクラムには多くの例がある。スプリントごとにチームにタスクをアサインする。XPを行う部屋のような物理的環境がチームの恊働を促進する。スクラムマスタはチームメンバー間の責任のバランスを調整するようファシリテートする(ある意味、自分自身が障害になる)。
パターン名 : グループでの検証
説明 : レビューと検証は、コーディングのためだけでなく、情報交換としても価値がある。
スクラムメモ : スクラムではチームでこれを行う。チームに属さない品質保証担当が行うのではない。
パターン名 : ロールごとに３〜７の支援者
説明 : ロール間は緊密に連携する必要がある。しかし、神様は必要ない。
スクラムメモ : スクラムはコミュニケーションが肝だ。コミュニケーション経路を短くし、効率的なチームであるためには、組織階層を持ちすぎてはならない。そのかわり、各員が緊密に連携するべきだ。
パターン名 : 責任を動かす
説明 : "責任範囲を絞る" ために責任を動かす。
スクラムメモ : チーム全体が過負荷状態にある時、またはスプリント中に仕事がないメンバーがいる時、チームの中に「それは私の責任ではない」と言ってよいメンバーはいない。テスト担当は（コードを効率的に書けないために）開発タスクを手伝うことができないとしても、チームにコーヒーを淹れることくらいはできる。
パターン名 : 緊密な連携は遅れを減らす
説明 : ロール同士が緊密に連携すれば、遅れを減らすことができる
スクラムメモ : スクラムは、コミュニケーションとベロシティが肝だ。コミュニケーションは意思決定にかかる時間を削減し、ベロシティを引き上げる。
パターン名 : チームのプライド
説明 : もしそのチームが、督促されないと仕事しないなら、督促する代わりにメンバーにしっかりしたエリート主義を教え込む。
スクラムメモ : よいチームはコミットメントと独立心を持つ。彼らは毎日勤怠をつけるためだけに出勤しているわけではない。
