当潮水落去：说说我所认知的敏捷开发与用户故事

前言：围观了一周，关于张大神在微信内部所说的关于敏捷开发和KPI的这件小事，今天热度应该有所降低了吧。所谓“当潮水落去，才知道谁裸泳”，不知道刷屏了一周之后张小龙的这篇演讲到底是否会对你们的工作产生一丁点的影响？我认为几乎不会，大多数只当成一次消费，过后也就是过眼烟云，然后再一起等待下一次的演讲稿，再一次高潮。

微信是微信、腾讯是腾讯，张小龙还是那个不爱说话低调却神秘的张小龙，你还是你，该背的KPI你今年还得背，马上就年底了都好自为之吧。

开始，说正事~

一、敏捷开发，其实并不神秘

先推荐两本入门书：《敏捷开发与用户故事》、《敏捷开发一千零一夜》

敏捷开发，其实早在上个世纪90年代就已经开始被应用在软件开发行业。所以，并不是什么新奇的事物，只是在如今在国内的互联网公司中我们少有提及而已。但是，前天看了苏杰在他微信公众号写的，关于他去硅谷交流时所见到的趣事，我们还能看到在硅谷的的互联网团队中，还是有很大一部分的小团队依然喜欢使用敏捷的开发方式。

• 敏捷开发，不是一门技术，而是一套软件开发的方法论、流程。

核心的思想更多的是集中在，以用户的需求、快速迭代、分割项目成多个小项目循序渐进当中。是针对传统的“瀑布流开发方式”中以文档驱动、需要撰写大量的需求文档、缺乏人与人之间的沟通弊端。而提出来的一种开发方法。相比传统的瀑布流开发方式， 敏捷开发更加强调的是人与人之间的沟通，包括团队的沟通、与客户的沟通，而文档则只会撰写必要少量的文档。尤其适合早期的小团队。

• 敏捷开发，同时是一套“开发工具集“

写代码的同学都知道IDE这东西，在没有IDE之前我们可以直接拿个记事本就可以开始敲代码照样可以实现你的hello world。但是集成开发环境（IDE）相比与普通的记事本，其内部集成了更多的开发工具、插件，对于提高写代码的效率有着非常重要的作用。 而敏捷开发我们也可以把它当做一套软件开发的“工具集成”在这套方法中集成了多种的小工具包括了：

用户故事 ：以用户的需求为核心， 站在用户需求的角度

团队站会 ：简洁有效的团队沟通方式，快速解决当前问题

（团队站会）

任务看板 ：将任务分解，写在小便签卡片之上，查看当前正在进行的任务，已完成的任务，未完成的任务。当你把一个未完成的任务完成了，那么久可以将未完成的任务卡片，挪到已完成的区域。形成一个非常明显的进度表。

（任务看板）

二、用户故事，不只是故事

上文中我们了解到，用户故事之作为敏捷开发中的集成工具的组成部分而存在。用户故事（user story），是从用户的角度出发来描述用户渴望和需要的功能，其包括三个重要的元素：

• 角色 ：到底是谁要使用这个功能，这个功能是为谁而设计
• 活动 ：这个功能是怎样的？要达到什么程度
• 商业价值 ：为什么要这个功能，这个功能最后能带来什么有益的商价值，对用户来说有什么意义。 

通常来说一个优秀的用户故事必须包含以上几点，也只有包含了以上三点的才能称之为用户故事。一般我们在描述一个用户故事的时候会按照如下的格式：

作为一个<角色>，我想要<活动>，以便于<商业价值>

举个栗子：作为一名<作者>，我想要<一个可以快速排版的在线编辑器>，以便于<我在投稿子的时候可以快速的排版>。

再举个栗子：作为一名<作者>,我想要<在编辑器上传图片的时候可以看到当前上传的进度>，以便于<缓解我因为上传失败而感到焦虑>。（小编你看着办吧~）

小TIPS：在描述一个用户故事的时候，千万不要使用非常技术官方的专业术语、文字来表达。

三、如何划分用户故事

在实际的开发工作中，一个功能模块的实现会有着大大小小的用户故事来组成。那么在实际的敏捷开发中，我们该按照什么样的方式来划分用户故事？

1.一个优秀的用户故事该有的样子

一个优秀的用户故事，除了要严格遵守以上提到的描述格式之外，最重要的是在划分用户故事和描述的时候还要考虑到如下几点。

• 保证你的每一个用户故事尽量的保持独立性，不要过多耦合；
• 保证你的每一个用户故事，最终是可以通过测试来验收的；
• 在描述用户故事时，要保证其文字内容的简洁、简短，有利于阅读提高效率。
• 要保证用户故事，可以让开发团队进行开发周期的评估，只有开发团队可以评估出某个用户故事的开发周期，才有利于项目推进。
• 要保证你的用户故事是来自用户的需求，要保证这个用户故事最后实现是可以带来商业价值的。这也是最重要的。

2.如何划分系统庞大的用户故事

在敏捷开发中，每一个功能就是一个用户故事或者多个用户故事的集成。那么庞大的系统功能，就是由成百上千的用户故事所组成，那么在进行需求整理时，该如何把这些用户故事划分，整理归集就是个必要的问题。

因为不同复杂的系统在划分时，标准是不一样的，所以下文是我按照之前个人经历的项目中的划分原则来说明的。并不一定全对也不一定适合所有的项目。 

• 按照功能的优先级，划分用户故事

这个和我们在写需求列表的时候是相似的，优先把用户当前的核心需求，基本需求按照优先级列出来。之后，按照不同粒度，将用户故事细分划。最后通过优先级进行归类，将权限最高的归到一起，并优先开发。

• 按照使用的角色、划分用户故事

用户故事的核心就是角色，谁在使用这个功能？所以在划分系统用户故事时，我们可以按照使用角色，划分出来粒度较大的用户故事。然后在按照角色再进行二级划分，得到粒度较小的用户故事。

举个栗子：之前我负责过网上购买车险项目，按照前后台分为前台后台，按照使用角色划分前台是购买车险的用户，后台是系统的运营人员。首先按照角色，把前后台的用户故事划分，成大粒度的用户故事，然后在针对各个角色在进行划分。  

• 按照功能模块，划分用户故事 拿后台功能中我们最常见的的增、删、改、查来举例子，增加一个数据，删除一个数据就是两种不同的操作。所以我们在划分用户故事的时候可以按照不同的功能模块，操作来划分。

3.区分一个误区：用户故事（user story）与用例（user case）

当初首次接触用户故事的时候，个人也是掉进过这个深坑几次，今天在这稍作总结。用户故事和用例往往会被我们搞混了。

用例是在UML建模中一个重要的概念，它是用来描述一组动作系列的抽象描述。

 说人话就是：用户故事就是我对用户需求的一个具体化，用例则是对于用户故事的具体化。有可能一个用户故事会对应这多个用例。用例详细描述着一个功能的所有操作步骤，并且给出所有异常路径和提示。

下面这个用例是我按照上文中提到的购买车险这个用户故事，所写的其中一个用例。你可以看到用户故事只是告诉了我们用户期望的功能是什么，但是用例却是清晰的告诉开发人员，这个用户故事具体的实现需涉及到那些方面，具体到某一个控件，某一个边界值的规则。

四、最后，再说两句 

敏捷开发这东西，原本就不是什么新鲜事也不是什么特别的技术，只不过是因为是张小龙说出来了，所以在这个周末刷屏了。敏捷技术对于软件开发来说确实是个好的方法论，对于小团队快速完成产品，快速上线抢占市场也存在着一定的作用。

但如前言说，微信是微信，张小龙是张小龙，你还你该背的锅还得背。微信我没待过，但是敏捷方法我经历过，也许它适合微信但不适合我的团队，也可能不适合你们的团队。所以，适合团队的方法论，和工作流程才是最好的方法。

不同的团队规模，不同的leader风格都会有不同的方法论，切忌生搬硬套。看了大神的演讲稿，更多的感觉是对于团队扩张之后运行效率的不满，期望可以如当初小团队的敏捷运行模式。但是说句实话，微信团队已经达到1500多人，敏捷说起来容易但执行起来估计大神自己心里也犯困。

最后，向各位求教个问题，你们在需求确认这个环节是怎么落实的？最近我们都是走邮件，搞得什么小需求偏偏面对面就已经确定了还要坚持发邮件确认。

本文系作者@豆笙 （微信号：dousheng95），部分图片来自百度。