5.2 交付對(duì)象模型

在我為其擔(dān)任咨詢顧問的很多團(tuán)隊(duì)里，大家常以功能或是模塊作為交付對(duì)象的單位。這樣的方式雖然在操作上感覺比較自然，因?yàn)榇蠖鄶?shù)人都是以功能或模塊為邊界，自上而下地分解和理解一個(gè)系統(tǒng)，但從度量角度來講，這種方式在粒度上就比較模糊。我在計(jì)劃和評(píng)估會(huì)上經(jīng)常看到一兩百行代碼的功能和三五千行的功能在同一個(gè)層面上討論。即使拋開對(duì)功能和系統(tǒng)本身的熟悉程度、個(gè)人的經(jīng)驗(yàn)和評(píng)估能力，這種方式在估算和度量的準(zhǔn)確性上其實(shí)很成問題。這是由于我們?cè)谧雠袛嗟臅r(shí)候，經(jīng)常會(huì)受到錨定偏見/基準(zhǔn)點(diǎn)偏見（anchoring bias）的影響，這種心理上的偏見很容易就把我們帶到坑里去，而且很難僅靠小心謹(jǐn)慎來排除。

錨定偏見是心理上的一種經(jīng)驗(yàn)性的或是啟示性的作用，會(huì)對(duì)人們的評(píng)估結(jié)果造成影響。當(dāng)我進(jìn)了一個(gè)餐館時(shí)，在菜單上看到大多數(shù)菜至少都是八九十元一份，更不消說那些幾百元、數(shù)千元的海鮮了，這時(shí)偶爾看到個(gè)三四十元的菜，頓時(shí)覺得這個(gè)還挺便宜啊，其實(shí)就是個(gè)炒時(shí)蔬或是某個(gè)家常菜。人們通常會(huì)根據(jù)前一個(gè)數(shù)字來對(duì)后面的數(shù)字有個(gè)判斷或是預(yù)期。在軟件的工作量評(píng)估當(dāng)中產(chǎn)生的結(jié)果就是，不管一個(gè)功能實(shí)際的大小如何，人們通常在估算的時(shí)候，傾向使結(jié)果靠近前面己經(jīng)估算的功能的大小量級(jí)上。那么估算一組大小相差極大的功能，其結(jié)果就很容易受到這種偏見的影響。比如我們剛剛估算一個(gè)大約3000行代碼的功能，后面馬上要估算的一個(gè)功能比起前面一個(gè)小很多，我們通常傾向于至少估個(gè)800行或是至少500行，不會(huì)太情愿放個(gè)200行的數(shù)字。因此，為了能夠更加系統(tǒng)地對(duì)度量的對(duì)象作出分析，我們需要對(duì)交付對(duì)象的粒度有個(gè)合理的定義。

為了能夠找到合適的粒度，我們先需要尋找一個(gè)合適的方式來拆分度量的對(duì)象軟件。敏捷開發(fā)提倡以端到端的方式劃分交付的對(duì)象，期望每個(gè)劃分出來的交付對(duì)象必須能夠?yàn)檐浖挠脩簦ú还苡脩羰且粋€(gè)自然人還是另一個(gè)存在交互關(guān)系的系統(tǒng)）提供直接的價(jià)值，為此還提出了劃分用戶故事的INVEST原則（見右圖），其中的V就指的是價(jià)值（Valuable）。在不同的軟件開發(fā)流派當(dāng)中，對(duì)端到端特性的描述術(shù)語(yǔ)有所不同。

Extreme Programming（極限編程）的實(shí)踐者大多使用用戶故事（User Story）描述客戶需求。用戶故事用簡(jiǎn)短的日常或業(yè)務(wù)語(yǔ)言來描述用戶的行為和需要，關(guān)注的是“誰(shuí)”，“要做什么”，“為什么”。Mike Cohn在他的《User Stories Applied: For Agile Software Development》中提到了用戶故事的3個(gè)方面，如下所述。

●用于計(jì)劃或是提醒的描述性記錄（是工作量估算和任務(wù)劃分的載體）。

●作為交流的載體，輔助對(duì)話者發(fā)掘相關(guān)生動(dòng)細(xì)節(jié)。

●作為測(cè)試的載體，為測(cè)試傳遞和記錄需求細(xì)節(jié)，并決定用戶故事什么時(shí)候算是結(jié)束。

Unified Process在建模上給予相當(dāng)多的關(guān)注，認(rèn)為模型能夠幫助人們理解并形成對(duì)問題的定義，并使解決方案具象化。從捕獲需求的角度來講，Unified Process選擇用例建模（User Case M odeling）這樣一個(gè)背景不同的人都能理解的方式，以期獲得諸如用戶、開發(fā)人員、客戶、管理者等，更廣泛的干系人的理解和共識(shí)。用例方法早先由Ivar Jacobson 在其著作《Object Oriented Software Engineering: A Use-Case-Driven Approach》里首先引入，而Alistair Cockburn的《Writing Effective Use Cases》一書則系統(tǒng)地展示了用例的實(shí)踐方式。其所用的例子都很有借鑒意義，有很強(qiáng)的可操作性，為用例使用的推廣起到了很大的作用，就連Extreme Programming的實(shí)踐者在需要細(xì)化用戶故事的時(shí)候，也經(jīng)常會(huì)采納用例的描述形式。

Scrum定義的Product Backlog是一個(gè)按優(yōu)先級(jí)排序的需求列表，但卻沒有定義backlog里的需求是在什么樣的粒度上，以什么形式描述，因此實(shí)踐者一般都從其他流派借來了需求的發(fā)現(xiàn)、分析和描述方法。這其中用戶故事在敏捷社區(qū)里被使用等似乎更加廣泛一些，也有不少人傾向于使用Use Case的方法。

在《Agile Software Requirements》一書中，Dean Leffingwell嘗試著梳理敏捷理念下的需求管理體系，使其能夠適應(yīng)不同規(guī)模、類型的開發(fā)場(chǎng)景。其中一個(gè)重要的做法是把軟件開發(fā)組織處理的工作單元分成了4個(gè)層面：投資主題（Investment themes）-Epic-特性-用戶故事。具體見圖5-2。我們用前面的Big Bank的一個(gè)系統(tǒng)來介紹一下這幾個(gè)層面的開發(fā)對(duì)象大概是個(gè)什么樣子。

投資主題（Investment Themes）——一家企業(yè)可能在向市場(chǎng)提供多個(gè)產(chǎn)品或產(chǎn)品線，在這些產(chǎn)品組合上的投入程度是以企業(yè)的產(chǎn)品戰(zhàn)略為前導(dǎo)的。企業(yè)通過計(jì)劃一系列的投資主題來獲得合適的產(chǎn)品布局，從而達(dá)成最終的戰(zhàn)略目標(biāo)，這個(gè)時(shí)候交付單位就是投資主題-Investment themes。

Epic/特性——一個(gè)大規(guī)模系統(tǒng)的開發(fā)通常以項(xiàng)目或項(xiàng)目群的方式組織，多個(gè)團(tuán)隊(duì)會(huì)并行工作在一個(gè)敏捷發(fā)布火車上（Agile Release Train）。這個(gè)時(shí)候管理和度量的對(duì)象是PSI（Potentially Shippable Increments）可交付的增量，可交付的增量經(jīng)常用特性或是Epic來代表。Epic一般指的是在比較高層面的描述，通常一兩句話，可以被分解成一組相關(guān)的特性。

用戶故事——在團(tuán)隊(duì)層面上，管理和度量的對(duì)象是團(tuán)隊(duì)Backlog中的故事列表。

除了明確各個(gè)層面的交付對(duì)象，另一個(gè)需要厘清的概念是什么代表了完成。