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