SAFeにおけるAgileチームの実践とScrumとの違い

友人たちの間で Burn Down Chartに関する最初の記事を公開した後、コメントで最初に寄せられた質問は「SAFeでのあなたの経験についてもっと詳しく知りたい」というものでした。そこで本記事では、私たちの実践におけるSAFeでの業務の特徴をScrumとの比較で明らかにしていこうと思います。私は絶対的な真実を主張するつもりはまったくなく、同僚からのあらゆる訂正や補足を歓迎します。

まず、私の考えではSAFeでの業務をSCRUMと区別する最も重要な点を箇条書きで挙げます。

• ScrumのIncrementとSAFeのProgram Increment
• ART - Agile Release Train
• 関与するチームの数
• PIPE
• SOS
• PO - ビジネスのオーナーではない
• RTE
• 学習のための5番目のスプリント
• System Demo

ScrumのIncrementとSAFeのProgram Increment。 実際には異なる用語ですが、混同しやすいです。というのも、私たちのところではProgram Incrementという用語は誰も使っておらず、みんな単にIncrementと言いますが、これはSCRUMで使われる別の用語です。しかし全体的には、意味の観点から見て両者はかなり似ていると思います。SCRUMのIncrementは、本質的には現在のプロダクト＋スプリント用に計画されたストーリーが完了状態になったもの（チームのDODを通過したもの）です。Program Incrementは、列車（Agile Release Train）がインクリメンタルな価値をプロダクションに届ける時間間隔です。期間は私たちの場合、開発に2週間のスプリントが4つと、学習に1スプリントです。

Agile Release Train - これは単一の価値創造の流れに取り組むチームのチームです。私たちはこれを単に列車と呼んでいますが、フレームワーク的には「Solution」と呼ぶのが正しいです。私たちの場合、このルールは完全には守られておらず、チームは技術的な観点から異なるプロダクトに取り組むことがよくあります。というのも、ほとんどのビジネスフィーチャーは複合的に実装され、複数のプロダクトにまたがるからです。これは技術的な側面です。しかし、すべてのITシステムを会社の1つのプロダクトと見なす人もいて、そちらの方がむしろ正しいかもしれないと確信しています。

関与するチームの数 は私たちのSAFeでは大幅に多く、合計で1つの列車に最大125人まで推奨されています。私たちには3つの列車があり、すべての列車でこのルールが守られているわけではなく、125人を超える列車もあります。SCRUMは他のチームとの連携方法を記述していませんが、私の知る限り、SAFeにはこの点に関する非常に明確な推奨事項があります。私の考えでは、そのための最も顕著なアーティファクトはProgram Boardです。

これには列車のチーム間の相互関係が表示され、これを議論しながら私たちのところでは毎週のScrum Of Scrums（SOS）イベントが行われます。

およそ2.5か月ごと（5スプリントごと）にイベント PIPE - Programm Increment Planning Event. これは分散したすべてのチームが1つのホールに2日間集まり、次の2.5か月間の作業を計画するものです。このイベントの過程で、例えばProgram boardのようなアーティファクトが生まれ、これには各列車についてチーム間のすべての依存関係が表示されます。上にその外観をすでに示しました。このイベントにおける各チームのスクラムマスターの任務は、最大数の依存関係の洗い出しをファシリテートし、その後可能な限りそれらを除去することです（例えば、あるチームから別のチームへ口頭でコンピテンシーを移転したり、あるチームから別のチームへ依存関係を引き取ったりして、チームが誰にも依存せずに自律的に自分のフィーチャーを実装できるようにする）。実際、私たちのところではそうなっています。まずフィーチャーがUser Storyに分解され、User Storyが4つのスプリントに振り分けられます。フィーチャーはProgram Boardに配置され、他チームからの依存関係があれば設定されます。イベント中にこれが議論され、修正されます。

SOS - Scrum Of Scrum。 このイベントは各列車ごとに週1回行われます。列車のすべてのチームのスクラムマスターがオンラインで集まり、列車のProgram Boardが共有され、特定の列車のチームのすべての依存関係とフィーチャーのステータスが議論されます。本質的にこのイベントは、列車内のチームの集中同期に必要です。いわばスタンドアップのようなものですが、週1回で、チームのためではなくスクラムマスターのためのものです。

PO（プロダクトオーナー） - ビジネスのオーナーではありません。Product Managerがいて、その人が該当するビジネス領域のBussiness Ownerたちと連携し、本質的にプロダクトオーナーにフィーチャーを配分します。プロダクトオーナーはすでに直接チームで働き、フィーチャーをUser Storiesに分解します（私たちの場合はチームと共同で）。常に分解するわけではありませんが、私たちはこの方向で絶えず前進しています。

RTE (Release Train Engineer - 列車運転士。スクラムマスターオブスクラムマスターズ。自身の列車のSOSイベントを実施する。フィーチャーレベルでプロダクトマネージャーと連携する。PIPEをファシリテートする。

学習のための第5スプリント - はい、スクラムとは異なり、ここではインクリメントの最後にチームに学習のためのスプリント全体が割り当てられます。私たちは通常、実践ではまずこれを社内トレーニング（SAFeに関するものも含むが、それだけではない）への参加に活用しています。プライベートコースやミートアップも可能な限りこの時間に計画するようにしています。また、必要に応じてチーム内の誰かのコンピテンシーをカバーできるよう（バックアップできるよう）、5スプリントの間に自分のスタックを拡張する開発者もいます。

システムデモ。 PIPEの結果として、各チームはインクリメントに対する目標のリストを持ち、これらの各目標は列車のビジネスオーナーによって10点満点で評価されます。これはビジネスバリューと呼ばれます。これらの目標は主要目標と拡張目標に分けられます。主要目標とは、チームが達成にリスクを感じない目標です。拡張目標とは、達成にリスクがある目標です。すべての目標は必須であり、作業量はすべての目標に対して計画されます。システムデモでは、ビジネスオーナーがインクリメントの作業結果を承認します。例えば、チームに評価10、6、8の主要目標が3つと、評価10、3の拡張目標が2つあったとします。ビジネスオーナーがそれぞれ次の評価を付けたとしましょう：8、6、4、2、0。これで目標達成率を計算できます：100%は主要目標の初期合計点（この場合は10+6+8=24）とされます。達成点は拡張目標を考慮して計算されます（つまり、チームは24のうち20を達成した）。その結果、チームの目標達成率は(20*100)/24 = 83.3%となります。80%から100%の達成が正常な結果と見なされます。

それ以外のすべてにおいて、私たちはSCRUMで働いています。まあ、ほぼすべてにおいて :) 私たちの経験に関して言えば、私の観点では進化は明らかだと言えます。1年間の活動でチームは大きく成長し、自己組織化するようになりました。確かにいくつかのチームは解散しましたが、そこにも一定の進化が見て取れます。成長の余地もまだあります。

facebookの同僚からのコメント

«Женя、こんにちは！書いてくれてすごい、よくやった！列車について少し訂正させて - それらは製品の周りではなく、価値創造の流れの周りに集まるんだ。そして小売では、SAFeの観点からすると私たちのは列車ではなくソリューションだ。ただコミュニケーションの便宜と理解の簡素化のために、私たちはそれを列車と呼び続けている）»

– コンスタンチン・ヴォロニン (インゴスストラフのプロジェクトオフィス代表)

«そして誰かが気づくかもしれないが、SAFeの観点からすると目標の評価はI&Aで行われ（SDはその一部として含まれるが評価に直接関係しない）、SD自体は毎スプリント（チームのデモの後）行われるべきだ。しかし私たちはまだそこから遠いので、意図的にあなたの記事に書かれている通りにすべてを呼んでいる）»

– コンスタンチン・ヴォロニン (インゴスストラフのプロジェクトオフィス代表)

«Женя、続けてください、とても役に立ちます！»

– アレクセイ・イオノフ (SAFe認定トレーナー)