現代軟件工程講義 8 軟件的血型

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

一個軟件團隊經歷了計劃/設計/開發等階段, 達成代碼完成 (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趨勢圖，橫坐標是構建的版本號

招數: 砍掉功能

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

砍！

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

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

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

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

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

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

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

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

招數: 逐步凍結

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