譯者 | 李睿

審校 | 重樓

在不斷發(fā)展變化的現(xiàn)代世界中，對于那些需要為目標市場快速提供既引人注目又引人入勝解決方案的企業(yè)來說，唯一不變的就是變化。雖然瀑布模式在實現(xiàn)過程存在一些局限性，例如無法有效地滿足動態(tài)客戶操作經(jīng)常出現(xiàn)的的時間緊迫性，但是轉(zhuǎn)型到敏捷模式不僅僅是一種方法，更是一種有關組織中系統(tǒng)、流程和技術之間相互作用的全新思考方式。

本文闡述如何幫助一家全球美容電子商務公司從傳統(tǒng)電子商務架構向由敏捷原則主導的集成方法轉(zhuǎn)型過程中所扮演的角色。但這不僅僅是采用敏捷模式——它涉及重新設計流程、集成系統(tǒng)以及構建流程，以創(chuàng)造一個看起來和感覺上都無縫銜接的環(huán)境。

超越瀑布模式的技術變革需求

傳統(tǒng)電商架構、客戶關系管理（CRM）系統(tǒng)和專用的忠誠度應用程序為電子商務提供了數(shù)字資產(chǎn)的主要技術堆棧。即使這些系統(tǒng)能夠有效運行，但是它們無法適應當前通常存在的持續(xù)循環(huán)的開發(fā)周期。在日常實踐中，部署敏捷方法顯然并不能解決由這種嵌入式基礎設施引起的更復雜的架構問題。

由此產(chǎn)生的一些關鍵痛點是：

• 系統(tǒng)互相孤立：由于平臺之間的互操作性有限，全渠道體驗的管理和客戶數(shù)據(jù)的同步效率低下。
• 產(chǎn)品發(fā)布存在瓶頸：開發(fā)過程的僵化和垂直依賴關系成為產(chǎn)品發(fā)布的主要瓶頸，使開發(fā)團隊幾乎沒有什么空間適應不斷變化的市場。
• 資源限制：技術堆棧在資源方面成本高昂，需要不斷的人工更新和大量的資源消耗來保持環(huán)境的一致性。

解決方案不僅需要敏捷轉(zhuǎn)型，還需要對工程進行重新配置，為模塊化系統(tǒng)、CI/CD管道和團隊內(nèi)部實時協(xié)作提供必要的工具。

在遺留系統(tǒng)驅(qū)動的生態(tài)系統(tǒng)中應對敏捷轉(zhuǎn)型

客戶遷移工作從審查其當前系統(tǒng)和正在進行的項目開始。這包括評估每個數(shù)字資產(chǎn)和平臺的屬性及其支持敏捷集成的能力，同時不會中斷現(xiàn)有的項目工作流程。解決方案是在部署敏捷技術的同時引入技術改進方面的變更，以避免干擾運營流程。因此進行了以下修改：

1.基礎設施的模塊化

遺留系統(tǒng)經(jīng)過改造成功實現(xiàn)了模塊化轉(zhuǎn)型，轉(zhuǎn)變?yōu)橛扇萜骰脚_（如Docker及編排平臺）全力支持的微服務架構。這使得系統(tǒng)執(zhí)行并行更新和部署成為可能，這加速了交付速度，并最大限度地減少了系統(tǒng)層面的中斷，同時增強了其可擴展性和容錯性。

2.數(shù)據(jù)流優(yōu)化

API和中間件解決方案（如MuleSoft和Apache Kafka）被用來搭建起孤立、不連貫系統(tǒng)之間的橋梁。這些集成措施允許在客戶電商網(wǎng)站、客戶關系管理系統(tǒng)或客戶數(shù)據(jù)平臺之間共享數(shù)據(jù)，從而根據(jù)客戶的需求改進全渠道活動。

3.集成工具鏈

對于CI/CD過程，像Jenkins和GitLab這樣的工具被配置，并用于根據(jù)敏捷方法部署構建和發(fā)布周期。這樣可以實現(xiàn)一致可靠的部署管道，最大限度地減少人工錯誤，縮短了開發(fā)時間框架，因為在流程中節(jié)省了更多的時間。

解決了這些基本的技術問題，組織就可以充分利用敏捷模式，同時克服遺留開發(fā)模式相關的問題。

如何為敏捷集成對數(shù)字資產(chǎn)進行優(yōu)先級排序和重新設計

為了幫助客戶在多個項目已經(jīng)在進行中的情況下進行重大的變革，采用了規(guī)模化敏捷框架（SAFe），因為它有助于在大型企業(yè)中集成敏捷實踐以逐步實施敏捷流程，使敏捷團隊能夠針對最關鍵的數(shù)字資產(chǎn)，同時繼續(xù)開展其他基本活動。這種自定義方法使開發(fā)團隊能夠更有效地推出產(chǎn)品，而不會干擾其他流程。

SAFe是一種全面的方法，旨在幫助組織在企業(yè)層面上成功實現(xiàn)敏捷實踐。

1.開發(fā)數(shù)字資產(chǎn)和平臺分類法

首先將每個數(shù)字資產(chǎn)（如產(chǎn)品顯示頁面、推薦引擎和客戶檔案）映射到客戶旅程。這種映射對于確定哪些資產(chǎn)對用戶體驗和業(yè)務價值影響最大至關重要。通過理解這些接觸點，使客戶能夠從戰(zhàn)略上對資產(chǎn)進行優(yōu)先級重組，確保敏捷集成工作與客戶需求和組織目標保持一致。

為了創(chuàng)建這個強大的數(shù)字產(chǎn)品和平臺分類，利用了現(xiàn)有框架和研究的見解，遵循了以下四個簡化步驟：

（1）定義目標和范圍：明確闡述分類法的目的和邊界，以與組織目標保持一致。

（2）確定平臺屬性：關注關鍵屬性，例如集中化、市場方面和提供方向，以區(qū)分平臺。

（3）開發(fā)分類模式：構建一個結構化框架，根據(jù)共享的特性和區(qū)別對平臺進行分類。

（4）驗證和改進：將分類法應用于現(xiàn)有平臺，為準確性和實際應用對其進行改進。

這種分類法允許創(chuàng)建專用于特定功能的“小組”（pod），并使它們與總體業(yè)務目標保持一致：

• 早期勝利：小組專注于評級、評論和忠誠度獎勵界面等前端組件，以最小的復雜性提供快速、高影響力的結果。這些項目改善了用戶體驗，建立了利益相關者的信心，為更大的轉(zhuǎn)型奠定了積極的基調(diào)。通過早期展示切實的進展，開發(fā)團隊獲得了處理更復雜的計劃所需的信任。
• 復雜集成：后端系統(tǒng)（如CRM平臺和數(shù)據(jù)湖）的處理工作稍后進行，需要深度集成以確?？缜赖目蓴U展性和數(shù)據(jù)一致性。這些努力為個性化推薦和實時分析等高級功能奠定了基礎。處理這些核心系統(tǒng)確保了支持不斷變化的業(yè)務需求所需的穩(wěn)定性和靈活性。

數(shù)字資產(chǎn)和平臺分類法的創(chuàng)建表明，這家美容電子商務公司將需要約30個由約270名員工組成的小組來為其提供前端產(chǎn)品。

注：在敏捷開發(fā)中，pod通常指的是一組具有特定技能和專業(yè)知識的團隊成員，他們共同工作以完成特定的任務或項目。

2.加強技術準備

為了確保組織在技術上為轉(zhuǎn)型做好準備，重點關注以下三個關鍵領域：

（1）云遷移：將非關鍵工作負載轉(zhuǎn)移到基于云的服務，例如用于無服務器計算任務的AWS Lambda。這種遷移減少了對內(nèi)部部署基礎設施的依賴，優(yōu)化了資源分配，降低了運營成本，同時提供了動態(tài)工作負載所需的可擴展性。

（2）API主導的連接性：通過API公開遺留數(shù)據(jù)庫，并使用Postman等工具進行測試，以及采用AWS API Gateway進行部署，從而實現(xiàn)了遺留數(shù)據(jù)庫的現(xiàn)代化。這種方法可以無縫地集成到敏捷工作流程中，而不需要對整個系統(tǒng)進行全面改造，從而為現(xiàn)代化提供了一種經(jīng)濟有效的漸進路徑。

（3）可擴展性：通過基礎設施即代碼（IaC），使用Terraform和AWS CloudFormation等工具編寫基礎設施。這種方法確保了跨開發(fā)、測試和生產(chǎn)環(huán)境的一致性，實現(xiàn)了自動化配置、版本控制和可重復部署，以提高效率和可擴展性。

3.構建多學科敏捷小組

為了推動敏捷轉(zhuǎn)型，該案例采用并定制了Spotify模型來創(chuàng)建專門的敏捷小組，這些小組不僅具備跨職能性，還與轉(zhuǎn)型的技術和業(yè)務范圍保持一致，重點關注移動和以網(wǎng)絡為中心的數(shù)字產(chǎn)品。每個小組原型都解決了特定領域的復雜性，同時在整個產(chǎn)品生命周期中嵌入了敏捷原則（從設計和開發(fā)到各種數(shù)字資產(chǎn)和平臺的測試和部署）。通過定制Spotify模型，建立了以小組形式運作的自主小組，同時整合結構，以促進小組之間的協(xié)作。

這種方法促進了面向客戶的平臺、后端系統(tǒng)和測試管道之間的一致性。它還允許加快交付時間并驅(qū)動一致的價值創(chuàng)造，確保敏捷轉(zhuǎn)換與客戶的戰(zhàn)略目標保持一致。

除了技術專業(yè)化之外，每個小組原型都是根據(jù)客戶的運營需求量身定制的，并設計成包括跨越產(chǎn)品、數(shù)字和技術領域的平衡混合角色。這種組合確保了每個小組能夠解決其領域的獨特挑戰(zhàn)，同時為更廣泛的轉(zhuǎn)換目標做出貢獻。

• 產(chǎn)品角色：產(chǎn)品經(jīng)理、業(yè)務分析師、領域主題專家。
• 數(shù)字角色：Scrum主管、客戶體驗專家、UI設計師、UX設計師。
• 技術角色：技術主管、軟件開發(fā)人員、平臺工程師、解決方案架構師、測試/QA工程師。

數(shù)字資產(chǎn)小組（Digital Assets Pod）包括產(chǎn)品設計和開發(fā)專家，他們協(xié)同工作，提供直觀和可擴展的面向客戶的平臺。同時，平臺小組（Platform Pod）支持這些系統(tǒng)的基礎設施需求，在動態(tài)業(yè)務條件下實現(xiàn)無縫性能。

4.為轉(zhuǎn)型彌合資源和能力缺口

（1）角色配置和專業(yè)知識

為了有效應對資源缺口問題，本案例研究對客戶的角色配置與專業(yè)知識進行了深入細致的評估，以確保與他們的戰(zhàn)略目標緊密契合。在參考了行業(yè)在資源規(guī)劃及團隊結構方面的先進實踐后，提出了以下建議：在組織內(nèi)部穩(wěn)固保留關鍵角色，例如解決方案架構師和領域主題專家（SME），從而為長期創(chuàng)新提供堅實支撐，并確保機構知識的傳承與連續(xù)性。針對軟件開發(fā)人員等中層技術崗位，采取了一種有選擇性的內(nèi)包策略，該策略以項目具體需求為優(yōu)先考慮，旨在確保在核心開發(fā)領域擁有專業(yè)知識。

為了進一步優(yōu)化資源配置，建議將標準化任務如測試和QA工程等外包給外部供應商，借助他們的專業(yè)能力高效處理這些重復但至關重要的工作。這一平衡策略借鑒了項目管理協(xié)會（PMI）人才三角模型及敏捷團隊結構原則等框架中的經(jīng)驗，使客戶能夠在戰(zhàn)略層面應對資源限制的同時，依然能夠保持組織的敏捷性。

（2）提高敏捷性技能

為了在組織內(nèi)部培育敏捷文化，采取了針對性的培訓策略，聚焦于提升內(nèi)部團隊在敏捷原則、CI/CD工具應用及API集成方面的技能。為此引入了認證計劃，旨在強化技術能力，特別是通過培養(yǎng)認證Kubernetes管理員（CKA）來掌握容器編排與云計算架構的關鍵技能，從而滿足轉(zhuǎn)型的需求。此外，團隊成員還積極追求與敏捷相關的專業(yè)認證，例如項目管理協(xié)會（PMI）的敏捷認證從業(yè)者(PMI-ACP)和認證Scrum主管(CSM)，以期深化他們對敏捷方法論的理解，并增強他們推動迭代開發(fā)、實現(xiàn)價值驅(qū)動交付的能力。

結論：數(shù)字化轉(zhuǎn)型的技術藍圖

這一實踐經(jīng)驗凸顯了在敏捷轉(zhuǎn)型中解決方法論和技術挑戰(zhàn)的關鍵需求。對于這家全球美容電子商務客戶來說，其成功取決于對工作流程的重新思考以及對支撐這些工作流程的基礎系統(tǒng)的重新設計。通過構建模塊化架構，自動化發(fā)布流程，以及協(xié)調(diào)跨職能團隊，此次轉(zhuǎn)型不僅加快產(chǎn)品推出，還帶來了更優(yōu)的客戶體驗，并為未來的增長構建了可擴展的技術平臺。

對于開始走上這一旅程的組織應該將敏捷轉(zhuǎn)換視為一項全局性工作，需要在技術基礎設施的長期投資與追求短期成果之間之間取得平衡。為了深入了解如何管理這一復雜的轉(zhuǎn)型，Craig Larman和Bas Vodde合著的《Large-Scale Scrum: More with LeSS》一書詳細闡述了有效擴展敏捷并應對組織挑戰(zhàn)的實際策略。

原文標題：Strategic Roadmap for Modernizing Digital Operations: Transitioning from Legacy Development Models to Agile-Driven Integrated Frameworks，作者：Thai Bao An Phan