《實例化需求-團隊如何交付正確的軟件》全書18章，210頁永脓，共30.7萬字。本書共分為三個部分：開始鞋仍、關(guān)鍵過程模式和案例研究常摧。本次閱讀第一部分開始，從第一章到第四章威创，大概65頁落午。
實例化需求說明是一組過程模式，它幫助團隊構(gòu)建正確的軟件產(chǎn)品肚豺。
1溃斋、實例化需求優(yōu)點
* 更有效地實施變更∥辏【活文檔（living documentation）后續(xù)需重點關(guān)注】
* 更高的產(chǎn)品質(zhì)量梗劫。
* 更少的返工。
* 同一項目不同角色的活動協(xié)調(diào)得更好截碴。
畫重點：
1）正確地構(gòu)建產(chǎn)品和構(gòu)建正確的產(chǎn)品是兩回事梳侨。二者兼顧才能取得成功。
2）實例化需求說明能夠在適當?shù)臅r間提供恰好夠用的文檔隐岛，幫助使用短迭代或基于流的開發(fā)過程構(gòu)建正確的產(chǎn)品猫妙。
3）實例化需求說明有助于提高軟件產(chǎn)品的質(zhì)量，顯著減少返工聚凹，并使得團隊更好地在分析割坠、開發(fā)和測試活動中進行協(xié)作齐帚。
4）從長遠來看，實例化需求說明有助于團隊創(chuàng)建一個活文檔系統(tǒng)彼哼，它是一種具有相關(guān)性的对妄、可靠的功能描述，會隨著程序代碼的變更自動更新敢朱。
5）實例化需求說明的實踐配合短迭代（Scrum剪菱、極限編程）或基于流的開發(fā)方法（看板）一起使用，效果最好拴签。
2孝常、關(guān)鍵過程模式
實例化需求說明是一組過程模式，它可以協(xié)助軟件產(chǎn)品的變更蚓哩，確保正確的產(chǎn)品能夠有效地交付构灸。
劃重點：
- 實例化需求說明的主要過程模式是從目標中獲取范圍、協(xié)作制定需求說明岸梨、舉例說明喜颁、提煉需求說明、自動化驗證時不修改需求說明曹阔、頻繁驗證以及演進出活文檔系統(tǒng)半开。
- 對于實例化需求說明而言，功能需求赃份、需求說明和驗收測試都是一回事寂拆。
- 其結(jié)果是一個活文檔系統(tǒng)，它解釋系統(tǒng)可以做什么抓韩，并且與編程語言代碼一樣確切和可靠漓库，但更容易理解。
- 不同背景的團隊使用不同的實踐來實施過程模式园蝠。
3、活 文 檔
實例化需求說明的過程和工件有兩種流行的模型：以驗收測試為中心的模型和以系統(tǒng)行為規(guī)范為主導的模型:
-?以驗收測試為中心的模型（通常稱為驗收測試驅(qū)動開發(fā)痢士，ATDD或者A-TDD）側(cè)重于自動化測試彪薛，并把它作為實例化需求說明過程的一部分。優(yōu)點：開發(fā)目標更加明確怠蹂，并且可以防止功能退化善延。
-?以系統(tǒng)行為規(guī)范為主導的模型（通常稱為行為驅(qū)動開發(fā)或者BDD）側(cè)重于制定系統(tǒng)行為的場景。它的主要工作是通過協(xié)作和需求澄清城侧，在項目干系人和交付團隊之間建立起共識易遣。該模型認為，通過自動化測試預(yù)防功能退化也很重要嫌佑。
作者認為：盡管回歸測試的確很重要豆茫，但我并不認為這種長期好處是它產(chǎn)生的侨歉。 首先，實例化需求說明并不是唯一可以防止功能退化的方法揩魂。 其次幽邓，Capers Jones在EstimatingSoftware Costs一書中指出，通過回歸測試移除缺陷的平均效率僅有23%火脉。這無法證明成功的團隊在實現(xiàn)實例化需求說明上作出長期投資是正確的牵舵。
從代碼中挖掘系統(tǒng)功能的過程叫做“系統(tǒng)考古學”【牍遥【我們也是考古系的畸颅！o(*￣︶￣*)o】
改動過時的內(nèi)容不是主要的成本所在，花時間去找出需要改動的地方通常才是成本較高的地方方援。
劃重點：
- 實例化需求說明允許你漸進性地建立起一個良好的文檔系統(tǒng)没炒。
- 活文檔是交付過程的重要工件，與代碼一樣重要肯骇。
- 側(cè)重于建立業(yè)務(wù)流程文檔系統(tǒng)可以幫助你避免長期維護需求說明和測試造成的大部分常見問題窥浪。
4、開始改變
20世紀80年代晚期笛丙，Gerald Weinberg和Donald Gause在《探索需求》一書中談到了軟件需求的溝通問題漾脂。作者認為實例化需求說明既是需求說明又是測試的兩重性。
實例化需求對敏捷來說主要解決的常見問題是返工胚鸯、溝通不暢導致的重復工作骨稿、為了理解系統(tǒng)而回頭閱讀代碼所浪費的時間，以及手工重復執(zhí)行相同測試所消耗的時間姜钳。
我們將探討如何著手改變過程和團隊文化坦冠，以便你去實施實例化需求說明。
4.1 如何開始改變過程
1哥桥、把實施實例化需求說明當作更廣闊的過程變更的一部分（適用于：新項目）
實施Scrum辙浑、XP或任何其他敏捷過程終歸是一種休克療法，因此如果有可能的話拟糕，可以把實施實例化需求說明也納入其中
2判呕、專注于提高質(zhì)量
先找出提高軟件質(zhì)量的最大阻礙，然后解決這個問題
3送滞、從功能測試自動化開始（適用于：應(yīng)用到現(xiàn)有項目）
如果你還沒有實行功能測試自動化侠草，請記住這是一個容易實現(xiàn)的目標，一個開始實施實例化需求說明的簡單方式犁嗅。
想要使用自動化測試完全覆蓋遺留系統(tǒng)是徒勞的边涕。為了從最早實施的功能測試自動化中獲得最大收益，請專注于將系統(tǒng)中存在風險的那部分先自動化掉，這些地方的問題會花費很多財力功蜓。
4园爷、引入一個可執(zhí)行需求說明的工具（適用于：測試人員負責測試自動化時）
使用支持可執(zhí)行需求說明的自動化工具后，開發(fā)人員會更多地參與到測試自動化中霞赫，同時商業(yè)用戶也能夠?qū)y試有更深入的了解腮介。
5、使用測試驅(qū)動開發(fā)作為踏腳石（適用于：開發(fā)人員對TDD有較深認識的時候）
引入實例化需求說明的另一個常見策略端衰，就是從（單元）測試驅(qū)動開發(fā)上入手叠洗，特別是在開發(fā)新項目的時候÷枚可執(zhí)行的需求說明就是針對業(yè)務(wù)功能的測試灭抑。
4.2?如何開始改變團隊文化
1、避免使用“敏捷”術(shù)語（適用于：在一個抵制變化的環(huán)境中工作時）
無需使用技術(shù)術(shù)語就能實施實例化需求說明抵代，這是完全可能的腾节。如果工作環(huán)境抵制變革，那么開始變革時就一定要避免使用術(shù)語荤牍。
2案腺、確保你得到管理層的支持
沒有管理層的認可和支持，過程變更成功的幾率很小康吵。
3劈榨、把實例化需求說明當作是比執(zhí)行驗收測試更好的方式來推銷
我認為，大部分團隊是能夠以避免把驗收測試拖到最后為理由證明實施實例化需求說明的花費是值得的晦嵌。改變過程同辣，讓團隊能更快地完成目標，會帶來可衡量的經(jīng)濟利益惭载，這樣也就可以證明在過程變革中的投資是值得的了旱函。
4、不要讓測試自動化成為最終的目標
團隊只關(guān)注測試自動化時描滔，就不會更好地協(xié)作
5棒妨、不要太關(guān)注工具
實例化需求說明并不以程序員為中心，而程序員獨自使用一個工具不會取得很好的效果含长。
6靶衍、在遷移過程中，遺留腳本也要有人維護（適用于：在遺留系統(tǒng)中引入功能測試自動化時）
通過委派一個專門的人員來更新遺留事項茎芋，團隊就可以更快地朝著遷移到新過程的目標前進。
7蜈出、跟蹤哪些人在運行（以及沒有運行）測試自動檢查程序（適用于：開發(fā)人員都不愿意參與時）
通過監(jiān)視測試是否執(zhí)行田弥，來讓程序員執(zhí)行自動檢查程序。
4.3?團隊如何在流程和迭代中集成協(xié)作
過程變更沒有通用的解決方案铡原，每個團隊都需要決定如何最好地擴展他們交付軟件的方式偷厦。
-通過快速周轉(zhuǎn)來提供快速反饋和重點商叹；高效地完成軟件的一小塊，而不是試圖一次性處理一大塊只泼。
-強調(diào)有效剖笙、高效的溝通，而不是冗長请唱、乏味的文檔弥咪。
-建立共享所有權(quán)，這樣在需求說明變成代碼或測試的過程中十绑，開發(fā)人員與測試人員不會互不通氣聚至。
-整合跨職能團隊，為了制定正確的系統(tǒng)需求本橙，測試人員扳躬、分析師和開發(fā)人員一起進行工作执赡，而非各自為戰(zhàn)鸠澈。
4.4 ?處理簽收和可追溯性
實例化需求說明提供了有關(guān)需求的工件：活文檔∥樟活文檔可用于追溯亏狰，這使得敏捷過程可以應(yīng)用于受管制的行業(yè)役纹。
1、在版本控制系統(tǒng)中保存可執(zhí)行需求說明
我訪問過的一些人說骚揍，把可執(zhí)行需求說明和產(chǎn)品代碼放在同一個版本控制系統(tǒng)中字管，是成功實施過程的最重要的做法之一。
2信不、通過導出的活文檔來簽收（適用于：逐個迭代簽收）
如果需要在實現(xiàn)功能前簽收需求說明嘲叔，并且可以在每個迭代里都這么做，那么你可以根據(jù)下一個迭代所計劃的可執(zhí)行需求文檔創(chuàng)建一個Word或PDF文檔抽活，然后在上面簽收硫戈。
3、簽收的是范圍下硕，而非需求說明(適用于：簽收較長的里程碑)
如果你要簽收的內(nèi)容比一個迭代所能交付的要大丁逝，那就試著對范圍而非對具體的需求說明進行簽收。比方說梭姓，簽收用戶故事或用例霜幼。
4、在“精簡的用例”上簽收
對“更輕量的用例”做簽收誉尖，而無需實例罪既。
5、引入用例實現(xiàn)（適用于：簽收時需要所有的細節(jié)時）
在方法論雷達監(jiān)控之下，添加諸如用例實現(xiàn)的細節(jié)是在正規(guī)過程中引入實例化需求說明的一個不錯的想法琢感。當商業(yè)合同需要對需求進行簽收但還允許之后對細節(jié)進行變更時丢间，這種做法同樣有助于實現(xiàn)實例化需求說明的概念。
4.5警告信號
1驹针、注意頻繁改動的測試
同跟蹤測試用例失敗來統(tǒng)計代碼修改來判斷測試用例的良莠烘挫。
2、當心回退
跟蹤回退也是一個很好的方法柬甥，可以為引入實例化需求說明提供業(yè)務(wù)上的支持饮六。它可以幫助團隊查明由需求模糊以及需求說明里的功能分歧造成的浪費。
3暗甥、注意組織級的失調(diào)
事先分析過頭喜滨、分析不會馬上被實現(xiàn)的東西，或者需要分析細節(jié)時卻滯后了撤防，這些都是過程出現(xiàn)問題的警告信號虽风。
4、當心“以防萬一”的代碼
實例化需求說明可以顯著減少這種問題（開發(fā)人員的以防萬一的過度設(shè)計）寄月，因為它會幫助我們建立共識辜膝，讓我們知道要交付什么。
5漾肮、注意霰彈式修改
這個信號同樣適用于活文檔：如果對生產(chǎn)代碼做了某個改動后厂抖，發(fā)現(xiàn)還需要修改很多可執(zhí)行需求說明，那說明你有地方做得不對克懊。組織好你的活文檔忱辅，這樣對代碼進行一個小改動時，只需要對測試做一個較小的更改即可谭溉。這是降低自動化長期維護成本的一個關(guān)鍵步驟墙懂。
小結(jié)
本書的第一部分開始主要從整體介紹實例化需求的有點；關(guān)鍵過程模式扮念；介紹活文檔损搬；以及如何開始改變。很適合想主動實踐的組織柜与。本書結(jié)合實際的團隊項目實例來介紹各種組織實踐的情況巧勤，具有很好借鑒作用∨埃可以說：我們遇到的問題颅悉，書里都有答案。
