需求的溝通

開發方與業務方之間最常見的溝通是關於需求的。業務方描述他們認為自己需要的東西，程式設計師按照自己理解的業務方表達的需求來開發。

在現實裡，關於需求的溝通是極其困難的，其中會出現各種問題。

過早精細化

    做業務的人和寫程式的人都容易陷入一個陷阱，即過早進行精細化。

    1、不確定原則

        每次向業務方展示一項功能，他們就獲得了比之前更多的資訊，這些新資訊反過來又會影響他們對整個系統的看法，這種現象也叫觀察者效應。

    2、預估焦慮

        開發人員會掉進精確化的陷阱。他們知道必須評估整個系統，而且通常認為需要精確評估。

        評估可以而且必須基於不那麼精確的需求，這些評估只是評估而已。開發人員通常會在評估中使用誤差棒，這樣業務方就能理解不確定性。

遲來的模糊性

    避免過早精細化的辦法是儘可能地推遲精細化。但是，這可能造成另一個問題：遲來的模糊性。

    在具體的語境中看來，意思可能是非常清楚的，但是對閱讀文件的程式設計師來說，意思可能截然不同。

驗收測試

業務方與開發方合作編寫的測試，其目的在於確定需求已經完成。

“完成”的定義

    完成意味著所有的程式碼都寫完了，所有的測試都通過了，QA和需求方已經認可。這才是完成。

溝通

    驗收測試的目的是溝通、澄清、精確化。

自動化

    驗收測試都應當自動進行。原因很簡單：要考慮成本。

額外工作

    驗收測試是為了確定系統的各項指標符合要求。確定系統的指標；程式設計師才能確知“完成”；業務方才能確認開發的系統確定滿足了需求；做到自動化測試。

驗收測試什麼時候寫，由誰來寫

    在理想狀態下，業務方和QA會協作編寫驗收測試，程式設計師來檢查測試之間是否有衝突或矛盾。

    但實際上，業務方通常沒有時間，或者有時間也難以達到所需要的細緻程式，所以他們通常會把測試交給業務分析員、QA甚至是開發人員。

    業務分析員測試“正確路徑”，以證明功能的業務價值。

    QA測試“錯誤路徑”、邊界條件、異常、例外情況，因為QA的職責是考慮哪些部分可能出問題。

開發人員的角色

    實現某項功能的程式碼，應該在對應的驗收測試完成後開始。

測試的協商與被動推進

    專業開發人員，與編寫測試的人協商並改進測試是你的職責。每個人都需要關心錯誤和疏忽，並協力改正。

驗收測試和單元測試

    單元測試是程式設計師寫給程式設計師的，是正式的設計文件，描述了底層結構及程式碼的行為。關心單元測試結果的是程式設計師而不是業務人員。

    驗收測試是業務方寫給業務方的（可能會由開發者來寫），是正式的需求文件，描述了業務方認為系統應該如何執行。關心驗收測試結果的是業務方和程式設計師。

圖形介面及其他複雜因素

    測試系統功能時，應當呼叫真實的API， 而不是GUI。

持續整合

    務必確保在持續整合系統中，單元測試和驗收測試每天都能執行好幾次。

    在持續整合系統裡，失敗的整合應該視為緊急情況，也就是“立刻中止”型事件。