[這是 現代軟件工程講義 的一篇]

一個軟件團隊經歷了計劃/設計/開發等階段, 達成代碼完成 (Code Complete) 這一目標，似乎后面的事情就水到渠成了.? 其實不然, 軟件生命周期的最后階段往往是最考驗團隊的，不但考驗團隊項目管理水平，應變能力，也考驗團隊的血型。 原計劃的軟件發布時間快到了，但是軟件還是有這樣那樣的bug，怎么辦？

優秀的軟件團隊會發布有已知缺陷的軟件么?

我覺得和人類血型類似，軟件團隊的“軟件血型”也可以分4種：

??? A型：他們知道優秀的軟件公司會發布有已知缺陷的軟件；

??? B型：他們不相信這一點；

??? O型：他們不知道這一點，因此嘴巴驚訝成O型；

??? AB型：他們對于自己開發的軟件是A型，對于別人開發的軟件是B型。

?

B型的人會發現搞軟件開發是很痛苦的事。要說明的一點是，所有軟件公司都希望能夠把缺陷都改正了才發布軟件，但是第一什么叫“缺陷”？如果只是一些無關大局的問題，用戶可以繞過去的，我們非得馬上解決么？第二什么叫“改正”？如果改正的方案中又有“缺陷”怎么辦？ 做商用軟件的人都在為此苦惱，只有優秀的軟件公司能找到一個平衡點，及時發布能夠解決用戶問題的軟件，并且能及時修改軟件中的問題——注意，這兩個“及時”并不一定是同一個時間。做“大作業”的軟件（比如為了演示、交作業）可以不用管這兩個及時，交了卷，就萬事大吉了。

說到“質量”，我們不提“全面質量管理”，因為“全面”之后，會出現“大道廢，有仁義”的現象，大家都講“全面質量管理”，往往意味著我們的質量管理沒有抓到點子上。而且有些庸人往往會以“高質量”為由，阻礙正常的工作進程。而那些口口聲聲要求“高質量”的人士，往往是出于下列情況：

??? a) 缺乏對用戶、行業、軟件開發的洞察力，對于“高質量”并沒有具體的定義。

??? b) 沒有具體的招數讓軟件達到所謂的“高質量”。

??? c) 害怕真實世界的反饋，因此不發布軟件，能拖一天是一天。

?

可以看看這兩個例子, 推斷出這些團隊的血型:

??? STG 游戲的跳票 （為了完美，推遲了 7 天，但是7天之后也沒有發布…）

??? 英語學習軟件? （說了 “明早發布”，但是明早一直沒到）

有些同學會馬上舉出世界有名的公司推出完美軟件的例子, 例如蘋果， 永遠的毀滅公爵等等…. 請問: iPhone 的第一個版本是完美的么?? 它連 復制/粘貼 的功能都沒有。

?

那么，從軟件的Code Complete 到最后發布, 我們要經歷哪些步驟，有哪些招數讓我們能以比較大的共識，比較小的痛苦走完這血腥的流程，需要什么樣血型，血性的團隊才能按時推出優秀軟件？

?

首先看看一些常用的名詞：

Alpha: 指集成了主要功能的第一個試用版本。有些小功能并沒有實現。事實上很多軟件的Alpha版本只是在內部使用。給外部用戶使用的版本會起一個比較美妙的名字，Technical Preview, 等等。

Beta: 功能基本完備，穩定性較Alpha版本高，用戶可以在實際工作中小范圍使用，可以有Beta1、Beta2、Beta3……

ZBB（Zero Bug Build）: 某天的版本要把在48 小時前記錄的bug 都解決掉。

RC（Release Candidate）: 發布候選版本，RC1、RC2……直到RTM為止，版本間隔時間較短。

RTM（Release To Manufacturer）: 最終發布版本。如果某一個RC版本沒有很大的問題，那么這一RC就會成為最終的版本, 通常情況下，軟件公司會把最終的版本和相關的文件及其他資料交給另一個團隊（Manufacturer）去包裝、刻軟盤、光盤。在AppStore/MarketPlace 的年代 , 我們有相應的 RTM （Release To Market）。

RTW（Release To Web）: 和RTM類似，對于網絡應用來說，我們無須依賴“Manufacturer/Market”來制造軟件的光盤或者管理軟件的發布渠道，但是我們要依賴“Web”來發布我們的最終版本。如果軟件產品是一個網站服務，那軟件系統一般會交給網站運營團隊（Operation Team）去管理，這樣的發布也可以叫做RTO（Release To Operation）, 運營團隊和研發團隊一起決定什么時候系統上線（Go Live）。

?

?

會診小組（Triage? Team）

軟件團隊的各個角色代表 (pm/dev/test/UX 等) 組成會診小組。處理每一個影響產品發布的問題。 打個比喻, 就像醫院的門診或急診室 （Triage Room）, 如果一下蜂擁進來好多病人,? 但是醫院里人手和設備有限, 值班的醫生護士要根據病人的情況安排。? 另一個類似但比較緊急的場景是,? 在戰地醫院里,? 兩次戰斗的間隙, 醫護人員沖上硝煙尚未散盡的戰場搜救傷員,? 有些做簡單包扎即可, 有些要抬擔架, 有些傷情太重的, 只好放下不管了。 大家的血型和勇氣在這一次次的triage 會議中得到了展現。 下面的招數都是在會診小組的領導下進行的。

對于每一個bug, 會診小組要做出下面的決定:

• - 修復
• - 設計本來如此 (as designed)
• - 不修復 (won‘t fix)
• - 推遲 (postpone)??? //如果我們的軟件是真正解決用戶問題的， 是有價值的，那它一定會有下一個版本。

?

招數: 設計變更（Design Chang Request）

經過Alpha / Beta階段，移山團隊收到了不少用戶的反饋，有些是意料之中的，有些是意料之外的。大家都看到，原來的設計也有不少要改進的地方。有了用戶反饋，大家也能夠取得比較一致的意見。另外，大家也有了很多新想法。一時間，眾說紛紜，很多人都嚷嚷著——DCR，DCR!

重寫或者是重構

小飛：我們的某某模塊真是太爛了，我覺得必須重寫，而且現在又有了新的技術叫 “我佩服”（WPF） [或插入任一最近時髦的技術]，它能做很酷的效果，為什么不呢？

二柱：我們先要看看，原來爛到什么程度，現在是否能完成功能？你所說的問題有多嚴重？是功能不能實現？或者界面有問題？或者不能擴展（例如：不能支持更多用戶）？

大栓：另外，是重構，還是重寫？

重構——在盡量保持原有界面的基礎上優化部分代碼。

重寫——重新實現原有功能，同時，要分清是全部重復原有功能，還是偷偷加上許多新的功能（Feature Sneak）？

小飛：咱們找領導去，超總，看看我新寫的功能。

阿超：你不是在修理這個模塊的 bug 么？怎么開始寫新的功能了？

小飛：對，但是你是不是覺得我加的這個新功能很酷，嗯……現在是有點慢，但是如果數據庫再做一些對應的修改，比如增加一個緩沖之類的，那就更好了。

阿超：用戶提到了這個功能么？這和我們項目的遠景有什么關系？數據庫修改后，原來的用戶數據要如何遷移到新的Schema下面？

小飛：嗯，但是用戶如果看到了，就會喜歡的。

阿超：很多程序員有這樣的沖動，在做修改的同時，想到自己還能做更多的事，有一個“東西”一直想做，但是提出幾次都沒人重視，那現在有機會，就 “加進去” 算了?；蛘哌€有很多靈機一動的想法。打一個比喻——本來是要修廚房頂上一個有時漏水的水管，結果修理工來了，修好了水管，同時靈機一動，加了一個帶淋浴的豪華衛生間。

小飛：但這畢竟是新的想法，我以為你會喜歡的。

阿超：記住我們在項目的當前階段是一個阻尼振蕩的過程，要收斂和穩定。等到下個版本開始的時候再進行發散的思考吧。如果你覺得目前的設計有問題，我們要用DCR 來管理。

對所有提出來的問題都列表（標題注明 Beta Feedback），阿超給大家列出了DCR的要點：

（1）如何提出DCR？

??????? a. 在提交一個DCR的時候，選用任務作為工作件類型，并在標題中標明：DCR。

??????? b. 在DCR的描述文字中，說明：

??????????????? i. 問題在哪里，問題的影響；

??????????????? ii. 如果不做修改，會有什么后果？

??????????????? iii. 幾種修改的方案，各種方案的優缺點，以及成本。

（2）如何決定DCR的執行次序？

??????????? a. 會診所有DCR。

??????????? b. 按照影響、成本排序，得到一個自上而下的名單，根據現有資源，按照名單執行。

另外, 適合在Beta分支實現的修改并不一定適用于主分支（Main Branch）, 我們要做好源代碼管理。

?

招數: ZBB

團隊要有把bug 都搞定的執行力。ZBB = Zero Bug Build，即這一版本的構建把所有已知的Bug都解決掉了。

Zero Bug Bounce：通常在一個Zero Bug Build之后，Bug數目會以驚人的速度反彈，故稱Bounce。系統要經歷幾次bounce，像阻尼震蕩一樣，Bug的數目在反彈了幾次之后，最后固定在（或者無限逼近于）0。

要注意必須要保證Bug的數量到0，以防止一些問題拖而未決, 有些bug 長期拖而未決,? 其實它們掩蓋了深層次的設計問題, 要早把這些問題暴露出來, 而且劃定一個時間期限, 一定要解決。

下圖是一個60人的團隊的“預想ZBB 進軍圖”。每個小組的Bug數量累加起來，就是團隊的Bug總量。下圖中的黑線表明修復的Bug總量。

項目ZBB = 此次構建中所有兩天 (48 小時)以前報告的缺陷都已經處理。

移山公司的例子：

第一個ZBB達到了，同時產生了一個ZBB 的構建，由于這個構建質量很好，因此測試團隊鉚足了勁把各個部分都測試了一遍。同時也測試了復雜的場景，進行了效能和壓力測試。結果報告出來不少新問題。因此ZBB 之后的 Bounce 就跳得特別高。第二次ZBB 后，由于各個模塊質量的提高，這一次的反彈就低很多，隨著每次ZBB 過程中質量的加強，Bug 的數目會越來越少。同時也有幾個功能被砍掉，這些功能的Bug 也就不計入總數。下面ZBB 的趨勢圖顯示了Bug 經過幾次反彈，逐漸到0的情況。

圖15-9 bug ZBB趨勢圖，橫坐標是構建的版本號

?

招數: 砍掉功能

有一個模塊看來不能實現預期的設計需求，時間快到了，怎么辦？

砍！

蕓蕓：可是我們花了很多心血才把設計做到目前的地步，好像再努一把力，就可以成功了?，F在撤退，我真是不忍心呀，這不是浪費以前的投入么？

果凍：對呀，我們可能只需要額外的三天，不，只要額外的三個通宵就可以了。再說我們可以以后接著修復任何新問題。

阿超：這些話好像有理，但是細一想，都沒道理。蕓蕓，你聽說過? “沉沒成本（Sunk Cost）”? 這個詞沒有？沒有的話，應該上網查一查，好好學學。果凍，從你做事的歷史來看，如果類似的功能需要N個單位時間才能最終完成，那么我們沒有理由相信新功能會花少于N個單位時間。我們再回顧一下以前看過的功能/資源/時間的平衡圖, 我們要不斷保持這些因素的平衡:

?

?

招數: 修復bug 的門檻逐漸提高

在beta 期間,? 修復bug 的門檻要逐漸提高,? 昨天修復了同樣類型的bug, 今天如果還找到了類似的問題, 團隊未必要修復。 在RC 階段, 只有影響巨大的bug 才能修復。 其它優先級較低的的bug 就只好在一邊等著。 如果有嚴重的bug 要修復, 那么這些不嚴重的bug 也許有機會跟著一起修復。

在alpha 階段, 如果開發人員拿到一個bug, 那他/她 就可以馬上去修復, 只是在簽入之后告訴大家做了什么樣的修改。

在beta 階段, 在新代碼簽入之前, 就要告訴會診小組這個修改潛在的風險是什么, 如何應對，等等。

在RC 階段,? 開發人員拿到 bug 進行修復工作之前,? 就要和會診小組溝通,? 看看這個bug 是否值得花時間。

?

?

?

?

招數: 逐步凍結

隨著程序功能的完善，我們要讓程序的各個方面有次序地“凍結”，這樣才能把穩定的軟件交付給用戶。一般來說，程序的人機交互界面最先開始“凍結”，不能再隨意修改，因為很多項目的文字信息要被本地化成多種語言，當人機界面所用的文字和排版（layout） 固定后，我們才能把這些文字交給負責本地化的部門。隨著時間的推移，一些功能也可以“凍結”，這些功能都經過全面測試，所有的Bug 都解決了，功能進入穩定狀態。在下一個版本前不要再碰和此功能相關的代碼。如果有新的功能要寫怎么辦?? 那就把源代碼分支 (fork), 在新代碼分支里開發下一個版本的功能。

?

[注: 大部分內容來自 移山之道]

?

總結

以上是生活随笔為你收集整理的现代软件工程讲义 8 软件的血型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。