Stay focused on executable software

 第三個不可缺少的RUP理論包括幾個方面。首先，你應(yīng)該盡最大可能的通過衡量你的可執(zhí)行軟件來衡量你的進展。當(dāng)然一半以上的用例已經(jīng)被細(xì)化是一件好事，但是這并不意味這相當(dāng)程度的需求已經(jīng)完成了。如果你之后發(fā)現(xiàn)因為你并沒有恰當(dāng)?shù)牧私庥脩粜枨?，進而導(dǎo)致了大多數(shù)的主要需求需要重新實現(xiàn)，那么你會怎么做呢？那可能意味著你僅僅完成了實際工作總量的很少一部分。所以如果你想表明你完成了一半的用例，也就相當(dāng)于你想表明你僅僅實現(xiàn)了一半不到的需求。
最好的衡量進展的方式就是衡量那些可以運行的軟件。它允許你測試，并且基于測試和次品率，估算出真正的進展。當(dāng)一個典型的開發(fā)者陳述說：“我已經(jīng)完成了90%”，那么你可以問問他，“很好，請演示一下你可以運行的東西。”然后通過演示，獲取一個能夠說明“到底完成了多少”的客觀的結(jié)果。你應(yīng)該總是采用演示-->察看測試覆蓋率和測試結(jié)果這樣的過程來估算進展，千萬不要被那些往往和現(xiàn)實不符的文檔所蒙蔽。當(dāng)然這并不是否定文檔的作用，而只是說明它們對于衡量項目進展情況的時候，只能起到微乎其微的作用。
其次，明確地把精力集中于“可執(zhí)行”的軟件上，這一點同樣提升了你的團隊的一些正確意識；你不會冒著犯“過渡設(shè)計”或者“重理論，輕實踐”這類錯誤的風(fēng)險，取而代之的是，用實實在在的工作去證明方案“A”和方案“B”的優(yōu)劣。強迫以可執(zhí)行軟件作為結(jié)束通常是最快的減少風(fēng)險的途徑。
再次，重視可執(zhí)行的軟件的第三個特點就是軟件的“副產(chǎn)品”（計劃、配置等管理手段）會去適應(yīng)軟件的開發(fā)，而不是讓軟件的開發(fā)去適應(yīng)這些“副產(chǎn)品”。這些“副產(chǎn)品”是為了讓你開發(fā)出更好的軟件。以“可執(zhí)行的軟件”為出發(fā)點，你可以決定是否生產(chǎn)這些“副產(chǎn)品”。通常這些“副產(chǎn)品”是為了讓你的軟件產(chǎn)生更好的效果或者更加容易維護。是的，在一些情況下答案是肯定的，但是這并不是“放之四海而皆準(zhǔn)”的。你需要衡量這些副產(chǎn)品所帶來的優(yōu)劣。通常這些副產(chǎn)品的優(yōu)勢會隨著你的項目的規(guī)模，以及你的產(chǎn)品對于商業(yè)的重要程度而增長。在這種情況下，所有的事實都表明：應(yīng)該產(chǎn)生出盡可能多的“副產(chǎn)品”。但是對于任意一個項目而言，你應(yīng)該努力的減少這些副產(chǎn)品，進而削減費用。
一個好的方針就是：如果你對于是否生產(chǎn)這些副產(chǎn)品而猶豫不決，干脆就別生產(chǎn)它們。但是不要對那些重要的活動使用此方針，比如記錄需求、進行設(shè)計和制定測試計劃的時候就不要這樣做。這些活動所產(chǎn)生的副產(chǎn)品有特定的價值。如果生產(chǎn)副產(chǎn)品的花費超出了回報，忽略它們。
RUP用戶經(jīng)常犯的一個錯誤就是僅僅因為RUP描述了如何生產(chǎn)那些“副產(chǎn)品”就去生產(chǎn)它們。記住RUP只是大餐前的開胃小菜。

Accommodate change early in the project.
變動是一件好事。實際上變動是一件偉大的事。為什么呢？因為當(dāng)代大多數(shù)的系統(tǒng)正在變得太過復(fù)雜以至于你都沒法獲取需求并在第一時間進行設(shè)計。變動允許改善你的方案。如果沒有變動，你可能會提交一個有缺陷的方案--這有可能會導(dǎo)致你的應(yīng)用沒有任何的商業(yè)價值。這就是為什么歡迎并且鼓勵變動。并且迭代方法已經(jīng)被進行了足夠的優(yōu)化，使它更加適應(yīng)于變動的情況。
但是變動也有些不良的后果。持久的變動會導(dǎo)致你的項目無窮無止。處在項目后期的一些變動會導(dǎo)致一些工作成為“無用功”，會增加費用，降低質(zhì)量，甚至?xí)?dǎo)致拖延--那些都是你想盡辦法要避免的。為了優(yōu)化你的變動管理策略，你需要了解不同類型變動的代價：
1、商業(yè)方案變動的代價。這種變動主要包含需求的重寫或者要面對完全不同的用戶或需求。應(yīng)該在先啟階段就處理這些變動或適應(yīng)這些變動，隨著進入“精化”階段，這種變動所帶來的代價會越來越大。
2、框架變動的代價。遵照RUP，在價值較高的精化過程到來之前，你可以進行一些重大的框架變動。在那之后，框架變動的代價會顯著增加。
3、設(shè)計和實現(xiàn)的變動代價。因為你的功能更加“模塊化”或者“組件化”，這些變化看上去更加“本地化”一些，因此在構(gòu)建階段它們的代價相當(dāng)?shù)汀５钱?dāng)初在正式版本提交階段，代價會顯著增加。
4、邊界變動的代價。裁減邊界，把一些特性放到下一個發(fā)布版本中去，對于一個產(chǎn)品來說代價相對較低。項目管理者可以使用這把“利劍”來確保項目的按時提交。
上面有關(guān)代價的考慮說明你應(yīng)該去管理這些變動。你需要：
1、在切當(dāng)?shù)臅r期決定是否引入一個變動。
2、評估變動所帶來的壓力。
3、盡可能縮減變動的代價。

   出自The Spirit of the RUP
RUP的那些階段已經(jīng)優(yōu)化并最小化了這些變動的花費，同時增長了迎合變動的能力。這就是為什么RUP要求在先啟階段的最后，在所有的視點上達(dá)成共識；在精化階段的最后能夠有一個可以作為基線的框架結(jié)構(gòu)；在beta版發(fā)布階段不再向產(chǎn)品添加新的特性。使用正確的工具可以為你的變動管理帶來很大的方便，并降低你的代價。