まとめ直し(collapse) の価値

作者 Dan Puckett , 翻訳者 吉田 英人 投稿日 2011年3月7日

セクション

プロセス/プラクティス,

設計/アーキテクチャ,

デベロップメント

トピック

顧客要求 ,

アジャイル技術 ,

Agile ,

仕様

共有 |

原文(投稿日：2011/03/01)へのリンク

Mike Burrows 氏によると，

大きな機能をもっと小さな機能のリストに展開 (分解) することはよくありますが，後になってそれを元々のチケットにまとめ直す(collapse)というのは，あまりないような気がします。

これをどう思いますか？

1. 当たり前？
2. 良いこと？ (理由は多々ありそうですが)
3. 悪いこと？ (これも同じ)
4. 条件次第？ (どんな条件でしょう？)

kanbandev グループ の見解は，小さな機能を大きな機能にまとめ直すことにはあまり価値がない，という方向で概ね一致しているようだ。Kurt Häusler 氏が 次のように書いている。

展開したりまとめたり，というのは感心しませんね。でもシステムにまだ入っていない初期の段階で，なおかつプロセスを通じてその状態が保たれるのなら，大きな要件を多数の小さなストーリに展開するのも悪くはないでしょう。トランザクションコストの削減が困難だから，顧客が "未完成の" 機能をテストできないから，あるいは "規模と複雑さ" を求める人が多いから，といった理由で，もっと大きな MMF やミニプロジェクト化などを安易に導入するくらいなら，試してみる価値はあると思います。いつもうまく行くとは限らないでしょうけれど。

でも単純明快なバーティカルスライス，バリューストリームを通じて これが一番でしょう (FTW)。

Ron Jeffries 氏 からは ，

かつての XP では，ストーリをタスクに分割することが推奨されていましたが，最近はそうでもありません。代わりに，小さなストーリにスライスすることがよい，とされています。

XP には "まとめる"，という明確な概念はありません。必要ないからです。

一方で Siddharta Govindaraj 氏は，まとめ直しに一定の意義を認めている。

開発チームに限った観点なら，それでもうまく行くでしょう。ストーリをスライスしてひとつずつ提供すればよいのであって，まとめ直す必要はありません。しかしもっと広い視野で見るときには，流れ全体の中での多数のステップという考え方が，大規模な機能には有効です。つまり，開発レベルでは小さなストーリで展開したとしても，大きな機能が次のステージに移るときには，それらをもう一度まとめ直すことも必要なのです。

これに 対して Ron Jeffries 氏は，

次のステージというのは，どのようなものですか？ 例えばスクラムや XP なら，イタレーションごとの成果は，ソフトウェアの拡張機能として (必要なドキュメントもすべて含めて) 完結しているはずです。

これは kanban の観点，つまり開発側の観点から見たものですけれど，それでも展開／まとめ直しを十分できていますし，ムダ(waste)やバッファ，遅れといった除去可能なものも，ほとんど完全にモデリングできます。

Paul Beckford 氏の 意見では，

ここで重要なのは，インクリメント，フィードバック，イタレーションを小さくすることです。それさえ出来れば，まとめ直しという発想は，最小のインクリメント単位 (例えばひとつのスライス，これは私にとって許容できる最小基準であって，およそ半日程度です)以外のどの抽象レベルにおいても，意味をなさないでしょう。