BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース まとめ直し(collapse) の価値

まとめ直し(collapse) の価値

ブックマーク

原文(投稿日: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 氏の 意見では,

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

この記事に星をつける

おすすめ度
スタイル

BT