大咖專欄 | 我在DevCloud作需求

筆者在華爲雲DevCloud工做，秉承吃狗糧的文化，DevCloud團隊在踐行精益敏捷DevOps的同時，也在使用DevCloud工具進行實踐落地。 而我但願講述老百姓本身的故事，說說DevCloud是怎麼作敏捷DevOps的，因此產生了寫「我在DevCloud」系列的想法，目前規劃的有以下內容：

【我在DevCloud作需求】

【我在DevCloud作估算】

【我在DevCloud作計劃】

【我在DevCloud作開發】

【我在DevCloud作測試】

【我在DevCloud作檢查】

【我在DevCloud作集成】

【我在DevCloud作交付】

... ...

採用「我在DevCloud」做爲系列主題有兩重含義：

• 其一，DevCloud是筆者所在的團隊，因此我會寫寫DevCloud團隊是如何作這些活動的；

• 其二，DevCloud是筆者所在團隊開發的DevOps工具鏈平臺，因此我會描述如何在DevCloud上進行這些活動。

須要說明的是：

• 這些實踐方式，DevCloud團隊在踐行，因此具備必定的示範性；

• 但不具有普適性，每一個團隊都應該根據本身團隊的業務特性、團隊成熟度、流程以及對方法論的解讀，來進行落地實現；

·裏面有不少優化的空間，並無最佳的實踐，只有適合的實踐。

一般而言，軟件開發起始於需求收集與分析，因此咱們系列第一篇，從需求談起。

傳統的瀑布研發模式基於三個假設：用戶準確的知道本身想要什麼，開發人員可以徹底理解用戶在說什麼，需求在研發過程當中不會發生變化。

但事實上這三個前提假設都不存在，需求溝通以後作出來的產品，每每如同下圖的蛋糕（笑而不語）

​

咱們以用戶故事來描述需求

維基百科上說，用戶故事的目的在於以更快的速度、更少的消耗來應對現實世界需求的快速變化。

在DevCloud，咱們以用戶故事的形式來記錄需求。華爲以往也用需求規格說明書以及用例的形式，但這樣的方式很是乏味、容易出錯、編寫耗時，並且說真心話沒人願意去讀。

採用用戶故事的好處在於：

• 用戶故事強調對話而不是書面溝通

• 故事更容易被客戶和開發人員理解

• 用戶故事大小適中，適合作迭代計劃

• 用戶故事鼓勵重要的事情先作

• 鼓勵推遲決策，延遲考慮細節

• 支持隨需求而變的開發

用戶故事將重點從以往的文檔轉換到了更實用的對話，面面俱到的文檔看上去當然很美，但費時費力並且還沒人去看。取而代之以經過與客戶溝通來獲取需求，經過與用戶協做來澄清需求，經過頻繁的發佈來確認需求。

用戶故事一般按照以下的格式來表達：

As a <Role>, I want to <Activity>, so that <Business Value>.

做爲一個<角色>，我想要<活動>，以便於<商業價值>。

三段式的用戶故事，核心是從用戶角度出發描述問題，站在用戶的立場思考問題。

好的用戶故事討論的是爲誰作和爲何作，而不只僅是作什麼。做爲Who，我想要What，以便於Why。有了Who,Why, What的信息，How就變得呼之欲出了。

以往咱們上來就寫需求的，每每注意到的是What（幹什麼），卻忽略了Who（爲誰作）以及Why（爲何作）。

而Who-Why-How-What的邏輯模式，剛好也是影響地圖的結構，有關影響地圖，咱們找機會單獨聊。

DevCloud支持工做項模板，在設置->項目設置中，能夠看到如何將用戶故事的三段式，預置在Story的工做項模板中，用戶也能夠根據須要自行定義描述信息。

​

咱們遵循Ron Jeffries提出的3C原則

關於用戶故事，Ron Jeffries用3個C來描述它：

• Card，卡片，咱們在用戶故事編寫工做坊中使用貼紙或卡片編寫，隨後錄入到DevCloud成爲工做項，展示方式能夠是卡片、列表或樹狀結構。卡片表明需求而不是記錄需求，詳盡的需求內容能夠用其餘文檔表述。

• Conversation，討論的過程建議是面對面的，若是你也是像DevCloud的成員同樣分佈在不一樣地域，能夠經過電話或IM工具（華爲內部用eSpace，能夠語音、視頻也能夠聊天）進行，將重要的結論寫在工做項提供的討論功能中，簡單的討論能夠直接經過工做項的討論進行。但須要牢記的是，文字的討論永遠沒法取代面對面或是電話的溝通。

• Confirmation，確認，用戶故事並不具有契約性質，達成協議的驗證要點是測試的依據，用來驗證用戶故事是否符合用戶的指望。在用戶故事編寫工做坊中，驗證信息能夠寫在故事卡片的背面，隨後錄入工做項。針對每個測試要點都應該變成完整的測試用例，咱們使用DevCloud的雲測模塊，具體測試的部分會在後續【我在DevCloud作測試】一文中介紹。測試用例會與需求進行關聯，由此完美的將3C結合在一塊兒。

卡片是用戶故事的展示形式，咱們會切換到迭代視圖的卡片模式，經過拖動卡片完成狀態更新。

​

討論是溝通的方式，不要讓討論的內容蒸發掉，討論過程當中最大的浪費就是大量的信息隨後被遺失掉了；咱們一般在Story工做項的評論中記錄討論結果，或是直接在評論中進行討論，並用@通知他人。

確認是驗收方式，驗收信息能夠填寫在描述信息中，也能夠在項目設置中在Story工做項的模板中添加一個屬性字段完成，具體實現方式不一，而且實現起來很是靈活，因此並未作進預置的項目模板中。

一個用戶故事工做項，事實上是一個需求的入口，以條目化或是卡片的形式展示，同時能夠進行多方位的關聯。

• 由驗收信息生成的測試用例，會關聯到工做項的」關聯用例「中。

• 在對話和溝通的過程當中會產生的有用信息，能夠經過Wiki（知識共享）、Docman（文檔協同）來保存，而且能夠關聯到Story工做項。

• 也能夠將現有的文件添加爲工做項的附件。

​

如何建立和收集故事？

一般有幾種方式進行用戶故事的建立和收集，其中前兩種是最常常採納的：

• 用戶訪談

• 故事編寫工做坊

• 問卷調查

• 觀察

用戶訪談的關鍵是找到真正的用戶，因此用戶訪談以前是用戶畫像，也就是找到Who的過程。

「大家的確開發了我所說的功能，但它並非我真正想要的」，用戶每每不知道或很難準確表達本身想要的，因此溝通須要頻繁，須要拿着不一樣階段的產物進行確認；

說者無意，聽者有意，會不會是本身主觀臆斷？說者有心，聽者無心，會不會遺漏關鍵字？同理心提及來容易，作起來很難。

用戶故事編寫工做坊是捕獲需求最有效的方式，原則是：數量優先而不是質量優先，鼓勵你們輸出，而不要去評判某個故事的好壞；深度優先而不是廣度優先，先把一條路走通，而不要中途跳到岔路上。

用戶最可能作什麼？可能會犯什麼錯誤？會有什麼困惑？會須要什麼信息？

在工做坊裏最好用貼紙，便於交互，隨後再整理到工具平臺上。

觀察用戶真實使用產品的機會是難能難得的，你會發現用戶永遠不會按照你設計的方式使用產品。

如何拆分用戶故事

​

需求一般以Epic-Feature-Story進行層級拆分：

• Epic一般是公司重要戰略舉措或者巨大的需求，例如作一個電商網站就是一個Epic。

• Feature一般是在Epic之下，對用戶有價值的功能，用戶能夠經過使用特性知足他們的需求。好比「電商網站」的 「門店網絡查詢功能」，特性一般會經過多個迭代持續交付。

• Story一般是對一個功能進行用戶場景細分，而且能在一個迭代內完成，Story一般須要知足INVEST原則：Independent 獨立的，Neogociable 可討論的，Valuable 對客戶/用戶有價值的，Estimatable 可估計的，Small 小的，Testable 可測試的。

• Story又能夠繼續拆成Task，Task是實現層面的，無需遵循INVEST原則。

戰略、功能、需求、任務等的在具體項目中很難進行歸類，也能夠簡單的按月、周、日、小時爲單位進行判斷，一般一個Epic可能會跨多個Release交付，Feature跨多個Sprint，Story須要在一個Sprint中完成，而Task一般是更短小以小時至多以天計。

從Epic-Feature-Story的拆分，能夠在項目規劃裏以腦圖的形式進行，一目瞭然。

​

一樣也能夠在Epic或Feature視圖中，以樹狀關係來展示和拆分。

​

非功能性需求以及技術類需求

NonFunctional Requirement，非功能性需求每每是決定產品/項目成敗的關鍵，卻每每容易被忽視。

當非功能性需求欠缺太多，就揹負了技術債務，須要經過按期的技術類活動進行清理。

典型的非功能性需求包括：性能、可移植性、可擴展性、可用性、易用性、可維護性、可重用性、可操做性、安全性、容量等。

技術類需求的例子包括：重構、搭建持續交付流水線、測試自動化活動、環境的維護與搭建、架構改造等。

​

目前咱們沒有預置非功能性需求和技術類需求做爲單獨的工做項類型，不但願工做項類型過於膨脹而增長了使用的複雜性。

能夠新增字段來標識不一樣類型的需求，更好的方式則是採用Tag標籤。

善用標籤和過濾器的結合，能夠實現很是強大的功能，關於過濾器的使用技巧，咱們能夠單開一個主題來討論。

​

Bad Smell 如何識別用戶故事的壞味道

如同低質量的代碼會有Bad Smell，用戶故事也同樣會有壞味道：

• 若是你發現幾十頁上百項需求堆在Product Backlog裏

• 若是你發現提交的需求，自始至終沒人和你溝通，某一天忽然發現需求被實現了

• 若是你發現排在Product Backlog中段和後段的用戶故事太過詳盡

• 若是你發現你們依賴Product Backlog電子系統，而不是面對面進行溝通

• 若是你發現用戶故事長得像需求規格說明書

• 若是你發現說不出故事的目標用戶以及帶來的價值

• 若是你發現很難爲衆多故事排優先級（不是高中低，而是惟一順序）

• 若是你發現故事之間牽一髮而動全身

有關用戶故事的一些零散建議

• 需求要有時間點，多問一句」何時須要？」，你每每會發現對方其實內心沒數，ASAP不是一個好答案，越快越好只能說明不信任。儘管會有顧慮，我依然會如實說「這個功能與一個月以後的某個活動相關，在此以前實現便可，但須要預留給我一週的時間進行驗證和修復」。

• 進行故事優先級排序時，須要考慮成本，一個重要的需求，有可能由於成本太高而延後，另外一種方法是對其進行拆分。

• 不要着急給用戶故事添加細節，遵循Kent Beck提出的最後責任時刻（Last Responsible Moment）原則，團隊要等到開始實現軟件特性前才寫下特性的具體細節。優先級排序，近期、中期、長期需求的詳略程度。

• 紙質卡片/貼紙，仍是電子工具？在需求收集和引導的前期，例如需求編寫工做坊，建議採用紙質卡片，便於交互，而且卡片的有限文字空間保證了咱們不會過早進入細節。當需求收集告一段落，統一將需求錄入到DevCloud平臺，需求不僅是Card一個維度，多方位的信息須要有工具平臺來支撐和記錄。同時平臺也提供了團隊成員之間的協同，DevCloud團隊異地的協同場景就是基於DevCloud平臺進行的。

小結

故事是講出來的，不是寫出來的；故事的目的是激發溝通中的火花，用戶故事之因此叫故事，是由於他要講而不是要寫的，溝通、協做並最終交付好的需求。

DevCloud的需求實踐並不是最佳的，只是適應咱們自身團隊以及產品/項目狀況的折中之選。

本文不追求面面俱到的介紹有關需求以及用戶故事的點，若是您有與需求相關的問題，請留言給我，我會集中回答。