也谈敏捷需求 ｜ IDCF

　　前几天和几个小伙伴就敏捷的需求有过一些讨论，大体是分为以下几个方面的疑惑：

　　敏捷的需求到底是分几层合适？Epic是不是User Story？User Story属不属于Scrum？

　　因此我开始就这三个问题仔细考（kao）证（gu）了起来。

　　我们先从第三个问题开始吧

　　Scrum Guide里有说过待办事项，但压根没有提及过用户故事这个说法，幸而记得哪一天，在某群里有位小伙伴发了一个Scrum历史（A Brief History of a Long-Lived Hype by Gunther Verheyen）的文档，我就仔细的用story，user等等关键词找了找，居然没找到！又不信邪，就去Scrum Guide2017版找了下，也没找到！还是不信，就去2020版也找了一下，结果还是一样。

　　那么至少第一个结论是，用户故事并不是Scrum的标配。

　　那如果这样的话，我们过去一直跑着的Scrum难道是一种豪华版！？

　　先不要这么早下结论，我们只找了几个子集，怎么能这么快以点概全呢？

　　所以我就认真地开始看这几篇文章（具体请最底部的参考文档）。

　　本来是一件探寻用户故事根源的事情，突然画风就转了，因此才促成了这篇文章的诞生，请看以下这段话：

　　Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.

　　我们可以知道几件重要的事情：

　　第一，任何人任何时间都可以书写和往产品待办product backlog中加入用户故事，可见用户故事的编写并不是product owner的某种特权，只要你参与讨论大家也认同你的合理见解，你就有权利来撰写一个用户故事。第二，一些用户故事将成为epic，epic再会被拆解成故事，直到对应到单一迭代中。第三，我们至少有了一些眉目，用户故事User Story和Epic之间似乎有一些对等关系，只是大小颗粒度不同。

　　为了结束第三个问题的答案，我去Wiki挖掘了一下历史。

　　史书上是这么记载的：

　　1998年，Alistair Cockburn拜访了克莱斯勒C3项目，提出了“A user story is a promise for a conversation”这一概念。

　　1999年，Kent Beck也就是XP极限编程的创始人之一，在他的planning game（也有叫planning poker）中提到了用户故事的使用。

　　2001年，Ron Jeffries（也是XP的创始人之一，另一位是Ward Cunningham）提出了用户故事的3C法则。

　　2004年，Mike Cohn又在他的著作《User Stories Applied For Agile Software Development.》中为用户故事引入了INVEST原则，然后再挖下去发现，自己又孤陋寡闻了，原来INVEST并非出自Mike Cohn，而是来自于Bill Wake，Bill在的文章"INVEST in Good Stories, and SMART Tasks"中，提到了用户故事的INVEST原则和对于任务的SMART法则。

　　2014年，Jeff Pattern发表了用户故事地图的技术。

　　大家读了半天是不是发现，仍旧没有和Scrum扯上关系呢？

　　事实也的确如此，Scrum了不起的地方并不是定义的多详细，而是定义的多么抽象和简约。

　　因此可以这么认为，用户故事正好是对于Prodcut backlog的一种比较适配的表现形式。（不知道这么解释是不是完全贴切，Scrum CSP/CTC/CST们请指正我）。

　　回到了第二个问题

　　开篇费了这么多口舌只是为了说明用户故事与Scrum的关系与来龙去脉，第二个Epic的问题答案就会相对容易些吧。

　　找了好几篇文章，都有说到一个概念：Epic是一种Large Story的概念。换句话说，在敏捷开发的世界观中，所有需求或许都可以称之为Story。当然除了SAFe将之与组织的经济帐联系在了一起（别的地方也没有明确说过没有联系）。

　　再次探寻User Story的起源，原来在2004年Mike Cohn早在其著作《User Stories Applied For Agile Software Development.》中就有介绍过Epic是large user story的概念。

　　这么回答似乎觉得事情就可以结束了，但是心里总觉得不够踏实，于是乎就又挖掘了一下，Epic既然这么称呼，显然从字面意思来看，就是史诗级别的。

　　Epic本意就是a long narrative poem in elevated style recounting the deeds of a legendary or historical hero the Iliad and the Odyssey are epics。可见Epic就不是一两个小故事可以说明得完整的。比如一部荷马史诗。并且如果没有Epic仅仅留存用户故事的话，那么敏捷需求也是不完整的，因为会缺乏一个Big Picture的概念。

　　因此，我们可以简单地下一个结论，Epic虽然可以认为是一种大颗粒的user story，但是两者并不完全等价。这也是为了回答第三个问题。

　　第三个问题是关于需求层级

　　敏捷培训中总是会提及一个敏捷计划的洋葱图，图中描述了敏捷计划的几个层次和时间的概念。我们也可以试着用我们之前调查的敏捷用户故事的实践来匹配到这些计划活动中去，显然的Daily的是Task，Iteration的是User Story。问题出在Release上，对于Release肯定不是User Story level的内容了，因为Release与Sprint/Iteration的关系就不用细说了。自然的一个Release大多数情况下是包含多个Sprint/Iteration的。如果这么说来，是不是可以认为Release的就是Epic呢？

　　

　　图：图解敏捷计划

　　如果刚才的问题，你回答Yes的话，那么在基于这种假设的世界观面前，敏捷需求应该是分为了Epic-Story的结构的。如果熟悉JIRA的小伙伴们应该不难发现，JIRA最天然的样子的确如此。

　　我们再来问问JIRA怎么认为，去到Atlassian的网站，可以看到对于敏捷需求的解释与我们刚才的假设基本保持一致，可是为什么Epic顶上还有Initiative（中文翻译可以叫作举措）呢？

　　Initiatives在Atlasssian的文章被定义为一组Epics的集合，并且具有同一个目标。Initiatives与Epics横向跨越的又称为Theme主题，主题可见是跨越Initiatives和Epics的。

　　

　　图：Atlasssian中所定义的敏捷需求

　　自此能不能下一个结论：敏捷需求分层应该是

　　Theme-Initiative-Epic-Story呢？显然这又不全对，因为随手在网上可见到Feature这一说法，并且目前在应用Feature这个概念的企业不在少数。

　　Feature这个词倒是非常容易被接受，因为Feature并不是一个敏捷世界才有的词汇，再次考古发现，在IEEE组织定义Feature为A distinguishing characteristic of a software item (e.g., performance, portability, or functionality)。在某些地方也有解释为是用户或者产品经理所认为的最小颗粒度的价值交付物。

　　不过我自己对此倒有一些不同看法。

　　首先Feature如果作为大于Story的颗粒度，用户或者PO所认为的最小价值交付物，从waterfall到agile的整个transitioning阶段，这么定义或许一时半会儿可以被大家所认同，但是一旦到了上线阶段，用户的需求层出不穷，并且变更内容开始逐渐小颗粒，发布频率加快以后，User Story将会越来越替代Feature成为真正的最小价值交付颗粒。

　　其次Feature在JIRA中并不是一个缺省存在，因此即便我们认同Feature的价值并且打算使用的话，立即将会面临的问题就是，我们需要手动的为JIRA中的需求层级配置添加一个节点，使之成为Epic-Feature-Story的结构。在操作复杂度上无形中提升了一个台阶。当然成功这么运用的企业也不在少数。这里个人意见并不表示我们就该放弃使用Feature这个用法。我们仍旧有理由可以使用这个需求层级。

　　SAFe中甚至定义了Feature的格式以及排序优先级方法。那么按照我们一开始考古的经历来看，Scrum没有明确定义我们必须采用User Story作为product backlog的内容，因此只要分类清晰，属于敏捷的最佳实践的，并且只要组织认同这个价值的话，那么如何分层只是一个不同组织的适配问题。

　　剖析到这里，差不多也算是分析完了。简单总结几点：

　　Scrum中没有定义用户故事；Epic与Story不完全等价；用户故事是敏捷需求的最小单位；比Story大的，跨多个迭代的需求可根据组织的定义，划分为：A）Feature特性需求；B）Epic史诗需求；是不是用了Epic-Story的就敏捷了，用了Epic-Feature-Story的就不敏捷了，这么下结论还太早，但是我们一定要考虑的是，本身这些结构问题与JIRA甚至其他管理软件的匹配度。

　　内容就介绍到这里，有疑问的欢迎在文末留言。

　　参考文档

　　What is a user story：www.mountaingoatsoftware/agile/user-storiesUser Stories with Examples and Template：www.atlassian/agile/project-management/user-storiesUser Story Wiki： en.wikipedia/wiki/User_storyINVEST in Good Stories, and SMART Tasks：xp123/articles/invest-in-good-stories-and-smart-tasks/INVEST：www.agilealliance/glossary/invest/#q=~(infinite~false~filters~(postType~(~'page~'post~'aabook~'aaeventsession~'aaexperiencereport~'aaglossary~'aaresearchpaper~'aa_video)~tags~(~'invest))~searchTerm~'~sort~false~sortDirection~'asc~page~1)Epic in Agile Dictionary：agiledictionary/309/epic/Difference between epics vs user stories：gbksoft/blog/difference-between-epics-vs-user-stories/