\

關(guān)鍵點

\\

• 不規(guī)范的需求描述會對項目產(chǎn)生不利影響。\\t
• 某項目需求描述標(biāo)準(zhǔn)化前后的狀態(tài)比較。\\t
• 需求描述統(tǒng)一的八大好處。\\t
• 標(biāo)準(zhǔn)化對測試過程的積極影響。\

\\

業(yè)務(wù)分析人員之間會經(jīng)常討論需求的描述格式。在這篇文章中，我將分享我在這方面的經(jīng)驗。我最近有一個項目。在這個項目中，所有需求描述采用了某種標(biāo)準(zhǔn)化格式。這不僅改善了測試人員和開發(fā)人員的體驗，提高了團隊的生產(chǎn)力，而且建立了更有效的項目流程。

\\

沒有標(biāo)準(zhǔn)的需求描述隱患

\\

新員工。當(dāng)產(chǎn)品經(jīng)理管理需求的時候，他們經(jīng)常沒有分配足夠的時間來合理地描述這些需求。這主要是因為時間緊迫而馬上需要開始研發(fā)的壓力又十分巨大，亦或是產(chǎn)品經(jīng)理缺少能以恰當(dāng)方式整理需求的必要技能。無論如何，研發(fā)能否順利開展都取決于研發(fā)團隊的經(jīng)驗和相關(guān)應(yīng)用經(jīng)驗。但是，當(dāng)新專家參與項目時，會發(fā)生什么事情？合適的文檔可以無縫地向新團隊成員介紹這個項目和正在研發(fā)的產(chǎn)品以及服務(wù)。這對于大型長期項目尤為重要。因為缺少這樣文件會到導(dǎo)致項目運行過程中遭遇更多嚴(yán)峻的挑戰(zhàn)。

\\

估算。如果需求是以一種隨意的方式進行描述，沒有互相理解的規(guī)則和明確的標(biāo)準(zhǔn)，當(dāng)出現(xiàn)無法回答的問題時，需求就無法被估算。萬一有遺漏，而開發(fā)人員已經(jīng)開始研發(fā)，那么就會出現(xiàn)瓶頸時期，浪費時間而且延誤開發(fā)。

\\

時間安排。沒有規(guī)范的需求描述，我們將難以創(chuàng)建可以持續(xù)執(zhí)行的可靠的項目計劃。當(dāng)產(chǎn)品經(jīng)理跳過詳細的需求文檔工作，開發(fā)的質(zhì)量會由于更多的漏洞和需要時間去修復(fù)它們而大打折扣，使得功能的實現(xiàn)需要比預(yù)計更長的迭代時間。

\\

Scrum項目規(guī)范需求描述前后

\\

規(guī)范需求描述對研發(fā)的直接影響可以從下面這個例子看出來。某大型的社交媒體公司擁有好幾個數(shù)以百萬計客戶的熱門網(wǎng)站。這是一個快速發(fā)展的敏捷項目，股東設(shè)定下很高的市場目標(biāo)，現(xiàn)有的文檔被壓縮到只為用戶和開發(fā)目標(biāo)提供服務(wù)。股東對數(shù)百頁文檔的創(chuàng)建和維護壓根不感興趣，而這恰恰是大多數(shù)敏捷項目有用而且常見的做法。

\\

客戶已經(jīng)有了他們自己的開發(fā)團隊和許多雄心勃勃的計劃，但需要更多的資源來實現(xiàn)它們。因此，他們需要額外新的研究人員、分析師和開發(fā)人員的團隊支持，將來還有增加QA（質(zhì)量保證）專家的計劃。

\\

當(dāng)新的團隊聚集在一起時，產(chǎn)品經(jīng)理的時間安排使他們能更專注于業(yè)務(wù)的發(fā)展方向、戰(zhàn)略和與企業(yè)主進行談判，而新項目領(lǐng)導(dǎo)能夠開始為研發(fā)和確保質(zhì)量準(zhǔn)備徹底的、結(jié)構(gòu)化的、完整的需求描述。

\\

全球范圍內(nèi)分布的團隊：一部分研發(fā)團隊在美國不同的州，另一部分是在明斯克。企業(yè)所有者和產(chǎn)品經(jīng)理居住在美國，而用戶則散居美國各個時區(qū)。由于所有團隊成員間頻繁和有效的溝通是項目重要的一環(huán)，時間差異讓溝通變得更復(fù)雜。

\\

在標(biāo)準(zhǔn)化需求描述之前

\\

在實施標(biāo)準(zhǔn)化需求描述之前，用例的描述沒有任何特定的格式：需求不夠詳細；案例缺失或案例太短；總體來說，缺少足夠的開發(fā)人員。這導(dǎo)致了一些負面的后果，包括：

\\

估算困難。在培訓(xùn)會議期間，問題出現(xiàn)了，在問題得到回應(yīng)之前，都沒有估算充足時間的辦法。

\\

問題和差距。在開發(fā)和測試階段，您可能會發(fā)現(xiàn)一些重要的方面沒有考慮實現(xiàn)功能（例如，遺忘了某些場景、異常流程等）。

\\

浪費時間和精力。在這一點上，整個團隊的有效性會受到影響：沒能完成預(yù)計的任務(wù)，因為它們沒有包含實施額外的需求；任務(wù)可能無法在迭代結(jié)束前完成；由于延遲推出新功能，用戶不滿意。此外，還需花費更多的時間向相關(guān)領(lǐng)導(dǎo)解釋為什么需求缺失和為什么開發(fā)團隊需要重復(fù)實施功能和測試任務(wù)。

\\

標(biāo)準(zhǔn)化的需求描述后

\\

為了改善這種情況，研發(fā)團隊開始使用“經(jīng)典”需求表達語句的標(biāo)準(zhǔn)描述方法：

\\\

“作為一個\u0026lt;用戶角色/類型\u0026gt;我要\u0026lt;一些功能\u0026gt;，以便\u0026lt;從這個功能中受益\u0026gt;”

\\\

此外，以下模板的基礎(chǔ)上，使用接受案例，：

\\\接受案例1：\------\\假設(shè)（某些上下文/前提條件）\和（一些更多的上下文/前提條件）\當(dāng)（由用戶執(zhí)行的事件/行動）\然后（預(yù)期的結(jié)果-根據(jù)上述用戶用例，什么應(yīng)該發(fā)生以滿足用戶的需求）\\接受案例2：…\-------\\\

項目一開始，團隊新開發(fā)人員都要從學(xué)習(xí)新的系統(tǒng)開始，他們不會只獲得一個簡短幫助說明，比如“當(dāng)審批在隊列中的影響因素時，系統(tǒng)應(yīng)在儀表板發(fā)出警告。”

\\

引入上述格式的結(jié)果就是開發(fā)人員和質(zhì)量保證工程師獲益于詳細的步驟和相關(guān)頁面的鏈接的完整描述。這顯著減少了問題的數(shù)量，并且關(guān)于“質(zhì)量”和相關(guān)指標(biāo)的要求都由于記錄詳細而變得清晰。

\\

當(dāng)然，在需要的情況下，我們可以在提供用戶的描述和接受案例的同時，提供支持性的東西。這些包括UI模型來說明在UI的變化、設(shè)計規(guī)范中變化影響最終用戶接口和多個圖表等。在大多數(shù)情況下，圖表都是用來說明過程中的變化的，并向整個團隊展示由于執(zhí)行一系列用戶描述，系統(tǒng)模塊需要做什么全局性改變。

\\

有主要接受案例的用戶描述項目案例：

\\

作為一個客戶服務(wù)經(jīng)理，我想能夠從搜索結(jié)果中排除已經(jīng)被調(diào)查的人員，以便我容易區(qū)分用戶是否已經(jīng)加入調(diào)查，并迅速將新登記的用戶加入每日調(diào)查。

\\\接受案例*：客戶服務(wù)經(jīng)理將某些人排除在被調(diào)查成員之外\\假設(shè)客戶服務(wù)部經(jīng)理進行調(diào)查，他/她希望邀請新用戶\并有用戶已經(jīng)被邀請到本次調(diào)查\有新的用戶還沒有被邀請\當(dāng)客戶服務(wù)經(jīng)理勾選“排除已參與調(diào)查成員”框，并應(yīng)用過濾器\然后顯示的用戶列表不應(yīng)該包括已被選中的要過濾的用戶。\\\

*上述案例成為三個現(xiàn)有案例中選出的最重要的一個案例，以便創(chuàng)建用戶描述以確保全面覆蓋。

\\

統(tǒng)一需求描述的好處

\\

360度無死角。當(dāng)基于一個標(biāo)準(zhǔn)的模板進行完整的描述時，問題會顯而易見而不容易被忽略。模板指南推動產(chǎn)品經(jīng)理和團隊認真思考流程中的每一步，并提出更多的問題。這些問題澄清后，用戶描述才會被估算和研發(fā)。因為后期和項目關(guān)鍵期遇到的問題減少了，因此節(jié)省了團隊的時間。因此，所有的過程都變得更透明并且項目預(yù)算能更有效地實施。\\t

全覆蓋。可能性很大的是，所有可能和需求相關(guān)的分支和替代方案將被全面描述并附上相關(guān)細節(jié)，以提高研發(fā)質(zhì)量和簡化測試。\\t

更好的性能。作為前兩個好處的結(jié)果，整個團隊的表現(xiàn)會更好，因為用戶或測試人員報告的用戶描述執(zhí)行的錯誤少了。性能也更好了，因為不需要浪費時間進行解釋，更多的任務(wù)能按時完成，用戶用例不會無法實現(xiàn)。\\t

每一個需求、過程或功能都歸檔整理。當(dāng)運作一個大的項目時，要同時開發(fā)不同的模塊，涉及復(fù)雜的功能和成千上萬的用戶與多個用戶角色，多方面溝通，使業(yè)務(wù)分析師不可能記住每一個項目細節(jié)。有了標(biāo)準(zhǔn)化需求，他們可以簡單地搜索每一個問題的答案，包括作為一個單獨的案例或案例步驟的用戶描述。\\t

更好的終端產(chǎn)品。為每個功能在JIRA加入統(tǒng)一描述后，不僅可以幫助項目新人，而且內(nèi)部運作的全面描述和理解也有助于全體成員對系統(tǒng)本身的整體理解。\\t

節(jié)省溝通時間。特別是當(dāng)涉及到外包項目時，往往還有時間差異，每個人都會得益于它能使研發(fā)沒有障礙和瓶頸。\\t

更高的開發(fā)質(zhì)量。總體研發(fā)質(zhì)量更高，因為每個人都以同樣的方式無歧義地理解需求。因為估算更簡單，進度規(guī)劃也更容易。\\t

更容易修改需求或場景。如果花足夠的時間寫詳細的需求，那么，修改它們更是毫不費力。業(yè)務(wù)分析師澄清和描述需求的投入將會在整體上節(jié)省時間和金錢。\

標(biāo)準(zhǔn)化與測試

\\

需求標(biāo)準(zhǔn)化可以讓測試人員更容易了解系統(tǒng)、系統(tǒng)功能和模塊。測試變得更順暢，因為接受的案例覆蓋所有的功能性流程的細節(jié)。因此，他們的時間可以更多花費在測試上，而不是學(xué)習(xí)了解這個系統(tǒng)。如果有功能某方面遺漏，測試人員也可以提醒開發(fā)者及產(chǎn)品經(jīng)理，進一步完成需求描述完整。

\\

此外，詳細的描述縮小了功能或模塊上的信息，因此測試人員明白，如果某東西設(shè)想要運作得和需求描述一樣，那么它必須不差分毫地實現(xiàn)。必須減少基于個人的意見或觀點的誤解和曲解的情況發(fā)生。

\\

管理不斷變化的需求

\\

對于沒有文檔的項目，在JIRA中保留用戶描述，對未來項目業(yè)務(wù)分析師、開發(fā)團隊和加入項目的其他人都是安全保障。如果需要改變系統(tǒng)過程的任意部分，這很容易。這是因為在JIRA中有全面的關(guān)鍵字搜索功能，你可以在特定的案例中發(fā)現(xiàn)需求并且看看需要考慮哪些案例。

\\

同時，在這個特殊的項目，當(dāng)對最重要的功能實施額外測試的時候，可靠的和感興趣的用戶將被指派為JIRA相應(yīng)任務(wù)的“觀察員”。他們將進行驗收測試，以了解該功能是否可理解，以及在發(fā)布之前它被完全正確地實施。他們將從一開始就盯著這一任務(wù)，所以他們可以跟蹤需求發(fā)生了什么變化，一旦創(chuàng)建需求，他們檢查它的描述，并讓業(yè)務(wù)分析師和產(chǎn)品經(jīng)理知道是否需要更新。從接受案例的角度描述需求，這有利于他們明確自己到底需要什么，并確保描述不會模棱兩可。

\\

結(jié)論

\\

合理地統(tǒng)一需求描述格式與項目的成功密切相關(guān)。迭代過程變得更容易，更少出現(xiàn)錯誤和延遲，每一步都給整個系統(tǒng)增加了價值。團隊獲益于更簡單的時間安排，從而獲得更快的發(fā)展，這對可能缺乏資源的大型項目更為關(guān)鍵。

\\

就我們的項目而言，企業(yè)的股東受益于良好的預(yù)算，這些預(yù)算不是浪費在修補漏洞上，而是致力于實現(xiàn)預(yù)期的新功能。標(biāo)準(zhǔn)化需求描述的實施使整個項目運行更為順利，使團隊能夠快速地提供新的功能模塊和功能，同時也滿足了所有的期望，最終用戶高興，股東滿意。

\\

作者簡介

\\

Elena Belkovskaya畢業(yè)于白俄羅斯州立大學(xué)，獲經(jīng)濟學(xué)學(xué)位。在加入Itransition之前，她是一名經(jīng)濟學(xué)家。在Itransition，她是業(yè)務(wù)分析師。她使用瀑布模型和敏捷方法將七年的經(jīng)驗用于信息技術(shù)。在她的工作中，Elena有效地將其良好的分析能力運用于在企業(yè)項目生命周期的所有階段，包括需求開發(fā)和管理、功能和培訓(xùn)文檔、業(yè)務(wù)分析規(guī)劃和估算、項目需求現(xiàn)場和遠程通信以及系統(tǒng)的設(shè)計問題等。她熱衷于通過培訓(xùn)課程和參與領(lǐng)先的行業(yè)會議來提高她的技能。

\\\\

閱讀英文原文：Standardizing Requirements Descriptions on Scrum Projects for Better Development and Testing Quality

總結(jié)

以上是生活随笔為你收集整理的为提高研发和测试质量而规范Scrum项目需求描述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。