你大概走了假敏捷：《手绘敏捷宝典》在此，还不来收！

欢迎你们前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~

本文由 薄玉桴发表于 云+社区专栏

今天你敏捷了没有？“敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流，往小了说是改进了开发方法，往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。

咱们使用 tapd 写 feature，流转、跟踪任务，言必谈敏捷，然而咱们是否真的走对了敏捷？（注：tapd 是腾讯内部的敏捷项目管理系统） 。

1.朋友，你据说过敏捷么？

2.离开敏捷工具，咱们怎么敏？

3.设计也要介入敏捷流程？

4.敏捷跟文档是对立的？

5.我这有个几百亿的大项目，怎么敏？

6.尽信书，不如无书。

1、朋友，你据说过敏捷么？

程序员说，要有敏捷

从敏捷的滥觞看去，比起方法，这玩意貌似更像一个宗教（笑）。

千禧之初，美国在计算机行业已经走了几十年，瀑布流、螺旋模型、快速迭代...各类各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善，但互联网的加速发展让传统方法显得笨重，难以快速适应变化。有十七个程序员（程序员改变世界）在美国犹他州的一个风景区开了个碰头会，找到了一个团队耦合度高，流程极其灵活的方法，他们把它称为agile program development。

这十七我的如同开宗立派的长老，在会议以后给本身起了个名字“敏捷联盟”，他们不只赋予了新方法名字，还有宣言，甚至纲领。

盐湖城- snowbird（敏捷联盟成立地——雪鸟滑雪场）

中文版的“敏捷宣言”。在创建于2002年3月的 《Manifesto for Agile Software Development》里你能够找到几十种语言的“敏捷宣言”。

另外，长老们还制定了12原则，做为福音传播。

显而易见，敏捷是绝对的结果导向，去文档化，去流程化，高效沟通和合做是究极奥义。

看起来是个很不错的方法，文档不重要了，流程不重要了，你们聚在一块儿说一说就能够了不是吗？太棒了，感受能够从繁重的文书工做中解脱出来了呢。

失之东隅收之桑榆。一处的方便必定意味着另外什么地方以其余方式运行着简化掉的部分。

去文档，敏捷管理者须要维护更为精细的需求池；去流程，口头沟通成为常态，对团队的耦合度要求更高。

胖友，这里有一份教义，你要不要听一下。

初识敏捷，有一些概念须要了解，若是你是老司机，跳过这部分，阿敏。

agile：迅速，敏捷。这是敏捷的理念也是精髓：迅速响应需求，快速反馈结果。agile 的引入像一股活水冲击着老气横秋的瀑布流模型，速度上跑赢几条街。

sprint：字面意思是短跑冲刺，一个开发阶段被认为是一次冲刺，一个个 sprint 首位相连，构成一个项目。

Scrum:指的是英式橄榄球中一股脑争球这一战术或行为。

scrum 即为这样一种方式，你们蜂拥而上，团队是球员，球是产品目标，人员环环相扣，围绕着产品目标进行工做。这里面多少有点“统筹法”的影子，人员深刻协做以达到最优化效果。

Product Backlog:

backlog 即需求池。待办事项列表。

Backlog 里面写什么：

1.待开发任务。

2.任务优先级。

敏捷须要维护一份详尽的需求列表。这份列表经常要求 scrum 持有人（通常是产品经理）对全部待开发事项有深刻了解，而且可以把待开发事项分解成更为细致的任务（或者跟敏捷教练一块儿，后面咱们会再次提到敏捷教练）

story board:

不少领域都有故事板的概念，交互领域里，用故事板表述用户场景、电影领域里故事板用来更具体地描述分镜。在开发领域，故事版是任务流转的可视化窗口，通常有“待开发”“开发中”“待测试”“返工”“待发布”几个区块，全部任务由任务操做者负责流转至于下一个步骤，这样任何一我的项目成员都能看到任务的完成状况。

一个app使用情景故事版

在开发中，故事板展示全部需求的工做流

burn down chart：

燃尽图

一个 sprint 内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，天天进行时间结算，绘制时间燃尽图。项目成员经过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则须要在下一个 sprint 进行调整。

名词听起来都玄乎乎的，很符合开宗立派的气质。这些概念定义了敏捷各个环节的工做，这些流程和节点是敏捷开展的基础和保障。

2、离开敏捷工具，咱们怎么敏？

一个误区：咱们用了敏捷管理工具，就敏捷了

随着敏捷在行业内的不断融入，各类工具产品层出不穷。国外jira、redmine，Axosoft ，国内的leangoo 、禅道，三你们则都有自研的工具，百度的icafe，阿里的aone，我鹅自研tapd。

（数据来源：“2016中国开发者白皮书”）

咱们在 tapd 上建迭代，建需求，研发、测试等着收到需求流转的邮件以后开始干活...任务在测试和研发之间流转，bug 提给研发，研发解决 bug .....咱们宣称：咱们敏捷化了！

咱们习惯于敏捷软件的便利，拉群解决一切，然而却丧失了敏捷的初衷，scrum 的本意。

Jira的名字来自于哥斯拉

假设咱们没有任何项目协同软件，敏捷怎么实施？

设定一个环境，如今没有任何协同工具可用，可是全部人都坐在一块儿。有人站起来讲，既然这样，咱们不如敏捷吧！

敏捷工具消失了

敏捷路径里必须有一个项目持有者，制定规划并把握项目走向。这位产品汪我看你骨骼惊奇，你就担负起这个责任吧。

另外还有一个关键人物 SM（别想歪）。SM 全称 scrum master，中文称敏捷教练。通常说来，SM 须要由对技术开发以及当前项目明晰的技术经理担任。

虽然缺乏线上工具，但至少要准备一些简单材料：一卷双面胶+白纸或一沓便利贴；笔，一面平坦的墙或一块黑板。

若是还有电脑可用，excel 或者 word，甚至写字板均可以，没有电脑那就白纸好了，总之你得找个地方写下你的需求池（backlog）

需求池示例(任务名称、平台、详细描述、优先级按照P0-PX逐渐递减)

肯定一个 sprint 周期的天然天。能够用月/旬/周等时间概念做为周期，咱们选择一周（五个工做日）做为一个 sprint 周期。

按照优先级，从需求池中拉出你认为应该加入大家一贫如洗的第一个 sprint 里面去的需求，别太贪心，大概以为差很少一周左右的开发量就够了。拉上SM桑单独开一次小会。

固然不是让你俩傻站着，你俩要开会

大家一块儿通览需求，SM 桑根据经验对需求先行分解一遍，好比某需求在开发层面须要分解为 ABC 三部分，这三部分就造成三个开发任务。

分解完成后，你获得了一个比较详细的待开发列表。

正式开始一个 sprint 开始以前，产品、研发、测试须要一同开一次 scrum 会议，共同讨论本次 sprint 的功能点。

会上讨论什么：

1.需求讨论或技术讨论；

2.成员预估需求所需开发时间；

3.需求是否match人力时间，需求排入sprint；

4.交流一下感情。

每一个任务的预估时间在最后由敏捷教练综合断定

scrum 会后你的工做：

1.整理这个 sprint 内的需求列表；

2.整理每一个需求的预期开发时间；

3.撰写故事版上的小纸条；

4.把小纸条贴到故事版上；

5.制做一个燃尽图。

一个改良版的小纸条，写明开发者、任务描述、预估时间和每日燃尽时间

故事版布局以下：

一个标准的故事版：最开始全部的小纸条都在“待开发”一栏

到此为止，你能够开始 run 起一个 sprint 。

觉得这就完事了？天真。

接下来你必须来参加每日举行的项目短会。这个环节在 agile 中很是关键，是 agile 的平常修炼。为了缩减会议时间，咱们通常站着开——因此也叫“站会”，早上上班后或晚上下班前，抽出十到十五分钟时间，完成它。

每日站会

站会都有什么人参加：

1.你（项目持有者）

2.SM

3.其余 scrum 成员

站会干什么：

1.昨天你们分别作了什么事，遇到了什么问题，如何解决或寻求解决方案；

2.昨天任务的完成状态，剩余多少时间，是否须要进行时间修正（增长时间或减小时间），把已完成的任务流转到下一环节（把纸条从一个item内撕下，贴到下一个item里去）；

任务进行中，小纸条的示例

3.功能测试后是否有返工；

4.交流一下感情。

站会以后你的工做：

绘制燃尽图。

一个燃尽图的示例：正常的 sprint 的任务时间是随着 sprint 的进程逐渐减小的

周而复始，完成了一个 sprint 后，大家开了第二次 scrum 会。这时议题多了一项:复盘上一个 sprint。

任务未能燃尽；研发返工过多；测试需求淤积.....

针对问题讨论解决方案，根据实际状况进行下一个 sprint 的任务安排。

自此，咱们在没有任何敏捷工具的帮助下，开始了敏捷的旅程。

提及来agile developing 原本就是排斥文档的做业方式，为一个小轻快的方法制做一套严谨庞大的工具，基本也算违背了元老们的初衷了吧，科科。

3、设计师在敏捷中如何介入？

咱们正在使用或者听过的一些流程方法——不单敏捷，瀑布流，迭代式，结对开发，精益开发....彷佛都不关设计师什么事。既然开发团队抱团敏捷了，设计，这个在产品流程中必不可少而工做内容相对独立的角色，要怎么介入敏捷呢？

一种思路是，设计拥有本身的敏捷流程。设计师做为一个 scrum 存在，以从上游获取的需求进行 sprint 。

另外一种思路，是把设计和测试彻底归入到团队中来，一块儿进行 scrum 的合做。

这样的话，UI工做至少要比开发工做前移至少半个 sprint 。

有请产品经理（项目持有者）出场。

很好，咱们有了一个设计师

项目持有者将需求分为“ UI 支持”和“非 UI 支持”两类。咱们将小纸条扩展一下。

多出来 UI 前置部分的小纸条

U I设计师参与到 scrum 会中。对于须要 UI 支持的需求，设计师给出一个 UI 制做的时间预估。项目持有者将这部分时间加到扩展小纸条上去。在一个 sprint 中，设计师的工做跟研发的工做分别进行。

当设计师将某一需求完成时，将小纸条的 UI 部分撕下，汇入到“”待开发”中去。

一个已经完成了 UI 设计的小纸条示例

4、敏捷不须要文档吗？

一切为快服务的敏捷特别适合初创团队使用。它能把团队人员紧密结合在一块儿，高效而有序地输出产能。而常规高效的版本输出每每是初创团队高速发展的第一要务。

敏捷了一段时间以后，产品进入正轨，项目拿到拨款，公司拿到投资，大家要扩大团队规模，新入职的同事想了解下产品和技术细节，你告诉TA：

你要不翻下 backlog 看看？这个实现你要不看一下代码？这个字段我也不记得有没有了....你抓包看下？

新同事一脸懵逼，难道我们没有文档吗？你自豪地指出：

“咱们是敏捷团队。”

十几我的八九条枪的阶段以后，产品趋于稳定，团队逐步扩大。不管从内部协调仍是外部沟通上对产品流程的正规化和文档化要求与日俱增。

从短时间收益上看，文档对于敏捷开发是非必须品，而且颇有可能会拖慢进度。在一个 sprint 中，口头沟通显然效率更高，每一个人都有精确到工时的任务，没人有等待文档更新的时间。强调文档就等于放弃灵活性。

从长期和宏观上看，文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本，同时下降错误的发生几率。对于一个将要长期实施敏捷的 团队来说，文档让后续的工做效率更高。

一个以讹传讹的过程

这样一个功在当代利在千秋的好事，固然要作。那么——

谁来维护文档，怎么维护？

咱们挑选几个重要的文档：产品文档、概要设计、接口文档

产品文档：很差意思内个产品经理你过来下。虽然你要维护 backlog 、跟 SM 分解需求、开 scrum 会、写小纸条、开站会、画燃尽图、还有什么外部沟通啊，写 PPT 啊，绞尽脑汁想规划啊......你还得认真把这个文档维护好。

对又是你

产品文档包括：

1.需求；

2.加入日期；

3.开发版本；

4.呈现和详细方案

在非敏捷开发流程中，文档在评审会后完善并更新，造成一个给研发参考的实现目标。在敏捷中，需求自己在 sprint 周期内不断完善，你能够在一个 sprint 以后将文档补全。

概要设计：敏捷的常规迭代中，概要设计不是一个必须的文档。但全新项目、重构以及重大新功能则必须输出概要设计文档。研发 leader 义不容辞，这个落你身上了。

接口文档：必要且重要。包括接口说明、字段定义、字段类型、值定义、数据上报、错误码等。通常来讲约定以后由接口开发者更新文档，若是大家没有云端存储的能力，至少我们人手一份，按期更新。

长久来看，文档是提升效率的一大利器

虽然《宣言》中明确地放低了文档的地位（“工做的软件大于详尽的文档”），敏捷强调互动和变化，以及对变化的及时响应。诚然文档偏偏作不到如此灵活。但敏捷真的彻底排斥文档吗？

文档的时效性和灵活性远低于口头沟通，但却有它实在的好处。

1.空间上，文档传播范围更广。规范化和常规化的内容造成文档能够大大减小沟通成本。尤为在多个系统协做的状况下，跨 scrum 、跨团队甚至跨部门的沟通时有发生，文档的重要性和便捷性不言而喻。

2.时间上，文档流传性更好。团队不是一成不变的，有人离开有人加入。更新换代中，新人快速了解系统，老兵传承研发理念；在更大的时间跨度上，团队可能成为忒修斯之船，文档的存在就是对产品历程的完整追溯，你将不用他人帮助就能够了解到产品的大部分面貌甚至全貌。

5、大项目怎么引入敏捷？

看起来敏捷方法特别适合产品常规迭代。有一种可能性是，你的产品须要插入一个巨无霸模块，与其说是模块倒不如说它几乎能够成为一个产品了。你想了想，这么大个项目怎么说产品、设计、研发、测试全情投入也得个一两个月。

还能走敏捷吗？

注意你的项目时间。有 deadline 的 scrum 是带着镣铐跳迪斯科，时间节点关乎 sprint 的大小。

大项目敏捷以前，先得不敏捷几步。

可能会发生一到屡次需求讨论会。

团队必须不厌其烦地理解需求或修正产品经理“天真的幻想”，产品经理使用不断完善的原型同团队进（tao）行( jia )沟( huan )通( jia )。在最后的产品评审以前，至少敲定产品框架和大部分细节。此次评审邀请项目成员和全部协同团队，除了敲定的产品功能，技术上须要获得一些初步结论（好比“能不能作”。事实上，产品经理应该在产品规划阶段就知会协同团队将要作什么）。接下来进行概要设计（新产品、重构、重大新功能必须进行概要设计）。技术评审邀请除设计之外的项目成员和协同团队参会。

大项目敏捷中：

1.将 deadline 以前的时间分解为多个 sprint 。（deadline 以前必须留出必定“出血时间”用以解决时间预估不足的任务、返工任务以及 bug )

2.将全部需求分解成任务，开一次全局 scrum 会。预估时间以后，分散任务到各个 sprint 中。在时间较紧的状况下，sprint 的容量就要相应增长。

一个须要加班的 sprint

3.进入敏捷流程，常规 scrum 会、站会，燃尽图，故事版。未完成任务在 scrum 会上从新预估时间，滚入新 sprint 内，以此类推（按时完成 sprint 内的任务是目标。实在不行咱们还有“出血时间”呢）

4.别忘了文档。

虽然被推崇备至，但敏捷并非完美的开发方法。敏捷的最大的优点是灵活，而形成敏捷问题的根源也正是灵活。

文末再总结本文重点：

1.敏捷是一种流程、方法、理念，甚至信仰。

2 用了敏捷管理软件不必定就是敏捷。敏捷的初衷是团队成员可以更加紧密地配合完成工做，线上的的流转若是削弱了这种配合性，反倒背离了敏捷的本意。实际上只要有白板纸张和笔，你的团队就能开始敏捷。

4.咱们敏捷了，不是不要文档了。在外部交流多、世代跨度长的状况下，文档的必要性显而易见。长期的面对面沟通最终会致使低效，这也是敏捷缺陷的根源。

5.设计师能够彻底介入到敏捷流程中，只须要作一些细心的安排。

6.大项目开发中能够走敏捷，具体问题具体分析，须要根据项目特色制定敏捷计划。

（文章全部插图为笔者手绘，版权全部）

问答
Scrum和敏捷开发有什么区别？
相关阅读
胡说八道谈敏捷
敏捷开发--scrum
破解敏捷的密码
【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识

此文已由做者受权腾讯云+社区发布，更多原文请点击

搜索关注公众号「云加社区」，第一时间获取技术干货，关注后回复1024 送你一份技术课程大礼包！

海量技术实践经验，尽在云加社区！