大厂都在用哪些敏捷方法

大厂做项目也没有什么特别的，无非就是工程中常见的“分而治之”的策略： 大项目拆成小项目，大服务拆成小服务，大团队拆成小团队。

服务之间通过商定好的标准协议进行通信，架构上将大的服务拆分隔离成微服务，大团队按照业务或者服务拆分成小组，按照一定的流程规范保障协作。最终，各个小组要负责的内容其实就不多了。

就像淘宝这种网站，不需要一个庞大的项目组，通过逐级分拆，一个小组可能就只需要负责一个页面中的一个小模块

敏捷开发相关的主要流程规范

工作任务围绕 Ticket 开展

早些年的项目开发，都是围绕着项目计划开展的，把甘特图打印贴在墙上，方便团队成员看项目进展到什么地步了。自从敏捷化后，开始变成了看板。

慢慢的物理的看板变成了电子看板，通过各种项目管理软件来管理跟踪这些任务，即时贴也变成了 Ticket。逐渐的，所有与开发相关的任务也都和 Ticket 挂钩：报一个 Bug、提一条需求、要重构一下代码都需要提交一个Ticket ；

每天上班第一件事就是打开看板，看看当前 Sprint 还有哪些 Ticket 没有完成，哪些已经完成，哪些正在进行中，非常直观。

作为项目成员来说，做完手头的事情也不用去问项目经理该干什么事情了，直接从 To Do 栏选一条 Ticket 做就是了；对于项目经理，看看 To Do 栏还有多少没有被选取，就知道还剩多少 Ticket 没完成，看看 In Progress 栏就知道哪些 Ticket 正在进行中。

如果有 Ticket 在这一栏待太久或者这一栏 Ticket 太多，那可能就有风险了，就可以及时介入

基于 Git 和 CI 开发流程

如果你的团队应用瀑布模型来开发，大概会有两大烦恼： 代码不稳定和部署太麻烦。

早些年虽然也用源代码管理，但是大家都是在master（主干）上开发的，所以 master 的代码特别不稳定，一不小心就可能被人签入了不稳定的代码。所以在上线前，有一段时间叫“代码冻结期”，意思就是这期间，除非是紧急修复，否则谁都不能往上面提交代码。

还有，测试环境的部署也是个老大难问题，尤其是在服务较多时，编译要注意各种依赖和环境的配置。所以更新测试环境是个大工程，以至于当年我在飞信的时候，专门有人负责部署测试环境。

上面的“代码冻结”和“专人部署”方案，可一点都不敏捷。所以团队想要敏捷起来，一定要解决代码不稳定和部署太麻烦这两个大问题。

好在基于Git的开发流程结合CI的自动测试部署，很完美的解决了这两大问题。

Git本来只是源代码管理工具，但是其强大的分支管理和灵活的权限控制，结合一定的开发流程，却可以帮助你很好的控制代码质量。

我们假设现在 master 的代码是稳定的，那么怎么保证新加入的代码也稳定呢？

答案就是代码审查（Code Review）和自动化测试。如果代码有严格的审查，并且所有自动化测试代码都能测试通过，那么可以认为代码质量是可靠的。当然前提是自动化测试代码要有一定的覆盖比率。

关于这点，对于大厂来说倒不是什么问题，正规的项目组对于代码审查和自动测试代码的覆盖率都有严格的要求。现在还有一个问题，就是如何在合并到 master 之前把代码审查和自动化测试做好呢？

简单来说，就是每次要往 master 添加内容，不是直接提交代码到 master，而是先基于当前稳定的 master，克隆一个branch（分支）出来，基于 branch 去开发，开发完成后提交一个PR（Pull Request，合并请求）。

PR提交后，就可以清楚的看出来代码做了哪些改动，其他人就可以针对每一行代码写评论提出修改意见。如果确认代码没问题了，就可以通过代码审查。

接下来还剩下自动化测试的问题。这时候该CI （持续集成）出场了。

如果你不了解CI是什么，可以把它想象成一个机器人，每次你提交一个PR（严格来说是Commit，这里略作简化）到源代码服务器，这个机器人马上就知道了。

然后它创建一个干净的运行环境，把你提交的代码下载下来，再下载安装所有依赖项，然后运行你的所有测试代码，运行完后，把测试结果报告给你。测试结果直观的反馈在PR上，绿色表示通过，红色表示不通过。

关于Git和CI，我在之后的文章中会展开讲解，这里只是为了展现敏捷开发方法的流程。另外，阮一峰老师写过两篇文章，《 Git 工作流程》《持续集成是什么？》，你也可以先行阅读了解。

至此，代码审查和自动测试的问题都解决了。当一个PR代码审查通过，以及CI通过了所有自动化测试，就可以合并到master了，而且我们也可以认为合并到master后的代码也是稳定的。

至于自动部署测试环境，反倒是简单，就是CI这个机器人，在你代码合并到master的时候，再次运行自动化测试代码，测试通过后直接运行自动部署的脚本，把master代码部署到开发环境或测试环境上。

在这里以一个开发任务为例，大致讲解一下应用敏捷开发方法的基本开发流程：

把要开发的Ticket从“To Do”栏移动到“In Progress”栏；
从主干（master）创建一个分支（branch），基于分支去开发功能或修复Bug；
编写实现代码和测试代码（单元测试和集成测试），是不是测试驱动不重要，看个人偏好或团队要求；
持续提交代码更新到分支，直到完成；
创建PR（Pull Request，合并请求），邀请其他人帮忙Review代码，根据Review的结果，可能还需要更新几次；
CI在每一次提交代码到代码库后都会自动运行，运行后主要做这些工作：

– 检查代码格式是不是符合规范；

– 运行单元测试代码；

– 运行集成测试。
最终这些检查都完成后，CI会把执行结果显示在PR上。通常绿色表示通过，红色表示失败；
PR能合并需要满足两个条件：CI变绿+代码Review通过；
PR合并后，CI会自动构建Docker Image，将Image部署到开发环境；
将相应的Ticket从看板上的“In Progress”栏移动到“Done”栏。

正常来讲，你是需要严格遵守开发流程的，但偶尔肯定也有紧急任务，来不及写测试代码，这种情况下，一定要再创建一条Ticket跟踪，以确保后续完成测试代码。

部署上线流程

最早的时候，程序员都是自己管服务器，但是由于这样过于随意，就会导致很多问题出现。

于是后来有专门的运维团队，将开发好的程序，编译好，数据生成脚本写好，然后写成部署文档，交给运维去手动部署。这个过程无比繁琐、无比慎重，通常几周才部署一次，遇上打补丁才隔几天部署。

这些年随着容器化、微服务、DevOps这些技术或概念的兴起，部署已经变得越来越高效，大厂已经开始在部署流程上融合这些理念。

以前是运维人员按照文档部署，现在已经变成了DevOps写自动化部署工具，然后开发人员自己去部署生产环境。

现在大厂的部署也都实现了自动化，但是流程上还是有一些控制。

首先，部署的不再是程序代码，而是Docker的Image，每次代码合并后CI都会自动生成新的Image，测试也是基于Image测试。
部署生产环境之前，先在内部的测试环境充分测试。
部署生产环境前，需要审批确认，有Ticket跟踪。
部署时，先部署一部分，监测正常后再全量部署。
整个过程都有监控报警，出现问题及时回滚。

如果一切顺利的话，整个生产环境的服务部署过程通常几分钟就完成了，这在以前简直是不敢想象的事。

每日站立会议

在敏捷开发中，每日站会是非常有名的。在大厂，但凡实施敏捷开发的小组，上班第一件事，就是一起开一个站会，沟通一下项目的基本情况，这也导致会议室越发紧张起来。

虽然站立会议什么时间开都可以，但是早上无疑是最好的时机，一天工作的开始，开完会全身心去干活。

是不是站着开会其实不重要，重点是要高效沟通反馈。 开会时间控制在半小时以内，半小时内不能完成的应该另外组织会议。

谁来主持站立会议呢？在敏捷的Scrum中，有一个角色叫Scrum Master（敏捷教练、敏捷大师），主要任务就是保证各种敏捷流程的。

所以通常是由Scrum Master主持会议，也可以采用轮班制，每个星期换一名团队成员主持。负责主持会议的人，主要职责是组织会议，一个一个环节开展，控制好会议节奏。

开会都干什么呢？主要有三个话题：

1. 成员轮流发言

每个人轮流介绍一下，昨天干了什么事情，今天计划做什么事情，工作上有没有障碍无法推进。

一个成员的发言可能是这样的：“昨天我实现了用户登录模块的前端输入框，今天打算完成后端API调用，在实现后端的时候需要API组的支持，昨天发现他们文档有问题，不知道该找谁。”

要注意的是，这过程中很容易偏离主题，比如突然有人提了一句：“我们好久没团建了，是不是该出去玩玩了。”很可能大家都很high的讨论起来了，这时候会议主持者要及时打断，记录到“问题停车场”，让下一个人继续，先保证大家能高效完成这一环节。

问题停车场（Parking lot question），把需要进一步讨论的问题暂时放到这里，一会儿再讨论。

通过这样的形式，项目成员可以相互了解任务进展，有困难也可以互相支援，及时发现问题和风险。还有一个重要因素，就是每个人对于自己提出的目标，也会信守承诺，努力完成。

2. 检查最新的Ticket

前面提到所有日常工作都是基于Ticket来开展的，这些Ticket可能是测试报出的Bug，也可能是产品经理提交的需求，也可能是其他。

所以每天例会都需要检查一下新增的Ticket，并且要甄别一下优先级，然后决定是放到当前Sprint，还是放到Backlog（任务清单）。

这个阶段同样要注意不能发散，不要针对Ticket的细节展开过多讨论，有需要讨论的同样可以先收集到“问题停车场”，会议组织者需要做好控制。

3. 停车场问题

在这个环节，大家可以针对之前来不及讨论的问题进行讨论，能在会议时间内解决的问题，就马上解决，不能解决的会后再私下讨论或者再组织会议。

当然，大厂的流程规范还有很多，在这里我仅列出与敏捷相关的主要开发流程。

总结

我们知道，在敏捷开发中有很多概念，像Backlog、持续交付、每日站会等，这些概念最终要变成实践的话，就必须要通过一定的流程规范来保障这些概念的实施。

这就是为什么很多公司写代码要求你写自动化测试代码，为什么要用一些像Jira、禅道这样的项目管理软件来管理任务，为什么要每天开站立会议，为什么要有代码审查。这些都不过是为了保障敏捷的实施。

如果你在实施敏捷开发的项目工作，就可以多去观察平时工作中这些和敏捷有关的流程规范，再结合敏捷开发中的知识点，就能很好的帮助你理解敏捷开发，理解这些流程规范背后的理论依据。

如果你工作中不是用的敏捷开发，也可以参考本文中提到的一些实践，尝试着试用起来。

在下一篇里，我还会以一个具体的项目小组对敏捷的应用为例，继续给你讲讲大厂都在用的那些敏捷方法。

课后思考

你的项目中，有哪些跟敏捷开发相关的实践？你觉得哪些做的好的地方，哪些做的不够好的？或者哪些是你疑惑的地方，都可以留言讨论。另外，你可以再思考一个问题：一个每周一个Sprint的敏捷项目，怎么保证每周都有交付，还能保证产品质量？

感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

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，这样做有什么优缺点？

感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。