[讀書報告]構建之法(八)

標籤：

今天讀了《構建之法》的第15章：穩定和發布階段

Alpha：指整合了主要功能的第一個試用版本。

Beat：功能基本完備，穩定性較Alpha版本高，使用者可以在實際工作中小範圍使用。

ZBB：某天的版本把在之前記錄的Bug都解決掉

RC：發布候選版本

RTM：最終發布版本

RTW：和RTM類似

會診小組

軟體團隊的各個角色代表組成了會診小組，處理每一個影響產品發布的問題。

決定對每一個Bug採取以下哪一種行動：

1.修複

2.設計本來如此

3.不修複

4.延遲

複雜項目的會診

第一步：開發人員提交慘叫會診的BUG和修改方案

第二步：會議決定是否同意修改方案

第三步：執行

開發人員需要報告的內容如下：

1.Bug是什嗎？

2.危害是什麼，如果不修複，有何後果？

3.使用者會有什麼變通方法？

4.是否經曆過代碼複審、夥伴測試？

修複等級：

1.Must：必須修複

2.More Info：需要更多資訊

3.No：不能接受

4.Like：可能，不一定會修複

項目接近尾聲時，要確保門檻越來越高。今天的Must必須必昨天以及前天的No嚴重性要高，這樣才能不斷提高系統的穩定性。

設計變更DCR：

在提交一個DCR時，選用任務作為工作件類型，並在標題中標明DCR

在DCR的標題文字中，要說明：問題在哪裡，問題的影響，如果不修改，會有什麼後果，幾種修改方案，各種方案的優缺點和成本

對於DCR的次序，首先會診所有DCR，然後按照影響、成本排序，得到一個自上而下的名單，根據現有資源，按照名單執行

[讀書報告]構建之法(八)