个人时间管理：

个人在工作上的时间只有分配合适，我们的时间才能最大化利用，当然也是看自己有没“划水”的需求，有的话...我觉得还是按照你划水时间再挑战吧，现在不在我文章的讨论范围。

心流

大部分开发都知道我们在开发过程中如果在思考一个方案或火热的敲着代码过程中不希望被打扰，因为这样会打乱自己的思绪或逻辑。一般在自己写代码或思考结束才愿意被打扰，这也是心流反应吧。

我们要做到一块一块时间的完整顺序才能更好的利用时间，也是根据自己的工作任务和人员风格决定的。

轻重缓急

我觉得方法应该是首先要把自己的任务划分好难易轻重，把难的放在打扰时间比较少的时间处理，轻的简单的放在打扰时间可能比较多的时间处理。

打扰时间

一般打扰时间比较多的是一个需求刚开始，因为你们要跟需求各方讨论需求细节和美术细节，就需要一定量的沟通，这时打扰就比较难避免，这时可以选择一些可以打断的任务。还有一个时间就比较平常的晨会和周会的后面半小时，因为有可能出问题需要多方沟通，这时就打断比较多了。

另外一个可能会出问题的是人员风格，比如策划或美术更希望下午找你，你就可以早上尽量做点难度大的（也看你的习惯了）

紧急与重要的划分

如果真的你在开发途中遇到有人打扰，你也可以分清优先级和紧急程度决定是马上给对方处理还是记录下来等你处理完手头事情再处理。

紧急程度高而且重要的，那你就应该马上放下手头工作解决对方问题了，这个其实没什么可说的。

紧急程度高优先级低的，这个可以跟对方讨论，记录下来，晚一点给他处理

紧急程度低优先级高的，要记录下来但是你要规划好时间不能让他超过期限而到达优先级高的程度，一般如果优先级高的话你可以插到自己的下个任务里，但你一定要让项目经理知道，把整个迭代的开发顺序做调整并且有可能要做完全部需要delay或砍一些需求。

紧急程度低的优先级低的，这些任务一定可以让他确定是否放下一个迭代之类的，完全可以不用在那里讨论了。

小结

保证自己心流不打断是一个非常重要的开发心态，能够让自己得到更好的开发体验。当然可别放了自己的休息时间，一般一小时你应该站起来休息下了，这件事一般很难做到，但为了自己还是尽量做到，起来休息前可以记录下自己做到哪了。

项目时间管理：

需求开发时间一般需求策划把需求完整叙述出来，也就是需求评审，需要把需求说得比较清晰比较细致，最好图文并茂，如果有类似玩法最好演示。

预研

如果有技术不确定的点一定要提前跟技术leader确定，提前一个迭代，如果需要预研要提前做预研工作

需求评审

技术leader和具体开发一起听需求，把需求中可能存在的逻辑问题或不清晰的内容去询问策划，并且要考虑是否有不好实现的内容或性能上可能有风险的地方，然后跟策划探讨这样设计得原因、如果实在不好解决，可以探讨替代方案。实在没有才考虑变更需求。

开发时间确定

时间一般由具体开发主导确定具体开发时间，然后由技术leader确认是否合理。时间要细化到以天为单位（如果紧急可以以半天为单位）。时间上要细化到具体的逻辑还要注意要包括自测时间。如果有不确定的技术点，还要在一开始有预研时间。并且要确定是否有上游任务需要依赖，比如ui交互的确定以及ui设计什么时候给到，以及服务器或客户端的依赖。这样的时间才能保证比较准确。

管理buff

但是也有可能时间上会不准确而出现delay，比如对系统不熟悉，框架不熟悉，评估过于乐观，细节没考虑到等等。所以这时技术leader就需要在前期要分析是否有这些情况，及时加一定的时间上的缓冲（相当于管理buff）这样才能比较可靠。

后期需求删减

就算是这样开发也可能因为不确定的人员请假，生病，情绪变化，开始时需求分析不清晰导致需求开发到后期发现存在delay风险。这个时间应该要跟相关开发确认问题点，如果能帮忙解决或加人力解决就要及时处理（一般在晨会，周会等能了解到）。如果这样不能解决的话要跟策划沟通，把实际情况跟策划说清楚，然后跟策划讨论是否可以改为更简单的需求，更严重的可能需要把整个需求砍了放到下一个迭代做。这样才能保证比较可靠的时间输出。

bug太多

当然就算这样我们在测试后期可能会因为某些系统bug量过多，很难收敛bug。

这样就需要先看系统开发的情况，是否能指导或帮忙开发完善，如果实在到后期很难收敛了（极端情况）就需要跟策划测试讨论是否可以减少功能或bug优先级重新划分，把中低的留到后面去完善（比如不影响流程的就先设置为中或低）这样也是能保证在开发出来后可以上线，当然到这个阶段肯定开发leader要一起把控了，并且记录开发的绩效。

测试阶段

到了测试阶段最好让全体开发一起过晨会，晨会需要测试提出剩下高优bug，开发确定今天能解决的bug，确定好后今天要解决的一定要今天解决。这样可以激发员工工作积极性

周会

周会需要跟大家确定现有需求和bug，并确定本周任务是否完成，没完成需要加班或协调解决。

复盘

当然上线后需要整体开会复盘下迭代出现的问题，把流程可以优化的记录下来，问题的解决方案记录下来，发邮件给所有人以及项目负责人。这样可以积累问题解决方案，可以让下个迭代更顺利。