07 大厂都在用哪些敏捷方法？（下）
你好，我是宝玉，我今天继续与你分享大厂的敏捷方法应用。
在上一篇文章中，我们一起看了一下大厂和敏捷相关的一些流程规范，同时也为你留了一道思考题：
如果每周一个Sprint，怎么保证每周都有交付，还能保证产品质量？
所以在这一篇中，我们就以每周一个Sprint的小项目组为例，看看它的日常是怎么应用敏捷开发的。
一个应用敏捷开发的小组日常
这个小组是做网站开发的，基于微服务负责网站的某一个小模块。标准配置7人左右，4个程序员（至少有一个资深程序员，有架构能力），1个产品经理（Scrum里面叫Product Owner），1个测试，1个项目经理（Scrum里面叫Scrum Master）。主要负责网站某模块的日常维护。
在分工上：
- 产品经理：写需求设计文档，将需求整理成Ticket，随时和项目成员沟通确认需求；
- 开发人员：每天从看板上按照优先级从高到低领取Ticket，完成日常开发任务；
- 测试人员：测试已经部署到测试环境的程序，如果发现Bug，提交Ticket；
- 项目经理：保障日常工作流程正常执行，让团队成员可以专注工作，提供必要的帮助，解决问题。
在敏捷开发框架下，已经形成了一些很好的敏捷实践，这个小组也是基于Scrum方法做过程管理，基于极限编程做工程实践，看板可视化。每周一个Sprint。
- 如何完成需求和修复Bug？
这个小组的日常工作，也是围绕Ticket来开展的。所有的需求、Bug、任务都作为Ticket提交到项目的Backlog，每个Sprint的任务都以看板的形式展现出来。
每个人手头事情忙完后，就可以去看板上的“To Do”栏，按照优先级从高到低选取新的Ticket。选取后移动到“In Progress”栏。
- 每周一部署生产环境
没有人愿意星期五部署，那意味着如果部署后发现故障，可能周末都没法好好休息了。所以即使程序早已经测试好了，除非特别紧急，否则都会留在下一周再部署。所以部署放在上半周，这样后面遇到问题还有足够的时间去应对。
部署很简单，按照流程执行几个命令就可以完成生产环境部署。部署完成后，需要对线上监控的图表进行观察，如果有问题需要及时甄别，必要的话对部署进行回滚操作。但轻易不会打补丁马上重新上线，因为仓促之间的修复可能会导致更大的问题。
像敏捷开发这样一周一个Sprint的好处之一就是，即使这一周的部署回滚了，下周再一起部署也不会有太大影响。
- 每周二开迭代回顾会议，总结上个Sprint
每周二的早上，这个小组一般还会预留一个小时的时间，因为常规的站会完成后，还有一个迭代回顾会议(Sprint Retrospective)会议，目的是回顾一下在迭代中，团队有哪些做的好的地方，有哪些做的不好的地方。
对于需要后续改进的，需要创建相应的Ticket，加入到Backlog中，在后续迭代中改进完善。
例如会议上，测试人员反馈说，上一个Sprint，开发人员上线前几个小时还往预部署的分支里面更新代码，导致测试需要重新做回归测试，但因为时间不够了，没来得及测试完整，导致上线后不稳定，建议以后不要随意在上线前，在部署分支更新代码。
对于这样的问题，可能不止一次发生，说明流程上还是存在问题。所以最后大家商定，以后如果不是紧急的修复，就不要在预部署的分支上更新，确实要加，需要和测试先确认。
如果会议中要形成涉及项目的决策，最好是通过集体表决的方式决策，尽可能避免独裁式决策。因为敏捷的原则之一是要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
- 每周四迭代规划会，计划下周工作
每周四早上，也需要一个小时来组织会议。因为常规站会完成后，还有一个迭代规划会（Sprint Planning Meeting）。这个会议是要大家一起讨论下一个Sprint 的内容。
在开会之前，产品经理和项目经理会商量好Ticket的优先级，会议上，大家一起按优先级从高到低的顺序，从Backlog中选出下个Sprint的内容。
团队每个成员都要对候选的下个Sprint Backlog中的Ticket从1-5分进行打分，1分表示容易1天以内可以完成的工作量，2分表示2天内可以完成的工作，5分表示非常复杂，需要5天以上的工作量。
这里需要注意，打分时，要大家一起亮分，而不是挨个表态，不然结果很容易被前面亮分的人影响。
评估每条Ticket工作量的大概流程如下：
- 会议组织者阅读一条Ticket，可能是用户故事，可能是Bug，可能是优化任务。同时会询问大家对内容有没有疑问。
- 大家一起讨论这个Ticket，确保充分理解这个Ticket。
- 每个团队成员在心中对Ticket进行工作量估算。
- 会议组织者确认大家是否都已经确定估算结果，确认后，开始倒数：“3，2，1”，大家一起伸出一只手，亮出代表分数的手指头。
- 如果估算结果存在分歧，出分最高的和最低的各自说明理由，讨论后达成一致。
这种估算工作量的方法有个名字叫估算扑克，因为亮分时用扑克牌亮分而得名，但并非一定要用扑克牌。
用这种方式评估工作量有几点很明显的好处：
- 大家积极参与，详细了解需求。相比以前，可能只有当某个功能模块分配到自己头上的时候，才会去详细了解那部分需求，而其他开发人员可能都不了解这部分需求。
- 工作量是由实际参与开发的成员作出评估，往往更准确也更容易被接受。以前项目经理代为估算的模式，很容易不准确，或者让开发人员抵触。
- 促进成员的交流和经验分享。我们知道一般经验浅的新手估算工作量都会偏乐观，而经验丰富的老手则会更准确，通过这种方式，新手可以向老手学习到很多工作量估算甚至技术实现的经验。
所以，在经过几个Sprint的磨合后，一般一个团队在每个Sprint的产出是比较稳定的。比如说这样一个7人的小团队，一个Sprint预计可以完成20-30分的Ticket。
- 每周五分支切割
周五标志着一周的工作要结束了，所以下班之前（4点左右），要做branch cut（分支切割），也就是要把当前主干上的代码，克隆到一个分支（branch）上。
为什么要做分支切割这一步操作呢？
经过一周的开发，master （主干）已经合并了不少新的PR（Pull Request，合并请求），但是如果你直接把master的代码部署到生产环境，肯定还是不放心，毕竟自动化测试还是不能完全代替专业测试人员的测试。
所以我们需要把master上的代码部署到测试环境进行测试，并且对测试出来的Bug进行修复，直到稳定下来为止。由于master还需要一直合并新的功能，所以最好的方式就是每次Sprint结束，从master创建一个分支版本出来，然后基于这个分支部署和修复Bug。
所以需要基于主干做一个branch cut，创建一个预部署的分支，将预部署分支的代码部署到测试环境，这样在下周，测试人员就可以测试新的版本。测试验收通过后，预部署分支的代码会部署到生产环境。
- 每周轮值
小组里面除了日常开发工作以外，其实还有不少琐碎的事情，比如每周部署生产环境，每天部署测试环境，每周的branch cut（分支切割），回答其他小组的问题，主持每日会议（不一定需要项目经理），这些事情如果都是一个人做难免会有些枯燥。
在敏捷开发中，鼓励发挥每个成员的主动性，所以每周轮值是一个不错的方式，可以让每个人都有机会去体验一下，帮助团队完成这些事情，更有集体荣誉感和责任感。
一些问题解答
上面只是选取的一个项目小组的日常，所以估计你看完还会有些疑问，在这里我把可能的问题列一下，先行解答一下。
1. 基于这种敏捷开发的方式加班多吗？
其实加不加班，绝大部分时候和是不是敏捷开发没关系的，还是看项目组的情况。
通常来说，基于敏捷开发一个Sprint、一个Sprint迭代，节奏还是比较稳定的，这个Sprint做不完的任务也可以顺延到下个Sprint，不影响发布。不像瀑布模型那样前松后紧，后期加班可能性大一些。
2. 一周一个迭代怎么保证质量？
以前我在使用迭代模型开发时，一般是4周左右的迭代周期，2周就是极限了，所以最开始看敏捷开发用1周的迭代周期，心中也有疑惑，1周时间又要开发又要测试，怎么保证质量？
实际实践下来，发现1周一个Sprint确实可行，而且质量也可以有保障，这里面有几个因素：
（a） 有足够比例的自动化测试代码，可以很好地保证质量。当用户的主要功能都通过自动化测试覆盖时，基本可以保证主要功能流程不会出问题。
（b） 一个Sprint开发完成后，并不马上部署生产环境，而是先部署到测试环境，会有1周时间测试。
（c） 有专业的测试人员进行测试，并非完全依赖自动化测试。有时候一些大的功能更新，甚至会组织全组成员一起测试，以弥补测试人员不足的情况。
在一个Sprint开发结束后，并不马上部署生产环境，而是先部署测试环境测试。
也就是说，虽然是1周的Sprint，但是其实还有1周的时间进行测试。每个Sprint不仅开发新功能，还要同步修复以前版本的Bug。
这样基本上可以保证有好的质量。而且这种1周的迭代，可以保持每周都有内容更新，还有个好处就是每周更新的内容不多，出现问题的话，很容易就定位到是什么地方导致的问题。
3. 基于敏捷开发如何做计划？
大厂里面通常会在上一年底确定第二年整年的大的开发计划，并确定上线的时间范围，每个季度再根据情况做一些调整。
这些大的计划最终会变成具体的开发任务，一个大的开发任务，会分拆到各个部门，各部门再将任务分拆到各个项目组。基于敏捷开发的话，主要就是看把这些开发任务放到哪几个Sprint去做，并且确保在规定的时间范围内完成。
至于工期的估算，在迭代规划会上会对每个Ticket进行打分，根据分数可以预估有多少工作量，要花多少时间。
4. 如何沟通协作？
组和组之间的沟通协作，主要通过邮件、会议、内部沟通工具，最终任务会以Ticket的形式体现。
团队内部的话，因为都在一起，所以沟通起来很方便，每天站立会议都是很好的沟通方式。
在敏捷开发中，有一种实践叫结对编程，就是两个程序员在一台电脑上一起工作。这个一直争议比较大，但是如果用来两人一起排查一些问题，或者是资深程序员带新手程序员，则是一种非常好的协作方式。
5. 上面介绍的实践案例和标准Scrum有什么不同？
我上面介绍的内容，确实和标准的Scrum有不少不一样的地方。
首先是角色名称不一样，在Scrum里面是分Product Owner、Scrum Master和Team三种角色，而在这个案例中是产品经理、项目经理和团队成员，但其实只是名字叫法不一样。
还有要注意一点，就是传统的项目经理，会是偏控制型角色，Scrum Master则更多是一种服务型的角色，主要职责是保障敏捷流程的执行，以及提供必要的帮助，很多团队的决策就是采用集体决策的方式。
另外，Scrum有四种会议，除了前面介绍的三种：每日站会（Daily Scrum）、Sprint计划会（Sprint Planning）和Sprint回顾会议（Sprint Retrospective），其实还有一种会议是Sprint评审会（Sprint Review）。
Sprint评审会的作用是让客户审查Sprint的完成结果。因为上面这个小组并没有直接的客户，都是完成产品经理提交的需求，而且沟通紧密，所以没有安排专门会议。
这个小组的站立会议并不是“标准”的站立会议，Scrum的站立会议通常只有15分钟，并且只有轮流发言环节。
这里增加的每天审查Ticket环节，主要是为了将优先级高的Bug修复之类的Ticket放到当前Sprint，及时响应，及时处理。有的项目组没有这个环节，是由测试人员或者Scrum Master直接将Ticket放到看板。
这个小组并没有使用用户故事来开发需求，而是由产品经理事先写好需求文档。在上一篇文章里面，提到了Scrum采用用户故事的方式，分拆需求，减少繁重的需求文档，在实现的过程中再沟通确认需求。
这是Scrum推荐的一种方式，也是一种高效的方式，但并不代表这是唯一的方式。如果有产品经理，可以提前几个Sprint就将需求文档写详细，一样可以达到高效的理解需求的效果。
那么这样还算敏捷开发么？
其实在《05 | 敏捷开发到底是想解决什么问题？》就有讲过，是不是敏捷开发，核心并不是应用了哪个方法，而是应用的时候，是否遵循了敏捷开发的价值观和原则。
比如说非标准的站立会议效率更优，那么就应该采用非标准的站立会议；如果有专业产品经理事先做好需求分析，可以达到解释清楚需求的效果，就没必要一定要用用户故事来理解需求。
总结
上一篇文章我们讲了大厂里和敏捷相关的一些流程规范，这一篇又讲了一个小组是怎么应用敏捷开发来开发项目的。
现在看上一篇文章中我留的思考题：如果每周一个Sprint，怎么保证每周都有交付，还能保证产品质量？想必你已经有了答案。
要保障质量，还是离不开充分的测试，不仅要有自动化测试，还要辅助一定量的人工测试。敏捷开发虽然求快，但是不代表应该牺牲质量。
其实，大厂的敏捷实践并不神秘，关键是分而治之，最终团队小，项目小，所以才可以敏捷起来。大厂会注重流程和工具的应用，通过Ticket的方式来管理和跟踪开发任务，通过自动化的方式来部署。
大厂的敏捷实践，一般是基于Scrum、极限编程和看板，针对各自项目组的特点，会有所侧重有所调整，在遵循敏捷的价值观和原则的前提下，做到高效使用。
希望上面介绍的敏捷应用，能对你理解敏捷开发有所启发，帮助你优化改进日常项目流程。还有要注意的一点就是，没有万能的开发模式，只有适合项目的开发模式，最重要的还是要摸索出一套适合你自己项目特色的开发模式。
限于篇幅，对于Scrum、极限编程和看板，我并没有展开细讲，还需要大家自己辅助看看书，我在《学习攻略 | 怎样学好软件工程？》和《05 | 敏捷开发到底是想解决什么问题？》文章中也列了一些参考书籍。
留言区有同学推荐的文章《天下武功，唯快不破—新时代敏捷项目管理之道》对敏捷开发也有很不错的讲解，推荐阅读。
课后思考
看完本篇内容，你可以将上面介绍的开发模式和你现在的项目开发模式对比，你觉得有哪些好的地方可以借鉴？你觉得有哪些做的不够好，可以改进的地方？
另外，你也思考一下，为什么文章中，这个项目没有在一个Sprint里面同时完成开发和测试，而是把测试放在下一个Sprint，这样做有什么优缺点？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
- williamcai 👍（14） 💬（3）
有个疑问v1.1 v1.2 开发分支是不是从master同一个版本拉下来的吗，因为到1.2的时候，v1.1处于待测，不可能合到了master
2019-03-09 - 探索无止境 👍（11） 💬（1）
这真是极客专栏的典范，有问必答，购买专栏的目的更多是为了跟大师有交流的机会，而有些专栏仅仅只是发布了文章或视频。说回我的问题，老师在文中说到的主分支切割"测试验收通过后，预部署分支的代码会部署到生产环境。"，我的理解是部署的分支的代码，上线测试没问题之后，再把这个代码合并回主分支，不知道这样理解对不对？
2019-05-06 - 舒偌一 👍（10） 💬（1）
看了上下两篇文章，自己当前紧急的问题是成员的责任心和能力问题，就是怎样培养团队成员？老师有没有好办法
2019-03-09 - 十斗簸箕 👍（8） 💬（1）
请问老师对于C++开发有什么好用的单元测试、继承测试框架推荐？
2019-03-11 - Felix 👍（8） 💬（1）
读了老师这篇文章，给我最大的启发就是扑克估算；我之前的做法是让具体开发自己先估算，我再基于他的估算结果根据自己的认识进行微调，虽然这估算经过两个人，但这种形式还是有估算不准的情况 下周周会我就要确定新的流程；后续我会让小组内成员加上我一起针对Ticket进行估算，充分讨论后达成一致 还有一个问题问一下宝玉老师，我对于结对编程的概念不是很明晰；一个冲刺，分派给两位同学开发，他们相对来讲都很资深，分工明确，互相配合，但是分别在自己的电脑上开发……这种是否是结对编程呢
2019-03-09 - stg609 👍（7） 💬（1）
绝对是模范老师，有问必答。 我也有个疑问想请教老师，如果在一个 sprint 过程中，客户(老板)提了2种新需求(第一种，属于新增的需求，但是客户希望立刻实现。第二种，是对老需求的修改，有可能是完全颠覆了sprint计划会议中所定义的需求)，此时作为 SM 该如何进行控制？ 如果sprint过程中经常出现这种情况，怎么办？
2020-03-25 - 一路向北 👍（6） 💬（1）
这篇学习完后，对敏捷的实际操作有了更深的理解。 对于小公司小团队的项目，因为项目经理，产品经理都是身兼数职，是否有更好的实施方式呢？ 目前认为的难处：1. 作为项目成员的程序员可能还需要去做项目经理或者产品经理的工作，2. 项目交织在一起，有新的项目在做，也有原先项目的维护工作或者新的需求。这样的情况在实施敏捷开发的时候应该如何最大化的发挥敏捷的优势？
2019-03-11 - alan 👍（6） 💬（2）
老师好！关于人工测试，我想向您请教一个困惑。 我所在的团队正在尝试敏捷开发，遇到的问题是“人工测试”不知该摆在什么位置。 我们当前在Jira上设置的工作流是这样：todo→进行中→已完成→测试中→已测试。这种工作流是可行的吗？还是说把当前sprint的测试工作，都放到下个sprint会比较好？ 由于我们有专职测试的同事，但是很多issue是测试同事很难进行测试的，导致工作流走不顺畅。 但如果不设置“测试中”这列，又觉得质量没有足够的保障（我们的自动化测试还很不完善）。 谢谢老师！不知您后续是否会就敏捷开发中测试的话题单独讲述。
2019-03-09 - 舒偌一 👍（5） 💬（1）
模式差不多。但我们测试和开发同步，我们有自动测试和专门的测试人员，测试人员测试前一天开发提交的代码，开发人员优先解决测试发现的问题（会导致开发加班）。如果不同步，会影响版本发布
2019-03-09 - J.M.Liu 👍（4） 💬（1）
关于Ticket工期估算那里有个疑问。团队中一般都是一两个人负责一个小模块，之所以这样做是为了提高工作效率，避免同一段代码每次迭代都由不同的人去修改，因为大家对自己的小模块很熟悉，所以工作效率很高。但这样带来的问题是，团队成员对其他人负责的模块不熟，所以工期估算只能由模块负责人自己完成，别人很难帮上忙。这种情况怎么解决啊
2019-03-21 - 哈拿 👍（4） 💬（1）
老师，你不是说当前的sprint可以放到下一个进行测试吗？为什么在回答alan的问题时又建议他放到当前的sprint里呢？
2019-03-12 - alva_xu 👍（4） 💬（1）
有一个问题，如果一个迭代里没有评审会，怎么知道我上线的系统是符合要求的？ 另外，我觉得在计划会上，有几个事情必须要做好，一是需要定义DOR和DOD，Define of Ready 和Define of Done,如果没有这两个定义，那么扑克牌可能会玩不起来。第二 需求（用户故事分解成的task)一定要尽量明确。不管扑克估算还是其他估算方式，如果第一轮估算偏差过大，说明大家对需求不明确，需要产品经理进行更详细的说明。通过几轮估算，如果大家能达成比较一致的估算，那么工作量的估算就比较靠谱了，这也是Scrum这种工作方法带来的好处，能让需求得到合理的资源安排。 不管怎么说，在Scrum里，要重视估算，有了好的估算，速率才真正有意义，才能真正保证交付质量。
2019-03-11 - javaadu 👍（4） 💬（1）
优点：新开发的功能有足够的时间测试 缺点：合并分支有点麻烦，开发和改bug同时进行，如果前一个sprint开发的代码bug比较多，可能会影响这个sprint的开发 关于分支部署那里，我们采用的办法是拉个新分支做开发，在预发测试好了再合并但master部署。 另外阅读本文的收获有两个：扑克牌估算工作量，这个确实之前是非常头疼的环节，准备尝试一下新方法；不同的会议的作用和介绍，有些可以借鉴一下用
2019-03-09 - SOneDiGo 👍（4） 💬（1）
关于课后提问: 我觉得可能是第一个sprint一时间还不能写完完整的代码可以去跑测试，所以只能放到下周…如果执念于第一个sprint也要做测试，可能项目代码没能好好完成，测试出一堆bug，那么这个强求的测试可能没什么意义了，反而还要回来再改bug,违背了敏捷的理念 缺点:如果说在安排的时候过于专注在开发上，有些bug不能及时在第二个sprint安排前发现，导致sprint2的进展出现困难，也违背了敏捷的理念
2019-03-09 - 什么也不说 👍（3） 💬（2）
老师有个问题没理解， brach分隔图上 sprint v1.1 在生成环境验证没问题的话，合并到master。 这个sprint v1.2需要测试，怎么做呢， v1.2不包含sprintv1.1的更新啊？
2019-03-18