关于敏捷开发和憋个大招两种开发方式的思考

      憋个大招的开发方式很是不适合团队合做，并且极其容易致使项目延期。

      当你没见过更优秀的沟通合做方式的时候，你觉得如今的开发方式和合做方式就是正常的样子，其实本质来讲就是见的少，遇到的少，但是话又说回来，当咱们以为合做方式很是累的时候，为何想不到去寻找更加优质的合做方式呢？仅仅只是在被动承受着这样的合做方式。

      或者说能够不能够这样理解，公司在项目最初期的时候，是不适合敏捷开发的？就是要集中精力先出一个能够用的版本？

      不对，不是项目初期不适合敏捷开发，任何阶段的项目都适合敏捷开发，敏捷开发原本就是两到六周的一个时间段，在项目初期急需出成果的时候，迭代周期根据须要和规划进行适当的延长，最显著的例子好比移动端，一般来讲web 端的发版要比移动端更加灵活一些，所以移动端就须要更长的迭代周期，可是测试周最多不要超过两周，而且能够中间加入一个过渡周，即开发的同时和测试二者并行，和测试沟通好开发这边会先进行哪些需求的提测，一次迭代周期过长对于项目的稳定性来讲不是一件好事，同时对于开发人员来讲周期过长会致使代码质量显著下降，bug 增长反而致使了更多的问题，所以两或三周一次迭代，小步快跑，能让项目更加灵活，同时各方都能以最快的速度看到成果和初期的效果，这也是敏捷开发的优点所在。

      采用敏捷开发的方式，配合诸如 worktile、Teambition等企业协做平台，能够很好的实现各方的信息同步、项目进度管理、项目周期规划、OKR 定制等各类事务，避免沟通全靠吼的合做方式，至少在合做方式上能让各方达到一个比较满意的状态，具体的执行和产出就须要各个层级的领导人去进行监管和沟通。

      每次迭代开始时，需求评审完毕以后根据现有开发人员数量进行初步开发估时（n*8*5，n 表明开发人员数量），若是项目时间不紧张，按照严格的时间标准进行开发，能够超出10%-20%的估时工做量，可是绝对不能再多了，由于超出预期的估时会有很大的风险形成上线延期，敏捷开发中延期的后果是很是严重的，由于每次迭代周期是相对独立的，若是又一次延期，那么必将影响下一次迭代，若是出现两次延期，就至关于少了一次迭代，这是得不偿失的，对于各方对接部门的影响也是很是大的。

 

敏捷开发迭代流程必定要根据当前项目状况和团队状况进行制定，根据执行过程当中出现的各类问题进行讨论并进行流程微调，不断的让流程更加适合于本身的团队。

 

上述想法是在刚毕业时进入一个一个高效的敏捷开发团队中所学到的，人最大的优点就是不断的反思调整总结，最终找到更加合适东西，若是在现阶段发现错误，那么及时调整，作到更好。