在績效管理中，有兩個名詞：考核和評估，分別表示了績效考核和績效評估兩種績效管理方式。這兩者有什么區(qū)別呢？
我們說考核是一種制度，而評估是一個過程。怎么理解呢？很多的公司都有績效考核的制度，這個制度一般是在年底的時候，對員工今年的工作做一個評定?？己耸且粋€點。但是評估不一樣，評估是針對某一段時間中員工工作中的不足之處，需要改進之處進行評價。不論是考核還是評估，它們兩者雖然都是為了達到評價并改進員工行為的目的而設(shè)計的，但是做法是不同的?？己酸槍^去的事情進行評定，容易實現(xiàn)，但是效果不佳，因為時間一長，大家可能忘記了以前的事情，而要公平的對過去一年的表現(xiàn)做一個評定也不是一件容易的事，評估則不同，評估是不斷進行的，針對剛剛發(fā)生的事情做出評價，并找到改進方法。就好像我們在第一章中舉的外賣店的例子，不斷地對過程進行分析和改進，這就是一種評估。評估的效果不錯，但難以實現(xiàn)。
這一思路在軟件過程中，直接表現(xiàn)為里程碑和迭代的思路。我們可以想想，里程碑是不是一種制度。在需求結(jié)束的時候，我們需要需求規(guī)約文檔，風(fēng)險列表等等一系列的文檔，在設(shè)計結(jié)束的時候，我們也需要另一些文檔。這種處理方式就是考核的思路。但是很多時候，這種考核起到的作用是有局限性的：
工件的設(shè)計原本是為了輔助生成最終的代碼，但是往往會演變成為了通過里程碑而設(shè)計；
a. 里程碑的設(shè)計不能夠完全捕獲所有的問題，部分的風(fēng)險被隱藏了；
b. 難以對工作量和工作價值進行評估；
c. 里程碑揭露問題的時間要遠遠落后于問題出現(xiàn)的時間；
這里對里程碑的方式做一些分析。我們對問題的理解往往是逐步深入的。在項目一開始的時候，業(yè)務(wù)和技術(shù)上都存在問題，存在不確定性和風(fēng)險，這時候往往是最需要評估和驗證的。但是里程碑方式往往要求必須深入的分析需求，很多的問題并沒有得以解決，而是被悄悄的有意或無意的掩蓋了。需求畢竟不是軟件，它是一個不同人具有不同理解的模型，這時候，項目中各個角色對它的理解都不相同，但是這并不影響他們做出一致的決定－通過需求里程碑。問題到了設(shè)計階段依然存在，這時候需求階段隱藏的一些問題開始出現(xiàn)，導(dǎo)致我們不得不補充一些工作量。但是所有的問題也沒有得到解決，依然存在未知的風(fēng)險。那么風(fēng)險到了什么時候才會暴露出來呢？最樂觀的情況是在編碼時期發(fā)現(xiàn)，最悲觀的情況是在交付期發(fā)現(xiàn)。我們把這種過程稱為固化考核過程。
問題在哪里？除了軟件本身，模型也好、文檔也罷，都不能夠代替最后的代碼。在精益原則中，我們說，必須消除浪費。當我們在開發(fā)工件的時候，我們的浪費行為已經(jīng)或多或少的出現(xiàn)了。
與固化考核過程相對的，我們認為存在另一種動態(tài)評估過程。里程碑或是檢查點并不是不重要。但是我們需要轉(zhuǎn)換思路，來將里程碑的實踐做的更好一些。我們上面提到說里程碑方式最大問題就在于一定要等到問題都積累起來了才解決問題，而這個時候往往已經(jīng)錯過了解決問題的最佳時機。而動態(tài)評估過程的含義就是在過程進行中不斷的發(fā)現(xiàn)并解決問題，而不是等到問題累積到一定程度才批量解決。過程隨著環(huán)境的變化不斷的調(diào)整，以適應(yīng)變化性和不確定性的需要。而里程碑實踐重在提供一個復(fù)審的機會，能夠從一個較高的層次上來評價軟件。
這種過程就是分階段開發(fā)軟件的思路，我們也可以稱呼它為迭代、螺旋、增量，都沒有關(guān)系。關(guān)鍵在于，我們需要不斷的發(fā)現(xiàn)導(dǎo)致客戶不滿意的問題，發(fā)現(xiàn)改進接電話的方法，發(fā)現(xiàn)改進做菜的方法，發(fā)現(xiàn)更快送貨的方法。
動態(tài)評估過程有一些基本的實現(xiàn)思路，第一個基本思路是盡可能早的發(fā)現(xiàn)所有的問題，如何發(fā)現(xiàn)呢？進行一次探險式的過程。這個過程周期不能夠太長，太長的周期容易失控，而且項目初期人員未必能夠全部到位；但這個周期也不能夠太短，太短的周期無法發(fā)現(xiàn)足夠數(shù)量的風(fēng)險，無法為后續(xù)的過程提供豐富的數(shù)據(jù)。
有時候，我們運用原型法來實現(xiàn)這個Mini過程。原型法包括了需求原型和技術(shù)原型，分別用于解決業(yè)務(wù)風(fēng)險和技術(shù)風(fēng)險。一個典型的需求原型是建立一個界面原型，來幫助客戶理解未來的軟件，避免抽象的思考。我看過很多界面原型的做法，有使用HTML的，有使用畫圖軟件的，有使用規(guī)范的XML的。但是不管如何，界面原型能夠幫助用戶直觀的理解需求。技術(shù)原型的主要目標是解決技術(shù)風(fēng)險，任何一個項目都可能存在這樣或那樣的技術(shù)風(fēng)險。對待風(fēng)險的基本態(tài)度是盡早的評估風(fēng)險并制定解決方案，而不是束之高閣。技術(shù)風(fēng)險的解決方案視具體情況而定，但是，值得注意的是，一個項目中，技術(shù)風(fēng)險不能夠過多。如果確實存在這種情況，想辦法找到有經(jīng)驗的導(dǎo)師或培訓(xùn)師，這要比自己摸索節(jié)省許多的成本。
XP對探險式過程的評估主要包括兩個方面，spike solution和迭代。spike solution其實就是我們在上面提到了的技術(shù)原型。它的目的是讓不明確的評估成為明確的評估（參見XP的過程圖中的Spike）。只有評估準確了，計劃才能夠準確。因此它是計劃和迭代的輸入項。
至于迭代，它是XP中的重要概念。迭代選取了用戶需要的功能（稱為用戶故事），并進行設(shè)計、開發(fā)、測試，迭代不斷重復(fù)，并解決各種各樣的問題。在通過用戶的測試和認可之后，最終產(chǎn)生了一個可以運行的版本。這個版本的產(chǎn)生，標志著一組迭代周期的完成。第一個小版本正是我們所強調(diào)的探險式的過程。它的成功和教訓(xùn)，足以讓你了解項目的各種知識，包括客戶的復(fù)雜組織關(guān)系，投資方的準確意圖，找出所有的涉眾，發(fā)現(xiàn)用例，令團隊成員和客戶達成初步的共識，驗證技術(shù)方案，建立一個初步的軟件架構(gòu)，或是針對現(xiàn)有的架構(gòu)進行初步的映射，程序員需要額外的培訓(xùn)，測試力量似乎不足夠，部署環(huán)境的風(fēng)險需要提前解決。只有你按照完整的生命周期真正的去做這項工作，這些問題才會在一開始都暴露出來，否則，其中的很多問題會在后續(xù)的階段中給你制造大麻煩。
第二個基本思路是增量開發(fā)。增量和迭代有什么區(qū)別呢？Alistair Cockburn在Surviving Object-Oriented Projects一書中將增量描述為修正或改進開發(fā)過程，形象的說法是逐步的完成軟件開發(fā)。注意到，XP的過程圖中的小版本正是一個增量。XP認為，一個增量應(yīng)該是可以發(fā)布的。做到這一點固然很好，但是并不是所有的項目都能夠達成這一目標。例如，第一次的增量目標可能主要是定義一個架構(gòu)，這個架構(gòu)并不包含用戶需要的功能，但是它是項目開發(fā)的基礎(chǔ)。架構(gòu)中可能包括業(yè)務(wù)實體基礎(chǔ)結(jié)構(gòu)、數(shù)據(jù)操縱基礎(chǔ)架構(gòu)等一系列的框架。但是對于XP來說，在用戶無法發(fā)現(xiàn)價值的框架上花費大量的時間是不值得的，XP提倡的做法是根據(jù)需求的發(fā)展來逐步完善架構(gòu)，而不是在項目一開始就花費精力開發(fā)架構(gòu)。很難評價哪一種說法正確，我比較傾向于前期花費時間進行架構(gòu)設(shè)計，但是實踐中確實發(fā)生過設(shè)計過于復(fù)雜導(dǎo)致高昂成本的情況。在花費了大量的時間開發(fā)了一個屬性處理框架之后，我發(fā)現(xiàn)其實簡單屬性就能夠處理大部分的情況，毫無疑問，前期的設(shè)計投入打了漂。因此，重要的是權(quán)衡前期的投入時間。理想的情況是，你已經(jīng)擁有了一個可重用的框架（或是架構(gòu)），這樣，你可以將項目的需求映射到框架上，而不是在項目一開始的時候花時間來開發(fā)框架。如果你沒有框架，在項目一開始的時候，花費一定的時間來開發(fā)架構(gòu)，但是這個時間不宜過長，你完全可以在后續(xù)的增量中對架構(gòu)進行改進，所以不用急于一時。而且，單純的框架（架構(gòu)）開發(fā)是沒有辦法進行用戶接受測試的，你的測試不得不推遲到第二次增量。這個理由也促使我們盡可能的縮短框架設(shè)計的周期。
而迭代則是改進或修正軟件質(zhì)量。這也是第三個基本思路。我們注意看XP過程圖中的迭代，多次的迭代才構(gòu)成一次的增量（小版本），每一次的迭代都是對上一次迭代的改進，其中可能是修正了設(shè)計錯誤，或是需求缺陷。值得注意的是，迭代中可能會出現(xiàn)新的需求變更（新需求或需求改變），并令項目人員對項目的進展速度更加的了解（Project Velocity），這些將會反過來影響計劃的修正。這體現(xiàn)了我們在上一章所講述的XP對待計劃的態(tài)度。
并沒有法律規(guī)定迭代需要和增量一起使用，但很明顯，結(jié)合這兩種方式是一種有效的做法。增量的目標是讓項目得以向前推進（這就像是修路的時候，路的長度變長了），而迭代的目標是令軟件的質(zhì)量更優(yōu)（就像是在一段路上架設(shè)路基、鋪上水泥，建設(shè)路面設(shè)施）。這讓我們想起了什么，不錯，重構(gòu)的兩頂帽子。一頂帽子是為軟件增加新功能，一頂帽子是改進軟件的質(zhì)量。非常的相似，只不過一個是過程級別的，一個是程序級別的。這里有一個基本的假設(shè)，不要同時增加功能和改進質(zhì)量。團隊也好，個人也好，一次只完成一個目標效率是最高的。
和傳統(tǒng)的先定義問題，然后再解決問題的做法不同，XP偏重于逐步的精化問題。軟件開發(fā)中的問題定義和數(shù)學(xué)中不同，它往往是模糊的，動態(tài)的，需要在解決問題的過程中不斷的調(diào)整解題的思路。對XP來說，這種解題思路，體現(xiàn)了其反饋的價值觀－盡快獲得客戶對軟件的反饋。
林星，辰訊軟件工作室項目管理組資深項目經(jīng)理，有多年項目實施經(jīng)驗。辰訊軟件工作室致力于先進軟件思想、軟件技術(shù)的應(yīng)用，主要的研究方向在于軟件過程思想、Linux集群技術(shù)、OO技術(shù)和軟件工廠模式。您可以通過電子郵件 iamlinx@21cn.com和他聯(lián)系。
