前言
實例化需求被認為是構(gòu)建正確軟件的優(yōu)秀實踐之一，越來越多的開發(fā)團隊開始使用這種工作方法，本文將為大家分享一個真實團隊的實例化需求實踐過程。
實例化需求這個概念來自于一本書《實例化需求：團隊如何交付正確的軟件》（Specification by Example: How Successful Teams Deliver the Right Software）。
書的作者叫Gojko Adzic，是一名英國的戰(zhàn)略軟件交付顧問。在近十幾年來，一直在各種行業(yè)領(lǐng)域（例如財務(wù)和能源交易平臺、移動定位、電子商務(wù)、在線游戲、復雜配置管理系統(tǒng)等等）從事著程序員、架構(gòu)師、技術(shù)指導和顧問等工作。
實例化需求就是Gojko在這十多年的軟件生涯中總結(jié)出來的一套行之有效方法。官方對于它的介紹是這樣的：實例化需求是一組方法，它以一種對開發(fā)開發(fā)團隊有所幫助的方式（理想情況下表現(xiàn)為可執(zhí)行的測試）描述計算機系統(tǒng)的功能和行為，讓不懂技術(shù)的利益相關(guān)者也可以理解，即使客戶的需求在不化，它也具有很好的可維護性，可以保持需求的相關(guān)性。從而幫助團隊構(gòu)建正確的軟件產(chǎn)品。
在我看來，這就是這套方法最牛的地方——幫助團隊構(gòu)建正確的軟件產(chǎn)品。正確這個詞，說起來簡簡單單，但實現(xiàn)起來卻真的很難。
我們?yōu)槭裁词褂脤嵗枨?/span>
我們都明白，需求是一切軟件開發(fā)的源頭。有了需求，開發(fā)才能開始。但實際情況往往是，當項目發(fā)生延期，或是項目測試投產(chǎn)出了問題的時候，第一個被揪出來當替罪羊的也往往是——需求不明確！
咦，需求不是應該在開發(fā)之前就已經(jīng)搞明白了嗎？怎么還會不明確？造成這個問題的無非下面幾種情況：
真的沒好好搞懂需求就開始了。在需求討論中，很常見的一種情況就是，剛開始說的是要做什么，為什么要做，講著講著，大家的探討焦點就變成了怎么做，如何實現(xiàn)，然后迫不及待地投入到軟件開發(fā)之中。很多團隊都會有這樣的誤解：只有開始寫代碼才是真正的干活。
項目干系人并沒有對需求有著一致的理解。常規(guī)的需求通常是用自然語言編寫而成的文檔，自然語言本身就會存在著一千個人有一千個漢姆雷特這樣的理解偏差。如果團隊使用的是需求-開發(fā)-測試這樣的軟件開發(fā)流程，需求在產(chǎn)生階段并沒有整個團隊的介入，僅由需求人員負責，在開發(fā)之初才移交給開發(fā)團隊，即使需求人員和開發(fā)人員有理解偏差也很難在第一時間發(fā)現(xiàn)。
不是我不明白，是這世界變化快?；ヂ?lián)網(wǎng)時代，軟件致勝只有一個法寶——快。很多人慨嘆，現(xiàn)在的時代過于浮躁，精雕細琢的東西不復存在。而事實是，整個IT界的業(yè)態(tài)變化得如此之快，如果你再按照從前的項目節(jié)奏走下去，當你的產(chǎn)品交付之時，也將是被淘汰之時。如今，大多相互的項目周期是按月來衡量的，項目階段則是以周甚至是天來計數(shù)的。所以，如果團隊期待的是一份大而全，且永不變更的需求文檔，并以此為依據(jù)進行開發(fā)，那項目延期或者出問題簡直是必然的情況。
過于依賴個人的認知結(jié)構(gòu)。需求從哪里來？有的團隊的做法是把用戶提出的需求當做用戶故事的源頭，竭盡全力去實現(xiàn)。但是用戶不了解你的系統(tǒng)，所以他所說的有可能超過了系統(tǒng)的范疇。再加上用戶也許并不真的像他以為的那么了解自己，往往把真實的需要隱藏在一個他自以為的解決方案中提出。如果真的照他說的做，那就慘了，只有在交付的時候才能聽到他說——這不是我想要的。另一種做法是由產(chǎn)品人員把用戶的需求翻譯過來。但是在翻譯的過程中只有產(chǎn)品人員孤軍奮戰(zhàn)。而每個人總有每個人思維的局限性，一定會有想不到的地方。
讓我們來看看實例化需求可以做什么吧。
實例化需求的核心是：讓項目的所有干系方進行有效的協(xié)作和溝通，用實例的方式說明需求，用自動化測試的方式頻繁地驗證需求，從實例化的需求說明和自動化測試用例中演進出一套“活文檔系統(tǒng)”。這套“活文檔系統(tǒng)”既可以有效地對系統(tǒng)進行說明，又可以當做交付驗收的標準。
有效的交流溝通確保有足夠的時間澄清需求。
使用舉例的方法澄清需求能在第一時間識別出需求是否足以支撐開發(fā)。
所有的干系方參與需求討論，可以確保大家對于交付哪些東西有一致的理解。
具有不同領(lǐng)域背景的干系方一同參加需求討論，可以規(guī)避因個人認知局限帶來的需求問題。
“活文檔系統(tǒng)”對于變更有著先天優(yōu)勢，可以以最少的維護成本維持文檔的相關(guān)性和可靠性。又能避免過度說明需求而產(chǎn)生浪費，避免花時間在開發(fā)前有可能發(fā)生變化的細節(jié)上，對于變更天然友好。
采用自動化測試的方法實現(xiàn)業(yè)務(wù)實例，代碼開發(fā)出來即可以驗證，無須經(jīng)過冗長的手動回歸測試，降低返工。
完美解決上述問題。
實例化需求怎么做
在《實例化需求》一書中，Gojko提出了實例化需求的主要過程模式，包含以下幾個環(huán)節(jié)：
從目標中獲取范圍：與客戶溝通協(xié)作，以用戶的業(yè)務(wù)目標為起始，通過協(xié)作節(jié)點可以實現(xiàn)目標的范圍。需要注意的是：1）要一直牢記商業(yè)價值，為什么要做。很多時候執(zhí)行項目時太關(guān)注怎么做了。2）不要把用戶自以為的解決方案當做系統(tǒng)需求。
從協(xié)作中制訂需求說明：協(xié)作是關(guān)鍵詞。目的是讓需求、設(shè)計、開發(fā)以及測試都參與進來，發(fā)揮整個團隊的知識和經(jīng)驗，力求讓項目的干系人都更多的參與到交付過程中。排除理解的不一致性，盡量減少個人認知造成的局限性。一定要在團隊著手開始項目之前再進行實例化需求的工作，否則太早進行有可能導致遺忘，或者是遇到需求變更使之前的工作沒有價值。
舉例說明：舉例說明其實是項目需求交流過程中不可或缺的，團隊中的成員業(yè)務(wù)背景不同，對同一事物的理解也不同，通過舉例說明的方式可以讓目標更一致。
提煉需求說明：協(xié)作過程中的開發(fā)討論可以建立大家對相關(guān)領(lǐng)域的共識，但得到的實例往往包含很多不必要的細節(jié)。而關(guān)鍵實例是從這些實例中提煉出來的，雖然精簡但足以說明業(yè)務(wù)流程的實例。并且這些提煉好的實例本身就可以當作交付的驗收條件。
在不修改需求的前提下，用自動化測試來驗證需求。需要根據(jù)需求實例生成自動化的測試用例和代碼。生成的自動化測試用例可以用來驗證程序是否符合需求。由此產(chǎn)生的自動化測試用例可以準確地描述系統(tǒng)是做什么的，由于和需求實例同步，因此也是最新的，所以它是提取“活文檔”的可靠來源。
重構(gòu)需求的同時，頻繁驗證：頻繁驗證的重要性不用多說，在任何一種軟件開發(fā)方法論，例如敏捷、BDD中它都被反復提及。頻繁驗證一定是所有過程實施中需要不斷進行的工作。有很多種方法可以用來實施頻繁驗證，例如持續(xù)集成等等。
利用工具，提取組織良好的、易于尋找的、前后一致的活文檔：使用工具，可以從自動化測試用例中提取出一份活文檔，這樣的文檔是最新的，最能描述系統(tǒng)行為的。通常來說，需求實例說明和自動化測試用例做好了，從中提取出一份好文檔也是水到渠成的事情。
原書中的流程圖是這樣的：
翻譯成中文是醬紫的：
我們?nèi)绾螌嵺`實例化需求
1、從目標中獲取范圍：
當咨詢老師詢問我們的業(yè)務(wù)目標時，我們先給老師介紹了某個完整的業(yè)務(wù)流程。于是老師問道，你們的目標就是實現(xiàn)這個購買的功能嗎？但是，隨著討論的深入，我們意識到，對于我們來說，業(yè)務(wù)目標并不是這個，而是——實現(xiàn)系統(tǒng)的透明轉(zhuǎn)移！這意味著我們要保證整個遺留系統(tǒng)在用戶眼中的樣子和現(xiàn)有系統(tǒng)不能有區(qū)別。而現(xiàn)有系統(tǒng)的文檔不完備，而且，即使有文檔，也未必表示現(xiàn)有系統(tǒng)和文檔完全一致。這就更需要我們使用實例化的方法來進一步探討需求。
2、從協(xié)作中制訂需求：
第一次討論是產(chǎn)品經(jīng)理、開發(fā)經(jīng)理、測試經(jīng)理、咨詢團隊共同進行的。后來我們又經(jīng)過了一次討論，包含了整個開發(fā)團隊。不同視角的人員的參與能保證需求考慮的全面性，以及建立起一套統(tǒng)一的描述語言，從而在第一時間消除理解偏差。事實上，我們在討論中，建立起來了本項目的領(lǐng)域模型，而此后的討論也一直確保探討的各個名詞或術(shù)語的范圍都在領(lǐng)域模型之中。
從哪里梳理領(lǐng)域模型中的詞匯呢？一切都從系統(tǒng)的工作流開始。從工作流中，我們可以識別出基礎(chǔ)場景、異常場景，還可以從系統(tǒng)交互的接口中識別出校驗的各種情況。這里有一點需要注意的，就是不僅要畫出系統(tǒng)之間的調(diào)用流程，并且需要明確出系統(tǒng)之間傳遞的數(shù)據(jù)有哪些。識別得越明確，對于后面的舉例工作越有幫助。
3、舉例說明：
將工作流中識別出來的種種情況，用具體的例子來說明。例子應該包含前置條件、輸入、輸出。前置條件指的是場景發(fā)生時，未作為輸入傳遞到本系統(tǒng)中，但是已經(jīng)存在，且對業(yè)務(wù)產(chǎn)生影響的數(shù)據(jù)。當大家用說的方式解釋不清的時候，舉例子是自然而然的選擇。事實上，即使你覺得能說清楚，也應該舉例，以免大家的理解有誤差。甚至在場景特別復雜的情況下，我們會使用流程圖來輔助舉例。
4、提煉需求說明：
將例子整理成更加精煉和清晰的表格。
5、在不修改需求的前提下，使用自動化測試驗證需求：
這一步由咨詢團隊指導我們使用Cucumber工具根據(jù)業(yè)務(wù)規(guī)則實現(xiàn)自動化測試用例。
6、重構(gòu)需求的同時，頻繁驗證：
通過持續(xù)集成和自動化測試的方式頻繁驗證代碼的實現(xiàn)是否符合業(yè)務(wù)規(guī)則。
7、利用工具，提取組織良好的、易于尋找的、前后一致的活文檔：
文檔一定是在每個迭代之前，針對這個迭代要做的價值點，整個團隊進行了需求澄清之后，再形成的。這樣可以保證這個文檔在這個迭代的進行中是權(quán)威的，有效的。當價值點做完了之后，再做新的價值點的時候，整個團隊再對需求進行澄清，再對已澄清的需求進行描述。這樣形成的文檔是可以自我生長，自我描述的，不斷更新，易于維護的。目前我們生成的文檔是這樣子的，包含了當前迭代中需要的工作流、業(yè)務(wù)規(guī)則和實例化說明。
實際上，這離作者所說的“活文檔系統(tǒng)”還是有一定的距離?；钗臋n還有一個更加重要的部分，就是根據(jù)業(yè)務(wù)規(guī)則實例形成的自動化測試用例。當規(guī)則實例不斷更新和增長時，自動化測試的用例和代碼也不斷更新和增長，永遠都是最新的，最能描述系統(tǒng)行為的，一目了然的。而自動化測試的用例和代碼通過BDD的一些工具能自動提取為html文件或者pdf文件，形成一份真正的“文檔”，這也就是作者書中描述的“活文檔系統(tǒng)”。這個也是我們未來要著重進行的部分。
(本文于2017-07-07首次發(fā)布)
