短いイテレーションの事例

作者 Dave Nicolette , 翻訳者 編集部 投稿日 2009年3月10日

セクション

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

設計/アーキテクチャ

トピック

Agile ,

方法論 ,

アジャイル技術 ,

変化

タグ

補完実践 ,

Scrum ,

プランニング

リリースサイクルの長さに合わせてイテレーションの長さを設定するのが当たり前になっています。私の考えは違います。2つのサイクルは切り離すべきです。長いイテレーションよりも短いイテレーションの方が、顧客からのフィードバックを頻繁に受けられるようになり、チームが仕事のやり方を熟考し、改善していく上で、より多くの機会を得られます。サイクルが短ければ、結果的に「ハートビート」が頻繁に発生し、十分意味をなすようになります。チームが創り出すワークアイテムが大きいと、大量の仕事をこなさなければ「成功」点に到達できないようになりますが、サイクルが短ければ、ワークアイテムがウンザリするほど大きくならないように自然と歯止めがかかります。以下のメリットは、リリースサイクルが長いときでも当てはまります。

メリット

1. 進行中の仕事を混乱させることなく、優先順位の変更に素早く反応。イテレーションの途中で、プロダクト所有者や顧客、代理人が優先順位を変更したり、機能を追加したりすることは珍しくありません。そうした変更を次のイテレーションに先延ばしできるほどイテレーションが短ければ、手際よく処理できます。なぜなら、イテレーション作業の規則正しい律動を混乱する必要がないからです。
2. 問題の検知。成熟したアジャイルチームなら、プロセススメルを識別して、すぐに行動を起こします。ところが現時点では、アジャイルな方法を使用している大部分のチームが依然として学習段階にあり、自らの感覚に頼れるほどアジャイル開発の成熟レベルには達していません。問題の識別にはプロジェクトメトリクスの傾向を追跡記録する必要があるのです。傾向の作成にはデータポイントが3つ必要で、プロジェクトデータの収集がイテレーション毎に１回行われるとすると、イテレーションが短いほど問題の露呈が早いということになります。編集部注：最適化戦略という状況におけるプロセス「スメル」は、コードのリファクタリングにおけるコード「スメル」に似ています。はっきりとは言えないけれど、「間違っている」ことが分かっている何かのことです。（http://safari.oreilly.com/0321486471/ch05lev1sec2 より）
3. スコープ管理。バックログ項目は、項目が大きい時より小さいときの方が容易に移動できます。イテレーションが長いと、ユーザーストーリが大きくなる傾向にあります。プロダクト所有者がバックログ項目の優先順位を変更しなければならなくなると、ユーザーストーリが大きい方が、変更によってもたらされる影響も大きくなります。イテレーションが短いと、結果としてユーザーストーリが小さくなる傾向にあります。プロダクト所有者はINVEST principles（INVESTの原則)(リンク)に従い、ユーザーストーリの優先順位付けのやり直しが簡単にできるでしょう。
4. 4. イテレーション計画と追跡記録。長いイテレーションによって生まれる大きなユーザーストーリの場合、容易に処理できるサイズに成果を解体するためには、「タスク」に分解する必要性が頻繁に出てきます。その後は、チームがすべてのストーリを理解できるようにすることだけを目的に、イテレーションの最初から最後までタスクを追跡記録しなければならず、それには、カンバンのようなシステムか、イテレーションのバーンダウンチャートを使います。多数のチームが毎日一時中断し、不完全な状態で残っている個々のタスクを再評価しているのです。イテレーションを短くすることにより、こうした内部プロセスのオーバーヘッドをすべて排除でき、そうすれば、ユーザーストーリそのものが小さな作業単位となり、チームはイテレーションの状態をより単純に理解できるようになります。
5. イテレーションレス（イテレーションのない）プロセスへ移行するための土台。イテレーションのアプローチには、ウォーターフォールプロセスにつきもののオーバーヘッドがいくらか残っており、取り除こうと苦労してもなくなりません。累積型のフローチャートでは、各イテレーションの開始から終了までの「リードタイム」という形で、このオーバーヘッドが表示されるかもしれません。私がこれまで一緒に作業したチームは、うまく処理できるところまで可能な限りイテレーション期間を圧縮したので、こうしたオーバーヘッドをかなり排除できたことが分かりました。イテレーションが短ければ短いほど、物事を予定どおりに運ぶために必要なプロセスオーバーヘッドが少なくなるのです。

他方、タイムボックス化したイテレーションで作業するという統制がかかることにより、アジャイルなアプローチの付加価値が生まれ、その中には頻繁かつ定期的に予定されるデモンストレーションやレトロスペクティブ、インクリメンタルな成果を提供する一貫したスケジュール、顧客のフィードバックを得る頻繁な機会、長期に及んでチームを従事させ続けると思われる「ハートビート」もしくは「脈」の感覚が含まれます。イテレーションレス・プロセスを導入する際に、作業をタイムボックス化することによる付加価値を放棄し、不幸にも「大切なものを無用なものと一緒に捨ててしまう」という過ちを犯したチームもありますが、短いイテレーションを使えば、そのような過ちを犯すことなく、わずかな痛みで非常に軽量なイテレーションレス・プロセスへ移行できると期待するのも無理からぬことと思えます。

イテレーションレス・プロセスへ移行すれば、「イテレーション」に関連してチームが行っていたあらゆる慣行全部を放棄してよいはず、という思い込みが頻繁にみられますが、これは誤解です。アジャイルな開発と一般に結び付いている特定の付加価値の慣行から「イテレーション」の概念を切り離し、有益な慣行を維持しながらプロセスオーバーヘッドを削減する方法を模索するのが賢明です。

潜在的なマイナス面

短いイテレーションを使って問題を経験した人もます。短いイテレーションの提案者であるMishkin Berteig氏も潜在的なマイナス面(リンク)に触れています。

• 「熱心に仕事するあまり、燃え尽き症候群にかかるおそれがあります」。チームが選択する「仕事のやり方」の問題である、と私は思います。サイクルが短いからといって、必ずしも仕事の激しさが増すとは限りません。短いサイクルは単に小さなタイムボックスを意味するだけ、という風にこなすことができます。すなわち、タイムボックス毎に達成しなければならない仕事は少なくなるのです。「激しさ」を変える必要はないのです。他のアジャイルの原則（とりわけ「持続可能なペース」）は、燃え尽き症候群を防止することを目的としています。
• 「戦略的思考はスケジュールへの順応が難しいことがあります」。 戦略的思考はイテレーション単位の問題ではありません。イテレーションは戦術的です。戦略的思考は…、そう、戦術的ではありません。短いイテレーションの特性そのものというよりも、管理の問題のような気がします。
• 「イテレーション毎に行わなくてはならないオーバーヘッドタスクに要する時間が、イテレーション全体のより大きな割合を占めます」。これも、チームが選択する「仕事のやり方」に凝縮される問題のように思われます。イテレーションの長さを圧縮した場合の、興味深い効果を観察しました。特定のオーバーヘッドタスクが実は元々必要ではなかったことに人々は「気づき」、そのタスクを止めるのです。最終的には必要なことだけを行うようになり、言い換えれば、プロセスから不要な物を排除したことになります。実際、私の観察はこうでしたので、Java Ranchの議論におけるJim Shore氏の意見(リンク)には敬意を表しながらも、賛成できないのです。Shore氏は、イテレーションが長ければストレスは少なくなり、経験豊かなアジャイルチームでは長いイテレーションの方がうまくいくと述べています。イテレーションの計画にこれ以上の時間をかけたくはないでしょう。イテレーション計画の時間は短い方がいいと思います。私はいっそう短いイテレーションに賛成で、シングルピース（「単一機能」と解釈する）フローの顧客プル型アプローチへの移行と並行して、イテレーションは消えて無くなるのです。
• 「チーム外の資源や人間を待っていれば、仕事が複数のイテレーションに及ぶ可能性が高くなります」。これは組織的な制約です。組織が処理可能な範囲を越えて短いイテレーションを試し、実行することは現実的ではありません。処理範囲を越えた短いイテレーションを実行しても、それほど迅速に成果をあげることは不可能 -- すなわち、組織は成果を吸収できませんから、それを「イテレーション」と呼ぶことは実はできないのです。この先に進むためには、組織の制約に対処する必要があります。組織の一時的な制約が原因で、短いイテレーションが不可能になるとは見なしておらず、もしその制約を本当に一時的にしたければ、一時的にできるのです。簡単ですか？　誰も簡単とは言っていません。でも、組織的な変更が簡単にできてしまったならば、それほどおもしろくないでしょう？

InfoQの関連コンテンツ：Extremely Short Iterations as a Catalyst for Effective Prioritization of Work（仕事を効果的に優先順位付けする促進剤としての、極度に短いイテレーション）(参考記事・英語)

著者について

1977年以来ITの専門家として活動しているDave Nicolette氏(リンク)は2002年にアジャイルを発見し、伝統的なITに特有の問題の数々をアジャイルが解決もしくは軽減していることに気づきました。それ以来、アジャイルとリーンな考え方および実践に向けた変化を推進する熱心な専門家として、また情熱的な提案者として、Nicolette氏は活動しています。仲間のIT専門家と経験や効果的な実践を共有することを楽しみ、アジャイルコミュニティに積極的に参加しています。現在は米国のValtech Technologies社でアジャイルチームを指導しています。

 

 

 

原文はこちらです：http://www.infoq.com/articles/short-iterations-argument
（このArticleは2008年10月31日に原文が掲載されました）

• 次へ >