フィーチャーチーム
Scrumのスケールアップでは、フィーチャーチームという考え方が必要になってくる。
リンクをメモ。
【元ネタ】
Scrumチームを編成する際の必読記事2点 - Always All Ways
Feature Team Primer - Craig Larman and Bas Vodde(日本語)翻訳者 : ebacky
(前略)
一般的に、Scrumにおけるチーム編成を行う上でポイントとなることが2点あります。それは、
・チーム分けの切り口(フィーチャーチームvs.コンポーネントチーム)
・メンバーの多能工化の進め方
(中略)
この2つに共通することはいくつかありますが、最も重要なのは「学習」だと思います。
フィーチャーチームを作ったり、またコンポーネントチームからフィーチャーチームに移行したりするときも、チーム内における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の本も翻訳してほしいなあ。
| 固定リンク
「Agile」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
コメント