アジャイルなソフトウェア開発を行う上で、イテレーションは基本的な特徴であると考える人は多いが、中には、果たして重要なのか、アジャイル方式に価値を加えているのか、余分ではないのか、はたまた無駄ではないかとさえ疑う者もいる。イテレーションがアジャイルチームにとって重要か否かの決定に役立ててもらおうと、InfoQではこの問題の論点を総括した。
lean-agile-scrumのメーリングリストでjdmcauliffe2002が次のように質問した(source)。
リーンでは物事を違った方法で行い、流れをより有効に使うようになっていることが分かっています。大きさで分類されたバックログのアイテムがあった場合、全部のイテレーションを十分見積もる時間をとらずに、代わりに一番上のストーリだけを抜き出して仕事（立案、詳細見積もり、設計、コーディング、テスト、合格）にかかったらどうなるでしょうか。 そのストーリが完了（合格）したら、リストにある次のアイテムに移るのです。この方が効率的で、リーンな方法ではないでしょうか？
Liz Sedleyが応える(source)。
YahooやDavid Andersonなど、多くの人がスプリントを止めています。
間違いなく無駄を排除すると思います。絶対に排除してならないその他のものを以下に記しました。
- 成功を祝うこと。
- 検査と適応。
- 管理者が要求するレベルでの立案。
- 持続可能なペース。
Max Guernsey IIIは、チームの規律に依存するのではないかと示唆する(source)。
スプリントは強力な政治的道具でもあります。スプリントは簡単に理解できる単位時間であり、この単位に照らし合わせて仕事量を測定できます。速度の上がり下がりを見ることができます。ところで、速度の上がり下がりは、通常の週や月、年、日でも見ることができます。スプリントにはもう1つ、重要な政治的側面があり、それは、チームが成功したか、失敗したかをはっきり伝える手段となることです。
抵抗がなくなり、組織的な転換が完了したら、スクラムの厳密性を少し削減して、より流動的なプロセスに替える時が訪れたのかもしれません。その時が来るまで、スプリントのようなものが必要なのです。規律のない人たちに秩序をもたらし、納得していない人々の恐れを鎮め、また、心底一生懸命取り組んでいる人たちを全くその気のない人たちによる政治的破壊工作から守るために。
以下のような問題を挙げた人もいる。Aaron Sandersは「Naked Planning Explained - Kanban in the Small」 (source)で次のように書いている。
可変長の製品バックログという考え方では優先順位を再編成し、サイズを見積もる必要がありますが、この考え方に取って代わったのが、製品オーナー（顧客）がホワイトボードに最小限の市場性機能（MMF）を書き込む固定長のキュー、スクラムで言うところのユーザーストーリです。Arloの考えでは、一人の人間が一度に頭に入れておくことができるアイテムの最大数が７のため、キューの長さは7になります。スロットには永久マーカーで印がつけられます。製品オーナーは、チームを信頼して仕事を任せています。チームはこうした機能が本当に最小限であると確信しています。なぜなら、これ以下になると市場性がなくなりますが、このままでは新規ユーザーもしくは既存ユーザーにとって直接的な価値となるからです。
顧客は、適切と思われるまで、何度でも7つのMMF を再編成できます。チームの準備が整って新しい機能に移れるようになったら、その機能はその時点でスタックの最上部にあるものとなります。7つのMMFは、ホワイトボード上にある2つの目標のうちの1つに適合しなくてはなりません。新規の機能を入れる場合、キューに残っているMMFを完了すれば目標が達成できるか否かを顧客は判断します。目標を達成できる場合は、新しい目標をホワイトボードに追加でき、できない場合は、目標を達成するためのMMFをもう1つ追加します。顧客がWIPを無効にできる迅速処理スロットが1つありますが、その他についてはスロットが空くまで待たなければなりません。
どのMMFが完了した時点でもリリースになる可能性があります。なぜなら、プロセス中の作業は本番サイトで隠せるからです。顧客には、MMF７アイテムや他の目標から溢れてしまったオーバーフロー用として、アイデアのパーキングロットがあります。機能1つがリリースされるまでのおよその待ち時間が、ホワイトボードの最下段に追加されます。MMFに日付がつけられるのは、ホワイトボードに置かれたとき、そして完了して一機能の標準時間が派生するときです。スループットが影響されるほど仕事のサイズに著しい変更があると、このリードタイムが再計算されることになります。Arloはこれを「ディズニーランドのおよその待ち時間」と呼んでおり、「今日この時点からの予定待ち時間は、ｘ日からｙ日になります」などというメッセージにしています。
Amit Rathoreは自らのブログで次のように提案する(source)。
イテレーションの長さをゼロまで減らします。人工コンストラクトはすべて無くします。
- ビジネスアナリストが製品オーナーおよび利害関係者と協力し、ユーザーストーリのリストの優先順位を常につけておくようにすること。
- ビジネス分析、タスク割当、開発がジャストインタイムで行われるようにすることで、開発チームの有効性を確実に最大化すること。
- 製品の紹介、レトロスペクティブの実施、休止は、必要時にいつでも行うこと！
Mary PoppendieckはManaging the Pipeline(source)という記事の中で、リズムの重要性を説明しているが、イテレーションなしではリズムの達成は難しい。
リーンファクトリでは、あらゆるプロセスが「タクトタイム」という決まったリズムで動きます。8時間で80台の自動車を生産したい場合、1時間に10台の自動車を作ることになり、6分毎に1台の自動車が生産ラインから出て来ます。ソフトウェア開発で推奨される実行方法は、おそらく2週もしくは１ヵ月のイテレーションリズムを確立し、そしてデプロイメント準備ができたソフトウェアの小バッチを各イテレーションで引き渡すことです。
定期的なリズム、別名「ハートビート」（心拍）があれば、動作するソフトウェアを信頼できる速度で確実に引き渡せるチームの能力を確立することができます。定期的なリズムで引き渡しする組織は、そのプロセス能力を確立済みであり、その能力を容易に測ることができるものです。
定期的なリズムはさらに、相互依存するチームに信頼できる同期化ポイントを提供します。同期化ポイントは顧客からフィードバックをもらうための望ましいポイントであり、複数の機能チーム全体での作業調整に役立ち、ソフトウェア開発からハードウェア開発を切り離す手助けにもなります。
イテレーションなしのプロセスを考えるもう1つの方法は、各機能にはそれぞれ独自サイズのイテレーションがあり、それを分離させて、可能であれば機能ブランチ(source)を使って取り組むやり方である。
機能ブランチはこの章の例で主に取り上げた種類のブランチであり、Sallyが/trunk作業を続ける間、あなたが取り組んでいたブランチです。/trunkの安定性を妨げることなく、複雑な変更に取り組むために作られる一時的なブランチです。リリースのブランチと異なり（リリースのブランチは永久サポートの必要があるかもしれないため）、機能ブランチは誕生後にしばらくの間使われ、トランクに併合され、最終的には削除されます。機能ブランチの有用性には期限があるのです。
このアプローチでは真にイテレーションを排除できないと主張する人もいるだろう。イテレーションを機能限定型、もしくは複雑なプロジェクトでの使用が指示されている並行イテレーションアプローチ(source)とそれほど相違のない並行型に再定義したに過ぎないというのが、こうした人たちの主張だ。
多数のアジャイリストや自らをポスト・アジャイルと呼ぶ人たちの提案は、どのプロセスが重要かつ有用で、どのプロセスがそうでないかを、それぞれのチームが判断するというものだ。今回の議論では、せめてこう提案しておこう−−あなたやあなたのチームにとって、イテレーションが有用であるか否かを、あなたが検討してはどうか−−。つまり、イテレーションは価値を付加しているのか、それとも無駄として処分されるべきものなのか？
原文はこちらです：http://www.infoq.com/news/2008/01/are-iterations-waste-or-value