應用生成式人工智慧進行敏捷計劃
生成式人工智慧 (Generative AI) 最終將從計劃到操作影響整個 DevOps 生命週期。我起初是一名開發者，但在職業生涯的大部分時間內擔任產品經理；對我而言，「DevOps 的聖杯」將是一個產品經理 (PM) 和業務分析師 (BA) 能夠定義未來的業務流程狀態，並按下按鈕即可完成交付，而不需要涉及任何開發人員、設計師或測試人員。
這個夢想在短期內並不切實際，而且從長遠來看也並不可取。PM 和 BA 擅長理解用戶需求並將其轉化為功能，但並非互動設計師。人工智慧可能能夠生成程式碼和測試，但兩者的軟體架構仍需要對系統有深入的了解以正確構建解決方案，尤其是在企業級 SaaS 開發中。因此，我的夢想是建立一個團隊，讓 BA 可以定義變更，而一小部分非常有才華的架構師和互動設計師團隊能夠在不需要大型團隊實施細節的情況下，在目前所需時間的 10% 內實現這些變更。這與製造業類似，其中機器人和數控機床能夠在操作員的幫助下完成重型工作。
計劃是關鍵
當生成式人工智慧實際構建解決方案時，良好的計劃將成為成功的關鍵。一份有良好記錄且經過深思熟慮的計劃將使人工智慧能夠完成大部分繁重的工作。因此，夢幻團隊的主要重點應該是確保計劃正確並在適當的細節層次上進行文檔化。就像我 20 年前由我的第一位敏捷教練所教導的那樣，當談到文檔時，你需要恰到好處的適時。
在像Salesforce和 ServiceNow 這樣的企業 SaaS 平台中，業務從一個新實施的系統開始，然後逐步自訂此軟體以更好地滿足其需求。因此，我們不應該考慮從零開始建立系統，而是將數字轉型視為隨時間的推移對現有系統的持續改進。這意味著人工智慧必須從好的模型開始，包括：
- 現有的業務流程
- 系統的元數據配置和
- 設定之間的相依性
在新世界中的開發
這在實際中意味著什麼？讓我們來看一天夢幻團隊的生活。
BA 將從高層次告訴人工智慧所需的變更。人工智慧將通過填補缺失的細節來幫助細化需求。這將通過擴展、細化和總結的迭代過程進行，直到需求明確定義。就像現在源碼的 Lint 工具檢查一樣，人工智慧將檢查需求，以確保用戶故事完整，並且接受準則明確定義。在此過程中，人工智慧將進行詳細的相依性和影響分析，以在出現任何不必要副作用時向 BA 發出警告。
這個細化過程將更像是 BA 與人工智慧之間的對話，而不是單向的撰寫過程。經過多次迭代後，將創建一套完整的用戶故事，其中包含所有必要的細節。
一旦需求完成，BA 將與用戶互動設計師和軟體架構師一起工作。
互動設計師將通過自然語言描述新流程和功能原型的結合來定義互動規格。通過與生成式人工智慧的互動，這兩個元素將被創建並進行改進。原型將不再僅僅是由前端工程師編寫的簡單圖形工件。人工智慧將通過口頭要求和傳統的點擊方式，在您選擇的框架中即時生成一個可運行的原型。
他們將審查計劃並開始設計解決方案的架構，這將產生一份自然語言軟體規格，其中記錄了數據模型更改和組成解決方案的類別的高層次規格。可以預期數據模型更改將在開發環境中隨需求創建，並更新實體關係圖以反映新模型。
根據變更的類型，架構師和互動設計師可能會協作並迭代規格，直到「如何」被完全定義。當設計準備就緒時，夢幻團隊將會開會審查設計並批准方案。
生成和迭代
一旦計劃獲得批准，就該是人工智慧生成初步解決方案的時候了。我們希望並期望生成解決方案只需數分鐘。在這種情況下，夢幻團隊可以休息一下，然後回到會議室審查工作中的解決方案。
沒有什麼比實際使用解決方案來提醒您忘記的邊際案例或實際使用新功能時的繁瑣感更好了。但這沒關係，因為團隊可以快速更新需求以應對這些變更，然後再次按下生成按鈕。
實際上，他們可以盡情地進行調整。但就像所有偉大的藝術家一樣，他們必須決定何時足夠好以進行交付。
在短期內，我們將無法盲目依賴生成式人工智慧，因此架構師將不得不像今天與初級開發人員一樣進行程式碼審查。同樣地，人工智慧可能無法理解系統中的所有可能相依性。因此，在過渡期間，該過程將是半自動的。
最終，兩週的冲刺概念將顯得過時，每天定義並推出生產將變得司空見慣。夢幻團隊的成員將花更多時間擔心設計的高可用性和效能，而不是與實際實施奮鬥，這應該使他們的工作更加有價值，並且工作成果更好。我期待著這一天的到來。
