現代軟件工程講義 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), 在新代碼分支裏開發下一個版本的功能。

 

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