从需求到交付——论敏捷过程中的需求管理

背景

在之前组织的一次敏捷线下活动中，有家企业问道：“我们公司刚做敏捷转型不久，遇到一个比较头疼的问题——团队每天都很忙，从转型到现在已经两个多月了，基本没有一个迭代能做完全部任务，问题出在哪？”该问题一提出后，引发了激烈讨论：

“我们公司也是，总有那么几个人完不成手头任务，每次拖后腿让客户不满意”；

“最近我们项目用了个新框架，很多人他没用过啊，不知道从哪下手，项目评审的时候一片惨淡”。

其实上述几种情况归根到底都属于需求无法按时交付，类似这样的困扰你是否也遇到过呢？

问题分析

在交流中，笔者了解到每家公司的情况：

背景中第一家企业在第一个迭代认领了15个故事，团队很容易就完成了；老板觉得以团队的能力可以做到每个迭代完成30个故事，于是后续每个迭代都希望团队认领30个故事，团队认领30个任务后，累死累活只能完成20左右的故事；
第二家企业研发团队8人，每个迭代总有两个成员工作完不成：团队每天早会正常开，但是总感觉那两个成员整个迭代都在做那一两个故事，做的功能也没啥进展，有时候还做不完；
第三家企业使用了一个新框架，近两个迭代团队按以往的速率进行任务认领，结果由于团队对框架不熟，每个迭代只完成了冲刺待办列表中一半的故事。

笔者结合交流结果及以往经验，对需求延期交付的原因进行了如下分析：

需求延期交付通常有两方面原因——团队主观原因以及客观原因。客观原因通常是由过程方面的阻塞造成的，比如团队需要购买一批云资源，公司规定资源采购需要老板最终审批签字方可实施，正巧赶上老板出差无法签字，导致工作卡在最终审批环节无法交付。

没有客观因素干扰，需求无法按时交付通常就是指团队手头工作在迭代结束前无法全部完成，这是主观原因。造成团队手头工作完不成的原因有很多，背景中提到的原因可概括为以下三种：

冲刺待办列表故事过多

冲刺待办列表是计划会议的输出之一，计划会议上团队根据团队速率认领故事，形成冲刺待办列表；如果团队速率被高估或者个别故事估值偏小，则冲刺待办列表中的故事点数相对团队真实速率就会偏多，最终导致工作过多，迭代结束时部分需求无法按时交付。

冲刺待办列表中故事过多还有一种可能：计划会议输出的冲刺待办列表是合理的，可是由于一些突发因素，产品负责人向迭代插入了新的任务，导致冲刺待办列表故事太多。

工作技术难度较高

项目使用了新的框架、语言、工具等，团队之前没接触过，需要一定时间去磨合，所以前期难免出现延迟交付。工作技术难度较高是相对于团队平均水平来说的，如果团队整体技能水平偏薄弱，比如都是团队成员都是刚入行的新人，普通研发工作相对这个团队来说都很困难，这种情况也很容易出现延迟交付。

个别员工工作完不成

团队某位成员请假了，原本计划完成的工作因为请假只做到一半，所以最后无法按时交付；另外如果团队成员没做到自组织，在项目中出工不出力，也容易导致迭代结束手头工作没有完成；最后如果团队成员工作遇到障碍被卡住，该成员不向团队暴露障碍，而是一直自己孤军奋战，也会导致需求延期交付。

除请假外，其他两种情况都可以通过敏捷的风险管控方法（如每日站会）避免发生，所以这种情况也可以总结为团队风险管控没有做好。

解决措施

针对分析中客观原因部分，团队可以通过建立Backup的形式进行避免。以采购为例，项目经理或老板秘书做老板的Backup，当老板由于自身原因无法亲自审批时，Backup可向老板汇报，征得老板同意后代替老板审批，避免流程方面的因素影响团队交付，也体现了敏捷宣言中的“个体与交互胜过流程与工具”。

针对团队主观原因部分，本文基于合理开展敏捷活动给出如下措施。

针对冲刺待办列表故事过多

冲刺待办列表故事过多的主要原因是高估团队速率，故事大小估算错误以及迭代中有新需求插入。针对这三种情况，给出如下解决方案：

问题	解决措施
高估团队速率	合理估算团队速率
故事大小估算错误	正确估算故事大小
迭代中有新需求插入	需求置换

合理估算团队速率，按照速率认领故事

团队速率是团队在迭代中认领多少故事的依据。

在敏捷转型初期，由于团队没有历史数据做参考，很容易估算错团队速率，导致冲刺待办列表中故事过多或过少——故事过多则可能导致延期交付；故事过少，则会浪费开发资源。如何估算团队速率呢？

确定开发团队每天在开发工作上投入的时间（刨除会议，接打电话，收发邮件等时间），将时间乘以迭代天数，即可得出迭代中团队用于开发冲刺任务的生产力。然后团队从产品待办列表中选择一系列故事，预估这些故事的完成时间和用于开发冲刺任务的生产力相近，然后统计这些故事的点数，即可估算出团队速率。起初估算结果可能不准确，但是通常团队对速率的估算会随着迭代进行而愈加准确。

举个例子：团队5个开发人员，其中三个人每天有6.5小时用来工作，其余二人每天有6小时可以工作，迭代两周（10 工作日），那么团队可工作的时间总和就是（6.5×3+6×2）×10=315。我们从产品待办列表中选择315小时左右的故事放入冲刺待办列表。冲刺待办列表详细信息如下（本文故事由华为云DevCloud进行管理）：

由图可看出团队速率大概是33左右。也就是说，计划会议中团队从产品待办列表中选择30个故事点的故事放到冲刺待办列表，进行开发，团队有可能全部交付，而选择50个，则全部交付是有困难的。

根据团队速率认领故事，可以让团队量力而行，有效地减少延期交付。

正确估算故事大小

除了对团队速率估算错误，对故事大小估算错误也容易导致延迟交付，关于故事大小的估算方法可以参考【DevCloud · 敏捷智库】如何估算第二篇：利用核心概念解决估算常见问题

需求置换

敏捷迭代中由于时间盒和工作量都固定，如果有新需求加入迭代——比如生产环境突然发现一个之前没测出的Bug，需要修复，迭代工作量可能会超出团队生产力，导致延迟交付。

出现这种情况时，团队应该如何应对？

首先团队需要向产品负责人确认新需求是否应纳入本轮迭代，做到需求来源唯一；
当确定需求要做，产品负责人将新需求以用户故事形式放入冲刺待办列表中，然后和团队一起重新梳理冲刺待办列表；
将工作量与新故事相近的低优先级故事移出本轮迭代，放回产品待办列表，以确保当前迭代团队工作总量不变，形成需求置换。

Tips：团队在计划会议领取任务时，不要领取的太满，最好预留一些缓冲时间，以便于应对突发情况。

如果产品负责人迫于领导或客户压力，不允许需求置换，只能向冲刺待办列表中硬塞故事，这时候应该怎么办呢？在敏捷中，Scrum Master作用之一是扮演团队的“保护伞”，让团队集中精力去完成迭代目标。如果产品负责人强制的向迭代中添加故事，Scrum Master可与对方沟通，弄清楚对方为什么向迭代中插入故事——之前整理故事有遗漏或者发现了以前未测出的Bug，还是对方不知道Scrum不建议向进行中的迭代插故事。如果是需求遗漏，应该在回顾会议上总结经验，日后避免；如果对方不了解Scrum，可以通过讲解Scrum相关知识，让对方理解为什么Scrum不建议向进行中的迭代加入新故事，以后避免这种情况发生。

加班也是一个应对突发问题的选择，但是研究表明短期加班会提高效率，长期加班团队成员会因休息不足，注意力不集中等原因降低效率。长期加班除了不利于团队建设之外，不定时的加班对团队速率也有很大影响，而敏捷提倡可持续发展，所以加班解决突发问题属下策。

针对工作技术难度较高

对于项目技术难度要求超出团队能力，成员无法估算工作量或无从下手导致项目交付延期的情况，可以利用“探针（Spike）”技术评估项目。

探针是一种敏捷实践。当遇到无法估算，或无从下手的故事时，团队可以从这个大故事中分割出一个小故事，然后对小故事进行开发，这个小故事就是探针。探针的开发完成时间可作为估算整个故事完成时间的依据，后续估算有了依据，就会准确很多，延迟交付的风险也会随之减少。

当然除了探针技术，团队成员的技术培训也是必不可少的——团队内技术分享或培训，可以提高团队整体技术水平，从而提高研发效率、减少特性延迟交付的风险。

针对个别员工工作完不成

每日站会是一个很好的风险管控工具。迭代中的每一天都可以看成是一个小迭代，每日站会通过保证小迭代正常运行，进而保证整个迭代的稳定进行。每日站会如果只汇报工作，通常会变得浮于形式，各种风险可能也无法被确认，最后导致每日站会发挥不了自身作用。认真开好每日站会可以预防延迟交付。

团队成员在每日站会“前一天做了什么”，“今天要做什么”的基础上，陈述工作详细情况以及具体进度，这样可以让团队的工作状态更加透明。从团队风险管控角度来看“我昨天用了5小时开发A功能，目前A功能开发了50%，今天预计再投入5小时，开发至80%”比“我昨天开发了A功能，今天要继续开发A功能”要好得多。

另外借用一些项目管理工具，可以更直观的看出员工的工作状态。以华为云DevCloud项目管理功能为例，在故事中，可以清楚地看到员工的实际工时和故事的完成度，便于了解和把控故事延迟交付的风险。

没做好风险管控会影响故事的按时交付，每日站会通过“我遇到什么风险”识别团队遇到的风险。遇到风险时，首先团队成员可以指定团队中某一成员，让其帮忙清楚风险；当然团队成员也可以主动帮忙清除风险。如果团队内没有人能够清除风险，这时候Scrum Master就应该发挥“清道夫”的作用，通过协调内部或外部资源来解决风险，帮助团队扫清障碍，以确保项目可以按时交付。

想了解更多关于每日站会的内容可以参考：【DevCloud · 敏捷智库】如何玩转每日站会？

参考附录

【DevCloud · 敏捷智库】如何估算第二篇：利用核心概念解决估算常见问题

【DevCloud · 敏捷智库】如何玩转每日站会？

Mike Cohn 敏捷软件开发实践——估算与计划北京：清华大学出版社