Kanban7：持续工程

1、什么是持续工程？

在产品或服务发布后，执行的软件维护工作。

发布后的软件缺陷修复工作是不可避免的，计划外的维护工作和新特性开发工作的优先级排序和进度安排，使用特定的看板工作流程来跟踪缺陷。

2、定义术语、目标和角色，以确保在支持、开发和持续工程团队中得到一致使用

1）术语

缺陷：与产品预期的偏离；

核心工程团队：一个跨职能团队，由业务分析师、项目经理、软件开发人员、质量保证工程师、用户体验工程师及任何有助于提供产品和服务的人员组成；

事故升级：一个客户支持人员无法轻易解决的事故，需要核心工程团队帮助；

补丁程序：一种缺陷的修复；

事故：一个客户报告的软件问题（客户支持团队负责所有的事故并管理其结果）；

服务包：作为一个总体发布的一组缺陷修复和补丁；

2）挑战和目标

工程团队通常会面临以下挑战：

a. 客户的问题需要很长时间才能解决（因资源有限）；

b. 工作的优先级很难界定；

c. 计划外的维护工作难以预测和计划；

d. 客户支持团队不了解核心工程团队工作的进展；

e. 核心工程团队在孤岛中工作，不会定期与客户支持团队进行协作；

f. 核心工程团队没有动力修复缺陷；

目标（通过看板来提供帮助）：

a. 最大限度地减少团队的干扰；

b. 快速做出决策；

c. 以正确的方式解决合适的问题，强制按照优先级排列的工作项列表；

d. 可视化正在进行的工作；

e. 最小化正在进行的工作项的数量；

f. 频繁交付；

g. 衡量持续工程的效率；

h. 改善与客户支持的协作，通过将流程与看板工作流程协调起来；

i. 提高团队积极性；

3）定义角色和职责

*  客户支持团队

    与客户直接联系，并且对客户报告的任何问题负最终责任。

* 产品管理团队

    负责产品路线图，也负责对向工程团队提出的任何需求进行优先级排序。

* 核心工程团队

    由业务分析师、项目经理、软件开发人员、质量保证工程师、用户体验工程师及任何有助于提供产品和服务的人员组成，负责对问题进行详细分析。

3、确定持续工程的负责人

1）专职的持续工程团队

    拥有一个全权负责处理事故升级和发布后问题的团队。

    优点是，核心工程团队的看板包含最少的干扰。

2）专职的持续工程人员

    此人是核心工程团队中的一员，专门负责处理事故升级，不做产品开发的工作。

    优点是，同一个团队致力于清理可能由其产生的发布后的问题。

3）核心工程团队负责持续工程【推荐】

    收到的事故升级与团队的其他任务一起在看板上进行排序。

    优点是，解决问题的人通常是最资深的人。

4、设置所使用的支持级别

1）第 1 级

客户反馈一个产品问题，客户支持代表创建一个事故。

如果事故被实时解决了，事故将被关闭，不会升级到第2级。

2）第 2 级

需要跟进的事故会分配给长期的支持工程师，记录所有的后续跟进日志。

如果需要更深入的技术调研，事故将升级到第3级，通常涉及核心工程团队。

3）第 3 级

在工作跟踪系统里记录这些工作（创建一个新的工作项，展示在展示板上）。

5、高效协作（协作以提高效率）

1）分诊

对于收到的事故进行分诊是软件团队确定哪些问题需要核心工程团队注意及优先处理的最佳实践。

在核心工程团队开始处理任何问题之前，分诊小组审核所有的事故升级，确保最重要的问题首先得到关注。

分诊团队通常由客户支持团队的代表、产品经理（或业务分析师或项目经理）、开发组长和QA组长组成。

分诊团队的主要目标是防止对核心工程团队产生干扰。

分诊会议通常每周进行2次，根据实际情况调整次数。

在分诊会议后，新的工作项被排序到展示板上的适当位置，标示“事故升级”工作项类型。

* 在不需要其他核心工程团队成员介入的情况下，回答关于变通措施以及解决方案的可行性问题；

* 移除重复的事故升级；

* 验证提供给处理事故升级的数据是否足够；

* 在看板墙上，对收到的事故升级按堆进行优先级排序；

* 对任何立即被确认为缺陷的事故升级，建议用什么方式将修复发布给客户；

* 确保跨团队同步新的事故升级及正在进行中的任何事故升级。

2）”快速解决“会议

作为分诊会议的补充，目标是在核心工程团队开始处理事故升级之前，快速解决那些不需要更改代码的事故升级。

会议的参与者与参加分诊会议的人员相似。

通常每周进行1次。