13、持续工程：使用看板方法解决软件维护挑战

持续工程：使用看板方法解决软件维护挑战

1. 引言

多数向客户发布产品或服务的团队，在产品发布后都需要进行软件维护。即便高效的团队在开发阶段尽力减少缺陷，但发布后仍不可避免地需要进行一些修复工作。这给团队带来了难题，他们需要在开发产品新特性的同时，对未计划的维护工作进行优先级排序和日程安排。而看板方法（Kanban）则是应对这一挑战的有效模式。

2. 定义术语、目标和角色

2.1 一致的词汇表

在持续工程（SE）中，团队需要对一些术语有共同的理解，以确保在支持、开发和SE团队之间统一使用。

2.2 挑战与目标

工程团队在处理发布后漏洞时通常面临以下挑战：
- 客户问题解决时间过长，因为存在众多相互竞争（有时还会变化）的优先级。
- 工作优先级难以确定，团队难以在处理客户问题和推进产品路线图之间做出选择。
- 未计划的维护工作难以预测和安排，如果组织希望能预测发布日期，就需要预测团队在修复漏洞和添加新功能上分别花费的时间。
- 客户支持团队对核心工程团队的工作缺乏可见性，问题转移到核心工程团队后，客户支持团队希望了解问题的处理状态。
- 工程团队各自为战，与其他团队（如客户支持）的协作不经常进行。
- 核心工程团队修复漏洞的动力不足，开发者通常更热衷于创建新功能和解决新问题，认为修复漏洞不是“有趣”的任务。

通过采用看板方法，可以解决上述挑战，SE实践的目标以及看板方法的帮助如下：
|目标|看板方法的帮助|
| ---- | ---- |
|减少团队干扰|明确持续工程角色和职责，使团队高效处理升级问题，