【敏捷項目沒(méi)有需求分析嗎?】
在很多人的印象中，敏捷軟件開(kāi)發(fā)是種類(lèi)似黑客行為的過(guò)程，是程序員最?lèi)?ài)的勾當。不寫(xiě)文檔，不作需求分析，沒(méi)有項目經(jīng)理，做什么東西完全是程序員自己的行為。所以他們認為這樣的過(guò)程無(wú)法滿(mǎn)足真正大型項目和復雜項目的需要，因此在經(jīng)過(guò)考慮后，放棄了敏捷方法。 項目經(jīng)理圈子真的是這樣嗎?敏捷過(guò)程到底是如何做需求分析?用戶(hù)故事和用例有什么區別?敏捷過(guò)程如何去管理需求的?這些是一些想要實(shí)踐敏捷的人一直在困惑的事情。
我們常�？吹綍�(shū)中講，程序員拿到一個(gè)用戶(hù)故事后，怎么計劃，怎么分解，怎么寫(xiě)單元測試，怎么小步前進(jìn)，怎么持續集成。這是典型的程序員視角。事實(shí)上，敏捷方法分為三部分，敏捷項目管理，敏捷需求分析，敏捷軟件開(kāi)發(fā)。上述書(shū)中提到的完全是敏捷開(kāi)發(fā)中的實(shí)踐，很多人了解到的敏捷，只是敏捷的三分之一。
【敏捷項目中誰(shuí)來(lái)做需求分析?】
在敏捷的團隊中，作一個(gè)敏捷程序員確實(shí)是非常舒服的事情。從程序員的角度來(lái)看，只需要選擇一張他感興趣的故事卡片，了解清楚該卡片的需求，開(kāi)始從功能測試寫(xiě)代碼，等通過(guò)了所有測試就完工�；旧喜恍枰紤]太多的事情，非常輕松愉快。但程序員向誰(shuí)去問(wèn)清楚需求?故事卡片是怎樣寫(xiě)出來(lái)的呢?讓我們來(lái)關(guān)注開(kāi)發(fā)前發(fā)生的事情。
了解敏捷過(guò)程的人都知道，Kent Beck在XP過(guò)程中提到了現場(chǎng)客戶(hù)，如果一個(gè)敏捷團隊能夠有現場(chǎng)客戶(hù)，這當然是最棒的事情。但多數情況下，客戶(hù)都是很忙碌的，很難全力投入到軟件開(kāi)發(fā)過(guò)程中。這時(shí)候，我們就需要商務(wù)分析師這個(gè)角色，來(lái)充當客戶(hù)的角色。
我在公司的團隊中曾擔任的就是商務(wù)分析師這個(gè)角色。商務(wù)分析師最重要的職責就是與客戶(hù)交談，了解和分析需求，將其制作成用戶(hù)故事并將需求轉述給程序員。同時(shí)，商務(wù)分析師也要代替客戶(hù)負責功能驗收測試。
【敏捷項目中如何進(jìn)行需求分析?】
敏捷思想的核心是人與交流。需求問(wèn)題實(shí)際上是一個(gè)交流問(wèn)題。商務(wù)分析師要和客戶(hù)交流，搞清楚客戶(hù)到底需要什么，到底為什么需要這些東西。商業(yè)價(jià)值是商務(wù)分析師關(guān)注的最終目標。有了目標的指向，就可以不迷失方向。和客戶(hù)進(jìn)行交流，最終目的就是挖掘出客戶(hù)的商業(yè)目標�？赡艽蠹視�(huì )經(jīng)常有這樣的經(jīng)驗，客戶(hù)說(shuō)，我要這個(gè)功能，我想要怎么怎么樣。這時(shí)候要特別注意，他說(shuō)的這些東西并不是真正的需求。商務(wù)分析師需要詳細的問(wèn)客戶(hù)為什么，挖掘出他真正的目標。
在這個(gè)目標下，商務(wù)分析師開(kāi)始進(jìn)行需求的分析：我們到底是否真的需要這個(gè)需求?有沒(méi)有更好的解決方案?有沒(méi)有簡(jiǎn)單并且低廉的方式?換一種形式是不是也能達到這樣的需求?這個(gè)需求有多少地方涉及到以前的軟件變更?
搞清楚這些事情后，就可以寫(xiě)出用戶(hù)故事。用戶(hù)故事的書(shū)寫(xiě)遵循一定的原則，一般包括三部分："作為(系統的一個(gè)涉眾)，我想要(做一件事)，從而(達到一個(gè)商業(yè)價(jià)值)"。在書(shū)寫(xiě)的時(shí)候格式比較隨意，可以在故事卡背面寫(xiě)上注釋或疑問(wèn)，甚至畫(huà)上界面原形圖。
舉一個(gè)最常見(jiàn)的用戶(hù)故事例子，“作為一個(gè)普通用戶(hù)，我希望能夠用用戶(hù)名和密碼登錄，以便我能享受到個(gè)性化的服務(wù)”。其中，用戶(hù)是系統涉眾，登錄是他想要做的事情，而他的目標是獲得個(gè)性化的服務(wù)。
從這個(gè)例子我們可以想象到，這個(gè)頁(yè)面可能存在兩個(gè)文本框，用于輸入用戶(hù)名和密碼，有一個(gè)按鈕來(lái)登錄，并且不登錄就不能看到個(gè)人資料，另外，如果用戶(hù)輸入錯誤需要提示“登錄失敗請重試”。這就是可見(jiàn)性，也可以稱(chēng)為可測試性。我們可以根據這樣的可見(jiàn)性寫(xiě)出功能測試，從而驅動(dòng)這個(gè)用戶(hù)故事的開(kāi)發(fā)，這被稱(chēng)為 Acceptance Driven Development。
用戶(hù)故事的作用有兩個(gè)，一個(gè)是作為進(jìn)度跟蹤的依據，一個(gè)是作為與人交談的備忘錄。用戶(hù)故事卡片并不是很精確的需求，因此不需要把事情描述的非常清楚。將需求的詳細分析推遲到實(shí)現前夕來(lái)完成，這是敏捷需求分析的精華所在。任何提前做好的東西都會(huì )導致浪費，敏捷過(guò)程提倡足夠就好，避免浪費。
不少人對用戶(hù)故事和用例的區別感到疑惑。用戶(hù)故事的作用是備忘功能，而不是文檔。而用例需要詳細的描述其操作步驟，以及每個(gè)異常路徑，因而起到了文檔的作用。用戶(hù)故事是可見(jiàn)的商業(yè)價(jià)值，而不是功能描述。每個(gè)用戶(hù)故事的粒度和工作量都相差不多，這和用例有很大的區別。用戶(hù)故事是小粒度的，可測試的，可見(jiàn)的，并且是有價(jià)值的。
【敏捷項目需求分析案例】
公司有個(gè)項目組作的是一個(gè)網(wǎng)游物品交易平臺。該平臺是典型的互聯(lián)網(wǎng)項目，在開(kāi)工的時(shí)候客戶(hù)對功能需求還不明確，但需要快速推出搶占市場(chǎng)，正是最適合敏捷過(guò)程的項目。
在項目伊始，商務(wù)分析師和客戶(hù)做了深入的談話(huà)，了解他的商業(yè)構想，他的盈利模式，搞清楚宏觀(guān)的結構，然后思考并整理獲得的結果，花1-2天時(shí)間將客戶(hù)需求大略整理為幾十個(gè)用戶(hù)故事。這些用戶(hù)故事并不完善，不足以做好整個(gè)系統。但對于我們開(kāi)始項目的前一陣，已經(jīng)足夠了。我們可以從這里開(kāi)始項目。敏捷方法希望快速交付可用的軟件。實(shí)現軟件的快速交付是通過(guò)迭代來(lái)完成。在迭代開(kāi)始前，由一組有經(jīng)驗的開(kāi)發(fā)人員大致評估一下用戶(hù)故事，標記出不同的難度和風(fēng)險，并提出問(wèn)題供商務(wù)分析師來(lái)獲得更詳細的信息，商務(wù)分析師會(huì )和相關(guān)涉眾去討論。然后商務(wù)分析師將推薦優(yōu)先級最高的一組用戶(hù)故事給客戶(hù)來(lái)挑選，客戶(hù)可以選擇這些用戶(hù)故事，或者指出從他的視角看到的優(yōu)先級更高的用戶(hù)故事。這些將成為下一個(gè)迭代的內容。 項目經(jīng)理圈子客戶(hù)看到每個(gè)迭代交付的可運行的軟件后或者得到用戶(hù)反饋后，常常會(huì )有新的想法冒出來(lái)。有些想法是好的，有些想法就屬于看到別家網(wǎng)站有這個(gè)功能，不假思索的提出的功能。這些不同的需求都需要經(jīng)過(guò)認真的分析，找出哪些是值得我們立即考慮的，哪些是不用急迫的去實(shí)現的。
有一次和客戶(hù)談話(huà)時(shí)，他說(shuō)到希望增加拍賣(mài)功能。那么，我們?yōu)槭裁葱枰馁u(mài)呢?客戶(hù)說(shuō)希望讓用戶(hù)拍賣(mài)物品以獲得最高價(jià)格。經(jīng)過(guò)考慮，我們發(fā)現網(wǎng)游物品的實(shí)時(shí)性和唯一性決定了系統不適合使用拍賣(mài)機制。拍賣(mài)的時(shí)效性無(wú)法滿(mǎn)足實(shí)時(shí)交易的要求，因此，用戶(hù)最終放棄了這個(gè)特性。
另一次，客服人員提出增加一個(gè)查詢(xún)用戶(hù)交易的功能，而此時(shí)我們有其他更加重要的功能需要先去考慮，查詢(xún)用戶(hù)交易功能可以由技術(shù)人員臨時(shí)通過(guò)數據庫直接代為查詢(xún)，因為項目運營(yíng)初期交易不是很多，暫時(shí)還不需要專(zhuān)門(mén)的后臺功能來(lái)支持客服的工作。所以把這個(gè)需求卡片一直貼在墻壁上，始終沒(méi)有排到最高的優(yōu)先級。 客戶(hù)一開(kāi)始也不是很能夠接受敏捷需求中強調商業(yè)價(jià)值和優(yōu)先級的做法。但經(jīng)過(guò)幾個(gè)月的磨合，客戶(hù)也逐漸適應了許多敏捷思想，甚至我在和客戶(hù)討論時(shí)，偶然提起了后期的某種可能的情況，他們還能夠幫我糾正應當考慮目前的情況，為近期的情況作計劃。
用戶(hù)故事的跟蹤和管理是由項目經(jīng)理來(lái)進(jìn)行。每個(gè)迭代跟蹤卡片的進(jìn)展，是否已經(jīng)開(kāi)始實(shí)現?是否已經(jīng)完成代碼開(kāi)發(fā)?是否已經(jīng)開(kāi)始功能測試?不同的卡片在迭代前都會(huì )評估為不同的大小。我們一般分為大中小三級。等實(shí)踐過(guò)幾個(gè)迭代后，團隊的開(kāi)發(fā)速度基本保持恒定，我們就可以很容易的知道每個(gè)迭代能做多少個(gè)用戶(hù)故事，這樣就可以安排下一迭代的開(kāi)發(fā)。
每個(gè)迭代內分析好恰好足夠下一個(gè)迭代開(kāi)發(fā)的需求，就是商務(wù)分析師每個(gè)迭代的主要工作內容。商務(wù)分析師的需求分析工作在上一個(gè)迭代完成，包括需求的了解，分析，評估和排列優(yōu)先級。
在每個(gè)迭代開(kāi)始的時(shí)候，由商務(wù)分析師主持召開(kāi)迭代計劃會(huì )議，在會(huì )議上向所有的程序員解釋這個(gè)迭代要完成的用戶(hù)故事，然后由程序員自由提問(wèn)，知道他們能夠獲得足夠開(kāi)始實(shí)現該功能的信息。
在程序員完成一個(gè)用戶(hù)故事后，商務(wù)分析師還要來(lái)代表客戶(hù)做功能驗收測試，查看是否完成了預計的功能，是否有程序員還沒(méi)有想到的異常情況。如果存在問(wèn)題需要退回給程序員繼續完成。這在一定程度上保證了系統完成的需求不偏離客戶(hù)的要求。當然，更多的測試還需要QA來(lái)完成。
我們的實(shí)踐充分表明了，敏捷過(guò)程并不是沒(méi)有需求分析，而是把需求分析過(guò)程分散到整個(gè)開(kāi)發(fā)的過(guò)程中，讓開(kāi)發(fā)和需求分析并行進(jìn)行。這就是公司敏捷方法實(shí)施成功的秘訣之一。而商務(wù)分析師在這個(gè)過(guò)程中，起到了紐帶和橋梁的作用，是一個(gè)團隊不可缺少的角色 。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
