敏捷開發與數據科學的故事

數據科學可以用敏捷的方法來跑嗎？ 對於許多公司與團隊來說，數據科學家就像一個黑魔法自動販賣機，對於公司唯一能做的事就是定期把錢和原料投進進去，然後等待.....等待......等待新武器的產生。

所以許多公司很容對於這種投入很大，卻不容易估算預期產出的東西充滿恐懼....

而我們的故事是這樣開始的.....

團隊角色：

• DS君：身處遠方的資料科學家
• DE君：Python苦手的Data Engineer，號稱敏捷導入者
• D-Team：由一群擅長邊緣運算(Edge Comuting)的邊緣人組成的維運一條龍團隊

最初的故事：

D-Team的主要任務是開發/維運系統，並且定期會準備資料交給DS君做實驗，而身處在遠方的DS君被賦予任務是研究Paper，並且希望從中找出各種可能用來優化推薦系統的演算法，由於平時獨立在遠方做研究，所以對於團隊來說是個魔法黑箱子的存在。

對於D-Team來說光是要處理開發和維運的事情就已經夠頭痛了，實在沒有太多精力去處理與追蹤DS君的進度，所以遲遲等不到魔法黑箱子所產生的新武器。

查克拉提煉敏捷導入：

其實要讓開發團隊和Data Scientist 能順利合作並且有產出就跟提煉查克拉一樣，是把兩種不同能量提取並且加以混和的一種技能！而要變強的關鍵就是要能進行控制與持續放出的修練。

那要怎麼把這個查克拉修行法敏捷方法套到數據科學呢？
重點就是在 Iteration！Iteration！Iteration！
也就是透過的控制和維持產出，持續改進Iteration的順暢

其實說穿了就是嘗試引入了幾個敏捷開發的元素：

• Time Box
• Experiment Story (類似User Story)
• Iteration Process
• Review Meeting

Time Box

一個實驗需要做多久/收集多少資料才能被檢驗？何時該放棄？畢竟每個實驗都是有成本的...

Experiment Story

在這邊我們嘗試使用Experiment Story 的方式來描述工作，透過讓目標和產出物更為明確，希望可以讓雙方的溝通夠為順暢，工作主要分為兩種：

• DS君的研究與實驗 (POC)
• DS君希望請DE君幫忙的實驗 (上線A/B Test)

通常的情境如下：
Phase1：DS君研究出一個方法，並且在小資料層級做出可能有效的實驗。
Phase2：DE君加入幫忙，把這個實驗程式Spark化，套用在Production 層級資料
Phase3：把這這個實驗串上Producton 層級的Data pipeline 做A/B Test。

Iteration Process

這部分主要是DE君的工作，跟D-Team 討論Data Pipeline該怎麼設計，怎麼把整個實驗掛上Production 的環境，讓實驗能快速的被修改與驗證。

Data Pipeline 舉例如下：

如果一個W2V的Model 要上線被測試，中間能被切成幾個階段，每個階段該把資料存在哪裡？各服務之間該怎麼呼叫和交換資訊？

並且在每個階段的資料都是可以被拿出來檢視和驗證的

Review Meeting

當定好了流程，接下來就是每個iteration 定期討論研究內容與後續方向，主要產出：

• 研究週報 (請DS君每週產出一些實驗的數據和圖表提供討論)
• 討論接下來的研究方向與Prouction化的可行性

心得 

做數據科學真得是燒錢又漫長的道路....XDrz...
先不論是否有沒有產出很厲害的 outcome，至少在持續交付 output 的部分有得到了很大的改善。


延伸閱讀：
[1] A manifesto for Agile data science