我们会发现一种现象：
1、进入迭代前没有时间了解需求
2、最后一两天的一两个小时了解需求
3、迭代开始后开始细化需求
4、迭代中不停的变更
5、进入下一迭代前没有时间了解需求
在这种怪圈中，时间长了也许就习惯了，不觉得是个问题。同时， 可能又在不停的抱怨，不停的犯着同样的错误。
来分析一下这个怪循环，迭代末期开始了解需求，一知半解的情况下迭代已经开始了，也有一种可能是了解需求后发现有依赖方，技术方案需要前置准备。接着，迭代开始后，开始仔细研读需求并开始编码，进一步了解需求过程中，发现各种细节不太清楚，话说细节是魔鬼。然后研发与产品一顿沟通，方案改一改吧。然后在迭代中期慌乱的赶着进度，梳理下一迭代的需求，没时间，开发忙着把需求写完，丢给测试，一测未通过冒烟，Bug一堆，紧急修复。到了迭代末期，UAT阶段，也就最后一两天了，开始了解下一迭代需求，由于是初次细致的沟通，发现不少问题是现场无法解答，需要进一步思考方案。然后，匆忙排期，迭代再次开始。
这个循环是怎么形成的？经过深入了解，这是一个经过改进的流程，目的是为了减少产品对研发的打扰，提高研发的工作时间，最终达到提升产能的目的。
在形成认识偏差的情况下，团队很难跳出这个圈。对于研发需求，我们很难经过一两天了解需求的所有细节，并且把控好风险和依赖。
推荐的方式是，迭代中期就开始正式的需求沟通梳理过程，通过持续的沟通，把控好下一个迭代前需求的风险，确保在迭代以前，需求粒度和风险可控。通过需求的粒度和风险的可控进入迭代，在迭代的第一天，开发就可以正式开始，迭代的中期，团队成能够有时间开始讨论需求。最终形成一个良性的循环。
