憋个大招的开发方式非常不适合团队合作，而且极其容易导致项目延期。
当你没见过更优秀的沟通合作方式的时候，你以为现在的开发方式和合作方式就是正常的样子，其实本质来说就是见的少，遇到的少，可是话又说回来，当我们觉得合作方式非常累的时候，为什么想不到去寻找更加优质的合作方式呢？仅仅只是在被动承受着这样的合作方式。
或者说可以不可以这样理解，公司在项目最初期的时候，是不适合敏捷开发的？就是要集中精力先出一个可以用的版本？
不对，不是项目初期不适合敏捷开发，任何阶段的项目都适合敏捷开发，敏捷开发本来就是两到六周的一个时间段，在项目初期急需出成果的时候，迭代周期根据需要和规划进行适当的延长，最显著的例子比如移动端，通常来说web 端的发版要比移动端更加灵活一些，因此移动端就需要更长的迭代周期，但是测试周最多不要超过两周，并且可以中间加入一个过渡周，即开发的同时和测试两者并行，和测试沟通好开发这边会先进行哪些需求的提测，一次迭代周期过长对于项目的稳定性来说不是一件好事，同时对于开发人员来说周期过长会导致代码质量显著降低，bug 增加反而导致了更多的问题，因此两或三周一次迭代，小步快跑，能让项目更加灵活，同时各方都能以最快的速度看到成果和初期的效果，这也是敏捷开发的优势所在。
采用敏捷开发的方式，配合诸如 worktile、Teambition等企业协作平台，可以很好的实现各方的信息同步、项目进度管理、项目周期规划、OKR 定制等各种事务，避免沟通全靠吼的合作方式，至少在合作方式上能让各方达到一个比较满意的状态，具体的执行和产出就需要各个层级的领导人去进行监管和沟通。
每次迭代开始时，需求评审完毕之后根据现有开发人员数量进行初步开发估时（n*8*5，n 代表开发人员数量），如果项目时间不紧张，按照严格的时间标准进行开发，可以超出10%-20%的估时工作量，但是绝对不能再多了，因为超出预期的估时会有很大的风险造成上线延期，敏捷开发中延期的后果是非常严重的，因为每次迭代周期是相对独立的，如果又一次延期，那么必将影响下一次迭代，如果出现两次延期，就相当于少了一次迭代，这是得不偿失的，对于各方对接部门的影响也是非常大的。
敏捷开发迭代流程一定要根据当前项目情况和团队情况进行制定，根据执行过程中出现的各种问题进行讨论并进行流程微调，不断的让流程更加适合于自己的团队。
上述想法是在刚毕业时进入一个一个高效的敏捷开发团队中所学到的，人最大的优势就是不断的反思调整总结，最终找到更加合适东西，如果在现阶段发现错误，那么及时调整，做到更好。