也談敏捷需求 | IDCF

前幾天和幾個小伙伴就敏捷的需求有過一些討論，大體是分為以下幾個方面的疑惑：

• 敏捷的需求到底是分幾層合適？
• Epic是不是User Story？
• User Story屬不屬于Scrum？

因此我開始就這三個問題仔細(xì)考（kao）證（gu）了起來。

我們先從第三個問題開始吧

Scrum Guide里有說過待辦事項，但壓根沒有提及過用戶故事這個說法，幸而記得哪一天，在某群里有位小伙伴發(fā)了一個Scrum歷史（A Brief History of a Long-Lived Hype by Gunther Verheyen）的文檔，我就仔細(xì)的用story，user等等關(guān)鍵詞找了找，居然沒找到！又不信邪，就去Scrum Guide2017版找了下，也沒找到！還是不信，就去2020版也找了一下，結(jié)果還是一樣。

那么至少第一個結(jié)論是，用戶故事并不是Scrum的標(biāo)配。

那如果這樣的話，我們過去一直跑著的Scrum難道是一種豪華版！？

先不要這么早下結(jié)論，我們只找了幾個子集，怎么能這么快以點概全呢？

所以我就認(rèn)真地開始看這幾篇文章（具體請最底部的參考文檔）。

本來是一件探尋用戶故事根源的事情，突然畫風(fēng)就轉(zhuǎn)了，因此才促成了這篇文章的誕生，請看以下這段話：

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.

我們可以知道幾件重要的事情：

• 第一，任何人任何時間都可以書寫和往產(chǎn)品待辦product backlog中加入用戶故事，可見用戶故事的編寫并不是product owner的某種特權(quán)，只要你參與討論大家也認(rèn)同你的合理見解，你就有權(quán)利來撰寫一個用戶故事。
• 第二，一些用戶故事將成為epic，epic再會被拆解成故事，直到對應(yīng)到單一迭代中。
• 第三，我們至少有了一些眉目，用戶故事User Story和Epic之間似乎有一些對等關(guān)系，只是大小顆粒度不同。

為了結(jié)束第三個問題的答案，我去Wiki挖掘了一下歷史。

史書上是這么記載的：

1998年，Alistair Cockburn拜訪了克萊斯勒C3項目，提出了“A user story is a promise for a conversation”這一概念。

1999年，Kent Beck也就是XP極限編程的創(chuàng)始人之一，在他的planning game（也有叫planning poker）中提到了用戶故事的使用。

2001年，Ron Jeffries（也是XP的創(chuàng)始人之一，另一位是Ward Cunningham）提出了用戶故事的3C法則。

2004年，Mike Cohn又在他的著作《User Stories Applied For Agile Software Development.》中為用戶故事引入了INVEST原則，然后再挖下去發(fā)現(xiàn)，自己又孤陋寡聞了，原來INVEST并非出自Mike Cohn，而是來自于Bill Wake，Bill在的文章"INVEST in Good Stories, and SMART Tasks"中，提到了用戶故事的INVEST原則和對于任務(wù)的SMART法則。

2014年，Jeff Pattern發(fā)表了用戶故事地圖的技術(shù)。

大家讀了半天是不是發(fā)現(xiàn)，仍舊沒有和Scrum扯上關(guān)系呢？

事實也的確如此，Scrum了不起的地方并不是定義的多詳細(xì)，而是定義的多么抽象和簡約。

因此可以這么認(rèn)為，用戶故事正好是對于Prodcut backlog的一種比較適配的表現(xiàn)形式。（不知道這么解釋是不是完全貼切，Scrum CSP/CTC/CST們請指正我）。

回到了第二個問題

開篇費(fèi)了這么多口舌只是為了說明用戶故事與Scrum的關(guān)系與來龍去脈，第二個Epic的問題答案就會相對容易些吧。

找了好幾篇文章，都有說到一個概念：Epic是一種Large Story的概念。換句話說，在敏捷開發(fā)的世界觀中，所有需求或許都可以稱之為Story。當(dāng)然除了SAFe將之與組織的經(jīng)濟(jì)帳聯(lián)系在了一起（別的地方也沒有明確說過沒有聯(lián)系）。

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

這么回答似乎覺得事情就可以結(jié)束了，但是心里總覺得不夠踏實，于是乎就又挖掘了一下，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的概念。

因此，我們可以簡單地下一個結(jié)論，Epic雖然可以認(rèn)為是一種大顆粒的user story，但是兩者并不完全等價。這也是為了回答第三個問題。

第三個問題是關(guān)于需求層級

敏捷培訓(xùn)中總是會提及一個敏捷計劃的洋蔥圖，圖中描述了敏捷計劃的幾個層次和時間的概念。我們也可以試著用我們之前調(diào)查的敏捷用戶故事的實踐來匹配到這些計劃活動中去，顯然的Daily的是Task，Iteration的是User Story。問題出在Release上，對于Release肯定不是User Story level的內(nèi)容了，因為Release與Sprint/Iteration的關(guān)系就不用細(xì)說了。自然的一個Release大多數(shù)情況下是包含多個Sprint/Iteration的。如果這么說來，是不是可以認(rèn)為Release的就是Epic呢？

圖：圖解敏捷計劃

如果剛才的問題，你回答Yes的話，那么在基于這種假設(shè)的世界觀面前，敏捷需求應(yīng)該是分為了Epic-Story的結(jié)構(gòu)的。如果熟悉JIRA的小伙伴們應(yīng)該不難發(fā)現(xiàn)，JIRA最天然的樣子的確如此。

我們再來問問JIRA怎么認(rèn)為，去到Atlassian的網(wǎng)站，可以看到對于敏捷需求的解釋與我們剛才的假設(shè)基本保持一致，可是為什么Epic頂上還有Initiative（中文翻譯可以叫作舉措）呢？

Initiatives在Atlasssian的文章被定義為一組Epics的集合，并且具有同一個目標(biāo)。Initiatives與Epics橫向跨越的又稱為Theme主題，主題可見是跨越Initiatives和Epics的。

圖：Atlasssian中所定義的敏捷需求

自此能不能下一個結(jié)論：敏捷需求分層應(yīng)該是Theme-Initiative-Epic-Story呢？顯然這又不全對，因為隨手在網(wǎng)上可見到Feature這一說法，并且目前在應(yīng)用Feature這個概念的企業(yè)不在少數(shù)。

Feature這個詞倒是非常容易被接受，因為Feature并不是一個敏捷世界才有的詞匯，再次考古發(fā)現(xiàn)，在IEEE組織定義Feature為A distinguishing characteristic of a software item (e.g., performance, portability, or functionality)。在某些地方也有解釋為是用戶或者產(chǎn)品經(jīng)理所認(rèn)為的最小顆粒度的價值交付物。

不過我自己對此倒有一些不同看法。

首先Feature如果作為大于Story的顆粒度，用戶或者PO所認(rèn)為的最小價值交付物，從waterfall到agile的整個transitioning階段，這么定義或許一時半會兒可以被大家所認(rèn)同，但是一旦到了上線階段，用戶的需求層出不窮，并且變更內(nèi)容開始逐漸小顆粒，發(fā)布頻率加快以后，User Story將會越來越替代Feature成為真正的最小價值交付顆粒。

其次Feature在JIRA中并不是一個缺省存在，因此即便我們認(rèn)同F(xiàn)eature的價值并且打算使用的話，立即將會面臨的問題就是，我們需要手動的為JIRA中的需求層級配置添加一個節(jié)點，使之成為Epic-Feature-Story的結(jié)構(gòu)。在操作復(fù)雜度上無形中提升了一個臺階。當(dāng)然成功這么運(yùn)用的企業(yè)也不在少數(shù)。這里個人意見并不表示我們就該放棄使用Feature這個用法。我們?nèi)耘f有理由可以使用這個需求層級。

SAFe中甚至定義了Feature的格式以及排序優(yōu)先級方法。那么按照我們一開始考古的經(jīng)歷來看，Scrum沒有明確定義我們必須采用User Story作為product backlog的內(nèi)容，因此只要分類清晰，屬于敏捷的最佳實踐的，并且只要組織認(rèn)同這個價值的話，那么如何分層只是一個不同組織的適配問題。

剖析到這里，差不多也算是分析完了。簡單總結(jié)幾點：

• Scrum中沒有定義用戶故事；
• Epic與Story不完全等價；
• 用戶故事是敏捷需求的最小單位；
• 比Story大的，跨多個迭代的需求可根據(jù)組織的定義，劃分為：A）Feature特性需求；B）Epic史詩需求；
• 是不是用了Epic-Story的就敏捷了，用了Epic-Feature-Story的就不敏捷了，這么下結(jié)論還太早，但是我們一定要考慮的是，本身這些結(jié)構(gòu)問題與JIRA甚至其他管理軟件的匹配度。

內(nèi)容就介紹到這里，有疑問的歡迎在文末留言。

參考文檔

• What is a user story：https://www.mountaingoatsoftware.com/agile/user-stories
• User Stories with Examples and Template：https://www.atlassian.com/agile/project-management/user-stories
• User Story Wiki： https://en.wikipedia.org/wiki/User_story
• INVEST in Good Stories, and SMART Tasks：https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
• INVEST：https://www.agilealliance.org/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：http://agiledictionary.com/309/epic/
• Difference between epics vs user stories：https://gbksoft.com/blog/difference-between-epics-vs-user-stories/

來源：時代膠囊

作者：徐陳飛Wilson，徐陳飛Wilson在IT行業(yè)具有15年的工作經(jīng)驗，曾經(jīng)服務(wù)過IBM、PwC、inspearit等咨詢公司，涉及的主要行業(yè)領(lǐng)域有保險、銀行、汽車、互聯(lián)網(wǎng)等等國內(nèi)外大型企業(yè)。在正式開始敏捷教練生涯之前，曾擔(dān)任過程序員，架構(gòu)師，項目經(jīng)理，培訓(xùn)講師，Guidewire開發(fā)咨詢顧問等工作。尤其擅長大型項目的敏捷項目管理與敏捷轉(zhuǎn)型咨詢工作。

3月每周四晚8點，IDCF【冬哥有話說】將解讀四位國際大咖的經(jīng)典演講，一起精進(jìn)#敏捷#DevOps。

第4期，本周四（明晚）8點，王立杰老師解讀規(guī)模化敏捷SAFe聯(lián)合創(chuàng)始人Dean Leffingwell《業(yè)務(wù)敏捷，贏得數(shù)字化時代》。關(guān)注公眾號回復(fù)“牛上加牛”獲取直播地址哦~