フィーチャーチーム

Scrumのスケールアップでは、フィーチャーチームという考え方が必要になってくる。
リンクをメモ。

【元ネタ】
Scrumチームを編成する際の必読記事２点 - Always All Ways

フィーチャーチーム

Feature Team Primer - Craig Larman and Bas Vodde（日本語）翻訳者 : ebacky

(前略)
一般的に、Scrumにおけるチーム編成を行う上でポイントとなることが２点あります。それは、
・チーム分けの切り口（フィーチャーチームvs.コンポーネントチーム）
・メンバーの多能工化の進め方
(中略)
この２つに共通することはいくつかありますが、最も重要なのは「学習」だと思います。
フィーチャーチームを作ったり、またコンポーネントチームからフィーチャーチームに移行したりするときも、チーム内におけるSpecializatiionとGeneralizationのバランスを取ったりするときも、そこではある意味個人としてあるいは組織としての「学習」が要求されます。
その意味では、Scrumは改善のフレームワークであるとともに、組織の学習を強制するフレームワークとも言えるかもしれません。
(後略)

複数チームでソフトウェア開発する場合、コンポーネント単位にチームを形成してしまいがち。
よくある例は、インフラチーム、DBチーム、Webアプリチーム、バッチアプリチーム、などのように、機能と言うよりも使われる技術の単位でチームを作る。
すると、それぞれのチームのインターフェイスがシステムの溝になり、Conwayの法則が述べるように、システムのアーキテクチャに組織レイヤーが反映されて複雑になる。
上記の例では、フィーチャチームを作り、どのチームでもシステムのどこでも対応できるように形成すべきと言っている。

認定スクラムマスターの講師だったBas Voddeさんは、Scrumのスケールアップの話の中で、上記と同じようなことを言っていた。
その内容は、Feature Team Primer - Craig Larman and Bas Vodde（日本語）翻訳者 : ebackyとほぼ同じだ。

Bas Voddeさんの話を聞くと、とても分かりやすいけれど、本当にScrumで大規模チームが回せるの？という疑問は僕だけでなく、マネージャクラスの人達も同様に思っていたらしく、何度も質問していた。
Bas Voddeさんはその質問に丁寧に回答してくれたけれど、まだ理解が追いついていない。

僕自身、フィーチャチームで複数チームを運営した経験がないため、たくさんの疑問はある。
でも、ソフトウェア開発の本来のあるべき姿なのだろう。

但し、Bas Voddeさんは以下のように、Scrumのスケールアップに関する本を既に2冊出版されている。
しかも共著者は「実践UML」を書いたラーマンさんなので、経験に基づいて納得できるような内容なのだろうと推測する。
個人的には、@ebackyさんに是非翻訳してほしいなあと思っている。

また、Coplienの本も翻訳してほしいなあ。