筆者在華為云DevCloud工作，秉承吃狗糧的文化，DevCloud團(tuán)隊(duì)在踐行精益敏捷DevOps的同時(shí)，也在使用DevCloud工具進(jìn)行實(shí)踐落地。?而我希望講述老百姓自己的故事焚志，說(shuō)說(shuō)DevCloud是怎么做敏捷DevOps的，所以產(chǎn)生了寫(xiě)“我在DevCloud”系列的想法畏鼓，目前規(guī)劃的有如下內(nèi)容：
【我在DevCloud做需求】
【我在DevCloud做估算】
【我在DevCloud做計(jì)劃】
【我在DevCloud做開(kāi)發(fā)】
【我在DevCloud做測(cè)試】
【我在DevCloud做檢查】
【我在DevCloud做集成】
【我在DevCloud做交付】
... ...
采用“我在DevCloud”作為系列主題有兩重含義：
??其一酱酬，DevCloud是筆者所在的團(tuán)隊(duì)，所以我會(huì)寫(xiě)寫(xiě)DevCloud團(tuán)隊(duì)是如何做這些活動(dòng)的云矫；
??其二膳沽，DevCloud是筆者所在團(tuán)隊(duì)開(kāi)發(fā)的DevOps工具鏈平臺(tái)，所以我會(huì)描述如何在DevCloud上進(jìn)行這些活動(dòng)让禀。
需要說(shuō)明的是：
??這些實(shí)踐方式挑社，DevCloud團(tuán)隊(duì)在踐行，所以具有一定的示范性巡揍；
??但不具備普適性痛阻，每個(gè)團(tuán)隊(duì)都應(yīng)該根據(jù)自己團(tuán)隊(duì)的業(yè)務(wù)特性、團(tuán)隊(duì)成熟度腮敌、流程以及對(duì)方法論的解讀阱当，來(lái)進(jìn)行落地實(shí)現(xiàn)；
·里面有很多優(yōu)化的空間糜工，并沒(méi)有最佳的實(shí)踐弊添，只有適合的實(shí)踐。?
通常而言捌木，軟件開(kāi)發(fā)起始于需求收集與分析油坝，所以我們系列第一篇，從需求談起。
傳統(tǒng)的瀑布研發(fā)模式基于三個(gè)假設(shè)：用戶準(zhǔn)確的知道自己想要什么免钻，開(kāi)發(fā)人員能夠完全理解用戶在說(shuō)什么，需求在研發(fā)過(guò)程中不會(huì)發(fā)生變化崔拥。
但事實(shí)上這三個(gè)前提假設(shè)都不存在极舔，需求溝通之后做出來(lái)的產(chǎn)品，往往如同下圖的蛋糕（笑而不語(yǔ)）
?
我們以用戶故事來(lái)描述需求
維基百科上說(shuō)链瓦，用戶故事的目的在于以更快的速度拆魏、更少的消耗來(lái)應(yīng)對(duì)現(xiàn)實(shí)世界需求的快速變化。
在DevCloud慈俯，我們以用戶故事的形式來(lái)記錄需求渤刃。華為以往也用需求規(guī)格說(shuō)明書(shū)以及用例的形式，但這樣的方式非常乏味贴膘、容易出錯(cuò)卖子、編寫(xiě)耗時(shí)，而且說(shuō)真心話沒(méi)人愿意去讀刑峡。
采用用戶故事的好處在于：
????用戶故事強(qiáng)調(diào)對(duì)話而不是書(shū)面溝通
????故事更容易被客戶和開(kāi)發(fā)人員理解
????用戶故事大小適中洋闽，適合做迭代計(jì)劃
????用戶故事鼓勵(lì)重要的事情先做
????鼓勵(lì)推遲決策，延遲考慮細(xì)節(jié)
????支持隨需求而變的開(kāi)發(fā)
用戶故事將重點(diǎn)從以往的文檔轉(zhuǎn)換到了更實(shí)用的對(duì)話突梦，面面俱到的文檔看上去固然很美诫舅，但費(fèi)時(shí)費(fèi)力而且還沒(méi)人去看。取而代之以通過(guò)與客戶溝通來(lái)獲取需求宫患，通過(guò)與用戶協(xié)作來(lái)澄清需求刊懈，通過(guò)頻繁的發(fā)布來(lái)確認(rèn)需求。
用戶故事通常按照如下的格式來(lái)表達(dá)：
As a <Role>, I want to <Activity>, so that <Business Value>.
作為一個(gè)<角色>娃闲，我想要<活動(dòng)>虚汛，以便于<商業(yè)價(jià)值>。
三段式的用戶故事皇帮，核心是從用戶角度出發(fā)描述問(wèn)題泽疆，站在用戶的立場(chǎng)思考問(wèn)題。
好的用戶故事討論的是為誰(shuí)做和為什么做玲献，而不僅僅是做什么殉疼。作為Who，我想要What捌年，以便于Why瓢娜。有了Who,Why, What的信息，How就變得呼之欲出了礼预。
以往我們上來(lái)就寫(xiě)需求的眠砾，往往注意到的是What（干什么），卻忽略了Who（為誰(shuí)做）以及Why（為什么做）托酸。
而Who-Why-How-What的邏輯模式褒颈，恰好也是影響地圖的結(jié)構(gòu)柒巫，有關(guān)影響地圖，我們找機(jī)會(huì)單獨(dú)聊谷丸。
DevCloud支持工作項(xiàng)模板堡掏，在設(shè)置->項(xiàng)目設(shè)置中，可以看到如何將用戶故事的三段式刨疼，預(yù)置在Story的工作項(xiàng)模板中泉唁，用戶也可以根據(jù)需要自行定義描述信息。
?
我們遵循Ron Jeffries提出的3C原則
關(guān)于用戶故事揩慕，Ron? Jeffries用3個(gè)C來(lái)描述它：
?? ?Card亭畜，卡片，我們?cè)谟脩艄适戮帉?xiě)工作坊中使用貼紙或卡片編寫(xiě)迎卤，隨后錄入到DevCloud成為工作項(xiàng)拴鸵，展現(xiàn)方式可以是卡片、列表或樹(shù)狀結(jié)構(gòu)蜗搔”ψ伲卡片代表需求而不是記錄需求，詳盡的需求內(nèi)容可以用其他文檔表述碍扔。
????Conversation瘩燥，討論的過(guò)程建議是面對(duì)面的，如果你也是像DevCloud的成員一樣分布在不同地域不同，可以通過(guò)電話或IM工具（華為內(nèi)部用eSpace厉膀，可以語(yǔ)音、視頻也可以聊天）進(jìn)行二拐，將重要的結(jié)論寫(xiě)在工作項(xiàng)提供的討論功能中服鹅，簡(jiǎn)單的討論可以直接通過(guò)工作項(xiàng)的討論進(jìn)行。但需要牢記的是百新，文字的討論永遠(yuǎn)無(wú)法取代面對(duì)面或是電話的溝通企软。
?? ?Confirmation，確認(rèn)饭望，用戶故事并不具備契約性質(zhì)仗哨，達(dá)成協(xié)議的驗(yàn)證要點(diǎn)是測(cè)試的依據(jù)，用來(lái)驗(yàn)證用戶故事是否符合用戶的期望铅辞。在用戶故事編寫(xiě)工作坊中厌漂，驗(yàn)證信息可以寫(xiě)在故事卡片的背面，隨后錄入工作項(xiàng)斟珊。針對(duì)每一個(gè)測(cè)試要點(diǎn)都應(yīng)該變成完整的測(cè)試用例苇倡，我們使用DevCloud的云測(cè)模塊，具體測(cè)試的部分會(huì)在后續(xù)【我在DevCloud做測(cè)試】一文中介紹。測(cè)試用例會(huì)與需求進(jìn)行關(guān)聯(lián)旨椒，由此完美的將3C結(jié)合在一起晓褪。
卡片是用戶故事的展現(xiàn)形式，我們會(huì)切換到迭代視圖的卡片模式综慎，通過(guò)拖動(dòng)卡片完成狀態(tài)更新涣仿。
?
討論是溝通的方式，不要讓討論的內(nèi)容蒸發(fā)掉寥粹，討論過(guò)程中最大的浪費(fèi)就是大量的信息隨后被遺失掉了变过；我們通常在Story工作項(xiàng)的評(píng)論中記錄討論結(jié)果埃元，或是直接在評(píng)論中進(jìn)行討論涝涤，并用@通知他人。
確認(rèn)是驗(yàn)收方式岛杀，驗(yàn)收信息可以填寫(xiě)在描述信息中阔拳，也可以在項(xiàng)目設(shè)置中在Story工作項(xiàng)的模板中添加一個(gè)屬性字段完成，具體實(shí)現(xiàn)方式不一类嗤，并且實(shí)現(xiàn)起來(lái)非常靈活糊肠，所以并未做進(jìn)預(yù)置的項(xiàng)目模板中。
一個(gè)用戶故事工作項(xiàng)遗锣，事實(shí)上是一個(gè)需求的入口货裹，以條目化或是卡片的形式展現(xiàn)，同時(shí)可以進(jìn)行多方位的關(guān)聯(lián)精偿。
?? ?由驗(yàn)收信息生成的測(cè)試用例弧圆，會(huì)關(guān)聯(lián)到工作項(xiàng)的”關(guān)聯(lián)用例“中。
?? ?在對(duì)話和溝通的過(guò)程中會(huì)產(chǎn)生的有用信息笔咽，可以通過(guò)Wiki（知識(shí)共享）搔预、Docman（文檔協(xié)同）來(lái)保存，并且可以關(guān)聯(lián)到Story工作項(xiàng)叶组。
?? ?也可以將現(xiàn)有的文件添加為工作項(xiàng)的附件拯田。
?
如何創(chuàng)建和收集故事？
通常有幾種方式進(jìn)行用戶故事的創(chuàng)建和收集甩十，其中前兩種是最經(jīng)常采納的：
????用戶訪談
????故事編寫(xiě)工作坊
????問(wèn)卷調(diào)查
????觀察
用戶訪談的關(guān)鍵是找到真正的用戶船庇，所以用戶訪談之前是用戶畫(huà)像，也就是找到Who的過(guò)程侣监。
“你們的確開(kāi)發(fā)了我所說(shuō)的功能溢十，但它并不是我真正想要的”，用戶往往不知道或很難準(zhǔn)確表達(dá)自己想要的达吞，所以溝通需要頻繁张弛，需要拿著不同階段的產(chǎn)物進(jìn)行確認(rèn)；
說(shuō)者無(wú)心，聽(tīng)者有意吞鸭，會(huì)不會(huì)是自己主觀臆斷寺董？說(shuō)者有心，聽(tīng)者無(wú)意刻剥，會(huì)不會(huì)遺漏關(guān)鍵字遮咖？同理心說(shuō)起來(lái)容易，做起來(lái)很難造虏。
用戶故事編寫(xiě)工作坊是捕獲需求最有效的方式御吞，原則是：數(shù)量?jī)?yōu)先而不是質(zhì)量?jī)?yōu)先，鼓勵(lì)大家輸出漓藕，而不要去評(píng)判某個(gè)故事的好壞陶珠；深度優(yōu)先而不是廣度優(yōu)先，先把一條路走通享钞，而不要中途跳到岔路上揍诽。
用戶最可能做什么？可能會(huì)犯什么錯(cuò)誤栗竖？會(huì)有什么困惑暑脆？會(huì)需要什么信息？
在工作坊里最好用貼紙狐肢，便于交互添吗，隨后再整理到工具平臺(tái)上。
觀察用戶真實(shí)使用產(chǎn)品的機(jī)會(huì)是難能可貴的份名，你會(huì)發(fā)現(xiàn)用戶永遠(yuǎn)不會(huì)按照你設(shè)計(jì)的方式使用產(chǎn)品碟联。
如何拆分用戶故事
?
需求通常以Epic-Feature-Story進(jìn)行層級(jí)拆分：
?? ?Epic通常是公司重要戰(zhàn)略舉措或者巨大的需求，例如做一個(gè)電商網(wǎng)站就是一個(gè)Epic同窘。
????Feature通常是在Epic之下玄帕，對(duì)用戶有價(jià)值的功能，用戶可以通過(guò)使用特性滿足他們的需求想邦。比如“電商網(wǎng)站”的?“門(mén)店網(wǎng)絡(luò)查詢(xún)功能”裤纹，特性通常會(huì)通過(guò)多個(gè)迭代持續(xù)交付。
?? ?Story通常是對(duì)一個(gè)功能進(jìn)行用戶場(chǎng)景細(xì)分丧没，并且能在一個(gè)迭代內(nèi)完成鹰椒，Story通常需要滿足INVEST原則：Independent?獨(dú)立的，Neogociable?可討論的呕童，Valuable?對(duì)客戶/用戶有價(jià)值的漆际，Estimatable?可估計(jì)的，Small?小的夺饲，Testable?可測(cè)試的奸汇。
???Story又可以繼續(xù)拆成Task施符，Task是實(shí)現(xiàn)層面的，無(wú)需遵循INVEST原則擂找。
戰(zhàn)略戳吝、功能、需求贯涎、任務(wù)等的在具體項(xiàng)目中很難進(jìn)行歸類(lèi)听哭，也可以簡(jiǎn)單的按月、周塘雳、日陆盘、小時(shí)為單位進(jìn)行判斷，通常一個(gè)Epic可能會(huì)跨多個(gè)Release交付败明，F(xiàn)eature跨多個(gè)Sprint隘马，Story需要在一個(gè)Sprint中完成，而Task通常是更短小以小時(shí)至多以天計(jì)肩刃。
從Epic-Feature-Story的拆分祟霍，可以在項(xiàng)目規(guī)劃里以腦圖的形式進(jìn)行杏头，一目了然盈包。
?
同樣也可以在Epic或Feature視圖中，以樹(shù)狀關(guān)系來(lái)展現(xiàn)和拆分醇王。
?
非功能性需求以及技術(shù)類(lèi)需求
NonFunctional Requirement呢燥，非功能性需求往往是決定產(chǎn)品/項(xiàng)目成敗的關(guān)鍵，卻往往容易被忽視寓娩。
當(dāng)非功能性需求欠缺太多叛氨，就背負(fù)了技術(shù)債務(wù)，需要通過(guò)定期的技術(shù)類(lèi)活動(dòng)進(jìn)行清理棘伴。
典型的非功能性需求包括：性能寞埠、可移植性、可擴(kuò)展性焊夸、可用性仁连、易用性、可維護(hù)性阱穗、可重用性饭冬、可操作性、安全性揪阶、容量等昌抠。
技術(shù)類(lèi)需求的例子包括：重構(gòu)、搭建持續(xù)交付流水線鲁僚、測(cè)試自動(dòng)化活動(dòng)炊苫、環(huán)境的維護(hù)與搭建裁厅、架構(gòu)改造等。
?
目前我們沒(méi)有預(yù)置非功能性需求和技術(shù)類(lèi)需求作為單獨(dú)的工作項(xiàng)類(lèi)型侨艾，不希望工作項(xiàng)類(lèi)型過(guò)于膨脹而增加了使用的復(fù)雜性姐直。
可以新增字段來(lái)標(biāo)識(shí)不同類(lèi)型的需求，更好的方式則是采用Tag標(biāo)簽蒋畜。
善用標(biāo)簽和過(guò)濾器的結(jié)合声畏，可以實(shí)現(xiàn)非常強(qiáng)大的功能，關(guān)于過(guò)濾器的使用技巧姻成，我們可以單開(kāi)一個(gè)主題來(lái)討論插龄。
?
Bad Smell 如何識(shí)別用戶故事的壞味道
如同低質(zhì)量的代碼會(huì)有Bad Smell，用戶故事也一樣會(huì)有壞味道：
????如果你發(fā)現(xiàn)幾十頁(yè)上百項(xiàng)需求堆在Product Backlog里
????如果你發(fā)現(xiàn)提交的需求科展，自始至終沒(méi)人和你溝通均牢，某一天突然發(fā)現(xiàn)需求被實(shí)現(xiàn)了
????如果你發(fā)現(xiàn)排在Product Backlog中段和后段的用戶故事太過(guò)詳盡
????如果你發(fā)現(xiàn)大家依賴(lài)Product Backlog電子系統(tǒng)，而不是面對(duì)面進(jìn)行溝通
????如果你發(fā)現(xiàn)用戶故事長(zhǎng)得像需求規(guī)格說(shuō)明書(shū)
????如果你發(fā)現(xiàn)說(shuō)不出故事的目標(biāo)用戶以及帶來(lái)的價(jià)值
????如果你發(fā)現(xiàn)很難為眾多故事排優(yōu)先級(jí)（不是高中低才睹，而是唯一順序）
????如果你發(fā)現(xiàn)故事之間牽一發(fā)而動(dòng)全身
有關(guān)用戶故事的一些零散建議
????需求要有時(shí)間點(diǎn)徘跪，多問(wèn)一句”什么時(shí)候需要？”琅攘，你往往會(huì)發(fā)現(xiàn)對(duì)方其實(shí)心里沒(méi)數(shù)垮庐，ASAP不是一個(gè)好答案，越快越好只能說(shuō)明不信任坞琴。盡管會(huì)有顧慮哨查，我依然會(huì)如實(shí)說(shuō)“這個(gè)功能與一個(gè)月之后的某個(gè)活動(dòng)相關(guān)，在此之前實(shí)現(xiàn)即可剧辐，但需要預(yù)留給我一周的時(shí)間進(jìn)行驗(yàn)證和修復(fù)”寒亥。
????進(jìn)行故事優(yōu)先級(jí)排序時(shí)，需要考慮成本荧关，一個(gè)重要的需求溉奕，有可能因?yàn)槌杀具^(guò)高而延后，另一種方法是對(duì)其進(jìn)行拆分忍啤。
????不要著急給用戶故事添加細(xì)節(jié)加勤，遵循Kent Beck提出的最后責(zé)任時(shí)刻（Last Responsible Moment）原則，團(tuán)隊(duì)要等到開(kāi)始實(shí)現(xiàn)軟件特性前才寫(xiě)下特性的具體細(xì)節(jié)檀轨。優(yōu)先級(jí)排序胸竞，近期、中期参萄、長(zhǎng)期需求的詳略程度卫枝。
????紙質(zhì)卡片/貼紙，還是電子工具讹挎？在需求收集和引導(dǎo)的前期校赤，例如需求編寫(xiě)工作坊吆玖，建議采用紙質(zhì)卡片，便于交互马篮，并且卡片的有限文字空間保證了我們不會(huì)過(guò)早進(jìn)入細(xì)節(jié)沾乘。當(dāng)需求收集告一段落，統(tǒng)一將需求錄入到DevCloud平臺(tái)浑测，需求不只是Card一個(gè)維度翅阵，多方位的信息需要有工具平臺(tái)來(lái)支撐和記錄。同時(shí)平臺(tái)也提供了團(tuán)隊(duì)成員之間的協(xié)同迁央，DevCloud團(tuán)隊(duì)異地的協(xié)同場(chǎng)景就是基于DevCloud平臺(tái)進(jìn)行的掷匠。
小結(jié)
故事是講出來(lái)的，不是寫(xiě)出來(lái)的岖圈；故事的目的是激發(fā)溝通中的火花讹语，用戶故事之所以叫故事，是因?yàn)樗v而不是要寫(xiě)的蜂科，溝通顽决、協(xié)作并最終交付好的需求。
DevCloud的需求實(shí)踐并非最佳的导匣，只是適應(yīng)我們自身團(tuán)隊(duì)以及產(chǎn)品/項(xiàng)目情況的折中之選才菠。
本文不追求面面俱到的介紹有關(guān)需求以及用戶故事的點(diǎn)，如果您有與需求相關(guān)的問(wèn)題逐抑，請(qǐng)留言給我鸠儿，我會(huì)集中回答屹蚊。
