本章主要介紹軟件項目的會診（Triage），軟件按時發(fā)布的招數(shù)：DCR、ZBB，以及項目的總結(jié)和回顧。
15.1 從代碼完成到發(fā)布
從軟件的代碼完成（Code Complete）到最后發(fā)布，我們要經(jīng)歷哪些步驟，先了解一下幾個基本概念：
Alpha：指集成了主要功能的第一個試用版本。在這個版本中有些小功能并未實現(xiàn)。事實上很多軟件的Alpha版本只是在內(nèi)部使用。給外部用戶使用的Alpha版本會起一個比較美妙的名字，例如，技術(shù)預(yù)覽版（Tech-nical Preview），等等。
Beta：功能基本完備，穩(wěn)定性較Alpha版本高，用戶可以在實際工作中小范圍使用，可以有Beta1、Beta2、Beta3……
ZBB（Zero Bug Build）：某天的版本要把在之前（例如48小時前）記錄的Bug都解決掉。
RC（Release Candidate）：發(fā)布候選版本，RC1、RC2……直到RTM為止，版本間隔時間較短。
RTM（Release To Manufacturer）：最終發(fā)布版本。如果某一個RC版本沒有很大的問題，那么這一RC就會成為最終的版本，通常情況下，軟件公司會把最終的版本和相關(guān)的文件及其他資料交給另一個團隊（Manu-facturer）去包裝、刻制光盤。在AppStore/Marketplace的年代，我們有相應(yīng)的RTM（Release To Market）。
RTW（Release To Web）：和RTM類似，對于網(wǎng)絡(luò)應(yīng)用來說，我們無須依賴“Manufacturer/Market”制作軟件的光盤或者管理軟件的發(fā)布渠道，但是要依賴“Web”來發(fā)布我們的最終版本。如果軟件產(chǎn)品是一個網(wǎng)站服務(wù)，則一般會交給網(wǎng)站運營團隊（Opera-tion Team）去管理，這樣的發(fā)布也可以叫做RTO（Release To Operation），運營團隊和研發(fā)團隊一起決定什么時候系統(tǒng)上線（Go Live）。把軟件提交到各個應(yīng)用商店則可以稱為Release To Store。
15.1.1 會診小組（Triage Team）
軟件團隊的各個角色代表（PM/Dev/Test/UX等）組成了會診小組，處理每一個影響產(chǎn)品發(fā)布的問題。
修復(fù)（Fix）//小組同意修復(fù)一個問題。
設(shè)計本來如此（As Designed）//用戶或測試人員可能對功能有誤解，或者功能的解釋不完備。
不修復(fù)（Won't Fix）//這是一個問題，但是這個軟件版本不打算修復(fù)。
推遲（Postpone）//如果我們的軟件是真正解決用戶問題的，是有價值的，那它一定會有下一個版本。在大型復(fù)雜項目中，軟件團隊還會進行更為復(fù)雜的會診工作。
15.1.2 復(fù)雜項目的會診
第一步：開發(fā)者提交參加會診的Bug和修改方案，以及伙伴測試結(jié)果。
- Bug是什么；
- 危害是什么，如果不修復(fù)，有何后果；
- 用戶會有什么變通辦法；
- 是否經(jīng)過代碼復(fù)審，是否經(jīng)過伙伴測試。
第二步：會議決定是否同意修改方案。決定哪些缺陷必須現(xiàn)在就進行修復(fù)，哪些可以推遲到下一個里程碑。
- Must——必須修復(fù)，缺陷很嚴重，修復(fù)方案可行，相關(guān)的測試都通過。
- More Info——需要更多的信息，可能的原因有：1）缺陷的影響不明確，例如，這個缺陷是在任何情況下都發(fā)生，還是只在某一特定情況下才出現(xiàn)？后果如何？因此不能馬上做出決定；2）相關(guān)的測試不完備；3）解決方案有缺陷（會診會議成員可以復(fù)審解決方案和代碼的改動）。
- No——不能接受，可能是推到下一個里程碑，可能是提出的解決方案不符合要求。
- Like——可能，不一定必須修復(fù)，但是解決方案相對比較安全。
第三步：執(zhí)行。
15.1.3 招數(shù)：設(shè)計變更（Design Change Request， DCR）
經(jīng)過Alpha/Beta階段，得到的用戶的反饋，需要做一些改進工作。項目的當前階段是一個阻尼振蕩的過程，要收斂和穩(wěn)定。等到下一個版本開始的時候再進行發(fā)散的思考。如果你覺得目前的設(shè)計有問題，我們要用DCR來管理。
如何提出DCR？
在DCR的描述文字中，說明：
a. 問題在哪里，問題的影響；
b. 如果不修改，會有什么后果？
c. 幾種修改方案，各種方案的優(yōu)缺點和成本。
如何決定DCR的執(zhí)行次序？
1）會診所有DCR。
2）按照影響、成本排序，得到一個自上而下的名單，根據(jù)現(xiàn)有資源，按照名單執(zhí)行。
15.1.4 招數(shù)：Zero Bug Build，ZBB
ZBB = Zero BugBuild，即這一版本的構(gòu)建把所有已知的Bug都解決掉了。Zero Bug Bounce：通常在一個ZBB之后，Bug數(shù)目會以驚人的速度反彈，故稱Bounce。系統(tǒng)要經(jīng)歷幾次反彈，像阻尼振蕩一樣，Bug的數(shù)目在反彈了幾次之后，最后固定在（或者無限逼近于）0。
15.1.5 招數(shù)：最后回歸測試
項目臨近結(jié)束時，所有人員（開發(fā)、管理、測試）都要回歸測試所有的Bug。每個人都要幫助團隊確保這些Bug的確是被修復(fù)了，而且別的更改沒有導致功能的“回歸”。為便于管理，我們可以考慮新增一個字段，標記某個Bug已做過回歸測試。
15.1.6 招數(shù)：砍掉功能
有一個模塊看來不能實現(xiàn)預(yù)期的設(shè)計需求，時間快到了，怎么辦？砍！
15.1.7 招數(shù)：修復(fù)Bug的門檻逐漸提高
在Beta期間，修復(fù)Bug的門檻要逐漸提高。在Alpha階段，如果開發(fā)人員拿到一個Bug，那他/她就可以馬上去修復(fù)，只是在簽入之后告訴大家做了什么樣的修改。
15.1.8 招數(shù)：逐步凍結(jié)
隨著程序功能的完善，我們要讓程序的各個方面有次序地“凍結(jié)”，這樣才能把穩(wěn)定的軟件交付給用戶。
15.2 不同頻率和不同覆蓋范圍的漸進發(fā)布
上文提到的Alpha，Beta，Beta1，Beta2等發(fā)布方式，發(fā)布的間隔是一個月以上，一般來說，后一個發(fā)布是前一個版本的升級，發(fā)布的目標人群也類似。
以MIUI為例，MIUI有三個更新頻率，一天一更新，面對的用戶大概是幾千個，這個用戶組我們叫榮譽內(nèi)測組；一周一更新，面對幾百萬用戶，這個組叫開發(fā)組；一個月一更新，面對的是90%的普通用戶，有幾千萬，推出的版本叫穩(wěn)定版。
15.3 發(fā)布之后——事后諸葛亮會議
牢記會議的核心問題：“如果你可以重新來過，什么方面可以做得更好？”
例如：軟件發(fā)布后用戶報告了一個大問題?！?strong>為什么？”
因為程序沒有考慮某種邊界條件。“為什么在測試階段沒有測出來？”
因為這個代碼是測試的最后階段才加進去的?！?strong>為什么不通知PM/Test？”
因為Dev認為沒有問題的，是很簡單的修改?！?strong>為什么不通知別人？”
因為Dev認為那些都是軟件工程無聊的規(guī)定……Dev是大牛人，不必遵守的?！?strong>為什么？！”
問到這個層次，就把問題根源暴露出來了。
