【构建之法】第15章-稳定和发布阶段

蔚落 2023-08-17 16:30 51阅读 0赞

***本章重点：***

*  软件项目的会诊（Triage）
 *  软件按时发布的招数：Alpha Release、Beta Release、DCR、ZBB
 *  项目的总结和回顾

# 1 从代码完成到发布 #

软件生命周期的最后阶段往往是最考验团队的，不但考验团队项目管理水平、应变能力，也考验团队的“血型”。软件团队的“血型”可以分为4种：

<table> 
 <thead> 
  <tr> 
   <th align="left">血型</th> 
   <th align="left">特征</th> 
   <th align="left">表现</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">A型</td> 
   <td align="left">他们知道优秀的软件公司会发布有已知缺陷的软件</td> 
   <td align="left"></td> 
  </tr> 
  <tr> 
   <td align="left">B型</td> 
   <td align="left">他们不相信这一点</td> 
   <td align="left">B型人士会发现搞软件开发是很痛苦的事</td> 
  </tr> 
  <tr> 
   <td align="left">O型</td> 
   <td align="left">他们不知道这一点，因此嘴巴惊讶成O型</td> 
   <td align="left"></td> 
  </tr> 
  <tr> 
   <td align="left">AB型</td> 
   <td align="left">他们对于自己开发的软件是A型，对于别人开发的软件是B型</td> 
   <td align="left"></td> 
  </tr> 
 </tbody> 
</table>

***一些常用名词：***

<table> 
 <thead> 
  <tr> 
   <th align="left">名词</th> 
   <th align="left">解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">Alpha</td> 
   <td align="left">指继承了主要功能的第一个试用版本，在这个版本中有些小功能并未实现。一般只供内部使用</td> 
  </tr> 
  <tr> 
   <td align="left">Beta</td> 
   <td align="left">功能基本完善，稳定性较Alpha版本搞，用户可以再实际工作中小范围使用，可以有Beta1、Beta2等</td> 
  </tr> 
  <tr> 
   <td align="left">ZBB（Zero Bug Build）</td> 
   <td align="left">某天的版本要把在之前（例如48小时前）记录的Bug都解决掉</td> 
  </tr> 
  <tr> 
   <td align="left">RC（ReleaseCandidate）</td> 
   <td align="left">发布候选版本，RC1、RC2等，指导RTM为止，版本间隔时间较短</td> 
  </tr> 
  <tr> 
   <td align="left">RTM（Release To Manufacturer）</td> 
   <td align="left">最终发布版本</td> 
  </tr> 
  <tr> 
   <td align="left">RTW（Release To Web）</td> 
   <td align="left">和RTM类似，还有RTO（Release To Operation）等</td> 
  </tr> 
 </tbody> 
</table>

***从代码完成到最终发布软件：***  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70]

## 1.1 会诊小组（Triage Team） ##

软件团队的各个角色代表（PM/Dev/Test/UX等）组成了会诊小组，处理每一个影像产品发布的问题。

对于每一个Bug，会诊小组要决定采取下面哪一种行动：

*  **修复（Fix）**：小组同意修复这一问题；
 *  **设计本来如此（As Designed）**：用户或测试人员可能对功能有误解，或者功能的解释不完备；
 *  **不修复（Won’t Fix）**：这是一个问题，但是这个软件版本不打算修复；
 *  **推迟（Postpone）**：如果我们的软件是真正解决用户问题的，是有价值的，那它一定会有下一个版本。

## 1.2 复杂项目的会诊 ##

## 1.3 招数：设计变更（Design Change Request，DCR） ##

经过Alpha/Beta阶段，会收到很多用户反馈，这就使得原来的设计需要改进一些地方。

***DCR的要点：***

<table> 
 <thead> 
  <tr> 
   <th align="left">问题</th> 
   <th align="left">解法</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">如何提出DCR？</td> 
   <td align="left">在DCR的描述文字中，说明：<br>-问题在哪里，问题的影响；<br>-如果不修改，会有什么后果？<br>-几种修改方案，各种方案的优缺点和成本。</td> 
  </tr> 
  <tr> 
   <td align="left">如何决定DCR的执行次序？</td> 
   <td align="left">-会诊所有DCR；<br>-按照影响、成本排序，得到一个自上而下的名单，根据现有资源，按照名单执行。</td> 
  </tr> 
 </tbody> 
</table>

**注意**：适合在Beta分支实现的修改不一定适用于主分支（Main Branch），我们要做好源代码管理。

## 1.4 招数：零缺陷构建（Zero Bug Build，ZBB） ##

团队要有把Bug都搞定的执行力。ZBB = Zero Bug Build，即这一版本的构建把所有已知的Bug都解决掉了。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70 1]

## 1.5 招数：最后回归测试 ##

项目临近结束时，所有人员（开发、管理、测试）都要回归测试所有的Bug。每个人都要帮助团队确保这些Bug的确是被修复了，而且别的更改没有导致功能的“回归”。

## 1.6 招数：砍掉功能 ##

为某个功能已经花费的成本，可以叫做“沉没成本”（Sunk Cost）。不能因为以前花了成本，就要求以后一定要完成这个任务。

## 1.7 招数：修复Bug的门槛逐渐提高 ##

在RC阶段，开发人员在拿到Bug进行修复工作之前，就要和会诊小组沟通，看看这个Bug是否值得花时间。

## 1.8 招数：逐步冻结 ##

随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。

# 2 渐进发布和DevOps #

上文提到的Alpha、Beta、Beta1、Beta2等发布方式，发布的间隔是一个月以上，一般来说，后一个发布是前一个版本的升级，发布的目标人群也类似。在互联网时代，出现了一个产品同时对不同的目标用户用不同的频率来发布的情况。

***Windows 10的渐进发布：***  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70 2]  
在往后的几年中，由服务稳定性和效率推动的各种开发工作被归纳为一种新的开发模式：Development-Operations（DevOps）。

***DevOps流程：***  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70 3]

# 3 发布之后 - 事后诸葛亮会议 #

一个里程碑结束了，接下来怎么办？团队有什么经验教训？产品怎么才能做得更好？

一个软件开发的周期结束了，我们可以像医学的解剖一样，把这个软件开发的流程解剖一下，解剖的过程可以叫：**Postmortem**，**Retrospective**，**Review**，**事后诸葛亮会议**。

使用“**鱼骨图**”（**Ishikawa Diagram**）来列出各类因素中主要和次要的原因，并可以讨论改进的方法：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70 4]  
《**现代软件工程 项目回顾（Postmortem）模板**》 - 见原书335页。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70]: /images/20230810/8d0a1062af5845b482639b2d1386fd73.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70 1]: /images/20230810/c718a04d7e6b4a84ac9dc9649b899c43.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70 2]: /images/20230810/52957437952642d6b49019830159a6ad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70 3]: /images/20230810/ff05f35b40d74afa85736e19f6e828f8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NmYW45Mjc_size_16_color_FFFFFF_t_70 4]: /images/20230810/ad584550343c4ad399e439a6159c9211.png