《例項化需求》閱讀筆記（1）-畫餅充飢

一個系統開發的成敗，好的需求是必要條件，這一點毋庸置疑。每一個讀到這篇blog的人可以想一想你以前做過的失敗專案或者你以前的痛苦經歷有多少是需求太磕磣造成的？

經過n年的爭鬥，大部分人還是不得不承認，文件是需求最好的載體，我們離不了它。請不要說程式碼是最好的文件，且不說這麼多年了敢拍胸脯說程式碼特別好，特別可讀的專案有幾個？開發的同學起碼不要指望業務人員精通你的編碼，其實也不要指望測試人員，也沒理由指望，因為術業有專攻。（，跟今天白天的口水仗很貼題啊。）

說到文件，每個人都是一把辛酸淚:

程式設計師兼職文件人員：老子還要寫程式碼呢，coding沒做完還得寫破文件！不都在程式碼裡麼？

專職文件人員：這些細節怎麼可能一開始就想得明明白白啊！老子又不是神，要是了還要你們做毛？客戶說不明白，我也不明白，我搞明白了改完文件你都寫完了，賴誰啊！？

程式碼人員：喂喂！這寫的都是蝦米啊，什麼都說不明白，根本看不懂，我就按照我想的來了！什麼？說我實現錯了?老子昨天晚上coding到晚上一點，你TMD怎麼不早說？！

測試人員：需求好爛。。。被測系統也好爛。。。。什麼？改需求？什麼？開發錯了？什麼？Deadline到了？WTF！

專案經理：我要死了。。。。。你們這幫廢物！

面對失敗的專案，大家表面上不說，心裡肯定會有上邊這些吶喊！

但是沒有需求文件又不行，如何能夠有同時滿足下面所有條件的文件呢？

1.保證所有專案干係人和交付團隊的成員都對需求要交付那些東西有一致性的理解。（大家滿意）

2.有準確、完整的需求避免由模稜兩可和功能缺失造成的無謂返工。（開發，測試，專案經理滿意）

3.有用來衡量某項工作是否已經完成的客觀標準。（測試滿意，專案經理滿意）

4.在短時間交付的前提下滿足上述要求。（大家滿意）

5.文件能夠被及時修改，及時使用，易於維護。（大家滿意）

6.文件編寫成本低，其它變更成本低。（大家滿意）

這裡面好多貌似都是矛盾的，比如1和6。文件能同時滿足準確，易維護，隨寫隨用這3個特性麼？《例項化需求》這本書給出了肯定的答案：例項化需求 也就是將需求變為可以執行的驗收測試用例，也就是書裡說的活文件。如果滿足可執行的條件，需求肯定是定義清晰的；跟持續整合聯絡起來後，程式碼實現馬上可以被驗證；如果修改了活文件也就等於同時修改了測試需求與測試用例，程式碼實現沒有及時修改的話，馬上就會以測試失敗的形式報警，這樣一致性可以得到保證。再仔細分析還有好處若干，這簡直是一石n鳥皆大歡喜的革命！ 有這種好事？

書中給出了N個成功案例，並且是指名道姓的，不信你可以google它們甚至人肉出它們的聯絡方式去問問。真是一張讓飢餓的IT人垂涎欲滴的大餅。真的有這麼神奇麼？書已經翻完了一遍，裡面給出了很多實戰的例子，的確相當有啟發，但是很多地方也有很多疑問。今後一定要找機會嘗試一下，不過在此之前還是先再讀兩遍，把裡邊的一些細節吃透再實踐。後續會爭取把一些書裡的關鍵點和我不懂的地方貼出來。希望有興趣的同學一起討論，大牛過來指導一下。昨天跟做諮詢的敏捷教練聊起了這個，我問他國內有成功案例麼？他說聽說過，沒有親眼見過。誰親眼見過，或者實現過，趕緊出來現身說法造福一下大眾啊！誰失敗過也曬曬血淚史或者給這種方法論拍拍磚吧！

爭取能吃吃這張餅，品品什麼味道。