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

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

一個軟體團隊經曆了計劃/設計/開發等階段, 達成程式碼完成 (Code Complete) 這一目標，似乎後面的事情就水到渠成了.  其實不然, 軟體生命週期的最後階段往往是最考驗團隊的，不但考驗Team 專案管理水平，應變能力，也考驗團隊的血型。 原計劃的軟體發布時間快到了，但是軟體還是有這樣那樣的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), 在新代碼分支裡開發下一個版本的功能。

 

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