開發方與業務方之間最常見的溝通是關於需求的。業務方描述他們認為自己需要的東西，程式設計師按照自己理解的業務方表達的需求來開發。
在現實裡，關於需求的溝通是極其困難的，其中會出現各種問題。
過早精細化
做業務的人和寫程式的人都容易陷入乙個陷阱，即過早進行精細化。
1、不確定原則
每次向業務方展示一項功能，他們就獲得了比之前更多的資訊，這些新資訊反過來又會影響他們對整個系統的看法，這種現象也叫觀察者效應。
2、預估焦慮
開發人員會掉進精確化的陷阱。他們知道必須評估整個系統，而且通常認為需要精確評估。
評估可以而且必須基於不那麼精確的需求，這些評估只是評估而已。開發人員通常會在評估中使用誤差棒，這樣業務方就能理解不確定性。
遲來的模糊性
避免過早精細化的辦法是盡可能地推遲精細化。但是，這可能造成另乙個問題：遲來的模糊性。
在具體的語境中看來，意思可能是非常清楚的，但是對閱讀文件的程式設計師來說，意思可能截然不同。
業務方與開發方合作編寫的測試，其目的在於確定需求已經完成。
「完成」的定義
完成意味著所有的**都寫完了，所有的測試都通過了，qa和需求方已經認可。這才是完成。
溝通
驗收測試的目的是溝通、澄清、精確化。
自動化
驗收測試都應當自動進行。原因很簡單：要考慮成本。
額外工作
驗收測試是為了確定系統的各項指標符合要求。確定系統的指標；程式設計師才能確知「完成」；業務方才能確認開發的系統確定滿足了需求；做到自動化測試。
驗收測試什麼時候寫，由誰來寫
在理想狀態下，業務方和qa會協作編寫驗收測試，程式設計師來檢查測試之間是否有衝突或矛盾。
但實際上，業務方通常沒有時間，或者有時間也難以達到所需要的細緻程式，所以他們通常會把測試交給業務分析員、qa甚至是開發人員。
業務分析員測試「正確路徑」，以證明功能的業務價值。
qa測試「錯誤路徑」、邊界條件、異常、例外情況，因為qa的職責是考慮哪些部分可能出問題。
開發人員的角色
實現某項功能的**，應該在對應的驗收測試完成後開始。
測試的協商與被動推進
專業開發人員，與編寫測試的人協商並改進測試是你的職責。每個人都需要關心錯誤和疏忽，並協力改正。
驗收測試和單元測試
單元測試是程式設計師寫給程式設計師的，是正式的設計文件，描述了底層結構及**的行為。關心單元測試結果的是程式設計師而不是業務人員。
驗收測試是業務方寫給業務方的（可能會由開發者來寫），是正式的需求文件，描述了業務方認為系統應該如何執行。關心驗收測試結果的是業務方和程式設計師。
圖形介面及其他複雜因素
測試系統功能時，應當呼叫真實的api， 而不是gui。
持續整合
務必確保在持續整合系統中，單元測試和驗收測試每天都能執行好幾次。
在持續整合系統裡，失敗的整合應該視為緊急情況，也就是「立刻中止」型事件。
程式設計師職業素養 讀書筆記
專業主義不但象徵著榮耀與驕傲，而且明確意味著責任與義務。這兩者密切相關，因為你無法負責的事情上不可能獲得榮耀與驕傲。1.3 首先，不行損害之事 不要破壞軟體功能。每人能寫出完美的軟體，但這並不表示你不用對不完美負責。失誤率永遠不可能等於零，但你有責任讓它無限接近零。每次qa找出問題時，更糟糕的是使用...
程式設計師的職業素養 讀書筆記 第10章 預估
不同的人對預估有不同的看法。業務方覺得預估就是承諾。開發方認為預估就是猜測。承諾 承諾是必須做到的。專業開發人員不隨便承諾，除非他們確切知道可以完成。如果被要求承諾做自己不確定的事情，那麼就應當堅決拒絕。預估 預估是一種猜測。它不包含任何承諾的色彩。大多數軟體開發人員都很不擅長預估。原因在於我們並不...
《程式設計師的職業素養》讀書筆記
程式設計師的職業素養 是robert c.martin 大師的經典著作之一，旨在討論如何成為一名專業的軟體開發人士，以及專業的軟體開發人士所需的各種品質。他被人們親切的稱為bob大叔。在讀過之後，我對本書的一些理解，這些理解只是我個人的理解，可能比較片面，也有些理想化，畢竟每個人的理解都不盡相同。專...