用户故事驱动开发系列之二：用户故事的妙处

          敏用户故事驱动开发系列之二：用户故事的妙处

 

本文是用户故事驱动开发系列的第二篇，在于探讨用户故事的妙处。

 

传统IEEE 830需求模式

        我们还在上大学时，那时课本上是没有所谓“用户故事”，所有的需求都是由电气与电子工程师协会定义的如何编写软件需求规格的指南（即大名鼎鼎的IEEE 1998，标准的830文档），IEEE的建议覆盖了诸如如何整理需求规格文档、角色原型和良好的需求特征等等，其中最让人印象深刻的就是使用句法“系统应该……”，比如针对Nearme市场：

2.1 Nearme网站应该提供丰富的应用程序供用户下载。

  2.1.1 Nearme网站应该可以提供用户注册；

  2.1.2 Nearme网站应该显示丰富的应用软件；

  2.1.3 Nearme网站应该显示下载用户的评价；

    2.1.3.1 ……

……

        瞧瞧，我们倘若都按照这种方式进行需求的记录，会不会感觉非常乏味、容易出错呢？而且费时费力，假如这个Nearme网站比较复杂，需要记录长达500页这样的需求文档，不知道你会不会崩溃？

 

用户故事的妙处

         在上篇博文中，我们有提到用户故事的“3C原则”和“INVEST原则”，那么，上面Nearme网站的那个需求更可能描述成以下这个用户故事：

2.1 作为智能手机用户，我希望Nearme市场提供丰富的应用程序下载，以便满足我个性化的需求；

  2.1.1 作为使用智能手机的在校学生，我希望Nearme市场提供实用的学习软件，以便满足我随时随地学习的愿望；

  2.1.2 作为经常出差的智能手机用户，我希望Nearme市场提供出行工具软件，以便我在出差过程中称心如意；

……

      大家有没有感觉到用户故事和IEEE标准830文档的区别？那就是前者有用户角色，有功能，有价值，而后者仅仅只有生硬的功能。

        前段时间在公司进行敏捷教练的培训，当时在讨论到用户故事的时候，笔者给出的用户故事总结是“抛弃冗余的文档，通过协作来开发有趣的、对用户真正有价值的需求！”当时特别强调了“有趣儿”，有部分SWE是不太理解的，都说“我们的开发工作这么枯燥和苦逼，哪来的趣儿呢？”

 

       笔者的回答是我们或许是受传统开发模式的影响很深，过于关注功能定义，反而对功能实现后的“价值”究竟是什么，究竟能够用户带来什么好处忽略了。用户故事的优势就是把呆板的需求转换成“价值”，通过“价值流”在敏捷开发的统一团队中传递，从而大家都认同开发这个功能的价值所在，从而使开发过程变得有趣儿。

 

让笔者欣慰的是，大多数SWE、QT都迫切希望故事编写的前端人员，比如产品经理，用户体验工程师提供用户故事的真正价值，因为他们不愿做“编写代码的机器，而是一个能够认同故事价值、传递价值的使者”。

 

小结

         因此，用户故事的妙处在于真正关注软件对用户带来的价值，这样不管是开发团队成员，还是最终的用户，人人都可以非常容易的理解用户故事，可以基于这个故事进行讨论和交流，非常有利于最终用户参与到故事的开发中来，进而提升软件的价值。

        当然，用户故事是独立的，颗粒度适中，适合进行迭代化的开发，同时也鼓励在敏捷开发的初始阶段延迟故事实现的细节，专注于故事实现的价值，并且鼓励提升用户价值的变化，这些妙处在后面的讨论中逐步展开。