【以人为本，敏捷为先】华为云MVP黄隽：从排斥到布道者，敏捷的正确打开方式是什么

敏捷这个词虽然被很多开发人员挂在嘴边，但真正理解并能用敏捷解决实际问题的其实少之又少。

很多公司开始实践敏捷，但多数被伪敏捷折腾一痛，失败告终。

为什么会这样？难道敏捷出了问题，或者说敏捷转型有这么多痛点，敏捷还适合软件开发吗？

在敏捷专家黄隽看来，“如果本身对敏捷开发就存在误解，这很容易导致错误的实践方式。”

那么，敏捷的正确打开方式是什么？且听黄隽慢慢道来。

与敏捷结缘

黄隽最开始接触敏捷时，其实是有点排斥的，因为他一直处于传统开发模式状态下，一时很难改变传统软件开发的固定思维模式。

直到2012年初，当时在IBM工作的他，接触了非常多的相关培训和实践，随着了解的深入，黄隽逐渐跳出了当初的思维定式，对敏捷产生深厚的兴趣。

黄隽认为，“敏捷开发只是一个指导思想和原则，并没有给出具体的实施步骤。在实际工作中，如果企业只是觉得不用敏捷好像很老土，一再对外强调敏捷开发是没有意义的。重要的是在敏捷原则和核心价值观的指引下，哪些实践和方法可以帮助达到目标，或者如何解决这些问题从而达到目标。”

在从事敏捷开发过程中，黄隽看到许多企业因为认知偏差走进了死胡同，更加坚定了他的敏捷开发之路。

也正是因为一直从事敏捷开发工作，黄隽机缘巧合下接触到了华为云软件开发云DevCloud。

DevCloud是集华为研发实践、前沿研发理念、先进研发工具为一体的研发云平台，它面向开发者提供研发工具服务，让软件开发简单高效。

“和华为云几位敏捷专家分享布道的日子里，接触了很多企业用户、老板、高校教师和领导，更深刻的了解到企业转型和高校产教融合的很多痛点，一种要帮助解决痛点的责任油然而生。”黄隽笑言，“随后，我们就一起创建了‘敏捷江湖桃花岛社区’，专门解决敏捷和DevOps转型痛点问题。”

图：敏捷江湖桃花岛线下沙龙101敏捷转型痛点主题配图

在诸多转型问题中，黄隽发现多数企业有一个共性的难题：研发团队经常会提到的Backlog管理问题，特别是那些突发性的工作应该如何管理。

下面黄隽将对提到的这些痛点问题做详细阐述，从事研发的团队可以参考。

研发团队如何管理琐碎、突发性工作？

先看看解决方案思路：管理好工作项是解决问题的核心，那么在形成工作项之前，我们需要解决谁对工作项负责或者说工作项来源的问题，然后要针对工作项做好工作计划，这样开发团队才能很好的执行。

首先，明确产品经理为需求责任人，做到需求来源唯一。

其次，梳理产品待办列表，高优先级的工作项先做。

第三，重新定计划，确保团队容量适合，合理更新迭代目标。

第四，回顾总结，选出改善点，下个迭代做得更好。

最后，几个迭代下来，度量分析，不断改善。

另外，同步需要进行的是人才的培养，向跨职能型团队努力。解决方案思路示意图如下：

解决方案思路示意图

剖析解决方案，一步步解决Backlog管理问题

1、明确需求责任人

一方面，需求责任人必须很好地理解项目中的利益干系人、客户和用户的需要（包括前面提到的突发工作项）及其优先级。

同时，需求责任人还要在版本、迭代和Backlog层面都持续做出良好的经济决策，管理经济效益。为了统一叫法、便于理解，后面需求责任人都由产品经理充当（类似Scrum框架中的产品负责人）。

总结一下，产品经理的主要职责如下图所示：

产品经理主要职责图

产品经理需要与利益干系人充分沟通，确定这些突发的工作优先级别，同时从业务价值和管理经济效益等维度考虑，明确是否一定要在本迭代中完成。一旦确定这些突发工作属于高优先级，必须在本迭代中完成，那就需要重新梳理工作项了。

2、梳理产品待办列表

梳理产品待办列表，就是将高优先级的工作项放到迭代待办列表中先做。下图说明了通过梳理活动改变Backlog的结构：

梳理活动改变Backlog的结构图

梳理后，对应DevCloud中的体现：

DevCloud梳理活动结果图

产品经理梳理后，如图高亮部分，突发性培训任务的工作项得到了合理的优先级，同时它是被细化的，而且是经过工作量估算的。

产品经理是梳理活动的最终决策者，优秀的产品经理能够充分协调利益干系人，安排足够的时间，并根据团队的特点和项目类型来开展梳理活动。同时团队还要估算新加入突发工作的工作量，帮助产品经理根据技术依赖关系和资源约束排列工作项的优先顺序，如果新加入突发性培训任务的工作项优先级高，那么就会纳入本迭代代办列表中。

3、重新定计划

重新定计划，确保团队容量适合，合理更新迭代目标。

敏捷宣言中提倡“响应变化高于遵循计划”，盲目的相信计划往往会让我们忽视“计划可能有错”这个事实。

在敏捷开发过程中，目标是快速重新制定计划并根据开发过程中不断出现的、具有重要经济价值的信息进行调整。原计划准备做的工作项可能被移入到下一个迭代中实现，这里体现的是“等价交换原则”，意思是用优先级高的突发性工作项，替掉了同等工作量的其它工作项，这也是为了保证团队按照稳定的节奏交付，等价交换示意图如下：

等价交换示意图

具体在DevCloud中的体现，如等价交换图一和等价交换图二所示。

等价交换图一

等价交换图二

最后，从迭代中选取差不多工作量的低优先级工作项移回到Backlog中，即在DevCloud中完成了工作项的等价交换。

4、迭代回顾，识别改善点

迭代回顾是一个会议，目标是持续改进流程，以提高士气和效率。

几个迭代下来，需要对这类突发工作进行度量分析，识别改善点，持续改善。虽然我们提倡响应变化高于遵循计划，但执行迭代的时候也需要团队在不受干扰的情况下全力以赴。因此，就得思考为什么每个迭代中都有外界的干扰（突发工作）存在，团队共同分析和找到办法才是解决问题之道。

这里给出一个DevCloud的小实践，可以提供客观数据帮助回顾。

新纳入迭代待办列表的突发性工作项可以在DevCould的“模块”下进行管理。也就是说，在新建User Story之前建立一个“突发任务”模块。这是为了在后续几个迭代中对这类突发性工作进行度量分析，为持续改善做准备。

图：新建突发模块图

图：新建User Story图

选择报表—新建报表—自定义报表—增加筛选条件（模块）—按迭代维度—保存。然后对统计出来的数据进行分析，可以以图和表两种方式展示。

图：按图展示图

图：按表展示图

5、同步进行人才培养

如果团队成员都是T型技能的时候，每个任务都有好几个人可以做，那么团队就能够在迭代执行期间全力完成制约工作项流程的任务，更灵活地平衡资源，使团队更高效。

所以，同步需要进行的是人才的培养，向跨职能型团队努力。不仅仅可以应对处理突发性工作，而是让团队更高效。

以上就是黄隽对于敏捷开发中，研发团队如何管理琐碎、突发性工作的一些思考。总而言之，降低或解决突发性工作对团队的干扰非常重要，它直接影响团队工作的进度和速率，间接影响迭代目标是否能完成，甚至整个项目的成败。所以，一定要重视并想办法一劳永逸解决它。