0.最通俗的解释类比

如果去饭店吃饭，点了10个菜，经过一个多小时，服务员才一次性把做完的10个菜全部端上来，这就等同于传统的开发模式，而大部分的餐厅显然不会这样，更常见的是做完一道菜就先端上了一道菜（以顾客需求为核心），这就相当于敏捷开发。

1.如何实施？

image.png

如上图所示，在项目启动之前，会由团队的产品负责人（Product owner）按照需求优先级来明确出一份Product Backlog，为项目做出整体排期。

随后在每一个小的迭代周期里，团队会根据计划（Sprint Plan Meeting）确定本周期的Sprint Backlog，再细化成一个个Task，分配给团队成员，进行具体开发工作。每一天，团队成员都会进行Daily meeting，根据情况更新自己的Task状态，整个团队更新Sprint burn down chart。

当这一周期的Sprint backlog全部完成，团队会进行Spring review meeting，也就是评审会议。一切顺利的话，会发布出这一版本的Release，并且进行Sprint回顾会议（Sprint Retrospective Meeting）。

2.相关概念

scrum的几个基本术语：

Sprint：冲刺周期，通俗的讲就是实现一个“小目标”的周期。一般需要2-6周时间。

User Story：用户的外在业务需求。拿银行系统来举例的话，一个Story可以是用户的存款行为，或者是查询余额等等。也就是所谓的小目标本身。

Task：由User Story 拆分成的具体开发任务。

Backlog：需求列表，可以看成是小目标的清单。分为Sprint Backlog和Product Backlog。

Daily meeting：每天的站会，用于监控项目进度。有些公司直接称其为Scrum。

Sprint Review meeting: 冲刺评审会议，让团队成员们演示成果。

Sprint burn down：冲刺燃尽图，说白了就是记录当前周期的需求完成情况。

Rlease：开发周期完成，项目发布新的可用版本。

3.会议

在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：

会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）欢迎所有人参加，但只有"猪"可以发言。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立。（有助于保持会议简短）会议应在固定地点和每天的同一时间举行。在会议上，每个团队成员需要回答三个问题：

你完成了哪些工作？以后你打算做什么？完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）

每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。

Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。

Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法– 承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

4.具体实施

更直接、更容易执行、更适合中国国情的敏捷实现方法;
归结起来，就是三点：

a.管好你的需求；
b.使用统一的工具；
c.可视化！可视化！可视化！

管好你的需求

敏捷开发流程最容易在哪个缓解出问题？

肯定不是开发人员。至今为止，我见过开发人员对敏捷流程有抱怨的，但是，还真没见过敏捷流程毁在开发人员手上的，因为开发人员往往饱受项目管理混乱之苦，而且开发人员头脑比较理性有逻辑，都清楚敏捷流程是能帮助自己的。

我所见过最容易出问题的地方，在于需求管理，把敏捷搞乱的，往往是提需求的一方，在Scrum流程中，叫做PO（Product Owner），从职位上说，往往就是产品经理。相信我，全世界的产品经理都有一个特点——主意改得快，朝三暮四，早上提的需求，晚上一拍脑袋就改了。更要命的是，很多企业在进行敏捷流程培训的时候，没有叫上这些提需求的人，或者叫了他们但是他们不来。

“学习敏捷？你们做开发的搞一搞就好了，我还要开会，就这样。”

“敏捷培训？我就不用去了吧，敏捷不就是随机应变嘛，需求改了你们就快速反应，我们已经敏捷了。”

“你们搞敏捷？好啊，以后改需求就更方便了，呵呵……”

我相信你肯定也听过产品经理说过类似上面的话，这是一个可悲的事实，很多企业的敏捷开发过程只能在开发人员中推广，移到产品经理层面，就容易碰壁。需求是功能的源头，如果需求不能处理好，那就全完了。

所以，第一个关键：管理好你的需求。

怎么管理好需求？

一句话：让他们写下来！

首先我们要明确一点，敏捷并不是没有文档，《敏捷宣言》里说“运行的代码高于完备的文档”（Working software over comprehensive documentation），但是可没说要消灭文档，文档依然是软件工程的重要工具，一定要把需求落实下来，你可以用文字，你可以画图，你可以直接给一个竞品的功能介绍链接，但是不能撂下一句话就要求开发人员开工。

唉，说句可能不大中听的话，人性呐，也就是贱，如果让他说一句话就算是提完了需求，他也不会有多上心，所以需求细节往往也是考虑不周；但是，你要求他费点劲写成文档，而且白纸黑字留他的名，他也怕写烂了丢脸，写的时候考虑问题也会全面一些，最后需求的质量也会提高。

最好的方法，是让需求文档和开发的代码一样，都要有完整的历史记录，能够追溯到何时什么人做了什么修改，这样可以追责到每一次需求变更。

这就引出下一个话题，需要一个统一的工具来管理敏捷流程。

使用统一的工具

敏捷流程其实并不强求使用什么工具，你要是玩得好，用白板和小贴纸也能管理得井井有条，不过，现在我们面临的现实不是没那么专家嘛，毕竟不是谁都像我一样有那个证:-)

最现实的方法，就是使用统一的工具。现在工具选择太多，反而让人无所适从，比如代码控制用github，文档用wiki，然后任务管理又用JIRA，使用的工具多起来之后，就不方便管理了，新人加入进来学习曲线也陡峭，某些成员也会对工具挑三拣四，所以，使用统一工具是最直接最有效的方法，让产品经理和开发人员、测试人员都在一个工具上协同合作，避免了流程不畅，更重要的是，真的让所有人都感觉是在一个团队中工作。

工具选对，事半功倍。

我们以码云（不是那个有钱的那个马云，是“码云”）为例，来介绍一个实现敏捷开发的工具必不可少的功能：

• 任务管理
• 文档管理
• 代码库管理

首先，你需要一个可以管理任务的功能，项目管理的一个主要内容就是分解和分派任务嘛。

在码云中，除了开发者的“任务”，还有两种特殊任务：“需求”和“缺陷”（也就是bug）。这就把把产品经理（负责需求）、测试人员（负责开bug）和开发人员（执行开发任务和fix bug）放在了同一战线，而且，每个任务都有状态标示，产品经理不把需求写清楚并且被确认，开发人员是不会认可开工的，大家要做的事在一个视图中呈现，互相监督互相激励。

image

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">任务标签分类</figcaption>

然后，你还需要文档管理。

我说过，敏捷并不是不要文档，无论是产品经理还是开发人员都需要写文档，我们不是不要文档，我们要的是更加高效的文档管理。都已经2019年了，就不要再拿Word来写文档了！拿Word写的文档，放在自己电脑的文件目录里，拷来拷去，很难实现版本控制，最后追溯哪个功能哪个时候修改的，几乎做不到，所以，你的需求需要和代码一样也要有版本控制。

码云中可以直接编写文档，在任务中可以直接用Markdown格式编辑文档，可以添加图片，可以做必要的格式，非常方便。

也可以增加独立的文档，在任务中可以用链接直接引用文档，这里要说一下，你在文档中输入中文，码云可以自动生成英文URL，比如我输入“怎么才是真的敏捷”，对应文档专属地址中的路径部分自动翻译成how_to_be_really_agile。

image

无论哪一种开发流程，制定发布周期都是必须要做的，在Scrum流程中称为Sprint，每个Sprint都应该有一个明确目标，在Sprint开始之前，就要把实现这个目标的任务定义清楚，然后Sprint开始之后所有成员就向这个目标迈进，在一个Sprint内不要操太多心今后Sprint的事，以为计划赶不上变化，将来的事情谁能预料？排除干扰，把握住当下这个Sprint才是要紧的。

image

在码云中，“里程碑”这个概念可以对应Sprint，也可以对应任何一种其他更大的发布周期，因为怎么称呼不重要，重要的是包含这些元素：

• 什么时候开始？
• 什么时候结束？
• 最终交付的产品代码在哪里？
• 负责人是谁？

image

最后，敏捷实践的产出还是产品代码，所以归根结底还是要落实到代码上。

码云中当然也有代码的管理，提供了完整的git代码库管理功能，每一个PR可以和需求关联。

image

这样，从需求和文档，一直到代码，一个工具可以全部搞定。

团队中每一个成员，只要进入码云，每天要做的什么任务，每周有什么任务，都很清楚，一目了然。

不过，如果工具只是让每个成员只坐在自己的电脑面前对着任务表工作，那也就失去了敏捷的本质，敏捷需要团队成员如果只是盯着自己的一亩三分地，直到出大事才开会解决，那不叫敏捷，敏捷需要随时把握项目的健康状况，这就需要说下一个问题——可视化。

可视化！可视化！可视化！

问：“我们的项目进行得怎么样？”

答：“很好。”

问：“什么叫做很好？”

答：“开发任务进展了40%了。”

问：“40%？为什么才进展了40%就算很好，为什么不是达到80%才算很好？”

答：“因为……我们才开始2天啊。”

问：“那你觉得多少天才能达到80%？”

答：“……”

上面这段对话是想说明，即使是语言大师，也无法用语言精确描述一个项目的进展，因为软件项目的复杂程度，本身就不是三言两语就能讲清楚的。

不过，一图胜千言，无论多复杂的项目，都可以用可视化的方法一眼看清楚状况。敏捷流程中，有两样东西是每天团队都要在一起看的。

• 任务看板
• 燃尽图(Burndown Chart)

任务看板分为几列，最基本要包含“待办的”、“进行中”和“已完成”这几列，如果流程更细可以有“已验收”列，在界面上可以一目了然地看到哪些任务还没开始，哪些任务还在进行中，哪些任务已经搞定了。

image

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">任务看板</figcaption>

严格来说，敏捷流程并没有写“周报”这项活动，写太多报告就不敏捷了，但是，实际中领导还是想要有一个更详尽的周总结，在这个问题上，我们还是要面对现实，不要追求纯粹的敏捷。实际上，码云就有这样非常适应中国国情的功能，把任务看板从“看板模式”切换成“列表模式”，很让变就可以筛选“本周任务”，这周的任务一幕了然，更妙的是，还有“导出”功能，谁要是不想看网页工具，那就导出Excel给他看。有这样的工具辅助，既满足了领导的需求，又节省了开发者的时间，真是爽得不要不要的！

image

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">导出任务列表</figcaption>

不过，要说把脉项目进度，还需要看燃尽图，燃尽图是一个横坐标代表时间的X-Y坐标系，纵坐标代表任务量，图中会有两条线，一条是最理想情况下的任务完成曲线，还有一条是实际任务完成进度的曲线，如果实际曲线低于理想曲线，那就说明工期朝前，如果实际曲线高于理想曲线，就说明工期延后，非常清楚。

image

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">燃尽图</figcaption>

码云中还提供了任务分布饼形图，算是锦上添花，可以更加直观看到当前任务状态的分布。

image

<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">任务分布饼形图</figcaption>

有了这些可视化工具，团队任何一个人在任何一个时间，都可以对当前项目进展有一个直观认识，开放透明，这才是敏捷。

你还害怕解释不清楚项目进度吗？

问：“我们的项目进行得怎么样？”

答：“请看我们的燃尽图。”

完毕。

总结

敏捷口号在业界已经喊了这么多年了，道理该说的差不多大家也都知道了，之所以无法按照敏捷执行，在我看来，就是差工具这一步。

项目管理说到底就是管理任务和人力，不要再纠结在ppt上的敏捷教程了，直接用工具来实施敏捷项目管理，你值得拥有。

工欲善其事必先利其器，希望大家找到最合适自己团队的工具;以上所说的只是参考工具，也可以选择其他工具实施。更重要的是看如何在团队中实施这套开发流程；