需求審查的挑戰 - modernanalyst
如果有人說您只能對一個軟體專案執行一次質量實踐,您會選擇什麼?我會選擇對需求進行同行評審,我認為這是我們今天可用的最高槓杆質量實踐。
在同行評審中,工作產品的作者以外的其他人檢查產品的質量問題和改進機會。審查需求是一項強大的技術。使用它們來識別模稜兩可或不可驗證的需求,查詢尚未足夠詳細的需求,找出需求之間的邏輯衝突,並揭示許多其他問題。
同行評審最有效的型別是稱為檢查的結構化過程。需求檢查是可用的最高槓杆軟體質量技術之一。幾家公司報告說,他們在檢查需求文件和其他軟體可交付成果上投入的每一小時可避免多達十個小時的人工。誰不想嘗試可能提供1000%投資回報率的技術?
同行評審既是技術活動,也是社會互動。讓一些同事告訴您您的工作出了什麼問題是一種學問而不是本能的行為。軟體組織需要一些時間才能將同行評審引入其文化。
本文改編自我的書(與Joy Beatty一起編寫),第3版軟體需求,指出了進行需求評審時遇到的一些常見挑戰,以及有關如何解決每個挑戰的建議。有關進行審查和檢查的更多資訊,請參見《軟體中的同行審查:實用指南》一書。
大型需求檔案
徹底檢查長的需求文件的想法令人生畏。您可能會很想完全跳過審查,而只是著手進行構建實現,相信需求是正確和完整的,這不是明智的選擇。即使中等大小的文件,所有審閱者也可能會仔細檢查第一部分,並且有一些專家會研究中間部分,但可能沒有人會關注最後一部分。
為了避免使稽核團隊不知所措,請在整個需求開發過程中執行增量稽核。在敏捷專案上,花一些時間在每次迭代期間檢查需求。即使您使用的是非正式需求方法,將一些頭腦聚集在一起以確認理解,尋找隱藏的假設並確保已解決所有異常始終是一個好主意。使用檢查對高風險區域進行仔細檢查,對風險較小的材料進行非正式檢查。您可能會要求某些審閱者從需求集中的不同位置開始,以確保新鮮的眼睛注視著每個部分。
要判斷您是否真的需要檢查整個需求集,請仔細檢查代表性樣本。發現的錯誤的數量和型別將幫助您確定對全面檢查進行投資是否可能會有所回報。當然,即使您的樣本看起來不錯,您也無法確定其餘部分可能隱藏的問題,因此那裡仍然存在一些風險。
大型稽核團隊
許多專案參與者和客戶都對需求有興趣,因此您可能有一長串潛在參與者來進行需求審查。但是,大型的稽核團隊會增加稽核成本,難以安排會議,並且很難就問題達成協議。我曾經參加過有十四位審稿人的會議。14個人以離開表示不同意,更不用說就某個特定需求是否正確達成共識。嘗試以下方法來與可能龐大的檢查團隊打交道:
- 確保每個參與者都在那裡發現缺陷,而不是受教育或保護政治立場。
- 瞭解每個檢查員代表哪個角度(例如使用者,開發人員或測試人員)。代表同一社群的幾個人可以集中他們的意見,只派一位代表參加檢查會議。
- 建立幾個小組,以並行檢查需求,併合並其缺陷列表,刪除所有重複項。多項研究表明,與單個大型團隊相比,多個檢查團隊發現的需求缺陷更多。這種並行檢查的結果主要是累加的,而不是多餘的。
- 召集一個由四到七個人組成的小型檢查小組,但要事先將所需條件提供給其他有興趣的利益相關者,這樣他們就有機會貢獻自己的意見。
地理位置分開的審稿人
如今,地理位置分散的團隊經常合作來開發產品。這使評論更具挑戰性。電話會議不會像面對面會議那樣顯示其他審閱者的肢體語言和表情,但是視訊會議可以是一種有效的解決方案。Web會議工具使審閱者可以確保他們在討論期間都在看相同的材料。
放置在共享網路儲存庫中的電子文件的審閱提供了傳統審閱會議的替代方法。在這種非同步審閱方法中,審閱者使用文書處理器功能將其評論插入文字中。每個評論都貼有評論者的姓名縮寫,並且每個評論者都可以看到以前的評論者必須說的話。基於Web的協作工具也可以提供幫助。一些需求管理工具包括一些元件,這些元件可以促進不涉及實時會議的分散式非同步審閱。
如果您選擇不舉行會議,請認識到這會降低稽核的有效性。各種研究表明,在審閱會議中,參與者之間的協同作用和討論通常會觸發一些想法,這些想法會發現在個人準備過程中沒有發現任何個人審閱者的缺陷。不過,非同步檢查肯定比根本不執行檢查更好。只是不要讓以文書處理器註釋形式的辯論代替彼此交談。
跨距離的協作通常涉及在不同文化中,有時在不同國家工作的人們。不同的文化對評論有不同的態度。例如,在某些文化中,人們很難對別人的作品進行批判性觀察。結果,他們可能在稽核會議上什麼也沒說。這是避免傷害他人情緒的好方法,但不是使工作產品更好的好方法。請注意這種文化差異,並嘗試建立安全的環境(例如,無會議非同步審閱),以使人們提出潛在的缺陷而不會令任何人感到不適。
沒有準備的審稿人
正式審查會議的前提條件是參與者提前檢查了正在審查的材料,並確定了他們想提出的最初問題。如果沒有這種準備,您可能會冒著使人們花費會議時間在現場進行所有思考的風險,並且可能會遺漏許多重要問題。實際上,如果您被邀請參加需求審查並且沒有足夠的時間自行事先閱讀材料,那麼甚至不必費心參加會議。浪費每個人的時間。
一個專案有50頁的需求規範,需要15個人進行審查(小組太大,無法有效地進行工作)。審閱者有一週的時間自行檢查文件,並將問題傳送回作者。毫不奇怪,大多數人根本沒有看過它。因此,首席業務分析師安排了一次強制性會議,以使檢查員共同審閱該文件。
BA將SRS投射在螢幕上,調暗燈光,並開始逐一閱讀要求。(房間中間有一個非常明亮的燈,直接射在主角BA上–談論成為聚光燈!)進入稽核會議幾個小時後,與會人員打著哈欠,注意力逐漸減弱。毫不奇怪,問題發現的速度下降了。每個人都渴望會議結束。BA最終讓與會人員離開,建議他們按自己的時間審閱文件,以加快下一次審閱會議的速度。毫無疑問,會議期間的無聊觸發了他們下一次的準備工作。
讓評審為您服務
審查需求並不是每個人都樂在其中。同行評審可能是乏味且耗時的,有時甚至是壓力大的。但是,如果您認真考慮要最大程度地提高軟體質量,您的團隊將使用更正式的檢查仔細檢查最關鍵或容易出錯的部分,以複審他們的所有要求。我的一般規則是:“及早,經常,正式和非正式地進行稽核。”
我知道已經透過需求檢查的團隊同意,他們花費的每一分鐘都是值得的。使用本文中的建議可以幫助您的團隊最大化他們在需求審查中的投資回報率。
相關文章
- 需求與規範的區別 - modernanalystNaN
- 北京益行公益:疫情下NGO的挑戰與需求調查報告(附下載)Go
- 微服務:服務化框架落地的挑戰和核心需求微服務框架
- 同行程式碼審查的實戰經驗行程
- 同行程式碼審查實戰分析行程
- NFR非功能性需求為什麼很重要? - modernanalystNaN
- 軟體測試的需求評審
- AI的道德挑戰AI
- 挑戰系統 / 進入區域挑戰怪物
- AI輔助需求規格描述評審AI
- 採用Scrum的挑戰Scrum
- Java面臨的挑戰Java
- 信用行業的挑戰行業
- 守衛者的挑戰
- 合同審查系列之:買量推廣合同的核心審查要點
- 程式碼審查
- 減輕敏捷實戰中故事點發生漂移的風險 - modernanalyst敏捷NaN
- Flutter的強制自我審查Flutter
- 程式碼審查“查”什麼?
- 中國新成立”網路安全審查委員會”審查些什麼?
- 賽事分為 “完全破解”以及“查詢漏洞”兩個挑戰
- ERP實戰演義之二 總體需求調查(轉)
- 程式碼審查工具
- 程式碼審查“查”什麼?(1)
- 程式碼審查的重要性
- 中國的網際網路審查
- 開發者眼中的程式碼審查“真相”
- 程式設計挑戰程式設計
- 測試人員如何做需求評審?
- 程式碼審查或評審的最佳實踐 - FogBugz
- 遊戲的戰略(二)——選擇性的戰略與落地的挑戰遊戲
- 克服物聯網部署的挑戰
- 量子計算:聰明人的挑戰
- 程式設計師的最大挑戰程式設計師
- 檢查軟體需求
- 程式碼審查“查”什麼(3):效能
- 程式碼審查過程
- 敏捷程式碼審查指南敏捷