任务排期
-
优先级排期。按优先顺序排列一个产品需求列表。
-
颗粒度。每个需求要尽量小，安排一个小需求在3天内完成。
-
工作量。技术管理者，要评估每个需求的工作量。评估工作量，除了开发时间，还要预留20%的时间处理bug，以及其他的杂事。
-
并行任务。任务并行能提高效率，串行会卡顿。
开发人员发成一个小需求后，可以提测，然后做其他的需求，这样测试人员就不会被卡住了。 -
预留测试时间。除了定好开发人员的开发时间，还要留充足的时间给测试人员测试。
-
何时完成？何时发包？发出哪些内容？
晨会
-
站会。坐着的会议经常会开得太久，晨会没必要太久。
-
简要。每人花两分钟讲一下昨天/今天做的事情。
-
白板。通过白板展示每个人的工作内容，进度，以及遇到的阻碍。
-
量化。统计工作量，完成了某个需求的百分之多少，比如50%之类的。
还可以写上耗费的开发时间，2h。(统计开发时间的意义不大)
需求评审
-
需求文档提前发布。文档提前半小时发给其他团队成员，给大家阅读思考的时间。
-
反讲解。程序员听完需求后，反过来讲给产品/需求人员听，看程序员对需求的理解是否准确。
-
拒绝不合理的需求。不明确的需求不要做。
-
在开发的过程中，最好不要乱改需求。这样会浪费开发时间，也影响交付的质量。
-
理解真正的需求。多沟通，开发人员理解了需求，再进行开发流程。
开发流程
代码设计
- 代码设计。包括接口设计，数据表设计等等。
时间允许，还可以给出时序图，UML图。
代码开发
-
单元测试。单元测试的覆盖率要达到要求;
-
功能自测。程序员写完了代码，最好多测几遍，确保开发环境和测试环境都没问题。不要浪费测试人员的时间。
Review
- 在提交代码前，先让高工帮忙Review一下，Review完修正了代码再Commit。
代码评审
- 代码评审。复盘代码的设计是否合理、逻辑是否正确。
测试流程
用例评审
- 用例评审。测试用例，要在测试之前就先写好。
测试
- 正确地提bug。测试人员，最好能写清楚bug，包括期望结果、重现步骤等，如果能给出具体的图片更好。
将bug描述清楚，能够节省开发和测试之间大量的沟通成本。
发布上线
-
发布说明：包括相关的服务，版本更新内容。sql脚本。
-
上线/发包必须经过运维。保证版本的可控性，避免泛滥，后续问题不可控。包尽量控制发的频率，不然很多功能控制不住。
-
一周一迭代。或者两周一迭代。
会议
- 会议总结文档。开完会要有结论，并记录文档。
来源：https://www.cnblogs.com/expiator/p/12650769.html