EPIC和Story你用得来吗?

史诗故事(Epic)和用户故事(User Story)是随着敏捷开发理念而来的两个新概念、新“物种”。它们是站在用户的立场,对产品功能的实现效果所做的描述

既然是新的“物种”,我们就不应该用传统的理解去看待它。小说和工具书是两类完全不一样的书籍。使用和理解它们的场景是不一样的。

我们以往理解的需求,是可以用功能点(Function Point)做准确评估的功能项(Feature),以文档形式存在并签署的需求说明书(Requirement Specification)。作为说明书,我们会期待它有明晰的章节,待需要时可以准确无误地定位需求,并以此作为标准的参考。换句话说,我们希望在产品还未做出来之前,先出一本使用说明书。

先不提架构师团队需要什么样的经验和想象力去完成一份需求说明书,单说任何一个利益干系人对产品提些意见,这文档改动的代价就不小。

而用户故事呢,自然是有对比的啦。话不多说,这就开始举(吹)例(捧)用户故事。

之所以叫做“故事(Story)”,因为它是用来讲的。而讲它的人是用户(User)

讲故事更容易将人带到使用场景里去。那故事可以扯淡吗?当然,天马行空,漫无边际。但就一点,一定是随心而动,由感而发的。

作为一个老师;我需要一个可以发布教学内容和心得的网站;从而可以有更多的人听到、看到我的课

用户是一名老师。注意!不是那些可能会使用网页的学生用户哦。“能有更多的人听到、看到我的课”,是这名老师美好的愿望。而这个故事的实现是为这名老师服务的。或许这个网站最终会实现很多老师的愿望,但就目前来看,一切都是不可知的。

用户老师描述了一个故事,“我需要一个可以发布教学内容和心得的网站”,仅这些内容是不够组成一个完整的故事。随意几个问题这位老师就开始倒吸凉气。

  • 教学内容是什么?音频,视频,还是图文?还是都要?
  • 心得和教学内容属于同一类东西吗?不同的话,区别在哪?
  • 内容谁都能看吗?

好了,他或许已经开始意识到,这个故事是史实级别的!在我们还没有准备好着手研究、拆分它之前可以就这么把它作为一个史诗故事(Epic)“凉”着,记录为Epic_A。然而当我们开始考虑实现它时,就需要将史诗故事拆成小故事。

作为一个网站,我需要一个门户页面,这样所有人都可以链接打开我

有了这样一个颗粒度的故事,记录为Story_1。我们可以比较清晰的理解它了,任何人可以从互联网中的任意终端打开一个页面即可。当然在正式启动时,还会澄清一些细节,例如域名,服务器租用预算等。但是这样的一个用户故事,已经是可以清楚的看到头、做估算、并承诺完成的了。

一鼓作气,老师又定义了好几个需要在首次上线时携带的基本实现效果,分别作为Story_2/3/4/5。没多久,Story_1,2,3,4,5实现并上线了。经过几个星期的打理和推送,老师发现网页的人气惨淡,还不如自己在微信朋友圈里发的一条消息有人气。

于是大家坐下再看Epic_A,老师的愿望是“可以有更多的人听到、看到我的课”。哦,原来老师需要更多的听众/观众,那么或许微信小程序可以有效的实现这个目标。

就这样,经历了几个星期的磨练,史实故事Epic_A又开启了新的“序章”。不一样的是,这次的经验值可不是从零开始了:)

故事讲完了,一句话总结

对诺基亚8210的描述会让你得到8210。而对手机要更好用的描述,或许可以让你得到iPhone

 

Leave a Reply

Your email address will not be published. Required fields are marked *