作者介紹

朱志，建設銀行廈門開發中心技術管理處負責人，目前主要負責大資料技術平臺規劃和技術資產管理。在銀行IT專案管理、資料分析、資料治理以及架構設計領域工作了十五年，曾領導過建總行人力資源專案、ERP報表專案、分行資料分析平臺ODSB專案、管理會計專案以及新一代資訊系統資料分析平臺的建設。

現在各種大資料會議充滿了AI（人工智慧）的主題，還好仍有人強調資料敏捷性，要不我今天分享的Data APP敏捷實踐話題就落伍了。敏捷誕生也有二十多年了，經歷了兩次高潮，何時提敏捷都不落伍。

今天介紹的這個Data APP基本目標是支撐100,000+使用者、120億條資料、TB級儲存、秒級響應。比起效能，更受使用者歡迎的功能在於支援不同機構或業務條線釋出資料，支援不同崗位不同角色不同使用者按需訂閱，而這些絲毫不用技術人員介入。

看這個邏輯架構圖，Oracle、GreenPlum、Teradata不同系列的資料庫產品（不同的計算區）計算出來的各種指標，通過ETL技術把各種資料來源源不斷地匯入公共訪問區，接著通過Redis、HBase和Kylin等時下流行的開源技術實現兩級快取以應對海量的移動用數訪問。移動端採用了HTML5技術遮蔽裝置作業系統差異，同時VUE.js和ECharts等技術實現了資料展現和自動推送。通過引數化設計將業務運營從開發中分離出來，讓工程師更加關注如何支援好業務資料和使用者自然增長。

這種自我生長的APP模式，就像一顆樹苗，依靠樹根從土壤（GreenPlum和Teradata構成的計算區）源源不斷地吸收養分，再通過樹幹（公共訪問區）以及樹枝（各級Cache）生出樹葉（使用者在移動APP端用數），通過這種架構的孕育，樹苗長成參天大樹不過是時間問題。

注：樹型架構，出處參見高煥堂 Annpping Kao所著《思考軟體，創新設計——A段架構師的思考技術》第5頁“1.4軟體的複雜時本質性的-架構師從複雜設計出簡單”）

這個APP從什麼時候開始蘊藏著如此巨大的能量？

1962年9月12日，肯尼迪發表了著名的月球演說之後（https://er.jsc.nasa.gov/seh/ricetalk.htm），NASA硬著頭皮開始登月，阿波羅1號竟然在地面就爆炸了，經歷多次失敗，直到阿波羅8號首次完成了載人環行月球一週並返回地球之後，NASA才確信人類登上月球只是時間問題。很多人知道阿波羅11號登月成功，卻不知道在肯尼迪航天中心紀念的是阿波羅8號，因為這個阿波羅8號是工程師所懷念的成功原型。是的，這幾個簡單的介面就是Data APP的“阿波羅8號”，接下來重點介紹如何通過敏捷開發打造出這個“阿波羅8號”。

知易行難（2016年5月-2016年8月）

第一步，按圖索驥。

大資料這條路上，一定要看每年釋出的大資料藍圖（《Big Data LandScape》由Matt Turck首先於2012年提出，通過這張圖的更新，可以找到業界的技術投資潮流）。這張圖的使用訣竅，在於要透過複雜的表象按照大資料技術的抽象分類（可參考http://www.bigdatalandscape.com）來尋找可能的技術方向。

這個專案剛開始的時候，我們想法很簡單，採用H5技術遮蔽IOS和Android，用ECharts實現移動端資料視覺化，沿用資料平臺公共訪問區已有的GreenPlum。

第二步，按部就班。

一項技術要成為企業的選擇，必須經歷一系列的測試，從功能到非功能，根據預先設定的指標進行匹配，找到最合適的。入選企業級技術產品目錄後，再逐步推廣，產生規模效應。選好的技術不涉及商業產品，時間緊任務重，趕快出活才是硬道理。

第三步，使用者至上。

在應用架構、資料架構和技術平臺幾個層級上，解決了共享問題之後，要按照使用者體驗組合這些元件服務，在保證後臺功能相對穩定的同時，積極擁抱使用者在前端需求的快速變化。使用者體驗組（移動端用數需求負責人），多次走訪基層網點和分行部門及高層的管理人員，按照不同崗位提煉出了典型應用場景（晨會、週會、經營分析會），形成了100多頁需求。

邏輯推理加穩步執行，這頓想象中共襄盛舉的資料自助餐應該水到渠成。經過三個月的努力，按計劃到了初始版本交付的時間。原計劃要交付分行三類管理崗位和一個總行部門的功能，結果只交付了基層網點負責人的部分頁面。

就拿首頁來說，在測試環境還好，上了生產之後，運行了一週慘不忍睹，頁面要跑10來秒，資料對不上、缺數也是常有的事。更悲哀的是，付出艱辛努力經歷了試執行失敗的同志們，還要被“不就是推幾個數到手機上這麼簡單的事情”的質疑所摧殘。一切印證了一句古話，大道至簡，知易行難！

置之死地而後生（2016年9月）

參與專案的每個人說的都沒有錯，可是結果不好，沒有人承擔責任，一定是整個團隊都出了問題。回顧雄心壯志開啟移動端開發的初衷，在沒有公司資源輔助投入的情況下，我們作為甲方中的乙方，似乎把業務人員的口味調高了；隨著專案深入，業務人員對移動端的認知穩步提升，三次大規模的需求變更就是業務人員進步的實證。其實，大家都害怕移動端不能一炮打響！

然而，隨著時間的發展，每個人都熱情高漲的添磚加瓦，要啥給啥，只有技術人員為進度所迫不斷降低對自己的要求（包括範圍和質量），缺乏溝通也沒有實時的產出物可以驗證，而交付和期望的差距已經發展到不可收拾的境地。到了約定交付的時候，發現業務使用者的情感在瞬間熄滅，領導層的許諾也隨之崩塌，這也是許多瀑布型專案失敗的原因。
我們如何才能扭轉這個局面？想起這三年關注的資料敏捷開發，乾脆把死馬當活馬醫，於是這次危機就成了我們敏捷開發實踐的機會。於是，我們就按敏捷的教科書上說的，第一要把需求變成使用者故事，第二要把故事按輕重緩急排個序，實施團隊在此基礎上構建軟體的最小可執行集。

第一天，我們就依葫蘆畫瓢把原來的Word需求文件，通過CV大法整理成教科書中要求的使用者故事的樣子——作為XX（具體人名），為了XX目的，需要提供XX功能。整理了不到十個使用者故事，小夥伴們開始懷疑這樣做的意義！敏捷的本意就是關注目標，避免過於浪費的過程。把內容寫在便籤紙上，貼在牆上，標上約束，足夠提醒程式設計師要做什麼。最關鍵的是，要讓技術人員和業務人員通過直接溝通在故事的驗收標準（測試用例）達成一致。

看到五顏六色的便籤圖片了嗎，黃色或綠色便籤用來寫使用者故事，橙色用來寫約束，紅色用來標問題或是技術債。事情做完或問題解決後，便籤就會從牆上摘下來放進盒子裡，隨著時間的推移，放進盒子裡的便籤越來越多，團隊的自信心就這麼一點一點的找回來，大家慢慢的忘了什麼事情做不成，而只去想“能做成什麼”。
還有一個事情要說一下，關於使用者故事的排序問題，如果直接詢問業務人員，很難得到確定的回答。那個時候已經九月初離第二次試執行上線只有一個月了，如果每一天都當作最後一天來過，使用者需要的是什麼，我們又能做出什麼迴應？運氣很好，恰恰是這兩個問題，把我們和使用者拉到了一起。畢加索抽象公牛的手稿，啟發了我們對抽象的思考。按不同崗位的工作場景編寫的需求，本質的訴求在於讓業務人員通過手機移動端隨時可以看到關鍵指標，而不在於業務場景和頁面需求的多少。有了抽象思維，整個小組達成了共識，與其“按期交付100個不可執行的頁面“，不如“只交付最有用且保證質量的5個頁面”。我們開始意識到，通過抽象思維，可以總結頁面模式，不需要那麼多頁面和場景也能達到目的。
可是，什麼樣的頁面模式才能達到我們的目的？我們如何找到“阿波羅8號”？我們的運氣很好，珅哥用VUE改出的第一套頁面模板（首頁、指標趨勢分析、機構資訊和結構解析四個頁面），就得到了使用者和其他開發人員的認可，再多的指標再多的場景，只要把這個四個頁面的效能調到1秒以內，任何指標分分鐘實施完。為了測試使用者體驗，我們甚至把業務引數化設計也放到一邊，改用json配置先看看哪些業務引數易變。

是不是很神奇？以為我會說得很曲折，必須承認就是運氣！

天下武功，唯快不破（2016年10月-2016年11月）

當需求變成了使用者故事，我們的設計開發也變成了”測試驅動開發TDD+持續整合CI“。客觀的說，不是每個人都馬上適應TDD，更苛刻地說，大部分人無法適應TDD思維。把TDD上升到精神層面，可能挑戰的是人的惰性，堅持下來會激發人的激情，做不好就會全軍覆沒。

作為可以借鑑的經驗，我們把TDD先下降到戰術層面，把TDD當作帶測試案例的需求文件，把TDD當作設計思路的形成過程，那就說TDD對工程師的好處在於可以省略掉需求分析和設計文件（還好沒有正式立項，要不會有人追殺我的）。TDD真是敏捷開發的重要一環，沒有有效的測試程式，識別技術債也是空想，重構會成為空中樓閣，CI就如同行屍走肉般無用。TDD是敏捷轉型技術部分的底線，沒有退讓的餘地。所以，我們先用免文件誘導，再靠行政命令固化，最後曉之以情動之以理，把所以同志帶到TDD的道路上。結果，意想不到的是最後轉型的人居然是團隊裡最資深的成員（此處略去稱謂，簡稱“老大哥”）。

還好，逮到了一次機會。老大哥每個週末都辛勤地用CV大法（拷貝+貼上）應付指標口徑的變更（變更來自資料分析師的修正），在我看來，這是用戰術上的勤奮掩蓋戰略上的懶惰。慢慢的，大哥頂不住了，找我增援。我以“2 Piazzas”法則（敏捷重要法則之一，團隊不宜太大，兩個披薩夠吃為宜，當然，我們團隊裡最壯的哥們經常挑戰這個法則，因為他一個人就能吃兩Pizza）為由拒絕了。同時，找了和大哥最親密的小夥伴小鋒，一起研究程式碼，寫了幾個TDD的範例，同時直接重構出幾個函式。當江湖上最後一位大哥擁抱了TDD，通往快速迭代的道路上就再也沒有障礙了。

領導特別關注的專案，壓力雖然大，也有很多好處，我們爭取到了每週上一次線的頻繁犯錯機會。根據使用者故事和技術債，我們擬定了一週上功能一週調效能的策略。敏捷響應業務的速度，讓業務人員都驚呆了，11月19日版本封版前一天，試點分行又提出了新的崗位和指標變更需求，結果我們用了半天就完成了，並順利封版上線，從側翼支援了江西行新一代三期試點。

時間就這樣，一週一週一月一月得過去了，我們的APP在功能上收穫了“使用者直接訂閱指標”、“後臺配置指標全集”、“不同指標適應不同維度”、“按使用者要求設立警戒線”等等大塊功能，為了滿足毫秒級響應的使用者體驗，也慢慢地集成了Redis、Mondrian、Kylin等多種技術，完成了手機APPOLAP的多級快取，完成了大規模使用者推廣的準備工作。
天下武功，唯快不破。在這個快速迭代的過程中，我們知道，成功的祕訣在於快。“快”不是偷工減料，而是緊盯目標，只要能達到效果就上，絕不浪費時間猶豫不決，每一次的故事，我們只在乎，APP是不是能更快的支撐業務變更、是不是能執行得更快、是不是能讓運維更方便。

無招勝有招

工程師是人，就會恐懼，會焦慮，要讓人做出自己不敢做不敢想的事情，需要夢想和文化的支撐。本文介紹的只是我們團隊的轉型體驗，技術很重要，可是我們沒有糾結於特定技術，因為我們用實踐體會了敏捷宣言：

個體互動勝於流程和工具
Individualsand interactions over processes and tools

可工作的軟體勝於可理解的文件
Workingsoftware over comprehensive document

客戶協作勝於合同談判
Customercollaboration over contract negotiation

響應改變勝於遵從計劃
Respondingto change over following a plan

文章來自微信公眾號：DBAplus社群