敏捷开发的迭代周期

    我们在开发产品中，遇到了一个很有分歧的事。从早期准备进行敏捷开始，就强调一个可控的，快速响应变化的迭代周期，而一般的项目开始的建议也是以30天，应是一个月作为一个迭代周期为准，当然三十天也不是绝对的，而是相对靠近，比如24天，36天之类的，为了符合三十天而三十天是没意义的，从而对产品经理、对于团队来说，应是大家整个都向某一个大家都达成共识的标准去靠近。
    我们的产品经理在划分sprint时，在早期是由于大家进行概算时，估计超一点三十天，那么我们做设计和开发的辛苦一下，就勉强接受吧，但是在后来对需求进行评审时，由于需求发生变化，所以sprint周期变化了，而给产品经理提出后，产品经理要求开发接受这个时间，但以后呢？从而研究为什么敏捷开发强调一个较短但又不是太短的三十天作为一个周期呢？我的理解是，众所周知，不论是国内还是国外，月薪是一个较普遍的方式，当然有些企业或国家采用时薪或日薪或别的薪水制，但时薪或日薪会让一般的劳动者对薪水接受变得太普通和麻木，在获得了薪水时没有相应的成就感；月薪则对人有一种对当月工作的成就或总结的感觉，如果月薪滞后则带给大多数的人的感觉也不好；从这个面上来讲，迭代周期则是对人的一般的成就感的一种快速响应。
    从另一个角度看，软件的开发过程包括，需求分析、设计、调研、编码、集成、测试、反馈等过程，时间太短的话，从以上的各个阶段来说是不可行的，没有时间余量或工作量太小，做不成什么事就结束了一个迭代也是不合理的，而周期过长呢？传统的瀑布模型就是不能快速响应变化，如果我们做了二个月或三个月的计划，相比以前的半年或一年的计划可能是变少了，但响应变化时，二个月三个月的周长，要再进行研发的各阶段，比一个月的响应要变动大很多了。
    所以，我也很乐意地接受三十天左右的迭代周期，快速开发出结果，快速响应变化。