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