一次有益的敏捷 XP 失敗 / 前言

作者：張恂 發(fā)表日期：2006 年 6 月 18 日

更新日期 2007-11-20 10:37:52

本案所反映的問(wèn)題和現象在我國的軟件開(kāi)發(fā)項目中是非常典型的。程序員高手和篤信編程技巧大于一切的觀(guān)察家們會(huì )指著(zhù) PRM 項目說(shuō)：這明顯是開(kāi)發(fā)人員的水平不夠，頁(yè)面處理太笨，數據庫設計太次 …… 要是我早就搞定了！可是，問(wèn)題的根源果真是技術(shù)原因嗎？

前言

當我三年前第一次在 developerWorks 上讀到這篇文章（漫談企業(yè)應用項目的軟件開(kāi)發(fā)過(guò)程：一個(gè) PRM 系統實(shí)施的經(jīng)驗與教訓）時(shí)，就發(fā)現它是一篇非常難得的好文章 —— 國內類(lèi)似這樣的軟件工程案例分析太少了，很多人沒(méi)有時(shí)間寫(xiě)或舍不得與旁人分享屋中瑰寶，何況這篇文章還是專(zhuān)門(mén)針對 XP、RUP 涉及到敏捷統一過(guò)程實(shí)踐的。

除了這篇 PRM （Partner Relationship Management）案例外，Johnson 其實(shí)早在 2002 年 7 月還發(fā)表過(guò)一篇《從一個(gè)項目談 XP 在國內的應用》，該文在網(wǎng)絡(luò )上也流傳甚廣。在我的印象中，這兩篇文章好像是國內（互聯(lián)網(wǎng)上）最早公開(kāi)的 XP 實(shí)踐案例，而且還是嘗試 XP、RUP 整合的案例。姑且不論它們是否真正做到了敏捷，整合是否成功，這兩個(gè)應用案例的結局恰好一個(gè)成功，一個(gè)失敗，其價(jià)值就在于真實(shí)性和典型性，具有很好的說(shuō)服力和教育意義。通過(guò)案例介紹用事實(shí)和數據說(shuō)話(huà)，我為 Johnson 的勇氣和科學(xué)態(tài)度叫好！不管結果如何，PRM 原文的篇幅不長(cháng)，卻有很多值得我們借鑒、學(xué)習的地方。除了作者總結的經(jīng)驗和教訓之外，我還看出了一些其他問(wèn)題，有一些新的聯(lián)想和補充，于是寫(xiě)下來(lái)與大家交流探討。

我個(gè)人認為 PRM 這個(gè)項目無(wú)論從商務(wù)角度，還是從工程技術(shù)的角度來(lái)看，都是比較失敗的。印象最深刻的一處是 PRM 系統雖然通過(guò) 2 個(gè)月緊張的敏捷、迭代開(kāi)發(fā)準時(shí)交付使用，卻由于后來(lái)出現性能問(wèn)題，過(guò)了大半年仍然沒(méi)有通過(guò)客戶(hù)驗收，不但有近一半的尾款沒(méi)有收到，而且還影響了開(kāi)發(fā)商其它項目的投標。為什么一個(gè)曾一度成功按時(shí)交付的系統，在新舊系統數據集成、上線(xiàn)運行的幾個(gè)月后會(huì )出現嚴重的性能問(wèn)題，并暴露出系統架構設計上的缺陷，導致遲遲無(wú)法獲得客戶(hù)的信任，讓項目各方都陷于被動(dòng)和尷尬？這些麻煩究竟是什么原因造成的，是 XP 不行，RUP 不行，還是敏捷過(guò)程、方法不行？有沒(méi)有可能事先避免這種嚴重的風(fēng)險呢？以上所有這些有趣的問(wèn)題都值得我們深入探究。

案例概況

從 Johnson 的介紹來(lái)看，這是一個(gè)遺留系統改造項目，涉及的應用領(lǐng)域是快速消費品領(lǐng)域的PRM（合作伙伴關(guān)系管理），系統主要提供訂單管理等功能。需要用 J2EE 框架開(kāi)發(fā)一個(gè)新系統來(lái)取代已經(jīng)運行了 2 年的 PHP 老系統，以完善、增加功能。從系統規模來(lái)看，有三十多個(gè)用例，六萬(wàn)多行代碼，近二百個(gè) JSP 頁(yè)面，當屬于中等復雜度。

項目團隊為 10 人，分別有項目經(jīng)理、技術(shù)經(jīng)理、客戶(hù)經(jīng)理（Business Development）、開(kāi)發(fā)人員、測試人員、HTML 人員（頁(yè)面設計）等 6 種角色，其中技術(shù)經(jīng)理和頁(yè)面設計師均為兼職。我看到，團隊成員清單里沒(méi)有包含客戶(hù)方面的技術(shù)（或業(yè)務(wù)）人員。

我有個(gè)疑問(wèn)，不知道這個(gè)團隊里誰(shuí)承擔“架構師”的任務(wù)，是項目經(jīng)理、技術(shù)經(jīng)理，還是開(kāi)發(fā)人員（程序員）當中的某個(gè)人？技術(shù)經(jīng)理是兼職的，好像不適合擔任架構師。不知道項目經(jīng)理是否參與編程。


開(kāi)發(fā)時(shí)間一共只有 2 個(gè)月（從 7 月 1 日到 9 月 1 日），9 月 2 日當天就要交付，所以，可用于開(kāi)發(fā)、測試的實(shí)際時(shí)間不足 2 個(gè)月。顯然，進(jìn)度緊是這個(gè)項目的一個(gè)顯著(zhù)特點(diǎn)。這讓很多人聯(lián)想到，應該采用敏捷快速開(kāi)發(fā)，快速迭代應該會(huì )適用于這個(gè)項目。

約束條件：

1）由于客戶(hù)預算原因，要采用原有硬件。

了解了 PRM 項目的大致情況后，我們有一個(gè)基本問(wèn)題：這個(gè)項目到底是“成功”還是“失敗”，應該如何來(lái)評判？


從以上這段話(huà)，我作出的判斷是：這個(gè)項目是比較失敗的，沒(méi)有能達到敏捷迭代開(kāi)發(fā)的初衷。系統在初次交付（9 月 2 日）的 8 個(gè)月之后（次年 5 月）竟然還沒(méi)有通過(guò)驗收，這不能不說(shuō)是客戶(hù)、開(kāi)發(fā)商都不愿看到的糟糕局面。

當然，作者也寫(xiě)到：


我覺(jué)得，這可以理解為“局部的成功”，那么，“局部的成功”能否抵消“全局的失敗或被動(dòng)”？所以，“局部”的經(jīng)驗和長(cháng)處當然也要總結，不過(guò)看來(lái)我們更應當很好地吸取這個(gè)項目的“全局”教訓。

做事后諸葛亮是比較容易的。如果這個(gè)項目從頭讓你再做一遍，你會(huì )怎么做？

1）風(fēng)險管理的失敗

沒(méi)有實(shí)施有效的風(fēng)險管理，做到真正的風(fēng)險驅動(dòng)的迭代式開(kāi)發(fā)，盡早排除架構（性能上）的風(fēng)險

總體上我認為，沒(méi)有做到真正的風(fēng)險管理與控制是導致此項目失敗的最重要原因。我一直持有這樣一個(gè)觀(guān)點(diǎn)：風(fēng)險管理是軟件項目管理的第一管理（要點(diǎn)）。

敏捷開(kāi)發(fā)的基礎是首先做到迭代式（iterative）開(kāi)發(fā)。迭代不僅僅意味把整個(gè)系統開(kāi)發(fā)任務(wù)逐一分解、按階段分步驟來(lái)實(shí)現，如果迭代的含義僅僅停留在這個(gè)層面上，那么提出用迭代演進(jìn)式過(guò)程取代瀑布型開(kāi)發(fā)模型也就毫無(wú)意義，因為我們做任何工作本來(lái)就是要一周一周、一天一天、一塊一塊地來(lái)完成——不管瀑布型還是演進(jìn)式，皆如此。迭代真正的主要目的其實(shí)是為了通過(guò)加速客戶(hù)反饋顯著(zhù)地消除開(kāi)發(fā)風(fēng)險，這就要求每次迭代結束必須有一個(gè)可運行、可演示的系統。這時(shí)的系統可能功能上還不完整，僅僅是一個(gè)骨架，但它總是系統開(kāi)發(fā)中最難、最重要也就是風(fēng)險最大的部分。

風(fēng)險驅動(dòng)的迭代是 RUP的核心特征之一，XP 對此強調的不夠，在早期的 XP 項目中主要是客戶(hù)驅動(dòng)的。所以，真正的迭代式開(kāi)發(fā)能夠在項目早期就允許客戶(hù)對可運行的系統進(jìn)行驗證，從而使項目的風(fēng)險減到最小。開(kāi)發(fā)工作也應該根據風(fēng)險的大小來(lái)安排，通過(guò)迭代及時(shí)調整優(yōu)先級，風(fēng)險越大的任務(wù)越應該及早設計、實(shí)現、測試和反饋。

我們知道，RUP 從風(fēng)險驅動(dòng)出發(fā)把一個(gè)軟件項目分為四個(gè)階段：起始階段、細化階段、構造階段和移交階段，這四個(gè)階段分別對應著(zhù)項目的四個(gè)里程碑。起始階段主要消除項目的業(yè)務(wù)風(fēng)險，細化階段應該盡力消除項目的主要技術(shù)風(fēng)險 —— 架構風(fēng)險（同時(shí)包括功能和非功能兩方面）。很遺憾，PRM 項目是在到了項目最后一個(gè)階段：移交階段 —— 在系統運行了幾個(gè)月、數據遷移完成之后才發(fā)現架構設計上存在著(zhù)嚴重的性能缺陷需要修補，而重要的是，在項目之初的合同上其實(shí)就已經(jīng)對數據遷移、上線(xiàn)運行的要求作出了規定?？梢?jiàn)這個(gè)事后暴露的最大架構級風(fēng)險 —— 系統性能否滿(mǎn)足用戶(hù)的真實(shí)需要 —— 直到臨近項目結束也一致未能被消除，也可以這樣認為，實(shí)際上 PRM 項目的“細化階段”并未真正完成，建立穩定、可靠的系統架構的里程碑目標也從未達到。

在項目幾近成功、圓滿(mǎn)結束的時(shí)候，突然爆炸一顆碩大的“地雷”（嚴重的系統缺陷或問(wèn)題），導致項目進(jìn)度拖延甚至失控，干系人失和，資金拖欠，這差不多就是軟件開(kāi)發(fā)中最糟糕的一種情況，在各種經(jīng)典的軟件工程教材中都能看到大量此種案例。不幸的是，歷史再一次地在已經(jīng)（部分）采用了敏捷 XP、RUP 實(shí)踐的 PRM 項目上重演了。那么，我們有沒(méi)有可能事先防范 PRM 項目這顆延遲爆炸的“地雷”呢？

從當年 7 月至次年 5 月 PRM 項目已經(jīng)花了 10 個(gè)月的時(shí)間，卻仍未能通過(guò)客戶(hù)驗收。前期用了 2 個(gè)月完成功能開(kāi)發(fā)，2 個(gè)月部署和試運行，從第 5 個(gè)月完成實(shí)際數據導入、開(kāi)始正式運行起，出現嚴重的性能問(wèn)題，隨后的 6 個(gè)月基本上都用在了系統的性能優(yōu)化和改進(jìn)上?？傮w上有點(diǎn)手忙腳亂、進(jìn)度失控的感覺(jué)，初步估計 PRM 項目的進(jìn)度至少延誤了 100% 以上。

軟件工程不相信眼淚。如果 PRM 團隊和客戶(hù)從一開(kāi)始就意識到了系統潛在的性能問(wèn)題，明確了對系統容量的要求；如果 PRM 系統的架構師擁有足夠的設計經(jīng)驗，系統表示層、控制層和數據資源層在上線(xiàn)之前就已經(jīng)得到優(yōu)化，提供了足夠的性能；如果架構設計評審產(chǎn)生了真正的效用；如果 PRM 團隊做到了完備的系統測試；如果時(shí)間能夠倒流 ...所有這些“如果”當中，只要有一條靈驗，那么那顆可惡的“地雷”不就不復存在了？所以，到底 PRM 項目原本可不可以做得更成功？我想，這是有可能的，我的理由來(lái)自逆向思維：如果 PRM 團隊能夠把這個(gè)項目再重頭做一遍，把這里吸取到的教訓和學(xué)到的軟件工程“新”知識都用上，在 5 個(gè)月內提供滿(mǎn)足客戶(hù)實(shí)際要求的系統應該不再是件很困難的事了吧，至少 PRM 團隊下次再遇到類(lèi)似的項目他們成功的幾率肯定會(huì )大許多。

可見(jiàn)規避風(fēng)險，成熟的軟件工程可以設置幾道防線(xiàn)，采取許多措施。如果 PRM 項目按照 RUP 風(fēng)險驅動(dòng)的迭代方式來(lái)做，其實(shí)從項目一開(kāi)始我們就應該對需求、架構進(jìn)行更為細致、全面的分析，既包括功能，也包括非功能，還可以通過(guò)多次迭代反饋來(lái)確認分析的結果。如果不知道有哪些風(fēng)險，又如何來(lái)防范？所以，關(guān)鍵是要建立一張隨著(zhù)迭代演進(jìn)不斷被動(dòng)態(tài)更新維護的十大（或五大）風(fēng)險清單（RUP 工件叫 Risk List），制定出防范其中所有主要風(fēng)險的預案。

就 PRM 項目而言，功能開(kāi)發(fā)估計不是一個(gè)重大風(fēng)險，因為有舊的 PHP 系統甚至還有源代碼、現成的算法可以參考，而客戶(hù)為什么要啟動(dòng)二期開(kāi)發(fā)，功能目標也是相當明確的。另一方面，J2EE 平臺上的企業(yè)應用開(kāi)發(fā)有哪些風(fēng)險？行業(yè)經(jīng)驗提示我們 J2EE 應用架構設計得不好可能會(huì )存在性能問(wèn)題。故看來(lái)，我們應該把注意力更多放到系統的非功能風(fēng)險上（性能、可靠性、可維護性等等）：客戶(hù)應用訪(fǎng)問(wèn)的最大并發(fā)用戶(hù)數到底是多少，而我們交付到客戶(hù)手里的系統最大容量又是多少？怎樣才能保證系統的性能？如果上線(xiàn)后性能達不到，不能滿(mǎn)足客戶(hù)要求怎么辦？

明確了項目所面臨的重大風(fēng)險，比方系統的性能問(wèn)題，我們就可以根據需求和設計方案制定出完善的、有針對性的測試計劃，包括明確在客戶(hù)可接受的響應時(shí)間要求下，系統最大能夠支持多少個(gè)用戶(hù)的并發(fā)訪(fǎng)問(wèn)（具體可細分為增、刪、改、查等多個(gè)操作類(lèi)型）。明確了項目的風(fēng)險、需求還不行，作為風(fēng)險預案的落實(shí)，我們還應該進(jìn)行系統性能、可靠性等方面的設計，并真正（通過(guò)編碼）做出一個(gè)符合要求的架構（框架）基礎，通過(guò)迭代開(kāi)發(fā)、測試和評審對此進(jìn)行驗證。

在開(kāi)發(fā)階段，系統還未部署，我們無(wú)法獲得真實(shí)的用戶(hù)和使用環(huán)境怎么辦？模擬測試。

我想，如果嚴格按照 RUP 風(fēng)險驅動(dòng)的迭代演進(jìn)式開(kāi)發(fā)進(jìn)行管理，在半年多的時(shí)間里應該還是有機會(huì )盡早發(fā)現這個(gè)問(wèn)題的。原文提到“該項目在系統維護期間，對代碼進(jìn)行走查，修改了很多對于性能有影響的語(yǔ)句”，需要提醒的是，這種方式可以消除局部的缺陷，但卻很難發(fā)現全局性的架構問(wèn)題。對于軟件架構，“頭痛醫頭，腳痛醫腳”的做法往往是行不通的。

作者寫(xiě)道：


PRM 項目雖然模仿了 XP 迭代周期，甚至每天都開(kāi)例會(huì )（這有點(diǎn)像 Scrum），保證了初始版本的準時(shí)交付（在保證 PRM 前期進(jìn)度方面，迭代還是有功勞的），卻仍然沒(méi)有能夠防止較大風(fēng)險的發(fā)生（交付系統幾個(gè)月后才逐漸暴露出性能和架構上的質(zhì)量問(wèn)題），可以說(shuō)這并沒(méi)有達到 XP 或 RUP 迭代開(kāi)發(fā)的最終目的。在項目初期沒(méi)有把合同中已經(jīng)提到的數據遷移視為一個(gè)關(guān)鍵風(fēng)險是前期分析工作或者說(shuō)整個(gè)項目的一大失誤。

2）需求分析的失誤

如果從一開(kāi)始就明確了需求 —— 系統最大要能支持 5000 名用戶(hù)的并發(fā)訪(fǎng)問(wèn)，PRM 項目的麻煩是否就不復存在了!

由于進(jìn)度很緊（看來(lái) 2 個(gè)月交付的進(jìn)度計劃一開(kāi)始就定得不太合理），PRM 團隊以及客戶(hù)都把注意力放在了按時(shí)完成功能上，卻忽視了關(guān)鍵的非功能需求（原文教訓 2 “在需求獲取階段沒(méi)有明確地了解系統的性能指標等非功能需求”），從而導致系統的架構設計不能勝任大量并發(fā)用戶(hù)和大量業(yè)務(wù)數據的處理，這也是導致 PRM 項目失敗的重要原因之一。正是由于需求不完備，沒(méi)有及時(shí)發(fā)現遺漏了關(guān)鍵的、隱蔽的性能需求，才直接導致了項目后期的被動(dòng)。

借鑒了 RUP 用例方法的 PRM 項目為什么還會(huì )出現遺漏關(guān)鍵需求的狀況？雖然 PRM 團隊采用了用例來(lái)管理需求，在嚴格性、需求的精度上比 XP 進(jìn)了一步，但缺點(diǎn)在于只重視了描述功能需求（用例），忽視了提取非功能需求。完善的需求工程，比如 RUP 的需求科目，非常強調捕獲非功能需求，RUP 中的完整需求工件集是由《用例文檔》和《補充規約》兩部分組成的。系統級非功能需求主要在《補充規約》中描述，包括 FURPS+（特性、易用性、可靠性、性能、可維護性）等許多方面。除了《補充規約》，我們還可以在用例的“特殊需求”、“非功能需求”、“約束”、“業(yè)務(wù)規則”等字段中明確地說(shuō)明每個(gè)具體用例的非功能需求。這些要求都是顯示說(shuō)明的，也就是說(shuō)如果程序員認真看過(guò)、學(xué)習過(guò)這些經(jīng)驗指南，應該是不大容易忘記的。項目一開(kāi)始，需求定義不完整、不明確、不一致沒(méi)有關(guān)系，在敏捷迭代開(kāi)發(fā)中，RUP 的需求分析不是一次性完成的，而是通過(guò)多次迭代和演進(jìn)逐步清晰、完善和穩定下來(lái)的?？上?PRM 項目的客戶(hù)參與度不夠，整個(gè)開(kāi)發(fā)過(guò)程也似乎缺少正式、規范的需求驗證和評審過(guò)程，這些因素綜合作用才導致在系統部署上線(xiàn)之前的很長(cháng)一段開(kāi)發(fā)時(shí)間內 PRM 團隊始終沒(méi)有能及時(shí)發(fā)現遺漏的關(guān)鍵非功能需求，給項目成功造成很大的隱患。本案再次向我們強調了全面、細致需求分析的重要性。

讀者可能會(huì )問(wèn)，如果 PRM 團隊當初采用 XP 的用戶(hù)故事來(lái)描述管理需求，結果會(huì )怎樣？我的估計是：可能更糟。XP 采用非正式的、寫(xiě)在索引卡片上的用戶(hù)故事來(lái)定義需求，短短只有幾句話(huà)，而且要求寫(xiě)得簡(jiǎn)單不能再簡(jiǎn)單，大部分內容應該放在腦子里，通過(guò)程序員與客戶(hù)的口頭交流和實(shí)際的程序來(lái)細化，故而我猜測像并發(fā)用戶(hù)數、頁(yè)面一次顯示的記錄個(gè)數之類(lèi)的非功能約束往往很難通過(guò)這些簡(jiǎn)單的用戶(hù)故事句子被發(fā)現。我們知道只有通過(guò)細致認真、全面成熟的需求分析、需求工程方法，才有可能捕獲許多潛在的、隱蔽的需求。為什么 XP 對待需求可以如此隨意和輕松？這是因為，在明確的干系人責權利法則庇護下，XP 項目擁有認真負責、全身心投入、專(zhuān)業(yè)素質(zhì)很高的現場(chǎng)客戶(hù)。加上，系統級認可測試也是在客戶(hù)的積極參與和主導（授權）下編寫(xiě)，測試驅動(dòng)下的 XP 要求測試方案、測例相當完備和詳盡，基本上可以起到取代詳盡需求、保證項目成功的作用，XP 用詳盡的測試代替詳盡的需求，這才有可能在很大程度上減少因遺漏需求導致項目失敗的風(fēng)險。而且，即使項目出現了風(fēng)險、遇到麻煩，對于客戶(hù)驅動(dòng)下的 XP 項目，客戶(hù)至少也應該承擔起 50% 以上的責任。

事實(shí)表明 PRM 團隊既沒(méi)有做到 XP 的測試驅動(dòng)、現場(chǎng)客戶(hù)，也沒(méi)有做到 RUP 的結構化需求分析（用例加非功能）和完備測試，所以 PRM 系統風(fēng)險兌現、遭到失敗看來(lái)是偶然中的必然。

3）不成熟的開(kāi)發(fā)過(guò)程

PRM 項目靈活采用了若干敏捷做法，因而在項目開(kāi)發(fā)進(jìn)度的控制上的確取得了局部成功 —— 項目前期進(jìn)度得到了保證，按時(shí)交付了系統的功能。然而，質(zhì)量、內容和速度永遠是個(gè)矛盾。由于風(fēng)險管理沒(méi)有到位，PRM 項目看似滿(mǎn)足了合同的進(jìn)度要求，卻在項目后期遇到麻煩，客戶(hù)不滿(mǎn)意系統的質(zhì)量，由于交付了一個(gè)不符合客戶(hù)性能要求的系統架構，項目完成的總體進(jìn)度實(shí)質(zhì)上是遠遠拖后了。

從以上的討論我們發(fā)現，把本案的失敗歸結為敏捷、XP 或 RUP 的失敗其實(shí)是不公平的。PRM 團隊采用的是 XP 過(guò)程嗎？不是。理由:現場(chǎng)客戶(hù)、測試驅動(dòng)、結對編程、頻繁重構是 XP 的幾個(gè)核心特點(diǎn)，在這幾個(gè)方面 PRM 團隊沒(méi)有做到或者雖然嘗試了卻沒(méi)有達到 XP 的要求。PRM 團隊做到了每日晨會(huì )、持續集成、小步發(fā)布和部分的自動(dòng)測試，這些實(shí)踐其實(shí)是大部分敏捷迭代方法所共有的特點(diǎn)，它們很重要也很基礎，但僅僅做到這些，離真正的 XP 其實(shí)還很遠。

PRM 團隊采用的是 RUP 過(guò)程嗎？顯然也不是，盡管他們做了并不充分的用例分析和架構設計。幾條理由：PRM 團隊沒(méi)有采用風(fēng)險驅動(dòng)的迭代式開(kāi)發(fā)，自始自終進(jìn)行有效的項目風(fēng)險管理；PRM 團隊沒(méi)有實(shí)現通過(guò)細化階段獲得穩定、可靠的系統架構的里程碑目標；沒(méi)有充分的證據說(shuō)明 PRM 項目開(kāi)展了有效的需求驗證、迭代與階段評審。

PRM 團隊做到敏捷了嗎？從實(shí)際效果來(lái)看，該項目差不多延期了 100%，這顯然不能算是一個(gè)“敏捷”的過(guò)程。PRM 項目失敗難道是因為采用了敏捷方法嗎？不是，PRM 項目恰恰是因為沒(méi)有做到真正的敏捷才會(huì )失??！PRM 團隊對 RUP、XP 的定制、裁剪和整合成功嗎？No，他們沒(méi)有領(lǐng)會(huì )敏捷的原則，定制出來(lái)的 PRM 過(guò)程遺漏了 RUP、XP 當中最核心的東西。我們在實(shí)施軟件過(guò)程改進(jìn)的過(guò)程中，往往容易機械地理解一些軟件過(guò)程的規范和教科書(shū)，單純地學(xué)習某些具體、個(gè)別的做法，卻忘卻了軟件工程的基本原則，沒(méi)有從根源上明白 XP、RUP 為什么要這樣做。

我們發(fā)現 PRM 項目在軟件開(kāi)發(fā)過(guò)程的需求、架構與測試三個(gè)核心關(guān)鍵環(huán)節都存在著(zhù)明顯的缺陷。Johnson 寫(xiě)到“主要（失?。┰蛟谟陧椖块_(kāi)發(fā)商之前沒(méi)有大規模業(yè)務(wù)系統開(kāi)發(fā)的經(jīng)驗，對于非功能性需求沒(méi)有足夠的重視；同時(shí)，在測試階段，也沒(méi)有對于系統負載和性能做過(guò)測試。”PRM 項目做到了單元測試、集成測試，卻缺少部署上線(xiàn)之前的系統級性能測試和壓力測試。與其說(shuō) PRM 團隊沒(méi)有大規模業(yè)務(wù)系統開(kāi)發(fā)經(jīng)驗（事實(shí)說(shuō)明大家的技術(shù)技能還是很不錯的，出現的一些問(wèn)題后來(lái)也逐步得到了糾正），還不如說(shuō) PRM 項目的開(kāi)發(fā)過(guò)程不盡完善，缺乏對實(shí)施規范軟件工程（需求、架構、測試、評審）必要性和重要性的強烈意識。難道是被個(gè)別敏捷極限過(guò)程的不當宣傳迷惑了？

如果 PRM 團隊事后總結自己的項目過(guò)程教訓，相信他們會(huì )贊成完善項目的開(kāi)發(fā)過(guò)程和制度規范將在很大程度上可以避免類(lèi)似情況的再度發(fā)生。如果通過(guò)迭代交付，使系統盡早進(jìn)行數據遷移、容量負載方面的試驗（既然合同上已經(jīng)明確提到了這個(gè)需求），并通過(guò)嚴格的需求和架構設計評審，解決頁(yè)面顯示和并發(fā)用戶(hù)訪(fǎng)問(wèn)的性能問(wèn)題就將更加從容。

4）架構與重構

...

曾經(jīng)有朋友告訴我這樣一個(gè)真實(shí)的故事。在進(jìn)度高壓下有一位架構師成功開(kāi)發(fā)了 1 個(gè) J2EE 應用系統，正當他為此興高采烈時(shí)，客戶(hù)卻告訴他原來(lái)的性能要求需要修改 —— 平均響應時(shí)間應該從 15ms 減少為 5ms（注：虛構數據）。這時(shí)他才發(fā)現原來(lái)自己辛辛苦苦花了 3 個(gè)月時(shí)間設計出來(lái)的架構對于這樣一個(gè)性能指標的調整完全不能適用，需要推倒從來(lái)，此時(shí)他的心情是何等沮喪可想而知。

PRM 項目的性能出現問(wèn)題是在系統交付幾個(gè)月之后，如果事先沒(méi)有根據合同（客戶(hù)契約），經(jīng)過(guò)充分的架構設計和評審，誰(shuí)知道以后還會(huì )發(fā)生什么情況，誰(shuí)又能保證今后不會(huì )出現類(lèi)似的或新的問(wèn)題？

5）溝通的問(wèn)題

—— 對客戶(hù)的啟發(fā)、引導、反饋和協(xié)作不夠

原文寫(xiě)到：


客戶(hù)代表，以及作為“現場(chǎng)客戶(hù)”替代者的開(kāi)發(fā)商客戶(hù)經(jīng)理沒(méi)有依據迭代計劃和迭代評審及時(shí)提供反饋，這也是導致 PRM 項目失敗的重要原因?？蓡?wèn)題是：PRM 項目有沒(méi)有可能做到真正的“現場(chǎng)客戶(hù)”？我看可能性不大?，F階段，國內項目完全實(shí)施 XP 現場(chǎng)客戶(hù)的實(shí)踐難度較大，因而我們不能指望通過(guò)現場(chǎng)客戶(hù)來(lái)提高項目的成功率，而實(shí)際上十多年來(lái)國內外很多成功的項目也沒(méi)有或者沒(méi)有必要做到現場(chǎng)客戶(hù)。當然 XP 的反饋環(huán)也不一定要全部通過(guò)現場(chǎng)客戶(hù)來(lái)實(shí)現，它只是達到明確需求、強化反饋、落實(shí)客戶(hù)驅動(dòng)責任的一種形式，在不同條件下可以有不同的變通處理方式。對于 PRM 項目而言，我以為在迭代周期中引入由客戶(hù)參加的正式架構評審（RUP 推薦的實(shí)踐），使關(guān)鍵性能問(wèn)題能夠被盡早發(fā)現或預見(jiàn)到，可能比現場(chǎng)客戶(hù)起到的作用更大。

人們常常愛(ài)說(shuō)“客戶(hù)就是上帝”，從事軟件工程千萬(wàn)不能抱有這樣的觀(guān)念，這其實(shí)是一種欺騙 ——因為“上帝”顯然是無(wú)所不能、無(wú)所不知的，而客戶(hù)絕不是萬(wàn)能的，他/她們經(jīng)常會(huì )犯錯誤，很多技術(shù)內幕細節客戶(hù)不了解、不知情，也不可能比開(kāi)發(fā)商更懂軟件。所以，我們一方面不能等著(zhù)客戶(hù)來(lái)主動(dòng)告訴我們應該如何去做，另一方面也不能對客戶(hù)百依百順，客戶(hù)意見(jiàn)照單全收，不然結果只能是自吞苦果。成熟的軟件工程更應提倡“客戶(hù)是朋友、合作伙伴”的正確觀(guān)念。只有通過(guò)規范正確的軟件工程過(guò)程和項目管理措施，在客戶(hù)和開(kāi)發(fā)商之間建立起良好、透明的溝通橋梁和協(xié)作機制，雙方將心比心，互相理解、引導和啟發(fā)，才能增加共贏(yíng)取勝的機會(huì )。

這里，我還想起了 D. Dikel 在《軟件架構：組織原則與模式》中總結的架構組織反模式。不幸的是，本案的情況好象正好符合書(shū)中的“電話(huà)鈴未響”和“遺漏的部分”兩個(gè)反模式—— 由于“電話(huà)鈴一直未響”，在開(kāi)發(fā)過(guò)程中客戶(hù)溝通不暢（很可能是因為客戶(hù)放心地認為開(kāi)發(fā)商及其客戶(hù)經(jīng)理非常了解業(yè)務(wù)，所以不愿親自操心），項目組也就沒(méi)有預見(jiàn)到在數據遷移后的大用戶(hù)量情況下可能出現的問(wèn)題并提前采取措施；項目組知道了明確的用戶(hù)需求（合同規定的大致內容），卻遺漏了為了向客戶(hù)提供有價(jià)值的東西（合同之外隱蔽的需求）所應該做的事情（調整架構，數據庫優(yōu)化，確保運行等等）；結果造成系統雖然及時(shí)交付了功能，卻由于缺少一些客戶(hù)必需的關(guān)鍵非功能特性（保證大數據量處理和客戶(hù)端顯示的良好性能）無(wú)法被客戶(hù)所接受，用戶(hù)得到的是不完整的解決方案，它帶來(lái)的負面影響足以超過(guò)任何已完成的新功能的價(jià)值（不滿(mǎn)意的失去信任感的客戶(hù)不愿支付尾款）?；叵肫饋?lái)，PRM 系統遺漏的這些細節卻似乎又都是顯而意見(jiàn)的。如何避免重蹈覆轍？書(shū)中建議，需求調研的“覆蓋面很重要”，“規范的東西可以確保沒(méi)有東西被遺漏”，采取措施讓客戶(hù)參與協(xié)作，了解你的受益人、架構評審和客戶(hù)互動(dòng)等模式也有助于預防此類(lèi)問(wèn)題的發(fā)生 ……

6）客戶(hù)合同的問(wèn)題

根源之一：客戶(hù)合同契約的壓力、無(wú)奈與缺陷

我們知道，作為使用者代表的客戶(hù)方高層領(lǐng)導及 IT 部門(mén)負責人，負責銷(xiāo)售和協(xié)商簽訂合同的開(kāi)發(fā)商客戶(hù)經(jīng)理/產(chǎn)品經(jīng)理，以及開(kāi)發(fā)商內部負責系統實(shí)現的項目經(jīng)理/架構師，這幾方重要的干系人之間能否對合同的范圍和技術(shù)可行性進(jìn)行充分的溝通，達成清醒的共識，對項目的最終成敗起到至關(guān)重要的影響。

從原文分析看，這份客戶(hù)合同明顯存在著(zhù)缺陷。它對需求的理解是片面的（“主要描述的是系統功能性的需求，而沒(méi)有非功能性需求的規定”），對進(jìn)度計劃也過(guò)于樂(lè )觀(guān)。事后看，即使用去了 10 個(gè)月，開(kāi)發(fā)商也付出了不懈的努力，客戶(hù)仍不愿意驗收和支付尾款，顯然項目的實(shí)際進(jìn)度已經(jīng)遠遠超出了當初的估計（延誤了將近 100%）。既然如此，何必當初？

我看一開(kāi)始，PRM 團隊其實(shí)并沒(méi)有必要心急火燎地趕在 2 個(gè)月內交付系統，當然，如果開(kāi)發(fā)商狠下決心一定要拿下這單，即便沒(méi)有條件也要創(chuàng )造條件，抱著(zhù)“人定勝天”的豪情壯志甩開(kāi)干，也是可以理解的，關(guān)鍵就看老板如何權衡風(fēng)險與收益了?？墒聦?shí)又如何呢？我覺(jué)得如果事先能多做些客戶(hù)的工作（早期客戶(hù)一般都對開(kāi)發(fā)商充滿(mǎn)著(zhù)期盼和信任），爭取把合同進(jìn)度和條款定得寬松一些，把數據遷移和系統驗收/β 測試以及適當的返工時(shí)間和必要的補償措施也考慮在內，給雙方留有一定的余地，把基礎打好、做得更扎實(shí)一些，結果就可能要樂(lè )觀(guān)得多，雙贏(yíng)的把握也更大。

當然，對此我們可能有些一廂情愿 —— 明白、明白，國內的軟件開(kāi)發(fā)項目進(jìn)度往往是超奇的緊，所以整個(gè)行業(yè)不是一直都在呼喚著(zhù)天降“奇才”和“天才”嗎？為了應對激烈競爭，贏(yíng)得商機，開(kāi)發(fā)商往往對項目的前景作出過(guò)于樂(lè )觀(guān)的估計，而客戶(hù)也往往對軟件開(kāi)發(fā)的復雜性估計不足，甚至憑借買(mǎi)方市場(chǎng)優(yōu)勢對開(kāi)發(fā)商要求過(guò)于苛刻，這些因素迫使開(kāi)發(fā)商哪怕項目不行也要縮短工期、壓低報價(jià)硬著(zhù)頭皮上，違背軟件工程客觀(guān)科學(xué)規律的結果必然是兩敗俱傷?？陀^(guān)地講，在制造“神奇”的軟件進(jìn)度這方面，客戶(hù)的責任，或者說(shuō)客戶(hù)的領(lǐng)導以及領(lǐng)導的領(lǐng)導的責任，可能更大些。

然而，這不意味著(zhù)在此種“極限”情況下，規范的軟件工程就無(wú)能為力了，我們也沒(méi)有必要做出正確的項目估算和計劃。如果開(kāi)發(fā)商有了充足的理由和數據支持，至少可以據理力爭，在客戶(hù)知情的情況下有意而為之、防范于未然，總比最后因項目超時(shí)超支的地雷意外爆炸而驚慌失措、亡羊補牢要好得多。

7）OOAD、設計模式與數據庫設計的關(guān)系

（對 Johnson 的教訓三、四的補充）

面向對象的軟件分析設計技術(shù)（OOAD）與數據庫設計、優(yōu)化技術(shù)并行不悖，兩種技術(shù)解決的是不同領(lǐng)域的問(wèn)題，在軟件開(kāi)發(fā)項目的管理中應該并重。從系統工程的角度看，無(wú)論應用軟件部分的開(kāi)發(fā)采用的是傳統結構化還是新型結構化（OO）技術(shù)，數據庫和 DBA 的效能作為一個(gè)相對獨立的子系統，對于企業(yè)應用這個(gè)大系統而言始終都是關(guān)鍵因素，對系統的整體性能和質(zhì)量均有著(zhù)重要而直接的影響。

有些人可能認為 RUP、XP 等過(guò)程方法對數據庫介紹的篇幅不多，數據庫技術(shù)對于軟件開(kāi)發(fā)方法論好像就不重要了，這完全是一種誤解。同時(shí)，面向對象方法同樣可以設計出高性能、高可靠的應用軟件，兩者并不矛盾。當然，我們也不能過(guò)度使用設計模式，應該避免在錯誤的場(chǎng)合運用模式（這恰好是一種反模式）。

8）工具的局限性

我們看到 PRM 項目采用了不少先進(jìn)的 CASE 工具（例如 Rational ClearCase、ClearQuest、Robot）進(jìn)行代碼、缺陷和測試等管理，應用水平在國內當屬領(lǐng)先。自動(dòng)化軟件工程工具對于提高效率、保證進(jìn)度必不可少，然而工具的作用是有限的，工具被動(dòng)地為人服務(wù)，它們不能替代正確、完善的軟件項目管理和開(kāi)發(fā)工藝流程。本案恰好說(shuō)明軟件開(kāi)發(fā)團隊即使使用再好的工具（“銀彈”？），也無(wú)法彌補、挽救其在做事方式、開(kāi)發(fā)方法和技能上存在的缺陷，歸根結蒂還是人的因素。

總結

PRM 案例非常典型，給我們的教訓也是非常深刻的。我想它遇到麻煩的一些主要原因在于風(fēng)險管理缺位，前期需求分析、架構設計不足，加上系統測試不完備，迭代式開(kāi)發(fā)也沒(méi)有起到應有的積極反饋效果，結果造成雖然 PRM 系統被按時(shí)交付使用，但是一些關(guān)鍵性能需求（開(kāi)發(fā)中的系統到底能支持多少并發(fā)用戶(hù)）被進(jìn)度“順利完成”的假象掩蓋了，導致系統上線(xiàn)運行后才暴露出性能和架構設計上的嚴重缺陷，既導致客戶(hù)不滿(mǎn)，也給開(kāi)發(fā)商造成了很大被動(dòng)。這正是我們通常不愿看到的軟件開(kāi)發(fā)最糟糕的一個(gè)結果，可謂一個(gè)雙輸的經(jīng)典案例。通過(guò)討論，我們發(fā)現采用成熟的軟件工程/過(guò)程實(shí)踐，設置幾道風(fēng)險防線(xiàn)，原本可以顯著(zhù)地降低本案失敗的幾率。

為什么一個(gè)采用 XP、RUP、敏捷實(shí)踐的項目也會(huì )失敗呢？軟件過(guò)程的沙盤(pán)推演是一回事，軟件過(guò)程在實(shí)際項目中的執行則是另外一回事，后者充滿(mǎn)了各種荊棘坎坷和難以預料的風(fēng)險。本案還反映了在 XP、UP 和敏捷過(guò)程應用中存在的一些典型陷阱。我們不能因為 XP 強調敏捷、極限，就天真地省略成熟軟件過(guò)程的一些關(guān)鍵環(huán)節和必要步驟，敏捷并不等于極限，這方面適應面更廣的 UP 框架能給我們較大的幫助。我們不能只學(xué)習 XP、UP、敏捷過(guò)程的表面知識，應該注重掌握軟件工程的基本原則和軟件過(guò)程的核心設計思想。在未理解 XP、RUP 和敏捷過(guò)程精神實(shí)質(zhì)的情況下，僅憑一腔熱情而不顧具體適用條件，盲目地裁減、定制、修改自己團隊的軟件過(guò)程有的時(shí)候是相當危險的，本案恰好沒(méi)能避免此種風(fēng)險的發(fā)生。所以，把本案的失敗歸罪于 XP、RUP 或敏捷過(guò)程等方法本身的缺陷顯然是缺乏依據的，本案可以歸結為敏捷、統一過(guò)程實(shí)施的失敗。

本案還提醒我們不能把項目的成功完全寄希望于事后重構（除非你“藝高人膽大”），針對架構打補丁實(shí)在是很不劃算、很不聰明的做法，架構級的重構可能會(huì )讓組織和個(gè)人冒很大的風(fēng)險（一旦架構瓦解）。PRM 項目說(shuō)明等到架構級風(fēng)險發(fā)生了，再去重構、彌補，將要付出怎樣的代價(jià)。相信 PRM 團隊與越來(lái)越多的讀者會(huì )接受我的建議：寧可與客戶(hù)一道多花些精力做好前期工作，尤其要掌握相對全面的需求分析和風(fēng)險管理方法，做到善于發(fā)現風(fēng)險、捕捉潛在的需求問(wèn)題，把握好軟件設計的兩面 —— 前構與重構的平衡。