15.10 會診（Triage）
15.10.1會診Bug
在這一階段，移山團隊開始了每日會診。目的是要盡快減少bug 的數(shù)量，以保證按期交貨。
第一步：提交參加會診的bug。
bug的各個字段都要提供詳盡的信息。每個測試人員和PM要努力使得提交的bug不會出現(xiàn)下面的情況：
重復（Duplicated）：已經(jīng)有人報告了同一個小強。
無效（Obsolete）：報告的情況是關于無效的軟件功能的（如已經(jīng)被砍掉的功能）。
無法重現(xiàn)（Unable to reproduce）：沒辦法重現(xiàn)犯罪現(xiàn)場。這個小強還是有價值的，因為有些小強就是隨機發(fā)生的，但是測試人員要和開發(fā)人員一起找到bug發(fā)生的原因。
第二步：決定bug的命運。
如果決定修改，我們要設置優(yōu)先級，并把它分派給團隊成員。
如果同意可以不修改，則有下面的選擇：
a. 設計（As Designed）：程序就是這么設計的；
b. 推遲（Deferred）：推遲到下一階段，再處理。
第三步：會診設置 bug 的優(yōu)先級Priority，然后設置bug的會診（Triage） 字段為yes。表明已經(jīng)經(jīng)過了會診。
二柱：優(yōu)先級還要規(guī)定？這些都是要在RTM 之前完成的，都是優(yōu)先級1。
阿超：首先，我們從來沒有規(guī)定RTM 之前要完成多少bug，事先假設我們必須全部完成是不對的。注意，如果所有的事都是最高優(yōu)先級，那就等于沒有優(yōu)先級。決定一件事是一個較低的優(yōu)先級，需要很多勇氣。
15.10.2會診修改方案（BugFix）
在穩(wěn)定階段的初期，團隊只要決定哪些缺陷需要修復，然后團隊成員就會進行必要的設計—實現(xiàn)—測試工作，把修改簽入。但是隨著項目進展和發(fā)布日期的臨近，團隊還要保證修改方案不會給產(chǎn)品帶來負面的影響。這時，要對修改方案也進行會診。這也有三個方面：
第一步：開發(fā)者提交參加會診的bug和修改方案。
第二步：會議決定是否同意修改方案。
第三步：執(zhí)行。
下面詳細說明：
第一步：開發(fā)者提交參加會診的bug 和修改方案，伙伴測試（Buddy Test）結果。
開發(fā)者必須報告與會者：
（1）bug是什么。
?。?）危害是什么，如果不修復，有何后果。
?。?）用戶會有什么變通辦法。
（4）是否經(jīng)過代碼復審，是否經(jīng)過伙伴測試。
第二步：會議決定是否同意修改方案。
決定哪些缺陷必須現(xiàn)在就進行，哪些可以推遲到下一個里程碑。會診應該對每一個修復選擇下列的處理方式。
?。?）Must ——必須修復，缺陷很嚴重，修復方案可行，相關的測試都通過。
（2）MoreInfo ——需要更多的信息，可能的原因有：
a. 缺陷的影響不明確，例如，這個缺陷是在任何情況下都發(fā)生，還是只在某一特定情況下才出現(xiàn)，因此不能做出決定；
b. 相關的測試不完備；
c. 解決方案有缺陷（會診會議成員可以復審解決方案和代碼的改動）。
?。?）No——不能接受，可能是推到下一個里程碑，可能是提出的解決方案不符合要求。
?。?）Like——可能，不一定必須修復，但是解決方案相對比較安全。在更復雜的項目中，可以考慮引入這一個中間的狀態(tài)“l(fā)ike”（在相對簡單的系統(tǒng)中，這個選項可以不用）。如果在今天的會診中有“must”，那么處于待命狀態(tài)的“l(fā)ike”修復就可以一起集成到代碼庫中。如果沒有“must”級別的修復，那么“l(fā)ike”級別的修復就只能處于“待命”狀態(tài)，直到以后出現(xiàn)了“must”級別的修復為止。
如果再也沒有“must”的修復，咋辦？這些“l(fā)ike”的修復只好等到下一個里程碑了。這樣做的好處是最終發(fā)布的版本不會因為一些小的修復而不斷地更新，而消耗過多的測試資源。
對于管理團隊來說，重要的是要通過每天的會診讓團隊了解must/no的標準，幫助團隊的成員了解目前整個項目所處的位置。舉例說明，在每一次會診之后，列出下面的兩個極端情況：
?。?）剛剛超過門檻的修復（The lowest“must”）——意味著這個修復可以集成到Release代碼庫中。
?。?）剛剛達不到門檻的修復（The hardest“no”）——意味著這個修復不能集成到Release代碼庫中。
在項目接近尾聲的時候，要保證門檻越來越高。今天的“must”（超過門檻的修復）必須比昨天及以前的“no”嚴重性要高，這樣才能不斷提高系統(tǒng)的穩(wěn)定性。
荔荔：但是我們好不容易準備了充足的材料，然后會診說“no”，我們的努力就白費了？
阿超：你做的所有這些準備工作，都是必要的，只不過是在最后階段比較關鍵，要求提供完整的材料，并不是說以前就可以隨意簽入修改。另外，有些修改，可以簽入到另外的源代碼分支中。比如我們有beta-release分支，有main分支，一個修改可能沒必要簽入到beta-release中，但是可以簽入到main分支中。
15.10.1會診Bug
在這一階段，移山團隊開始了每日會診。目的是要盡快減少bug 的數(shù)量，以保證按期交貨。
第一步：提交參加會診的bug。
bug的各個字段都要提供詳盡的信息。每個測試人員和PM要努力使得提交的bug不會出現(xiàn)下面的情況：
重復（Duplicated）：已經(jīng)有人報告了同一個小強。
無效（Obsolete）：報告的情況是關于無效的軟件功能的（如已經(jīng)被砍掉的功能）。
無法重現(xiàn)（Unable to reproduce）：沒辦法重現(xiàn)犯罪現(xiàn)場。這個小強還是有價值的，因為有些小強就是隨機發(fā)生的，但是測試人員要和開發(fā)人員一起找到bug發(fā)生的原因。
第二步：決定bug的命運。
如果決定修改，我們要設置優(yōu)先級，并把它分派給團隊成員。
如果同意可以不修改，則有下面的選擇：
a. 設計（As Designed）：程序就是這么設計的；
b. 推遲（Deferred）：推遲到下一階段，再處理。
第三步：會診設置 bug 的優(yōu)先級Priority，然后設置bug的會診（Triage） 字段為yes。表明已經(jīng)經(jīng)過了會診。
二柱：優(yōu)先級還要規(guī)定？這些都是要在RTM 之前完成的，都是優(yōu)先級1。
阿超：首先，我們從來沒有規(guī)定RTM 之前要完成多少bug，事先假設我們必須全部完成是不對的。注意，如果所有的事都是最高優(yōu)先級，那就等于沒有優(yōu)先級。決定一件事是一個較低的優(yōu)先級，需要很多勇氣。
15.10.2會診修改方案（BugFix）
在穩(wěn)定階段的初期，團隊只要決定哪些缺陷需要修復，然后團隊成員就會進行必要的設計—實現(xiàn)—測試工作，把修改簽入。但是隨著項目進展和發(fā)布日期的臨近，團隊還要保證修改方案不會給產(chǎn)品帶來負面的影響。這時，要對修改方案也進行會診。這也有三個方面：
第一步：開發(fā)者提交參加會診的bug和修改方案。
第二步：會議決定是否同意修改方案。
第三步：執(zhí)行。
下面詳細說明：
第一步：開發(fā)者提交參加會診的bug 和修改方案，伙伴測試（Buddy Test）結果。
開發(fā)者必須報告與會者：
（1）bug是什么。
?。?）危害是什么，如果不修復，有何后果。
?。?）用戶會有什么變通辦法。
（4）是否經(jīng)過代碼復審，是否經(jīng)過伙伴測試。
第二步：會議決定是否同意修改方案。
決定哪些缺陷必須現(xiàn)在就進行，哪些可以推遲到下一個里程碑。會診應該對每一個修復選擇下列的處理方式。
?。?）Must ——必須修復，缺陷很嚴重，修復方案可行，相關的測試都通過。
（2）MoreInfo ——需要更多的信息，可能的原因有：
a. 缺陷的影響不明確，例如，這個缺陷是在任何情況下都發(fā)生，還是只在某一特定情況下才出現(xiàn)，因此不能做出決定；
b. 相關的測試不完備；
c. 解決方案有缺陷（會診會議成員可以復審解決方案和代碼的改動）。
?。?）No——不能接受，可能是推到下一個里程碑，可能是提出的解決方案不符合要求。
?。?）Like——可能，不一定必須修復，但是解決方案相對比較安全。在更復雜的項目中，可以考慮引入這一個中間的狀態(tài)“l(fā)ike”（在相對簡單的系統(tǒng)中，這個選項可以不用）。如果在今天的會診中有“must”，那么處于待命狀態(tài)的“l(fā)ike”修復就可以一起集成到代碼庫中。如果沒有“must”級別的修復，那么“l(fā)ike”級別的修復就只能處于“待命”狀態(tài)，直到以后出現(xiàn)了“must”級別的修復為止。
如果再也沒有“must”的修復，咋辦？這些“l(fā)ike”的修復只好等到下一個里程碑了。這樣做的好處是最終發(fā)布的版本不會因為一些小的修復而不斷地更新，而消耗過多的測試資源。
對于管理團隊來說，重要的是要通過每天的會診讓團隊了解must/no的標準，幫助團隊的成員了解目前整個項目所處的位置。舉例說明，在每一次會診之后，列出下面的兩個極端情況：
?。?）剛剛超過門檻的修復（The lowest“must”）——意味著這個修復可以集成到Release代碼庫中。
?。?）剛剛達不到門檻的修復（The hardest“no”）——意味著這個修復不能集成到Release代碼庫中。
在項目接近尾聲的時候，要保證門檻越來越高。今天的“must”（超過門檻的修復）必須比昨天及以前的“no”嚴重性要高，這樣才能不斷提高系統(tǒng)的穩(wěn)定性。
荔荔：但是我們好不容易準備了充足的材料，然后會診說“no”，我們的努力就白費了？
阿超：你做的所有這些準備工作，都是必要的，只不過是在最后階段比較關鍵，要求提供完整的材料，并不是說以前就可以隨意簽入修改。另外，有些修改，可以簽入到另外的源代碼分支中。比如我們有beta-release分支，有main分支，一個修改可能沒必要簽入到beta-release中，但是可以簽入到main分支中。
鄂公網(wǎng)安備 42010302001612號