要件は変わります — 市場が変わり、ユーザーから学び、優先順位が動きます。目標は変更を防ぐこと（それは不可能であり望ましくありません）ではなく、プロジェクトを脱線させるのではなく、製品を改善するように意図的に対処することです。
✓ EXPECT change → build flexibility into plans (don't over-commit far ahead)
✓ ASSESS each change → impact on scope, timeline, cost, other work
✓ Make the TRADE-OFF visible → "yes, but it costs X or pushes Y"
✓ Let the stakeholder DECIDE with full information
✓ COMMUNICATE the new plan to everyone affected
重要な規律はスコープ管理と同じです：変更を静かに吸収してはいけません。すべての変更は、誰かが所有する意識的なトレードオフです。
Agileは変わる要件のために構築されています：短いイテレーションは頻繁に優先順位を変え直すことを意味し、変更は年間計画を妨害する代わりに最大でも1スプリント待つだけです。小さなインクリメントで作業することで、単一の変更が引き起こすことができるリワークの量を制限します。
HEALTHY change → new learning, better understanding of the problem
UNHEALTHY churn → indecision, unclear goals, no one owning priorities
要件が常に変わる場合、実際の問題は上流にあります — 目標が曖昧か優先順位付けが弱い — そしてそれが修正するべきことです。
スプリント途中に、ユーザー調査により計画されたフローは人々を混乱させることが明らかになります。先に進む代わりに、次を評価します：それを再編成するのに3日かかり、より優先度の低いアイテムを延期します。そのトレードオフを提示し、PMが同意して調整します — 製品を良くした変更、混乱なく処理されました。
すべての変更を厳密に拒否する（間違っていることを知っているものを出荷する）か、影響評価なしですべての変更を受け入れる（慢性的なズレとバーンアウト）。
適応能力は強みです — 変わることができないソフトウェアは、ゆっくりと時代遅れになっていくソフトウェアです。
変更を上手く処理すること（評価し、トレードオフを目に見えるようにし、コミュニケーションを取り、インクリメントで作業する）により、配信のコントロールを失うことなく現実に反応し続けることができます。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する