敏捷开发流程

零、迭代

  • 小步快跑,快速迭代。

版本迭代中,尽量不要做大而全的瀑布流的需求,最好是一些小的快速交付的需求。

在快速迭代中,迅速做出用户需要的需求,并在迭代中,根据用户的反馈,快速调整。

一、需求评审

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

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

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

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

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

二、任务排期

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

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

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

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

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

三、晨会

  • 站会。坐着的会议经常会开得太久,晨会没必要太久,最好不要超过30分钟。

  • 简要。每人花两分钟讲一下昨天做了什么事情,今天准备做什么事情。

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

  • 目的。同步进度,暴露问题。暴露问题不可怕,可怕的是不暴露问题。问题越早暴露越好。

  • 需求。晨会是用来同步进度的,不是用来讨论需求的。需求的细节不要放在晨会上讨论。这是在浪费其他人的时间。

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

四、开发流程

技术评审

  • 开发给出技术文档。
    包括工作项拆解,工时评估,接口设计,数据表设计、时序图、UML图。

代码开发

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

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

Review

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

代码评审

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

五、测试流程

用例评审

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

测试

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

六、发布上线

  • 发布评审checkList:包括相关的服务,版本更新内容。sql脚本。动态配置。

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

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

七、其他

会议

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

复盘

  • 每个迭代/每个月结束,定期组织团队复盘,总结提高。

工具

Jira:敏捷开发团队的项目开发及管理工具。
Confluence:团队协作及知识库管理平台,可以构建项目的文档。

posted on   乐之者v  阅读(1094)  评论(0编辑  收藏  举报

努力加载评论中...

导航

点击右上角即可分享
微信分享提示