《软件工作之美》材料地址:https://time.geekbang.org/column/article/0?cid=158
1.主题
以一周迭代开发为例,讲述敏捷方法
2.角色
1,产品经理(product owner)写需求设计文档,将需求整理成 Ticket,随时和项目成员沟通确认需求 (1人)
2,开发人员 (4人)
3,测试人员(1人)
(2,3为team,这个例子里开发和测试是不同角色的)
4,项目经理 (scrum master)保障日常工作流程正常执行,让团队成员可以专注工作,提供必要的帮助,解决问题。(1人)
(与传统的项目经理不同,侧重于提供服务,而不是偏控制,决策主要靠集体决策,而不是scrum master)
*** 每周轮值制度 ***
可以考虑scrum master 的轮值制度,可以发挥每个成员的主动性,培养融入感
敏捷的原则之一是要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
3.工程方法
极限编程
4.迭代周期
一,Scrum安排:
长度一周,开发和测试分开,即一个sprint 开发,一个sprint 测试,交替开展,周一至周五
- 周四 迭代规划会( sprint planning meeting),规划下周工作(1小时)
这里的一个重点是story point 的评估,老师介绍的是扑克估算法。在我的留言部分我有些想法可参考。另外速率(velocity)是考核进度的,必须依据与合理的story point 估算,才能得到合理的velocity ,以后才能计划合理的工作量。 - 周二 迭代回顾会议 (Sprint Retrospective meeting),主要回顾方法论 (1小时)
- 每天站会 (Daily Scrum) (15分钟)
- 由于有项目经理和测试人员验收,与最终用户没有关联,干系人(stakeholder)比较少,所以不开迭代审核会(spring review meeting )
二,工程安排:
- 每周五分支切割
疑问1:
v1.1 v1.2 开发分支是不是从master同一个版本拉下来的吗,因为到1.2的时候,v1.1处于待测,不可能合到了master
老师解答: 好问题,这个通常有两种方案:
方案一:v1.1可以不合并回master,如果有bug修复,先在v1.1上修复,然后把修复的代码同时cherry-pick到master,就是要提交两个PR,内容一样。
方案二:v1.1在部署后合并到master,这样就可以把v1.1上的修改合并到master,但是可能会有不少代码冲突
各有优缺点,具体怎么做还是看项目组的决策
- 每周一部署生产环境
目的是为了给更多的修复系统的时间。
5.常见问题
- 加班问题
- 质量问题
- 计划问题
- 沟通问题
6. 我的留言
一、项目没有在一个 Sprint 里面同时完成开发和测试,而是把测试放在下一个 Sprint
这个问题,我的理解是,如果测试团队和开发团队是完全分开的,那么放两个Sprint比较好。但如果开发人员同时可以做很多代码和接口测试工作,而集成测试又可以通过编写测试脚本,进行自动化测试,那么,我觉的没必要分开。关键是在接受ticket时确定好验收标准,那么把一周一个迭代变成两周一个迭代,一个迭代里既包含开发又包含测试,这样多个开发测试任务并行进行,可以提高交付效率。
2019-03-11
作者回复: ?
支持你的观点:如果有专职的测试团队,放两个Sprint更好,这样正好测试和开发可以错开,如果没有专职测试,还是一个Sprint更好。
如果一周Sprint变两周一个Sprint就有更充足的时间进行测试。交付质量也会相应提高。
二、有一个问题,如果一个迭代里没有评审会,怎么知道我上线的系统是符合要求的?
另外,我觉得在计划会上,有几个事情必须要做好,一是需要定义DOR和DOD,Define of Ready 和Define of Done,如果没有这两个定义,那么扑克牌可能会玩不起来。第二 需求(用户故事分解成的task)一定要尽量明确。不管扑克估算还是其他估算方式(比如T-shirt方式),如果第一轮估算偏差过大,说明大家对需求不明确,需要产品经理进行更详细的说明。通过几轮估算,如果大家能达成比较一致的估算,那么工作量的估算就比较靠谱了,这也是Scrum这种工作方法带来的好处,能让需求得到合理的资源安排。
不管怎么说,在Scrum里,要重视估算,有了好的估算,速率才真正有意义,才能真正保证交付质量。
2019-03-11
作者回复: 对于估算这部分的补充非常赞?
没有评审会,但是有专职测试针对最初提的需求进行测试,另外产品经理也会验收,如果验收不合格会提交Ticket。也就是说是有验收,只是没有专门的会议。