在專案的最開始，你和團隊需要學習需求。光是被告知該做什麼或聽取使用者的意見是不夠的：閱讀 Topic 45，了解如何避免常見的陷阱和錯誤。
傳統智慧和約束管理是 Topic 46 的主題。無論你是在進行需求分析、編碼還是測試，困難的問題都會出現。大多數時候，它們不會像最初看起來那麼難。
當那個不可能的專案來臨時，我們的秘密武器是 Topic 47——一起工作。這裡的「一起工作」不是指分享一份龐大的需求文件，而是在編碼的同時一起解決問題。
即使敏捷宣言以「個人和互動高於流程和工具」開頭，幾乎所有「敏捷」專案都以討論使用哪個流程和工具開始。但無論多麼深思熟慮，沒有方法能取代思考。你真正需要的是 Topic 48，敏捷的本質。
本章概覽#
| Topic | 說明 |
|---|---|
| Topic 45 - 需求坑 | 需求很少浮在表面，它們深埋在假設和誤解之下。程式設計師的工作是幫助人們理解他們想要什麼 |
| Topic 46 - 解開不可能的謎題 | 面對看似不可能的問題時，識別真正的約束條件，找到自由度所在 |
| Topic 47 - 一起工作 | 與使用者和同事緊密合作，在編碼的同時一起解決問題，而非隔著文件交流 |
| Topic 48 - 敏捷的本質 | 敏捷不是名詞而是形容詞，它是一種回應變化和回饋的風格，而非固定的流程 |
核心觀點： 在專案啟動前把這些關鍵議題釐清，你就能更好地避免「分析癱瘓」，真正開始並完成你的專案。