大規模な反復設計

通常、ゲーム開発では、線形開発（ウォーターフォールモデル）には、プログラマーの正気を失わせる障害があります（ゲームは恐ろしいことが判明し、再設計できません）。反復設計を入力してください。反復設計により、遊び場でのさまざまな可能性のプロトタイピングが可能になります。残念ながら、これには大きな問題があります。プロジェクトのサイズが大きくなるとすぐに、繰り返しは退屈に長くなり、主な利点である迅速な結果が失われます。

大規模プロジェクトの設計反復をどのように短縮できますか？

良いインフラストラクチャがこれを助けることができると思います。1つの例は、エンジニアが新しいデータを簡単に公開でき、設計者がデータをすばやく変更してその結果を確認できる、使いやすい、優れたデータシステムです。もう1つの優れた点は、ゲームプレイのプログラマーやデザイナーでさえも素早くプロトタイプを作成できる、luaなどのスクリプト言語を使用することです。

また、使いやすく、アセットをゲームに簡単に取り込むことができる、優れたアート/アセットパイプラインがあります。

基本的に、仕事をしている人の障害を取り除き、ワークフローを合理化します。

残念ながら、これらの機能の既成のソリューションは実際には存在しません（一般的なゲームエンジンでも、これらはすべて実際に解決された問題ではありません）。つまり、この俊敏性を得るには、エンジニアリング時間を費やす必要があります。だから悲しいことに、答えはあなたがそれを作るために時間を費やす必要があるということです。しかし、時間を費やすと、物事はうまくいきます。将来のプロジェクトで作業を再利用できれば、配当はさらに良くなります。

タイムボックス化は、反復が長くならないことを意味します

反復を短縮する方法を尋ねます。しかし、それは彼らがより多くの時間を費やしていることを意味します、それはあなたがタイムボクシングを適用していないことを意味します。複雑さが重くなり始めた場合（または他の予期しない後退がある場合）の反復では、反復の長さを変更しません。代わりに、イテレーションの開始時に計画した増分加算を無効にします。反復法の中には、反復の途中（手遅れになる前）にこの評価を行うことを提案するものがあります。OpenUPの提案の詳細については、以下をご覧ください。

目標の管理 チームが大幅に遅れている場合、またはチームがイテレーション目標を達成できない重大な問題が発生した場合、最大化しながら、チームがイテレーションの終わりまでに有用な製品の増分を確実に提供できるように作業を分解する必要がある場合があります。利害関係者の価値。チームおよび利害関係者と協力して反復計画を改訂し、必要に応じて、重要度の低いタスクを次の反復に延期することにより、それらの重要性を減らします。まれなケースですが、イテレーションの目標を達成できないと思われる場合、チームはイテレーションを終了するか、イテレーションを新しい目標に再調整することを検討することがあります。

最初のグラフを見ると、後の反復では付加価値が低いことがわかります。つまり、繰り返しは以前と同じくらい長くかかりますが、おそらく、各繰り返し内の（比較的）新しい機能は少なくなります。

あなたが言うように、反復の強みは頻繁にフィードバックを得ることによってリスクを減らすことです。プロジェクトの複雑さが後のイテレーションに後退していることについて話しているように聞こえますか？これが反復の弱点であることには同意しません。これは、管理が複雑であるという弱点です。

理論的には、プロジェクトの最大のリスクを最初に考えます。これは、非常に不安定なプロジェクトがあることを意味しますが、大きなリスクを管理することで、プロジェクトは安定するはずです。もちろん、複雑さはリスクの1つです。

スクリプト言語と自動化されたプロセスは、「偶発的な」複雑性と呼ばれる複雑性のリスクを軽減するのに役立ちます（別の回答で説明されています）。非常に反復的でありながら複雑なプロジェクト（Chromiumはゲームでなくても良い例です）には、複雑さを管理するためのインフラストラクチャがたくさんあります。BuildBotへのコーディングアドバイスのような多くの例については、https：//www.chromium.org/developersをご覧ください。

この図が示していないのは、おそらく次のようなプロジェクトの安定性です。

技術的なリスクが十分に理解されるまで、あなたは単純なプロトタイプを扱っています