Agile2009三日目
- 本日聞いてきたお話
Scaling Scrum with Feature Teams
- 大規模SCRUMの話。
- 日本にも支社があるOdd-eによる発表。
- 「どんなに大規模になっても、Product Backlogは一つにまとめよ」
- 「The Product Ownerはどんなに大規模でも一人」
- 一人しかいなくて、しかも他の仕事が忙しいProduct Ownerが、膨大な量のProduct Backlogをどう管理するのか？
- 一方、開発は複数チームに分けざるを得ない。
- どういう根拠で開発チームを分けるのか？
- 「大雑把な設計をし」「そのサブシステム単位で分ける」のが古典的な考え方。
- だが、この段階での設計は非常に粗い。
- その粗い設計を元にチーム分割する時点で、将来に向けての問題を埋め込むことになる。
- そして問題が発覚する時点で手遅れ。まずいチーム構成のまま進むことになる。
- Product Backlog...利用者の視点。
- 大雑把な設計によるチーム分割...開発者の視点。
- ここで不整合が生まれている。Product Backlogをどういう根拠でチームに割り振るのか？
- Product Ownerは実装のことなどわからないので割振り基準を理解できない。
- 各開発チームは自分の「縄張り」以外の実装を含むProduct Backlogが振られることを回避できない。
- 結果的に他チームへの仕事依頼や他チームソースとの同期などが必要になる。
- そこでPM(プロジェクトマネージャ)の登場ですよ！
- とはならない。
- PMは各チーム間で生じる不整合などを「予測し」「対処する」。
- この予測が正しかったかどうかは、対処が終わるまでわからない。
- その周期はイタレーションより長いのが普通なので、Agileの強さを殺すことになる。
- この発表で「なるほど」と思ったのは、チームを「Product Backlog単位で分ける」という方針。
- つまり、Product Ownerの視点。
- その分担を決めるのがFeature Team。
- 各Feature Team構成員の下に、開発チームがつく。
- 結果的に開発チーム間でソースコードの共有が発生する。
- あるチームが他チームのソースに手を入れることもあり得る。
- チーム間で重複する機能を造りこむ可能性もある。
- これらにうまく対処するには...
ほほう、と思ったこと。
Become a Better Agile Practitioner: Learn from other sources
Agileを推進していくのに役立ちそうな考え方の紹介。
- NLP(Neuro Linguistic Programming)
- Battle Ground Mapping
印象に残った言葉
- Dean Leffingwell: 「アプリケーションを書く人達が方式設計しろ」
- Dean Leffingwell: 「方式でもめたらコードを書いて判断しろ」(机上の空論厳禁)
