敏捷中关于需求和测试问题

今天召开的回顾会议上，讨论了我们一直存在的两个老生常谈的问题：1.迭代过程中中，功能提测太晚，测试时间不充足，故事推进缓慢。2.需求讨论时，需求不明确，大多是一个方向，需求确认没有产出，耗人耗时。...



今天召开的回顾会议上，讨论了我们一直存在的两个老生常谈的问题：

1. 迭代过程中，功能提测太晚，测试时间不充足，故事推进缓慢。

2. 需求讨论时，需求不明确，大多是一个方向，需求确认没有产出，耗人耗时。

讨论

针对这两个问题，我们会认为是敏捷的问题！敏捷要求一个迭代交付给用户可运行的产品，但敏捷又没有详细需求设计说明（PRD），这就使需求在迭代中会有很大的变化。需求越不清晰，开发出产品的偏差越大，测试的进场就越晚，迭代的推进也就越慢！

这时你就会问，为什么不用瀑布式开发啊？瀑布式开发有完善的文档，清晰的过程组，各个职能团队配合有条不紊。

这里，其实我们可以跳出自己思维的枷锁，不管是敏捷还是瀑布式或是其他，我们的初衷是什么？是为了能让团队更优秀的运作，协作沟通更顺畅！

针对以上的问题，难道在瀑布式的开发中不会出现么？瀑布式的长周期开发，如果出现了同样的问题，难道不是更加灾难么？

所以，这不是规则的问题。因为规则是死的。我们仔细看问题。

为什么测试时间不充足，是因为提测时间太晚。为什么提测时间晚？有没有可能是故事的太多，或者故事推进的不合理，还有就是故事的边界不清晰。

故事太多，我们减少任务，但是这样可能会造成团队开发的不饱和！

故事推进不合理，是不是在召开计划会议的时候，故事的优先级没有把测试考虑进去，以及提测的内容太多。我们再深入讨论下，回想一下我们迭代，2周的迭代任务，第一周开发、第二周测试上线，但是为什么会出现提测晚的问题呢？需求变化了，开发延后是原因之一，但不应该是常态。

解决故事太多和故事推进不合理的问题，我们可以根据团队的能力合理的安排，并且考虑故事紧急程度和是否需要提测安排优先级，同时控制提测的故事数。因为测试资源也是有限的，如果都提测，测试就是测不过来的。（引用经典的一句话：如果事情都重要，就没有重要的。）

所以，我们在召开计划会议的时候，一是控制提测的故事，二是优先级高的任务一定提测的。（优先级高不仅代表业务优先级高，也代表资源投入高）。这样安排之后，在迭代内，开发会在第一周内优先开发提测的故事，同时测试就可以进行测试用例的编写，在第二周的时候，测试就可以测试，而开发则可以开始处理不需要提测故事。

我们解决其中的一个问题，现在我们在来看看需求的问题。

在敏捷中，不需要产品提供完善的PRD文档，但是并不是说没有文档，关键的流程和原型图还是必须的。同时，也并不代表团队可以仅凭拍脑袋的一个想法就开始迭代。

对于需求的问题，我们应更严格的要求产品，首先，我们不需要完善的PRD，但是必须用非常简洁的图形把需求表达解释清楚，最重要产品必须非常清楚要做什么，对近期和远期都要有一定的规划！

并且对讨论的次数和时间都要进行控制，一个需求如果召开三方的需求阐述（三方包括产品、研发、测试），在一周内只有2个机会，每次控制30分钟到1个小时，如果超过以上限制仍没有任何产出或者确认，本周就不在讨论这个需求。因为我们可以认为，产品自己还没有完全理解这个需求，这是在把产品的职责甩给研发和测试，这是在浪费大家的时间。

同时，对于没有确认的需求，是不会安排到迭代中的。

总结

PO是对产品负责的，他们就像航船中的舵手，如果方向错了，做什么都是无用功。所以，需求说不清楚的PO，也不要指望他们指引你前进。

对于测试的问题，我们可以先想想，我们实践敏捷，行进了那么久，很多地方都做到了很好，这些小问题就是要跳出我们原有的思维，捅破那一层纸，就会豁然开朗。

    关注 ZHANGSR十年一剑