生成式 AI 的潛在應用場景似乎無窮無盡。雖然這令人興奮，但也可能讓人不知所措。因此，團隊在使用這項技術時需要有明確的目標：關鍵是要明確生成式 AI 在團隊工作中能產生哪些實質性影響。
在軟體工程中，一個引人注目的應用場景是需求分析。這是一個常常被忽視但充滿挑戰的環節，如果處理不當，可能會帶來許多負面的後續影響。
本文描述了我們與一位客戶進行的試點專案，我們的團隊驗證了一個假設，即利用生成式 AI 建立高質量的使用者故事可以縮短交付週期並提高需求分析的質量。在這個案例研究中，我們驗證了這一假設，並解釋了我們做了什麼以及得出了哪些結論。
方法
確定範圍和目標
在選定該團隊作為試點後，我們與他們舉辦了一次研討會，確定哪些任務可以透過 AI 支援。我們還與他們合作，定義了使用 AI 可能帶來的影響。研討會達成了兩個主要目標：
1. 找出適合 AI 支援的任務
團隊討論了他們經常進行且伴隨一定難度的任務。隨後，他們選擇了部分高價值且 AI 可行性較高的任務。其中一個被選中的任務是需求分析，因為團隊的工作領域相對複雜，開發過程中常常因需求被誤解或遺漏邊緣情況而返工。
2. 定義假設和預期結果
在研討會的第二步，團隊定義了使用 AI 期望實現的目標。以下是需求分析的假設：
| 我們相信，使用生成式 AI 來輔助... | ...將導致... | 我們知道它有價值的標誌是... | 需要監控的風險 |
|---|---|---|---|
| 撰寫史詩和使用者故事 | — 減少後續流程中的返工— 更好地滿足“完成定義”中的標準— 縮短交付時間 | — 縮短交付時間（從“分析開始”到“完成”）— 開發人員對故事的反饋更好— 開發人員的問題和澄清減少— 被阻塞的故事減少— 待辦事項列表始終保持充足— 測試中發現的遺漏需求減少 | — 範圍蔓延（AI 提供過多的想法）— 故事冗長，團隊迷失在細節中 |
實施
我們利用服務工具包中的加速器幫助實施 AI 支援。HaivenTM 團隊助理 是我們與客戶合作時使用的一個加速器，它為軟體交付團隊提供了一個試點生成式 AI 支援的精簡方式。在該專案中，它為使用者提供了整合上下文資訊和可重用提示詞的 AI 功能。
團隊的業務分析師（BA）和質量分析師（QA）是主要的工具使用者。他們在各自領域都有豐富經驗，並在該團隊工作了很長時間。在這次試點中，他們使用該工具將三個新的史詩需求分解為使用者故事。每個史詩都是關於為現有功能增加額外能力的。
收穫
上下文是關鍵！
其中一個關鍵收穫是團隊需要為 AI 提供多少上下文資訊才能讓其發揮作用。Haiven 在這方面非常有幫助，因為它允許使用者定義可重用的上下文描述，每次與 AI 互動時都可以呼叫。這意味著他們不必每次都重複相同的上下文資訊。
正如我們之前提到的，團隊的工作領域相對複雜，史詩的目標是擴充套件現有功能。因此，他們最初花了一些時間向 AI 描述領域和架構，以便每次與 AI 互動時能夠重複利用。這些上下文描述既提供了邏輯和領域語言的總體描述，也明確了當前功能的工作原理，幫助 AI 進行功能擴充套件的支援。
這種方法顯著提高了結果質量，但也表明，在他們的情況下，前期投入是必要的。類似程式設計助手，使用 AI 修改現有需求比從頭設計新功能要困難得多。
使用者需要時間適應 AI 支援
最初，使用者在如何有效地與 AI 互動方面遇到了困難。瞭解大語言模型（LLM）響應的非確定性並理解其影響需要一個學習過程。隨著時間推移，使用者調整了對 AI 的期望，逐漸適應了將 AI 作為助手，而不是一個能夠提供完美結果的軟體。他們還學會了如何在聊天對話中讓 AI 糾正方向，當初始輸出不準確時進行調整。
開發人員經常報告在使用程式設計助手時會出現“審查疲勞”，因此我們也詢問了 BA 和 QA 對審查 AI 輸出的感受。他們表示審查這些場景並不太繁瑣，至少在他們的經驗水平下是如此。
很難定量衡量影響
我們發現，衡量 AI 在需求分析中的影響比在程式設計中的影響更難。
- 這些任務不像程式設計那樣頻繁，因此對它們的改進難以單獨量化。
- 史詩比使用者故事或技術任務更難比較，因此難以與歷史資料直接對比。
- 需求分析質量的一個指標是故事在流程中被阻塞或反覆返回的次數，因為不完整或不清晰。這類資料通常不會非常細緻地跟蹤，因為那樣會讓流程和任務看板過於複雜。
儘管如此，無法定量衡量並不意味著它沒有價值！以下關於質量和速度的觀察基於 AI 使用者在該案例中的估計。
對質量和團隊流程的影響
重申一下，假設的一部分是使用 AI 進行需求分析會縮短交付週期，減少返工，並減少因進一步澄清而被阻塞的故事。
業務分析師報告說，由於他們的準備更加高效和全面，AI 助手使他們在與開發人員討論時更加自信。他們能夠回答開發人員在估算會議中提出的問題，不必再進行需求填補。
質量分析師發現，一旦上下文明確，AI 生成的驗收標準和測試場景比他們自己生成的要好。當他們開始測試開發人員的工作時，發現的 bug 和返工原因減少了大約 10%，因為使用者故事定義更好地涵蓋了邊緣場景。
對分析速度的影響
雖然三個史詩的樣本量不足以得出明確結論，但團隊估計分析時間減少了約 20%，儘管建立上下文花費了一定時間。隨著上下文建立的最佳化和上下文的重複
使用，未來的時間節省預計會更為顯著。
結論與展望
總之，這項案例研究表明，AI 能夠在質量、速度和整體團隊流程上帶來好處。在該組織中，下一步是將這種方法應用於其他團隊，這些團隊的經驗水平和流程有所不同，以驗證是否能重複這些收穫，並進一步提高效率。
這項經驗以及其他 AI 在軟體團隊中的使用經驗再次證實了上下文編排的重要性。
-
上述團隊工作在相對複雜的領域，他們發現，只有在為 AI 提供了詳細的領域上下文描述後，AI 才真正有用。對於那些在電子商務或客戶資料管理等常見領域工作的團隊，這一障礙要低得多，因為這些領域的模型訓練資料通常能廣泛適用於相關用例，而無需額外的引導。
-
Haiven 支援半手動的上下文編排，並允許重複使用上下文描述：團隊將領域描述作為提示詞的一部分，併為助理應用程式編制了相關維基文件的索引。雖然這需要一些設定工作，但它仍然是探索 AI 潛力的精簡方式。然而，我們密切關注軟體工具市場的創新，以實現更加自動化和智慧化的上下文編排，從而為客戶提供最佳建議，幫助他們充分利用 AI。
-
程式碼庫是應用程式工作原理的最終真實資訊。它始終比可能過時或不準確的文件或描述更可靠。在本案例研究之外，我們已經與客戶一起探索了為 AI 提供程式碼庫上下文的有趣而強大的方式，這使得使用者能夠在不需要理解或瀏覽程式碼的情況下提出問題。儘管該團隊在此次試點中未使用此類工具，但其潛力顯而易見，尤其是在指定現有功能的更改時。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
- LLM Agent應用開發
- 區塊鏈應用開發
- 大資料開發挖掘經驗
- 推薦系統專案
目前主攻市級軟體專案設計、構建服務全社會的應用系統。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！