駕馭敏捷航道:為何整合Copilot需要調整方法

美國國會近日禁止其員工使用微軟的AI助理Copilot,這是一款整合了大型語言模型的聊天機器人,可為微軟的Word、Excel、PowerPoint、Outlook和Teams等產品提供自動化功能,其中的安全疑慮是主因。這種觀點並非孤例,許多專業人士在面對AI時,既興奮又憂心忡忡。與此同時,微軟自信地推崇Copilot,承諾其AI的力量將減輕企業日常運營的負擔。該公司已從僅談論AI,轉為將其融入技術棧的每一層。其最新推出的Copilot Runtime甚至允許開發人員在自己的程式中使用AI,因此大多數資訊長正在試驗Copilot也就不足為奇了。它對於提高生產力的承諾,以及由此而來的範疇擴展和成本效益,實在太誘人而不容忽視。微軟無疑是以身作則,唯一的問題是其他人應該如何效仿。

在過去十年中,敏捷組織在做出決策和管理決策方面,表現優於其他組織。IT領域的敏捷採用,改變了基礎設施、應用程式、數據和技能的生產、消費或兩者兼而有之的方式。敏捷的基礎要素,如協作、自動化和持續改進,都是與應用程式開發和部署相關的創新關鍵來源。

然而,一些近期事件干擾了IT領域的敏捷進程。COVID時代帶來的工作彈性,無論是如何、何時或在何處工作,都在挑戰我們協作方式的現狀。此外,生成式AI及其對IT管理的複雜性,也動搖了敏捷的進展。因此,形成了一種增量經濟,迫使每家公司更加重視機會和挑戰。

分散式敏捷實踐已有一段時間了。遠端和混合工作的現實,只不過是分散式團隊的延伸。然而,Copilot等工具對於提高生產力的承諾則是全新的,因此假設目前的敏捷實踐也適用於生成式AI的做法是錯誤的。那麼我們該怎麼做呢?

以下是一些在採用Copilot時,整合敏捷方法論的想法:

擴展DevOps,納入DataOps和MLOps的代表
鑑於數據以及AI和機器學習模型的重要性,DevOps團隊必須包括DataOps和MLOps團隊(ModelOps是MLOps的子集)的代表。只有這樣,才能實現將”生產”和”運營”更緊密結合的目標。乍看之下,取代或許是AI最大的威脅,但它的第一步行動很可能是揭露並加深協作中的裂痕。

軟體智能比以往更為重要
在生產環境中自動生成代碼之前,若未全面了解應用系統,將是一場災難。企業IT是AI和非AI應用程式與IT資產的混合體。此外,只有獲得對生成式AI所產生代碼的軟體智能,才能實現”可解釋性”。從根本上說,最重要的不是功能的正確性,而是架構的適切性,這是解鎖生產力提升的關鍵。AI步伐飛快,但若讓速度優先於一切,註定會失敗。

持續合規和持續安全同樣重要
生成式AI工具的主要疑慮之一,是自動生成的代碼可能為企業IT帶來的漏洞,這也是美國國會禁止使用Copilot的主因。重要的是,要在Pod層級進行適當的調整,以持續設計和交付合規性和安全性,而非定期審核和確保。法規通常落後於創新,公司必須有意超前部署,以避免日後遭受痛苦。

為CI/CD管線中的AI助手增強質量關卡
開源的創始原則——透明度、檢查和調整——可擴展到生成式AI產品。”檢查”不僅應涵蓋工具所提供代碼的質量、性能、安全性和用戶體驗等方面,還應考慮其在企業IT中的架構適切性。

衡量成功,並坦白缺陷
AI的影響或許模糊不清,但為了證明其採用的合理性,部分結果必須是可衡量的。制定AI特定的關鍵績效指標,有助於鞏固Copilot在團隊中的角色。找到合適的衡量指標本身就是一大挑戰。

在詳細審視AI影響的過程中,坦白承認缺陷也很重要。系統本質上難免有缺陷,需要追蹤並解決這些缺陷。由於AI發展如此迅速,許多問題很可能在短期內得到解決。記錄下這些缺陷,並有意按規律間隔重新審視。

技能不匹配將影響生產力的承諾
工具的好壞取決於使用者的能力。有經驗的開發人員可以透過AI助手展現超乎平均的生產力水準,但是沒有經驗的開發人員卻可能製造更多問題而非解決方案。培訓開發和品質保證團隊掌握代碼和測試管理的工具與指引,需要調整敏捷作業模式。

請記住,DevOps團隊不僅包含開發人員,DataOps團隊不只有資料工程師,ModelOps團隊也不只有資料科學家。當AI加入討論時,DevOps團隊的跨領域技能將會發生重大變化。隨著這些領域的界線逐漸消失,願意適應變革的人將會脫穎而出。

調整方法以因應預期的挑戰,不應該限制了GenerativeAI所能帶來的潛在效益。如果使用得當,GenerativeAI可以幫助超自動化開發與品質保證任務、透過快速原型設計評估不同選擇、簡化文件流程、監控生產環境預測效能瓶頸等。

如果我們不調整敏捷方法以符合這些新現實,並以更快的步伐釋放價值,「上市時間」和相關的成本效益將會被視為不佳。敏捷方法的改變是不可避免的,因為GenerativeAI和敏捷正為我們帶來真正的競爭優勢。切勿掉以輕心。