软件工程之美学习笔记八 07 | 大厂都在用哪些敏捷方法？（下）
《软件工作之美》材料地址：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。也就是说是有验收，只是没有专门的会议。