敏捷开发流程

任务排期

• 优先级排期。按优先顺序排列一个产品需求列表。

• 颗粒度。每个需求要尽量小，安排一个小需求在3天内完成。

• 工作量。技术管理者，要评估每个需求的工作量。评估工作量，除了开发时间，还要预留20%的时间处理bug，以及其他的杂事。

• 并行任务。任务并行能提高效率，串行会卡顿。
  开发人员发成一个小需求后，可以提测，然后做其他的需求，这样测试人员就不会被卡住了。

• 预留测试时间。除了定好开发人员的开发时间，还要留充足的时间给测试人员测试。

• 何时完成？何时发包？发出哪些内容？

晨会

• 站会。坐着的会议经常会开得太久，晨会没必要太久。

• 简要。每人花两分钟讲一下昨天/今天做的事情。

• 白板。通过白板展示每个人的工作内容，进度，以及遇到的阻碍。

• 量化。统计工作量，完成了某个需求的百分之多少，比如50%之类的。
  还可以写上耗费的开发时间，2h。(统计开发时间的意义不大)

需求评审

• 需求文档提前发布。文档提前半小时发给其他团队成员，给大家阅读思考的时间。

• 反讲解。程序员听完需求后，反过来讲给产品/需求人员听，看程序员对需求的理解是否准确。

• 拒绝不合理的需求。不明确的需求不要做。

• 在开发的过程中，最好不要乱改需求。这样会浪费开发时间，也影响交付的质量。

• 理解真正的需求。多沟通，开发人员理解了需求，再进行开发流程。

开发流程

代码设计

• 代码设计。包括接口设计，数据表设计等等。
  时间允许，还可以给出时序图，UML图。

代码开发

• 单元测试。单元测试的覆盖率要达到要求;

• 功能自测。程序员写完了代码，最好多测几遍，确保开发环境和测试环境都没问题。不要浪费测试人员的时间。

Review

• 在提交代码前，先让高工帮忙Review一下，Review完修正了代码再Commit。

代码评审

• 代码评审。复盘代码的设计是否合理、逻辑是否正确。

测试流程

用例评审

• 用例评审。测试用例，要在测试之前就先写好。

测试

• 正确地提bug。测试人员，最好能写清楚bug，包括期望结果、重现步骤等，如果能给出具体的图片更好。
  将bug描述清楚，能够节省开发和测试之间大量的沟通成本。

发布上线

• 发布说明：包括相关的服务，版本更新内容。sql脚本。

• 上线/发包必须经过运维。保证版本的可控性，避免泛滥，后续问题不可控。包尽量控制发的频率，不然很多功能控制不住。

• 一周一迭代。或者两周一迭代。

会议

• 会议总结文档。开完会要有结论，并记录文档。