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