敏捷开发眼下已成为互联网公司的首选方案，为应对市场的高速变化，我们公司也在大力推广敏捷，近期在读《用户故事与敏捷方法》一书，我想边读边做一些分享，传播知识的同一时候加强记忆。
1. 基于用户建模是一个比較好的起点。
产品团队能够採用头脑风暴等形式，挖掘出产品实际存在或者潜在的用户或客户，给他们一些角色。
多种角色出现重叠时，再将重叠部分成立一个独立角色。
比方“运维角色”和“部署角色”都须要做一件事情：做数据改动，那么我们就考虑一个“数据改动角色”专门做这个事情。然后“运维角色”和“部署角色”就都不包括这个职能了。
再然后呢，给每一个角色找一个生动的虚拟人物来取代，让团队熟悉这个人，就像身边的一个朋友一样了解。
样例：“借款人角色”。代表人物叫“张穷”。30岁，小餐馆经营者。这两年生意做得不错。想扩大店面。可是手头吃紧。正绞尽脑汁想找一笔贷款。
用户建模时，能够考虑一些特殊的人群，他们有助于发现一些仔细的需求。比方老太太须要屏幕字体够大。
2. 寻找用户。
最理想的方式是可以找到软件真实的使用者。了解他们的需求。
条件不成熟的情况下就仅仅有寻找用户代理。不同的人群都能够担任用户代理，可是要注意不同的用户代理看待问题大多是从个人须要出发的，要摸清他们的一些小脾气。
实际用户的经理：他们对于产品细节的关注度可能不高，由于他非常可能平时不做实际操作，对于群众疾苦了解得不够；他们可能会过分关注一些管理功能，比方任务调度、查看每一个手下如今的任务完毕情况等。而这些功能非常可能不是产品核心的东西。
开发经理：他们通常缺少对软件的实际体验，其内心驱动因素非常可能是业务压力或者成就感，这种动机非常easy背离产品核心业务价值。
销售人员：他们的核心价值观一般是尽量多的订单，为了不丢单，他们总会承诺“没问题”，各种稀奇古怪的东西都想丢进产品里面，使得产品没有规划、随遇而安。
领域专家：他们通常可以在产品设计上提供非常大的帮助。但要小心他们弄出一个太“高大上”的东西，不接地气。让小白的用户认为软件极其难用。
系统分析师：他们是非常有想法的文艺青年，既懂技术又懂业务。是非常好的用户代理。但要小心他们的空想症，他们有可能花上两天去精心设计一个业务流程。但根本没有做过不论什么调研。最坏的结果是最后不得不推翻一个精心雕琢的楼阁，浪费、肉疼。。
3. 分割故事。
传统的分割方式大多是按实现层面或者技术栈来分割，比方一个功能别分割为前台、后台、数据库几个任务。或者依照技术栈分割为java相关、C#相关、移动端几个任务。
这种分割方式最大的问题是：单个任务不能产生业务价值、相互依赖导致无法高速交付并得到反馈。
推荐做纵向的分割。每一个故事尽量是一个功能闭包，一个故事完毕意味着一个功能可交付。
以京东提交订单功能为例，其业务流程为：基于预先选好的商品信息，先选择支付方式、再选择配送方式，然后提交保存。
传统的分割方式可能为：
T1: 前台交互实现（选择支付方式、配送方式），形成可提交的订单数据后提交给servlet
T2:后台接收订单数据，保存到数据库，给成功提示。
考虑换一种分割方式：
S1：基于预先选好的商品信息，使用默认支付方式和配送方式。提交订单并保存。
S2：支持用户选择支付方式并保存订单。
S3：支持用户选择配送方式并保存订单。
我们不要写哪种大而全的故事，一个故事仅仅为一种客户编写，仅仅满足其一个小小的业务价值。
编写故事时尽量避免涉及界面的描写叙述。这会诱导开发者依照某人脑海中印象来实现功能，这实际是把设计意图强加到故事之中。更致命的是会隐含的扩大故事范围。
比方这样一个故事：
在首页的右上方。用户能够看到“注冊”button并点击它，之后弹出一个对话框，用户录入注冊信息后，点击提交button，若注冊成功就回到首页，并发送激活邮件。
它的问题：
涉及太多的界面信息，它阻止了开发者或者分析师跟客户做进一步沟通的欲望，或许这种交互设计是蹩脚的呢？
考虑写成这样或许更好：
在首页醒目位置能够进行用户注冊。注冊成功须要发送激活邮件。注冊失败须要失败提醒。
下期分享：故事估算和制定计划，谢谢围观~~