ITとアジャイルの熱狂的な支持者のひとりであるMike Burrows氏はKanbandevグループである議論を始めた。このグループはコミュニティを展開/収縮パターンの探索に連れ出し、このパターンと他の分析手法や用語との関連を考察し、大規模な要求を小さく、徐々に対応できるものに砕くことで発生する混乱に対処する方法を模索している。氏の始めた議論はInfoQの他の記事で紹介した。その記事では要求を細かく砕いて展開する方が、砕いたものを再度まとめることよりも価値があると考える実践者たちの見方を紹介した。しかし、多くの人がこのパターンは両方とも便利だと思っている。
氏は次のように質問して議論を始めた。
大きな機能を小さな項目の一覧に展開する(分解する)のですが、後になって展開した項目を元のチケットにまとめ直していないことに気付きました。これは、普通のことですか。いいのでしょうか。良くないのでしょうか。
現在この議論には100を超える返信が付いている。この議論の中ではMMF(Minimum Marketable Feature)とBVI(Business Value Increment)の違いや、リーンとカンバンのコミュニティでも最小限の価値を提供するためにこのふたつが使われていることに言及している。Feature Injectionの作者であるChris Matts氏は、
Julian Everett氏は"Business Value Increment"という言葉を考え出しました。この言葉はMMFより断然いいと思います。私は愚かにもずっと昔にこのグループにMMFという言葉を導入してしまいました。... そして、この言葉が混乱を引き起こしてしまったんです。MMFの考えでは、BVIより少ない機能性しか提供できなかったら投資家になにも価値を提供していないことになります。
提供したものがBVIに満たなかったら市場に投入するのが遅れてしまいます。考えていなかった追加の仕事が発生するからです。逆にBVIが大きすぎたらなるべく早く価値を提供することができなくなります。
企業分野のアジャイルの専門家であるDennis Stevens氏は展開/収縮パターンを利用する２つの異なる方法を探索している。まず、複数のボードにタスクを展開する。
1. プログラムのボードで複数のチームを調整する。... BVIを複数のチームに展開します。各チームは割り当てられた作業を完成させます。そして、各作業をプログラムBVIにまとめ直します。これで価値が提供できます。
2. 複雑なカンバンの中を動くひとつのストーリー。この場合、ストーリーは別々のカンバンの状態の異なるタスクへと分解されます。成果物も分析、設計、テスト、ドキュメント、開発など異なる形式に展開されます。... BVIは複数のタスクやストーリーに展開されます。それらの状態が"完了"になったときがBVIへとまとめられるときです。
リーンとアジャイルのコーチであるEric Willeke氏はブログの記事でこの議論に参加し、氏が考える展開/収縮パターンの利点を記している。
- チームに着目できる。展開/収縮の主要な利点のひとつはチームに関連するタスクに注力できることです。... 個々の活動が企業にとってどん役割を担っているのか把握することができるようにしておく必要があります。
- 進行中の学習を管理する。展開/収縮パターンを適用する場合、砕いた各タスクの中で"見つかった"ことに着目します。多くの発見があるものが高い価値を有していると言えます。
- 管理の抽象化。50(あるいは500)の5つの小さな項目より5つの大きな項目のほうが価値を見積もり、優先順位を付けるのが簡単です。一方で<開発者>は目的に向かって効率的に進むために詳細な項目が必要です。
- 会話の促進。単に分解するだけでも価値があります。スクラムはスプリントを計画し、タスクを見積もることで会話を促進します。しかし、イテレーションが止まってしまってもグループとして探索を停めていいわけではありません。
- 運用言語。"開発"と"ビジネス"の間に深刻な誤解が生まれる事例をよく聞きます。これは、このふたつの領域で働く人々が同じ単語を使っているにも関わらず、それが全く違うことを意味しているからです。法務、資産、コンプライアンス、運用などほかの利害関係者が現れるともっと複雑になります。
Eric Willeke氏は次のような見通しを語り、記事を締めくくっている。
タスクを取り出したときに、どのようなコードを書けばいいのかはっきり分かるということはありません。プロフェッショナルへの門戸は誰にでも開かれています。... ストーリーを完成させるためのタスクにも同じことが言えます。ストーリーを完成させるには大きな仕事を成し遂げなければなりません。また、その環境でそのストーリーを分解した結果生まれたタスクや分解した結果をまとめたタスクも完成させる必要があります。実際の"ルール"はかなり小さいものです。
上手くやりながら、より効率的な方法を模索するのがいいでしょう。