什么是合理的开发排期？我个人以为合理的开发排期是一个项目不延期，少加班的时间管理。
在目前接触的各种项目开发中，开始时觉得时间很充足，但是后面做着做着，就变成苦逼开发加班加点赶工期，甚至项目延期。不仅仅是毕业两三年的同学，甚至有工作近十年的老司机，也会经常遇到这种情况。出现这种情况大家很自然的想到是因为项目过程中各种不确定的事情发生，导致原本预感足够的时间变得紧张起来。所以在项目进行的前期，作为开发需要给自己定一个合理的开发排期。
那么如何来做一个合理的开发排期？
一、梳理时间分布
作为主要工作，理想的情况下一天的时间都应该花费在需求研发上，但是各种事情的插入，甚至开发自己的心情变化都会影响需求研发的进度。根据我们团队的工作事项，总结下来研发同学日常的时间主要花费以下几个方面：
- 需求研发
- 技术支持（工单、线上问题）
- 团队事务（指导新人、分享、招聘）
- 会议沟通（评审、例会、技术咨询）
- 技术学习
可以说大多数情况下，一个项目的工期进度，受到研发同学在这些维度上的时间分配影响。假设需求研发按照八小时来分配，那么随着其他维度的时间消耗，基本上在工作上的时间要花费是十一个小时左右，而对于在技术和管理中并行的同学，恐怕研发外的事务花费时间更多。同时需要在各个维度上进行思维的切换，这部分切换的时间按照0.5小时来算，那么在工作上的时间基本要达到十二个小时。算上通勤、吃饭、午休，基本要消耗十六个小时。一鼓作气，再而衰，三而竭。久而久之对项目造成严重的风险，对团队管理亦带来沉重负担。
要做合理的开发排期，第一步是要摸清楚自己每天的时间分布，然后按照自己的有效研发时间来对项目需求估算工期。打个比方如果开发同学真正的有效率的开发时间是6个小时左右。那么在新的项目中，就以六个小时的开发时间来估算工作量的消耗时间，从而估算出项目的开发周期。
根据多年来经验，对于上述维度的时间分配建议比例是，6:1:1:1:1，这样一天的时间是十个小时，对于互联网工作的同学，这个时间还尚可接受。另外除了需求研发外，其他的事项并不是每天都有或者每天都同时发生，那么省下来的时间，可以放到需求研发或者学习中去。在遇到时间紧张的项目时，可以根据情况砍掉一些项目（比如技术学习），可以请求其他同事在这段时间内，对一些事务进行支持（比如技术支持、团队事务）
所以做合理排期至关重要一步： 以实际（每天）需求研发时间来估算开发周期
二、预留buffer
工作中经常遇到一些很自信的同学，做排期时不留buffer。可预知的事情是在有事情插入或者遇到技术难题时，这位同学会往往加班加点赶工期的情况下度过，甚至导致项目对外承诺的时间点不成如期完成。所以不管是什么项目，不管是什么段位的技术大牛，一旦在实际项目中工作，预留buffer都是非常重要要的事情。对于buffer的作用无外乎降低项目风险，buffer的预留和使用可以参考以下两点：
- 总体buffer原则是一周预留一天
- 项目版本迭代建议也预留部分buffer
- UI走查建议使用buffer时间
三、管理依赖
需求某个事情完成才能进行的工作就是我们的依赖项。一个项目难免在项目成员或者对外部团队产生依赖，依赖完成的时间和质量都会产生项目风险。对于依赖的管理也会影响我们的开发排期甚至是整体的项目进度。根据经验依赖管理主要有以下两方面
- 依赖项完成时间点
- 规划联调时间，一个依赖建议1-2天
对于第二条要特别重视，很多情况下在项目排期时容易忽略联调时间，想当然以为依赖项在这个时间点给出的是一个稳定的输出。导致后期发现问题反复沟通修复，延误项目进度。
四、测试与复查
项目进行到尾期需要进行测试工作，在这个过程中还有两部分工作：产品复查部分细节逻辑合理性，UI走查设计同学确认交付产品满足视觉要求，但是这两部分都可以放到测试阶段来做。
测试阶段工作，对于开发来说主要是部署环境和修复bug。同时这部分时间还受产品逻辑的复杂度影响，在这阶段如果没有足够的时间来进行测试覆盖和bug修复，对产品项目来说同样是不能交付的产品，项目风险极大。测试与复查时间的分配可以参考以下几点：
- 周版本大概1-2天
- 两周版本大概2-3天
- 月版本建议4-5天
- 产品复查使用测试时间
- UI复查使用测试或者buffer时间
另外为什么测试时间这么重要，因为有些依赖项即使跟他联调成功后，输出的依然不是稳定产品，因为他们根本没有QA介入，只是简单的自测！
同时遇到项目周期超过三个周的项目，最后是拆分迭代版本，每个迭代都有一个输出成果，同时对每个迭代的输出成果单独测试。对每个迭代的测试bug，只修复严重问题，其他问题可以在项目后续开发中修正或者在整体的bug修复时间进行修复。
五、上线
最后进行到项目交付前的临门一脚，涉及到项目上线，最重要的是梳理上线流程，包括依赖方的上线，梳理各个服务提供方的上线顺序，发送邮件通知大家。另外一个重要的事情是各个环节都要有相应的回滚策略，甚至是依赖链的回滚。对于大的变动，测试基本结束后，在团队内部发起捉虫体验，每发现一个bug可以给与一定的奖励。项目上线和线上回归时间尽量在一天内完成。关于上线的注意事项罗列如下：
- 梳理上线流程，建议在上线前两天讨论
- 各环节确认回滚流程
- 大版本建议团队内部发起捉虫
- 无依赖上线+回归建议1天
- 同一个项目最好在1天内完成，否则拆分成多个独立模块单独上线
六、最后
项目上线完记得请客吃饭！！！
原文地址：https://www.cnblogs.com/dojo-lzz/p/10261690.html