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