0 引子的引子
毫无疑问，中国很多行业的信息化程度都是较低的，所以“快”更为关键，而不是“完美”。微软的成功便是一个很好的例子。
欲速则不达，补丁落补丁的瀑布过程，追求完美过程缓慢的统一过程（RUP是UP的一个子集）都不能满足“快”。
怎么快呢？敏捷开发方法敢说“敏捷”。自然带有“有效”的含义。
敏捷开发方法不是XP，XP是敏捷开发的一部分。这个是马和白马的关系。敏捷开发中还有过程、需求、编程(XP)、数据。
在这里我先简述一下敏捷需求中的“用户故事”。
1 引子
敏捷需求开发首先是一个沟通的游戏。沟通的结果是认可驱动开发 （Acceptance Driven Development）.
对于需求来说过最关注“隐藏在需求背后的是什么”
可能大家会经常有这样的经验，客户说，我要这个功能，我想要怎么怎么样。这时候要特别注意，他说的这些东西并不是（或不一定是）真正的需求。业务分析师需要详细的问客户为什么（这么想要这个），挖掘出他真正的目标（商业价值）。
为什么会这样呢？
客户往往有一个心里假设，认为需求调研人员了解他们的现况或是业务，所以他们不交代背景，从半途说起。
客户基于现有软件，或是使用过的软件思维提出“绕道”的需求，而不是想要解决的原始问题。
客户不一定是对的——任何人都有“思维误差”的时候。
沟通或分析时需考虑：
我们到底是否真的需要这个需求？或者说这个需求很重要么?（必要性）
有没有更好的解决方案？（实践经验）
有没有简单并且低廉的方式？（开发成本）
换一种易于实现的形式是不是也能达到这样的需求？（复杂度）
这个需求有多少地方涉及到以前的软件变更？（风险）
2 ？用户故事
搞清楚这些，就可以写出用户故事（Use story）。用户故事的书写遵循一定的原则，一般包括三部分："作为（系统的一个涉众），我想要（做一件事），从而（达到一个商业价值）".在书写的时候格式上比较随意，可以在故事卡背面写上注释或疑问，甚至画上界面原形图。
举一个最简单的用户故事例子，“作为一个普通用户，我希望能够用用户名和密码登录，以便我能使用系统”。其中，用户是系统涉众，登录是他想要做的事情，而他的目标是使用系统。——如果能够系统能够提供其他的身份鉴别诸如指纹、视网膜识别，用户还愿意填写2-3个文本框，再点击一个按钮，不留神还会“用户名或密码错误，登录失败请重试”？
上述用户登录这个功能的实现是简单并且低廉的。
3 $ 用户故事
任何提前做好的东西都会导致浪费，敏捷过程提倡足够就好，避免浪费。（yagni的反对“预想开发”）
用户故事是可见的商业价值，而不是功能描述。
每个用户故事的粒度和开发工作量都相差不多，这和用例有很大的区别。
用户故事是小粒度的，可测试的，可见的，并且是有价值的，——还有可以沟通讨论的。
（这些小粒度是用需求规格组织的）
——这个，1.5小时，基本写完了，删除60%的废话后，然后睡觉。 |