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