敏捷开发的管理方式,我们也用了一段时间了,感觉就是一直跟着流程走,但是还没有真正的总结过整个过程。今天就来总结一下。
我们使用的工作流程更像是SCRUM框架。
敏捷项目管理有很多方法,其中SCRUM是最初起源于软件开发领域,通过将项目划分成更小的单元来帮助计算机科学家实现敏捷的开发过程。
学习SCRUM需要了解一下内容:3个角色,3个工件,5个事件,5个价值。
3个角色:
- 产品负责人PO(Project Owner)
- Scrum Master
- 开发团队(包括开发和测试)
3个工件:
- 产品BackLog(产品待办事项列表)
- SprintBacklog(本次Sprint待办事项列表)
- 产品增量(Increment)(理解成下一步的产品计划或需求)
5个事件
- Sprint(Sprint本身是一个事件,包括了如下4个事件)
- Sprint计划会议(Sprint Planning Meeting)需求的review和拆解,工作量的评估、任务分配
- 每日站会(Daily Scrum Meeting)汇报:昨日工作进度,今日计划,是否需要求助
- Sprint评审会议(Sprint Review Meeting)评审任务完成的质量
- Sprint回顾会议(Sprint Retrospective Meeting)复盘
5个价值
- 承诺 – 愿意对目标做出承诺
- 专注 – 把你的心思和能力都用到你承诺的工作上去
- 开放 – Scrum 把项目中的一切开放给每个人看
- 尊重 – 每个人都有他独特的背景和经验
- 勇气 – 有勇气做出承诺,履行承诺,接受别人的尊重
一些概念:
- Sprint:冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
- User Story:用户的外在业务需求。用户场景。
- Task:由 User Story 拆分成的具体开发任务。
- Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
- Daily meeting:每天的站会,用于监控项目进度。有些公司直接称其为 Scrum。
- Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
- Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
- Release:开发周期完成,项目发布新的可用版本。
然后就是把这些内容串起来:
我们使用的是jira工具,下面介绍一下我们团队的流程:
产品经理会将需求提出来,写明白需求文档,然后提交我开发团队做review
开发团队会去理解需求,分析需求是否可行,结合技术后是否有更好的产品方案,并协同产品经理进行修改。
需求确认没有问题时,我们会开会进行整体需求的讨论,讨论技术方案,对大的需求进行拆分,并评估工作量。评估工作量使用的扑克牌工具,里边的数值类似斐波那契数列,如果大家评估的工时差距较大时,需要给出自己的理由,然后重新评估一次,一直到评估结果大家都认同。
同时UI也开始进行设计。一般来说,UI和产品需求需要同时给出,但是时间比较紧的情况下,我们开发允许UI在开发后期给出,开发前期的这段时间,我们先写一部分不依赖UI的逻辑。
然后就是每天的立会,每人需要一两分钟时间,说一下昨天的任务完成情况,今天的计划,还有有没有困难需要求助。
有人完成任务后,需要找UI进行走查
UI走查完需要找产品经理进行show case,演示功能实现情况(此过程容易被改需求,小的改动可以接受(几小时),大的改动直接找PO商讨,开发原则上不直接接受产品需求)
进行提测,针对功能进行测试
此版本进行封包,完整性功能测试。
发版release
观察用户反馈,用户事件统计,app错误上报
复盘(很少有,除非出现大事故,比如项目严重delay)
https://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!