2010-12-31 作者：龔波 來源：過程之魂，優(yōu)化之道
摘 要
小型軟件組織的軟件過程改進(jìn)始終是軟件行業(yè)面臨的一個(gè)挑戰(zhàn)，諸如CMMI等過程改進(jìn)和評(píng)估模型都 是基于大型項(xiàng)目的成功經(jīng)驗(yàn)總結(jié)而來的[1]，對(duì)于我國(guó)占軟件組織總量70%以上的小型組織而言，存在諸多不合適的地方。為了實(shí)現(xiàn)小型組織的有效過程改善， 近年來發(fā)展起來的敏捷開發(fā)方法是一個(gè)很有價(jià)值的途徑，而且更能體現(xiàn)小型組織“小而靈活”的特點(diǎn)。用戶故事是極限編程的重要實(shí)踐之一，體現(xiàn)溝通、反饋、簡(jiǎn)單 等極限編程原則，非常適合于需求易變化的小型組織/小型項(xiàng)目[2]。為全面了解用戶故事的實(shí)施方法和規(guī)程，本文介紹一種用戶故事驅(qū)動(dòng)的軟件開發(fā)模式，使用 用戶故事進(jìn)行軟件需求分析，制定發(fā)布計(jì)劃和迭代計(jì)劃等，實(shí)現(xiàn)軟件項(xiàng)目和過程的可控性。經(jīng)過部分項(xiàng)目的驗(yàn)證，這種方法非常適合10人以下的小型項(xiàng)目團(tuán)隊(duì)。
關(guān)鍵詞 用戶需求 故事 迭代
A User Story Driven Software Development Method
Abstract Software process improvement in small organizations is a challenging task; process improvement and assessment models, such as CMMI and ISO 15504, are best practices of large organizations and projects [1]. In china, 70 percent of software organizations are small organizations; upper models aren’t suitable for small organizations, not reflecting the “small and flexibility” character of small organizations. To support the process improvement in small organizations, Agile development methods are very valuable [2]. User Story is one of the important practices of eXtreme Programming, encouraging communication, reflection and simpleness. To learn the development model of user story, the article introduces a user story-driven software development method oriented to small organizations and projects. The method is valuable for project team less than 10 people proved by some projects.
Key words User Requirement, User Stories, Iteration
現(xiàn)在很多研究機(jī)構(gòu)都在研究如何有效實(shí)現(xiàn)小型組織的過程改進(jìn)問題，有的研究思路是對(duì)已有CMMI或者ISO9001模型進(jìn)行剪裁；有的研究成果則另辟蹊徑，敏捷開發(fā)就是現(xiàn)在一種很流行的方法[3]。極限編程(XP)是Kent Beck在1998年首先提出的，是敏捷方法中最著名的一種方法，它由一系列簡(jiǎn)單卻互相依賴的實(shí)踐組成。用戶故事是XP的核心實(shí)踐之一，用于捕獲和組織需求，摒棄傳統(tǒng)冗長(zhǎng)繁瑣的需求文檔，提供處理需求變更的靈活機(jī)制。
本文簡(jiǎn)要分析用戶故事的特征，討論如何基于用戶故事定義發(fā)布和迭代計(jì)劃，總結(jié)流行的基于用戶故事驅(qū)動(dòng)的軟件開發(fā)方法。這種軟件開發(fā)方法可以有效解決小型組 織過程完善面臨的問題，充分體現(xiàn)小型組織的靈活特征，有效促進(jìn)軟件過程改進(jìn)。
1 用戶故事
用戶故事描述了對(duì)軟件（或系統(tǒng)）用戶或客戶有價(jià)值的功能。用戶故事包括三方面內(nèi)容：書面描述（用于計(jì)劃和備忘），交談（細(xì)化故事細(xì)節(jié)），以及測(cè)試用例（驗(yàn)證故事實(shí)現(xiàn)）。用戶故事描述的傳統(tǒng)形式是手工書寫的用戶故事卡， Ron Jeffries稱如上三方面內(nèi)容為Card(卡片)、Conversation(交談)和Confirmation(確認(rèn))[2]。
開發(fā)者輔助客戶編寫故事，告訴客戶所編寫的故事是進(jìn)一步討論的引子，而不是詳細(xì)的需求規(guī)范。在任何項(xiàng)目中，需要客戶團(tuán)隊(duì)根據(jù)故事的重要性來安排開發(fā)者的工 作，回答所有開發(fā)者的問題，編寫所有的故事?？蛻魣F(tuán)隊(duì)包含多個(gè)成員（諸如測(cè)試人員、產(chǎn)品經(jīng)理、真實(shí)用戶、交互功能設(shè)計(jì)人員），確保軟件滿足目標(biāo)用戶的需 求。
在編寫故事之前應(yīng)該建立用戶角色模型，必須包含對(duì)項(xiàng)目成功至關(guān)重要的角色，盡量保證所有用戶對(duì)系統(tǒng)完全滿意。
1.1 用戶故事的特性
如想創(chuàng)建優(yōu)秀的故事，需要認(rèn)真領(lǐng)會(huì)6個(gè)屬性，分別是：獨(dú)立性、可協(xié)商性、對(duì)用戶或者客戶有價(jià)值、可預(yù)測(cè)性、短小精悍，以及可測(cè)試性。Bill Wake使用縮寫詞INVEST表示6個(gè)屬性。
1）獨(dú)立性。盡可能避免故事之間存在依賴關(guān)系，故事間依賴關(guān)系會(huì)產(chǎn)生優(yōu)先級(jí)和規(guī)劃問題。
2）可協(xié)商性。故事是可協(xié)商的，不是必須實(shí)現(xiàn)的書面合同或者需求。
3）對(duì)用戶或者客戶有價(jià)值。確保每個(gè)故事對(duì)客戶或用戶有價(jià)值的最好方式是讓用戶編寫故事。
4）可預(yù)測(cè)性。開發(fā)者應(yīng)該能夠預(yù)測(cè)（至少大致猜測(cè)）故事的規(guī)模，以及編碼實(shí)現(xiàn)所需要的時(shí)間。
5）短小精悍。故事規(guī)模對(duì)實(shí)現(xiàn)有影響，何種故事規(guī)模最合適，取決于開發(fā)組規(guī)模、開發(fā)組的能力，以及技術(shù)實(shí)現(xiàn)等方面。
6）測(cè)試性。所編寫的故事必須是可測(cè)試的。
1.2 用戶故事與IEEE803、用例和場(chǎng)景的比較
當(dāng)今流行的其他需求獲取和定義方法包括：用例、IEEE830軟件需求規(guī)格說明，以及場(chǎng)景設(shè)計(jì)。下面簡(jiǎn)單說明用戶故事與它們的區(qū)別[6]。
（1）與IEEE803需求規(guī)格說明的區(qū)別。用戶故事與IEEE 830軟件需求規(guī)格說明的最根本差異是：對(duì)于后者，只有編寫完所有需求時(shí)，才能知道每個(gè)需求的成本；對(duì)于用戶故事，每個(gè)故事在定義時(shí)就需要提供成本的估計(jì) 值，客戶知道團(tuán)隊(duì)的速度和每個(gè)故事的點(diǎn)數(shù)。
（2）與用例的區(qū)別。用例最早由Ivar Jacobson在1992年提出，用例通常與統(tǒng)一軟件過程相聯(lián)系。用例描述系統(tǒng)和角色之間的交互。兩者差別主要在于：
1）范圍不同。二者都用來體現(xiàn)商業(yè)價(jià)值，但故事規(guī)?？梢栽O(shè)定比較?。ɡ?，10天完成），以便以此為單位安排工作。用例包含的范圍可能比故事大得多。
2）完成程度不同。James Grenning曾指出：故事卡中的文字“加上驗(yàn)收測(cè)試用例就基本等同于用例”，這意味著故事對(duì)應(yīng)于用例的基本流，而故事的測(cè)試要求對(duì)應(yīng)于用例的備選流。
3）壽命不同。用例通常是持久的工作產(chǎn)品，在產(chǎn)品開發(fā)和維護(hù)時(shí)，用例一直存在。然而，故事通常只存在于實(shí)現(xiàn)該故事的迭代中。雖然故事卡可以存檔，但是許多團(tuán)隊(duì)都將故事卡銷毀。
4）編寫目的不同。用例的目的是記錄客戶和開發(fā)團(tuán)隊(duì)的一致意見。故事是為了便于制定發(fā)布計(jì)劃和迭代計(jì)劃，并作為有關(guān)用戶需求細(xì)節(jié)方面的交談備忘錄。
（3）與場(chǎng)景的區(qū)別。場(chǎng)景不僅指用例的一個(gè)路徑，而且還用于人-機(jī)交互設(shè)計(jì)。交互設(shè)計(jì)中的場(chǎng)景不同于用例中的場(chǎng)景。實(shí)際上，交互設(shè)計(jì)中的場(chǎng)景一般比用例更 大、更廣。Carroll指出場(chǎng)景包含以下特征性：背景場(chǎng)所、演員、目標(biāo)，以及行為和事件。用戶故事和情景的基本區(qū)別是二者的范圍和詳細(xì)程度不同。場(chǎng)景包 含更多的細(xì)節(jié)，而且場(chǎng)景的范圍涵蓋多個(gè)故事。
2 用戶故事驅(qū)動(dòng)的軟件開發(fā)過程
在故事驅(qū)動(dòng)的開發(fā)過程中，用戶和客戶始終參與全部開發(fā)過程中。在項(xiàng)目中期，他們不應(yīng)該，也不容許離開。項(xiàng)目最初的故事通常是在專題討論會(huì)中完成的，但是在項(xiàng)目的任何時(shí)期都可以調(diào)整故事。開發(fā)者有了最初的一組故事，便可以估計(jì)每個(gè)故事的規(guī)模。
客戶團(tuán)隊(duì)和開發(fā)者共同確定迭代周期的長(zhǎng)度，項(xiàng)目期間應(yīng)該采用相同的迭代周期。一旦確定了迭代周期，開發(fā)者就可以估算一個(gè)迭代周期的工作量，稱之為“速度”（velocity）。
為了制定發(fā)布計(jì)劃，需要將故事卡分成幾疊，每疊代表一次迭代。每疊包含數(shù)個(gè)故事。優(yōu)先順序最高的故事安排在最前面的疊中優(yōu)先處理。
在每次迭代周期開始以前，客戶團(tuán)隊(duì)可以修改計(jì)劃。迭代周期結(jié)束時(shí)，就可以獲知開發(fā)團(tuán)隊(duì)的真實(shí)速度，這時(shí)采用真實(shí)速度改進(jìn)迭代和發(fā)布計(jì)劃。這意味著可以通過 增減故事的方法調(diào)整每次迭代的故事數(shù)量。圖1是用戶故事驅(qū)動(dòng)軟件開發(fā)過程的基本流程。
圖1 用戶故事驅(qū)動(dòng)的軟件開發(fā)過程
相對(duì)于其他開發(fā)方法，基于用戶故事的軟件開發(fā)方法更加倡導(dǎo)溝通和協(xié)作，鼓勵(lì)和積極擁抱需求變更，這種開發(fā)模式更加適合小型組織/項(xiàng)目的產(chǎn)品特點(diǎn)和組織特點(diǎn)，而且這種開發(fā)模式也是實(shí)施大型過程改進(jìn)模型，諸如CMMI和ISO/IEC 15504的基礎(chǔ)[4]。
2.1 故事估計(jì)
必須由整個(gè)團(tuán)隊(duì)來共同估計(jì)故事，估計(jì)方法應(yīng)該具有以下特點(diǎn)：無論何時(shí)發(fā)現(xiàn)故事的新信息，都可以調(diào)整故事；適用于大故事和小故事；估計(jì)花費(fèi)時(shí)間不長(zhǎng)；為項(xiàng)目計(jì)劃和工作安排提供有用信息；能夠容忍不精確的估計(jì)；用于項(xiàng)目發(fā)布。
故事點(diǎn)數(shù)（story points）是滿足上述要求的方法之一。故事點(diǎn)數(shù)的優(yōu)點(diǎn)之一是每個(gè)團(tuán)隊(duì)可以據(jù)自身情況來定義它。有的團(tuán)隊(duì)可能將一個(gè)故事點(diǎn)數(shù)定義為一天的理想工作量。另 一個(gè)團(tuán)隊(duì)可能將一個(gè)故事點(diǎn)數(shù)定義為一周的理想工作量。估計(jì)過程是一個(gè)迭代過程，過程如下[5]：
1）召集參與估計(jì)的客戶和開發(fā)者。拿出所有的故事卡和一疊空白卡，給每個(gè)參與者發(fā)幾張卡片?？蛻魪墓适驴ㄖ须S機(jī)選出一個(gè)故事，并讀給開發(fā)者聽。在初步了解 這個(gè)故事后，開發(fā)者盡可能提問，客戶盡可能詳細(xì)的回答。如果客戶不能回答，客戶可以猜，也可以要求開發(fā)者推遲實(shí)現(xiàn)該故事。
2）在每個(gè)故事的提問和回答結(jié)束時(shí)，每個(gè)開發(fā)者在卡片上寫下故事實(shí)現(xiàn)的估計(jì)值，估計(jì)值對(duì)其他開發(fā)者保密。如果團(tuán)隊(duì)規(guī)定一個(gè)故事點(diǎn)數(shù)代表一個(gè)理想工作日的工 作量，那么開發(fā)者應(yīng)考慮該故事包含多少故事點(diǎn)。如果團(tuán)隊(duì)規(guī)定故事點(diǎn)數(shù)代表故事的復(fù)雜度，那么開發(fā)者應(yīng)考慮該故事的復(fù)雜性。
3）在每個(gè)人都完成了估計(jì)后，大家都亮出卡片，如果估計(jì)值有差異，由最高者和最低者解釋自己的估計(jì)。
4）大家共同討論。其他參與者可能會(huì)提出一些新觀點(diǎn)?？蛻舫吻彘_發(fā)者關(guān)注的問題。這種討論可能會(huì)引出新故事。
5）討論結(jié)束后，開發(fā)者再次在故事卡上寫下估計(jì)值，寫完后亮出卡片。一般而言，在第二輪時(shí)估計(jì)值就一致了。但如果不是這樣，就讓最高者和最低者闡述自己的想法，重復(fù)上述過程。
2.2 發(fā)布計(jì)劃
許多軟件項(xiàng)目都爭(zhēng)取每2至6個(gè)月發(fā)布一次。一些網(wǎng)站項(xiàng)目的發(fā)布更頻繁，即使如此，也應(yīng)該在發(fā)布中引入新的功能。一種有效的方法是根據(jù)產(chǎn)品開發(fā)路線圖來啟動(dòng) 發(fā)布計(jì)劃，產(chǎn)品開發(fā)路線圖標(biāo)明每次發(fā)布的重點(diǎn)。根據(jù)產(chǎn)品開發(fā)路線圖，使用如下兩個(gè)問題啟動(dòng)發(fā)布計(jì)劃：計(jì)劃在何時(shí)發(fā)布？各個(gè)故事的順序如何？
一旦回答了這兩個(gè)問題，就能根據(jù)開發(fā)團(tuán)隊(duì)在一次迭代中完成工作量的估計(jì)來制定發(fā)布計(jì)劃，合理地預(yù)測(cè)需要多少次迭代才能完成一個(gè)滿足客戶要求的產(chǎn)品發(fā)布。
如果某項(xiàng)目有100個(gè)故事點(diǎn)數(shù)，每次迭代的速度是20個(gè)故事點(diǎn)數(shù)，就應(yīng)該使用5次迭代來完成該項(xiàng)目。發(fā)布計(jì)劃的最后一步是將各個(gè)故事指派到各次迭代中?？?戶和開發(fā)者從優(yōu)先順序最高的故事中選出總點(diǎn)數(shù)為20點(diǎn)的故事，并分配到第一次迭代。后面的20個(gè)故事點(diǎn)數(shù)對(duì)應(yīng)于第二次迭代，如此類推，直到分配完所有的故 事。
2.2.1 設(shè)定故事優(yōu)先級(jí)
現(xiàn)在有多種評(píng)判故事優(yōu)先級(jí)的標(biāo)準(zhǔn)。從技術(shù)角度可以考慮以下內(nèi)容[7,8]：
1）故事不能達(dá)到用戶期望的風(fēng)險(xiǎn)（例如：達(dá)到一定的性能特征、設(shè)計(jì)一個(gè)新的算法）；
2）如果推遲本故事，對(duì)其他故事可能產(chǎn)生的影響。
此外，客戶也有衡量故事優(yōu)先級(jí)的其他尺度，諸如：
1）多數(shù)用戶或客戶對(duì)該故事的需求程度；
2）少數(shù)關(guān)鍵用戶或客戶對(duì)該故事的需求程度；
3）某故事與其他故事的結(jié)合特點(diǎn)（例如，故事“縮小”的優(yōu)先順序可能并不高，但是它的互補(bǔ)故事“放大”的優(yōu)先順序高）。
總之，開發(fā)者和客戶各有故事完成順序計(jì)劃。當(dāng)二者不一致時(shí)，開發(fā)者必須服從客戶。
2.2.2 確定迭代長(zhǎng)度
總體說來，應(yīng)該由開發(fā)者和客戶共同選定合適的迭代長(zhǎng)度。迭代長(zhǎng)度通常為1到4周。迭代周期短有利于適時(shí)調(diào)整項(xiàng)目進(jìn)度和項(xiàng)目計(jì)劃。
在同一個(gè)項(xiàng)目開發(fā)中，應(yīng)盡可能堅(jiān)持同樣的迭代長(zhǎng)度。堅(jiān)持同樣長(zhǎng)度，項(xiàng)目將呈現(xiàn)出與團(tuán)隊(duì)步伐一致的自然節(jié)奏。當(dāng)然，有時(shí)候也需要改變迭代長(zhǎng)度。例如，某團(tuán)隊(duì) 一直采用3周的迭代長(zhǎng)度，現(xiàn)在突然要求他們準(zhǔn)備出新版本，在8周后進(jìn)行一次重要的商業(yè)演示。該團(tuán)隊(duì)與其在完成兩次迭代后就一直等待演示，還不如安排兩個(gè)正 常的3周迭代和一個(gè)短的2周迭代。應(yīng)該避免隨意改變迭代周期的長(zhǎng)度。
2.2.3 將故事指派到各次迭代中
發(fā)布計(jì)劃將故事粗粒度地分配到各次迭代中。在每次迭代的開始，制定更細(xì)致的計(jì)劃非常重要。
要計(jì)劃一次迭代，應(yīng)該召集團(tuán)隊(duì)舉行迭代計(jì)劃會(huì)議?？蛻艉烷_發(fā)者都應(yīng)該參加。開發(fā)團(tuán)隊(duì)要考慮故事的細(xì)節(jié)，所以勢(shì)必要提出一些有關(guān)的問題?？蛻魬?yīng)對(duì)這些問題做 出答復(fù)。通常，迭代計(jì)劃會(huì)議的活動(dòng)次序如下：討論一個(gè)故事；將故事拆分為多個(gè)任務(wù)；確定每個(gè)任務(wù)的開發(fā)責(zé)任人；完成所有故事的討論和任務(wù)分配后，開發(fā)者分 別估算自己接受的任務(wù)，確保不超量。
故事已經(jīng)很小了，足以作為工作單位，如果能將故事拆分為更小的任務(wù)，對(duì)項(xiàng)目會(huì)更有利。首先，對(duì)于多數(shù)團(tuán)隊(duì)而言，故事通常不是由一個(gè)程序員（或者配對(duì)程序 員）來實(shí)現(xiàn)。因?yàn)槌绦騿T精通特定領(lǐng)域，而分工可以提高開發(fā)速度，所以要將故事拆分到多個(gè)程序員。
2.3 驗(yàn)收測(cè)試
用戶故事很關(guān)鍵的一點(diǎn)是將測(cè)試看作開發(fā)過程的一部分，而不是“實(shí)現(xiàn)后再做”的工作。制定測(cè)試用例是產(chǎn)品經(jīng)理和測(cè)試人員的共同職責(zé)。產(chǎn)品經(jīng)理利用自己的組織經(jīng)驗(yàn)來推動(dòng)項(xiàng)目，測(cè)試人員則懷疑和審視項(xiàng)目。在迭代開始時(shí)，他們共同編寫盡可能多的測(cè)試用例。
驗(yàn)收測(cè)試用例含有大量信息，程序員應(yīng)該在編碼之前就可以使用這些信息。當(dāng)然，要想使程序員因此受益，故事的測(cè)試用例應(yīng)該在故事編碼實(shí)現(xiàn)之前完成。編寫測(cè)試用例的時(shí)機(jī)通常為[2,8]：
1）在客戶和開發(fā)者探討故事的過程中需要獲取清晰的細(xì)節(jié)時(shí)；
2）在迭代周期開始時(shí)（在編碼之前）；
3）在故事編程中間或完成編程后發(fā)現(xiàn)新測(cè)試需求時(shí)。
因?yàn)檐浖怯脕韺?shí)現(xiàn)用戶預(yù)期的，所以最好由用戶編寫測(cè)試用例?？蛻艨梢耘c程序員或測(cè)試人員一起編寫測(cè)試用例，但是至少應(yīng)該由用戶確定測(cè)試要求，這種測(cè)試要 求可用于證明用例書寫是否正確。此外，開發(fā)團(tuán)隊(duì)也需要編寫與隱含故事需求相關(guān)的測(cè)試用例。
3 結(jié)論
本文根據(jù)小型軟件企業(yè)的實(shí)際開發(fā)需求，用戶需求變更快等特點(diǎn)，闡述一種用戶故事驅(qū)動(dòng)的軟件開發(fā)方法，總結(jié)在實(shí)施用戶故事方法時(shí)需要特別注意的地方。這種方 法與其他軟件開發(fā)方法相比有以下優(yōu)點(diǎn)：注重口頭溝通；易于被所有人理解；用戶故事的大小適中，可用來制定計(jì)劃；支持迭代開發(fā)；鼓勵(lì)推遲細(xì)節(jié)；支持隨機(jī)設(shè) 計(jì)；鼓勵(lì)參與性設(shè)計(jì)；建立默契的領(lǐng)悟。但是可能出現(xiàn)的問題也比較突出，常見問題包括：在一個(gè)有許多故事的大型項(xiàng)目中，很難理解用戶故事之間的關(guān)系；雖然故 事可以提高團(tuán)隊(duì)中的默契領(lǐng)悟，但是很難覆蓋到大型團(tuán)隊(duì)/項(xiàng)目，尤其是分布式項(xiàng)目。這些都是需要進(jìn)一步完善的方面，有關(guān)研究也正在進(jìn)行中。
相關(guān)文章敏捷開發(fā)的靈魂—小跑精神架構(gòu)宣言: 采用敏捷開發(fā)企業(yè)實(shí)施敏捷制造過程的研究敏捷 PK CMMI：軟件工程的關(guān)公軟件過程的管理與改進(jìn)詳解在Scrum中實(shí)現(xiàn)敏捷建模敏捷開發(fā)過程中如何開發(fā)理解敏捷開發(fā)：需求處理更多...相關(guān)培訓(xùn)課程統(tǒng)一過程及應(yīng)用 火龍果MyProcess過程改進(jìn)實(shí)踐敏捷過程實(shí)踐基于XP/RUP的迭代開發(fā)軟件開發(fā)過程指南SCRUM過程實(shí)踐軟件工程哲學(xué)思考迭代開發(fā)與過程管理軟件工程方法與技術(shù)有效開發(fā)的原則和實(shí)踐更多課程...相關(guān)咨詢服務(wù)基于CMMI2-3過程改進(jìn)咨詢軟件工程體系與平臺(tái)構(gòu)建軟件開發(fā)過程更多咨詢...成功案例 項(xiàng)目管理+軟件質(zhì)量培訓(xùn)愛立信(中國(guó))軟件設(shè)計(jì)培訓(xùn)某知名電信軟件服務(wù)商 軟件技術(shù)文檔培訓(xùn)成功舉辦 某航空公司產(chǎn)品經(jīng)理與管理培訓(xùn)北京 敏捷軟件開發(fā)過程上海 敏捷軟件開發(fā)過程某美國(guó)著名資訊公司 敏捷開發(fā)英國(guó)帕吉特 MyP與敏捷開發(fā)總參 軟件工程基礎(chǔ)與導(dǎo)論航管科技 RUP中海油 軟件開發(fā)過程學(xué)門科技 個(gè)人軟件過程中國(guó)氣象局 CMMI ML3最佳實(shí)踐電訊盈科 CMMI體系與過程更多...
