为提高研发和测试质量而规范Scrum项目需求描述
關鍵點
\\- 不規范的需求描述會對項目產生不利影響。\\t
- 某項目需求描述標準化前后的狀態比較。\\t
- 需求描述統一的八大好處。\\t
- 標準化對測試過程的積極影響。\
業務分析人員之間會經常討論需求的描述格式。在這篇文章中，我將分享我在這方面的經驗。我最近有一個項目。在這個項目中，所有需求描述采用了某種標準化格式。這不僅改善了測試人員和開發人員的體驗，提高了團隊的生產力，而且建立了更有效的項目流程。
\\沒有標準的需求描述隱患
\\新員工。當產品經理管理需求的時候，他們經常沒有分配足夠的時間來合理地描述這些需求。這主要是因為時間緊迫而馬上需要開始研發的壓力又十分巨大，亦或是產品經理缺少能以恰當方式整理需求的必要技能。無論如何，研發能否順利開展都取決于研發團隊的經驗和相關應用經驗。但是，當新專家參與項目時，會發生什么事情？合適的文檔可以無縫地向新團隊成員介紹這個項目和正在研發的產品以及服務。這對于大型長期項目尤為重要。因為缺少這樣文件會到導致項目運行過程中遭遇更多嚴峻的挑戰。
\\估算。如果需求是以一種隨意的方式進行描述，沒有互相理解的規則和明確的標準，當出現無法回答的問題時，需求就無法被估算。萬一有遺漏，而開發人員已經開始研發，那么就會出現瓶頸時期，浪費時間而且延誤開發。
\\時間安排。沒有規范的需求描述，我們將難以創建可以持續執行的可靠的項目計劃。當產品經理跳過詳細的需求文檔工作，開發的質量會由于更多的漏洞和需要時間去修復它們而大打折扣，使得功能的實現需要比預計更長的迭代時間。
\\Scrum項目規范需求描述前后
\\規范需求描述對研發的直接影響可以從下面這個例子看出來。某大型的社交媒體公司擁有好幾個數以百萬計客戶的熱門網站。這是一個快速發展的敏捷項目，股東設定下很高的市場目標，現有的文檔被壓縮到只為用戶和開發目標提供服務。股東對數百頁文檔的創建和維護壓根不感興趣，而這恰恰是大多數敏捷項目有用而且常見的做法。
\\客戶已經有了他們自己的開發團隊和許多雄心勃勃的計劃，但需要更多的資源來實現它們。因此，他們需要額外新的研究人員、分析師和開發人員的團隊支持，將來還有增加QA（質量保證）專家的計劃。
\\當新的團隊聚集在一起時，產品經理的時間安排使他們能更專注于業務的發展方向、戰略和與企業主進行談判，而新項目領導能夠開始為研發和確保質量準備徹底的、結構化的、完整的需求描述。
\\全球范圍內分布的團隊：一部分研發團隊在美國不同的州，另一部分是在明斯克。企業所有者和產品經理居住在美國，而用戶則散居美國各個時區。由于所有團隊成員間頻繁和有效的溝通是項目重要的一環，時間差異讓溝通變得更復雜。
\\在標準化需求描述之前
\\在實施標準化需求描述之前，用例的描述沒有任何特定的格式：需求不夠詳細；案例缺失或案例太短；總體來說，缺少足夠的開發人員。這導致了一些負面的后果，包括：
\\估算困難。在培訓會議期間，問題出現了，在問題得到回應之前，都沒有估算充足時間的辦法。
\\問題和差距。在開發和測試階段，您可能會發現一些重要的方面沒有考慮實現功能（例如，遺忘了某些場景、異常流程等）。
\\浪費時間和精力。在這一點上，整個團隊的有效性會受到影響：沒能完成預計的任務，因為它們沒有包含實施額外的需求；任務可能無法在迭代結束前完成；由于延遲推出新功能，用戶不滿意。此外，還需花費更多的時間向相關領導解釋為什么需求缺失和為什么開發團隊需要重復實施功能和測試任務。
\\標準化的需求描述后
\\為了改善這種情況，研發團隊開始使用“經典”需求表達語句的標準描述方法：
\\\“作為一個\u0026lt;用戶角色/類型\u0026gt;我要\u0026lt;一些功能\u0026gt;，以便\u0026lt;從這個功能中受益\u0026gt;”
\\\此外，以下模板的基礎上，使用接受案例，：
\\\接受案例1：\------\\假設（某些上下文/前提條件）\和（一些更多的上下文/前提條件）\當（由用戶執行的事件/行動）\然后（預期的結果-根據上述用戶用例，什么應該發生以滿足用戶的需求）\\接受案例2：…\-------\\\項目一開始，團隊新開發人員都要從學習新的系統開始，他們不會只獲得一個簡短幫助說明，比如“當審批在隊列中的影響因素時，系統應在儀表板發出警告。”
\\引入上述格式的結果就是開發人員和質量保證工程師獲益于詳細的步驟和相關頁面的鏈接的完整描述。這顯著減少了問題的數量，并且關于“質量”和相關指標的要求都由于記錄詳細而變得清晰。
\\當然，在需要的情況下，我們可以在提供用戶的描述和接受案例的同時，提供支持性的東西。這些包括UI模型來說明在UI的變化、設計規范中變化影響最終用戶接口和多個圖表等。在大多數情況下，圖表都是用來說明過程中的變化的，并向整個團隊展示由于執行一系列用戶描述，系統模塊需要做什么全局性改變。
\\有主要接受案例的用戶描述項目案例：
\\作為一個客戶服務經理，我想能夠從搜索結果中排除已經被調查的人員，以便我容易區分用戶是否已經加入調查，并迅速將新登記的用戶加入每日調查。
\\\接受案例*：客戶服務經理將某些人排除在被調查成員之外\\假設客戶服務部經理進行調查，他/她希望邀請新用戶\并有用戶已經被邀請到本次調查\有新的用戶還沒有被邀請\當客戶服務經理勾選“排除已參與調查成員”框，并應用過濾器\然后顯示的用戶列表不應該包括已被選中的要過濾的用戶。\\\*上述案例成為三個現有案例中選出的最重要的一個案例，以便創建用戶描述以確保全面覆蓋。
\\統一需求描述的好處
\\標準化與測試
\\需求標準化可以讓測試人員更容易了解系統、系統功能和模塊。測試變得更順暢，因為接受的案例覆蓋所有的功能性流程的細節。因此，他們的時間可以更多花費在測試上，而不是學習了解這個系統。如果有功能某方面遺漏，測試人員也可以提醒開發者及產品經理，進一步完成需求描述完整。
\\此外，詳細的描述縮小了功能或模塊上的信息，因此測試人員明白，如果某東西設想要運作得和需求描述一樣，那么它必須不差分毫地實現。必須減少基于個人的意見或觀點的誤解和曲解的情況發生。
\\管理不斷變化的需求
\\對于沒有文檔的項目，在JIRA中保留用戶描述，對未來項目業務分析師、開發團隊和加入項目的其他人都是安全保障。如果需要改變系統過程的任意部分，這很容易。這是因為在JIRA中有全面的關鍵字搜索功能，你可以在特定的案例中發現需求并且看看需要考慮哪些案例。
\\同時，在這個特殊的項目，當對最重要的功能實施額外測試的時候，可靠的和感興趣的用戶將被指派為JIRA相應任務的“觀察員”。他們將進行驗收測試，以了解該功能是否可理解，以及在發布之前它被完全正確地實施。他們將從一開始就盯著這一任務，所以他們可以跟蹤需求發生了什么變化，一旦創建需求，他們檢查它的描述，并讓業務分析師和產品經理知道是否需要更新。從接受案例的角度描述需求，這有利于他們明確自己到底需要什么，并確保描述不會模棱兩可。
\\結論
\\合理地統一需求描述格式與項目的成功密切相關。迭代過程變得更容易，更少出現錯誤和延遲，每一步都給整個系統增加了價值。團隊獲益于更簡單的時間安排，從而獲得更快的發展，這對可能缺乏資源的大型項目更為關鍵。
\\就我們的項目而言，企業的股東受益于良好的預算，這些預算不是浪費在修補漏洞上，而是致力于實現預期的新功能。標準化需求描述的實施使整個項目運行更為順利，使團隊能夠快速地提供新的功能模塊和功能，同時也滿足了所有的期望，最終用戶高興，股東滿意。
\\作者簡介
\\Elena Belkovskaya畢業于白俄羅斯州立大學，獲經濟學學位。在加入Itransition之前，她是一名經濟學家。在Itransition，她是業務分析師。她使用瀑布模型和敏捷方法將七年的經驗用于信息技術。在她的工作中，Elena有效地將其良好的分析能力運用于在企業項目生命周期的所有階段，包括需求開發和管理、功能和培訓文檔、業務分析規劃和估算、項目需求現場和遠程通信以及系統的設計問題等。她熱衷于通過培訓課程和參與領先的行業會議來提高她的技能。
\\\\閱讀英文原文：Standardizing Requirements Descriptions on Scrum Projects for Better Development and Testing Quality
總結
以上是生活随笔為你收集整理的为提高研发和测试质量而规范Scrum项目需求描述的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Word2007文档数字如何批量替换为图
- 下一篇： DRBD安装配置