ASK MO第36期 | 大规模敏捷团队，如何处理好需求？

正文共：3136字  预计阅读：8分钟

• 如何正确的看待自己的工作？

• 没有达成迭代目标，就不能开始下个迭代？

• 大规模敏捷团队，如何处理好需求？

• 获取客户反馈，有没有简单而有效的方法？

• 如何把控需求打包规模？

例如骚扰电话AI之类的，我认为并不是坏事，而是市场化的产物，而科技的进步一定会带来便利性极大增强，P2P本来也是方便资金需求端和资产对接嘛。政府为什么要来整顿？是因为这个事情不可控了，劣币驱除良币。我认为不一定是坏事，反而是好事，市场越来越规范化，真正好的企业能活下来，并且活得很好。而且我认为，企业和政府本来就是要各司其职，企业应该怎么样在政府允许规范之内，合理最大化利润，为国家创造更多的税收。而政府的责任在于民生，怎么让人民更加满意，更加幸福，有安全感。

综上所述，我觉得你大不不必担心，只要在政策允许的范围内，合理经营，合法纳税，企业就是好企业，员工就是企业的好员工。

敏捷肯定是时间盒的，简单来说就是时间定死。比如我们两周一个迭代，也就是10个工作日，那不管是10个需求还是8个需求，只要是没有完成的需求，到了10个工作日，也要放在下个版本去做。

那需求未达成什么办呢？没有达成就没有达成，敏捷是价值驱动的。目标是你每次迭代能产生多少价值，而不是每次迭代完成多少需求数量。

那质量未达成怎么办呢? 为什么没有达成？是因为工期太紧，还是有别的原因？工期太紧一般是因为团队只会加需求，不会砍需求。说明还是没有运用敏捷思维。

如果没有达成就不能开始下个迭代，就会卡死在这里，工期被拉长。但如果直接开始下个迭代，就会变成是做敏捷的锅，迭代不是要交付可用软件嘛？敏捷不交付也行，敏捷就是这样的垃圾，我呸。

这个锅我们做敏捷转型的可是不背的，正确的方式应该是这样的：SM在回顾会上澄清，这次项目过程其实根本不是敏捷，是瀑布，也不是迭代完成，而是叫项目完成。这次我们叫做项目失败，然后再和大家去普级敏捷的时间盒概念，时间盒不是只关注时间，还要关注灵活调整项目范围，关注交付价值。

如果团队没有这样一个SM搞得清楚，那么，去招聘有经验的SM或者是请外部咨询顾问帮忙解决，都是可行的事情。切记，不要让半桶水的专家把团队带偏了。

大规模敏捷了解一下，开个PI会议，把大的需求进行澄清，但是不要深入需求细节，这个会议更多是让大家知道要达成的目标，要完成的项目价值，业务逻辑等。具体的交互细节不用放在这个会议来过，而是把需求进行拆分，把需求分成N个组来完成，组内要形成跨职能团队，既有产品，又有研发，能独立对需求的某一个整体模块进行独立交付。

最后，由项目经理来管理各组的交付时间，进行项目对齐，整体风险管控。这样既有局部自组织，又有整体的管控，目标清晰，项目成功率就很高了。

最简单有效的方式就是问卷调查，因为第一不要做系统去埋点，第二也非常快速，反馈周期又短，第三也不用去花大量时间去访谈客户，第四也不用深入客户的场景去观察。真是居家旅行之必备良药。

但是要注意的是，问卷调整最重要的不是问卷本身内容，而是调查的人群是不是你真的的客户群体，收集回来的样本有没有覆盖到你的所有典型用户，包括用户的地理位置，人口特征，使用行为，价值观，使用场合等等。这个怎么理解呢？如果我这个软件是为中国广大大学生设计的，那各种场景，比如所在的城市，性别，大一到大四，月平均消费水平，使用的场合都需要去覆盖到。

需求是需要拆分成用户故事的，一方面能方便大家理解和沟通，也能站在用户的角度上想想需求的实现方式。拆分的大小以不超过5人天为限，因为我们希望每周至少有一个独立的需求功能产出，让团队能看到完整具体交付物，增强团队信心。

另外，需求评估需要按照故事点的方式评估，故事点是一个相对的大小，是用来衡量团队的整体速率的。第一个用处是衡量每个迭代我们可以放多少的用户故事进来。第二个用处是通过最近几个迭代，每个迭代完成的故事点的总数，用来衡量整个团队的生产效率是否提升。