用户故事是敏捷开发的基础

个人认为，敏捷开发、迭代开发，是软件时代发展的一个必然产物。传统的瀑布模式，已经不能适应当下的需求模式。传统模式下开发出来的软件，并不要求易用性至上，或者由理论大牛根据、市场反馈、人类行为学、心理需求学等等理论，制定软件需求。而面对市场情况不清晰、用户至上、反馈太多的情况，瀑布模式就显得笨重而迟缓。所以，敏捷开发就产生了。
敏捷开发产生的原因：
        1.硬件升级后，编译速度变快，跨平台编程也成为现实；
        2.面向对象编程以及后续的软件发展，使得编写软件相对更加容易；
        3.网络的发展，使得发布、升级软件变得容易，且几乎没有成本；
        4.市场的多变性造成用户的多变性，传统的软件开发方法不能及时跟上这种多变性，且在竞争激烈的环境下，更快的发布软件，更快的满足用户的需求，成为首要问题。
        
敏捷开发的基础是用户故事，所以用户故事一定是重点中的重点。而用户与开发人员都不一定确定用户故事是什么，所以制定用户故事一定是一个讨论过程，而且随着软件迭代，用户故事是发展的，满足用户故事也是发展的。

敏捷开发的原则是，要让迭代转起来，不停的发布，不停的满足用户故事。

【书摘】
一个优秀的故事应该具备以下6个特点：
        1、独立的。对于相互依赖的故事：1）合并为一个故事；2）考虑其它的划分方法；3）在故事卡上标明依赖关系。
        2、可讨论的。用户故事应该只包含一两句话，用来提醒开发人员和客户沟通，并且包含一些注释，用于标明在沟通中亟待解决的问题。
        3、对用户或客户有价值的。为了保证每个故事对用户或客户都是有价值的，最好由客户来编写故事。
        4、可估计的。如果缺少领域知识导致不可估计，需要和客户沟通，如果缺少专业知识，则可以把故事拆分出一个调研故事，最好将调研故事和原始故事放在不同的迭代中。
        5、小的。需要注意对大的故事需要拆分，而太小的故事则需要合并。
        6、可测试的。尽量采用自动化测试。

DSDM包括一个排列优先级的方法，称之为莫斯科（MoSCoW）规则
        必须有（Must have）：系统的基本功能。
        应该有（Should have）：很重要但短期内有替代解决方法的功能，如果项目没有时间约束，通常认为应该有的功能是强制性的。
        可以有（Could have）：如果没时间就可以在发布中不予考虑的功能。
        这次不会有（Won't have this time）：客户期望拥有但同时承认需要在后续发布中实现的功能。
用户故事不良症兆一览
        1.故事太小：不容易估算cost，且容易分裂故事之间的有机联合。
        2.故事相互依赖：很难做迭代计划。只能把相互依赖的故事放入同一期迭代计划。
        3.镀金：开发人员实现了计划外的功能，但是在验收测试中却没有相应的测试用例，容易埋下质量隐患。
        4.细节太多：在实现故事之前花太多功夫去收集整理故事细节。也可能花了太多时间写故事，而不是讨论故事。只有讨论才能真正了解用户真实的故事。
        5.过早考虑用户界面细节：界面应该是在后期才考虑的问题，用户的故事可能随时在变。
        6.想得太远：想的太多或者太远，都是在预估用户的需求，而在敏捷开发中，用户的需求是时刻变化的。
        7.故事划分太过频繁：在迭代计划中，为了确保迭代工作量合适，频繁划分用户故事。
        8.客户很难为故事安排优先级：可能需要重新讨论用户故事。