敏捷數(shù)據(jù)工程項目開發(fā):高效機器學習團隊管理
定 價:89 元
叢書名:智能系統(tǒng)與技術(shù)叢書
- 作者:[美] 埃里克·卡特(Eric Carter) 馬修·赫斯特(Matthew Hurst)
- 出版時間:2021/8/1
- ISBN:9787111688488
- 出 版 社:機械工業(yè)出版社
- 中圖法分類:TP311.52
- 頁碼:
- 紙張:膠版紙
- 版次:
- 開本:16開
本書通過示例向你展示如何通過敏捷過程交付良好的數(shù)據(jù)產(chǎn)品,以及如何組織和管理快節(jié)奏的團隊,在生產(chǎn)環(huán)境中解決大規(guī)模的新數(shù)據(jù)問題。它將為你提供組織工作的方法,如何為數(shù)據(jù)設置可交付成果,如何在看似永無止境的任務中管理時間,如何理解數(shù)據(jù),以及如何增加團隊的透明度。書中所有的例子都來自真實的團隊、真實的會議和真實的數(shù)據(jù)。
本書誕生于一次偶然的相遇。2012年7月,當時Eric Carter剛剛回到美國,此前他在德國工作了三年,向歐洲市場推出了微軟的一款購物搜索產(chǎn)品。他非常失望,因為他在歐洲努力的項目被叫停,所以他需要尋求新的發(fā)展。當在Bing(微軟的搜索引擎)尋找機會時,他遇到了Matthew Hurst。Matthew是微軟Live Labs的一名成員,Live Labs是一個創(chuàng)新小組,負責探索圍繞搜索、云和連接技術(shù)的新解決方案和應用。從那時起,他就開始研究地圖和本地搜索的各種形式,通常是研究將搜索主題與地址連接起來的功能。Eric和Matthew之間是相輔相成的伙伴關(guān)系,他們的合作極大地提高了Bing本地搜索的質(zhì)量,并終引領(lǐng)兩人踏上了數(shù)據(jù)工程項目如何從敏捷原則的應用中獲益的探索之旅。
敏捷宣言(全稱:敏捷軟件開發(fā)宣言)于2001年由17個簽署者共同簽署,總結(jié)為四個價值觀(個體和互動的價值高于流程和工具;工作的軟件的價值高于詳盡的文檔;客戶合作的價值高于合同談判;響應變化的價值高于遵循計劃)和十二原則。在本書中,我們將依次檢查每一條原則,并將它們與我們在許多項目和上下文中使用數(shù)據(jù)和推理方法的經(jīng)驗聯(lián)系起來。
當兩位作者見面時,Bing的本地搜索產(chǎn)品在很大程度上還處于開發(fā)階段。本地商業(yè)目錄的質(zhì)量正在改善,但比起當時的市場領(lǐng)導者谷歌仍有很大差距。Matthew當時在本地搜索數(shù)據(jù)團隊,他和團隊的其他成員一直在探索一些創(chuàng)新的想法,以更好地利用Web并集成機器學習來顯著改善目錄。Eric在Bing的本地搜索空間發(fā)現(xiàn)了許多需要直面的挑戰(zhàn),并決定以工程經(jīng)理的身份加入Bing的本地數(shù)據(jù)團隊。
在Eric職業(yè)生涯的這個階段,他對在微軟管理團隊并不陌生,他曾參與過幾個Visual Studio相關(guān)產(chǎn)品的開發(fā)以及現(xiàn)在已經(jīng)取消的“購物搜索”項目。然而,正是在參與Visual Studio相關(guān)產(chǎn)品開發(fā)期間,他發(fā)現(xiàn)了敏捷的內(nèi)在價值,以及遵循敏捷原則的團隊是多么高效和歡樂。他想把這些也帶到他的新團隊中,卻發(fā)現(xiàn)自己陷入了一個困境—如何將敏捷應用到一個更多是生產(chǎn)數(shù)據(jù)而不是生產(chǎn)軟件的團隊中?要將敏捷引入數(shù)據(jù)工程團隊,需要哪些東西?
這并不簡單。首先,敏捷就像一個入侵的國外代理。因為原本的團隊文化是關(guān)于大概念的,通過實驗、長期研究和大量試錯科學項目來發(fā)掘,而所有這些似乎都與敏捷原則(如Scrum、迭代開發(fā)、可預測性、簡潔和頻繁交付可工作的軟件)背道而馳。對于一個專注于創(chuàng)建包含世界上所有的商業(yè)機構(gòu)的非常精確的數(shù)據(jù)庫的團隊來說,定義“完成”幾乎是不可能的。畢竟,數(shù)據(jù)中不變的就是將包含錯誤—工作從字面上來講永遠不可能完成。面對諸如與利益相關(guān)者溝通、團隊如何以及在哪里取得進展,確定某個特定的開發(fā)投入是否值得,以及確保以定期但可持續(xù)的節(jié)奏交付改進等挑戰(zhàn),現(xiàn)代敏捷方法顯然是至關(guān)重要的。但是,在一個由數(shù)據(jù)科學家和傳統(tǒng)工程師組成的、致力于面向數(shù)據(jù)的可交付成果的團隊中,如何應用敏捷?
傳統(tǒng)的敏捷流程旨在減少不確定性和回答諸如“客戶想要什么”以及“如何可靠并持續(xù)地交付軟件”之類的問題,但在這個新的項目、新的世界中,我們已經(jīng)知道了客戶想要什么(一個完美的本地商業(yè)目錄),但我們需要回答諸如“數(shù)據(jù)中有什么”“基于這些數(shù)據(jù)我們能交付什么”之類的問題。我們需要敏捷方法,但需要的是針對現(xiàn)代的、復合型人才組成的數(shù)據(jù)工程團隊改進后的敏捷方法。
隨著探索下一代機器學習挑戰(zhàn)的深入,我們發(fā)現(xiàn),敏捷原則毫無疑問可以應用于解決問題和減少數(shù)據(jù)的不確定性,進而打造一個更快樂和高效的團隊。
因此我們整合了敏捷方法論的這個現(xiàn)代化版本,希望本書所提供的經(jīng)過驗證的指南和來之不易的見解,能幫助個體、技術(shù)領(lǐng)導者和管理者在當今機器學習和大數(shù)據(jù)領(lǐng)域令人興奮的工作中更富有成效。
Eric Carter
Matthew Hurst
2019年6月
前言
關(guān)于作者
關(guān)于技術(shù)審查人
第1章 盡早交付1
1.1 入門3
1.2 用于規(guī)劃的數(shù)據(jù)分析 7
1.3 創(chuàng)造價值9
1.4 從盡早交付到持續(xù)交付11
1.4.1 更多實體 12
1.4.2 更多屬性 13
1.4.3 更多市場 15
1.4.4 更高的質(zhì)量 15
1.4.5 平臺即產(chǎn)品:更多垂直商業(yè)和客戶 16
1.5 盡早且持續(xù)交付價值16
1.6 結(jié)論 20
第2章 需求變化21
2.1 為變化而構(gòu)建 22
2.1.1 為變化而構(gòu)建度量 22
2.1.2 為變化而構(gòu)建管道 24
2.1.3 為變化而構(gòu)建模型 27
2.1.4 為變化而構(gòu)建架構(gòu) 35
2.2 為變化而構(gòu)建測試和監(jiān)控 37
2.2.1 監(jiān)控增量變化:數(shù)據(jù)DRI37
2.2.2 哨兵實體 38
2.2.3 日常判斷指標 39
2.2.4 測試特征40
2.2.5 測試學習后的模型 41
2.2.6 帶標簽的訓練數(shù)據(jù) 41
2.3 響應客戶DSAT43
2.3.1 確定DSAT的類別44
2.3.2 定期自我評估:數(shù)據(jù)滾動和質(zhì)量審查46
2.3.3 度量競爭對手48
2.4 結(jié)論50
第3章 持續(xù)交付51
3.1 驗證代碼更改52
3.2 持續(xù)集成系統(tǒng)53
3.3 持續(xù)部署系統(tǒng)54
3.4 驗證數(shù)據(jù)更改56
3.5 持續(xù)部署數(shù)據(jù)58
3.6 決定發(fā)布什么59
3.7 結(jié)論60
第4章 與業(yè)務人員保持一致61
4.1 日常的重要性61
4.2 集中辦公的優(yōu)勢64
4.3 業(yè)務驅(qū)動的Scrum團隊65
4.4 與業(yè)務人員合作了解數(shù)據(jù)68
4.5 幫助業(yè)務人員了解機器學習的局限性69
4.6 與業(yè)務人員溝通工程的節(jié)奏:我們?nèi)绾巫鯯crum71
4.6.1 Scrum團隊72
4.6.2 組合和產(chǎn)品待辦事項72
4.6.3 用戶故事75
4.6.4 任務77
4.6.5 沖刺82
4.6.6 通過郵件與業(yè)務人員溝通Scrum狀態(tài)89
4.7 結(jié)論93
第5章 激發(fā)個體94
5.1 頻繁重寫95
5.2 發(fā)現(xiàn)和培養(yǎng)激發(fā)個體96
5.2.1 面試與招聘98
5.2.2 激發(fā)個體的職業(yè)生涯管理103
5.3 為激發(fā)個體創(chuàng)造一個生產(chǎn)力環(huán)境106
5.3.1 內(nèi)外循環(huán)106
5.3.2 尋找工具、監(jiān)控和編制文檔107
5.3.3 開發(fā)人員NSAT109
5.4 支持組織外部的激發(fā)個體110
5.5 結(jié)論111
第6章 有效溝通112
6.1 圍繞數(shù)據(jù)的討論必須是交互式的118
6.2 數(shù)據(jù)工具基礎(chǔ)119
6.2.1 數(shù)據(jù)討論工具的要求119
6.2.2 進行快速評估120
6.2.3 實例挖掘122
6.2.4 抽樣策略122
6.2.5 迭代差分124
6.3 數(shù)據(jù)可視化124
6.4 召開有效的會議是一種技能126
6.5 結(jié)對和并行標記127
6.6 數(shù)據(jù)滾動128
6.7 演示會議130
6.8 結(jié)論133
第7章 監(jiān)控134
7.1 監(jiān)控工作軟件135
7.1.1 示例系統(tǒng):離開時間135
7.1.2 基于活動的監(jiān)控136
7.1.3 用于分析跟蹤的Azure數(shù)據(jù)資源管理器139
7.2 監(jiān)控可以告訴你什么141
7.2.1 工作軟件是否真的可工作141
7.2.2 什么地方出現(xiàn)了問題141
7.2.3 有多快142
7.2.4 業(yè)務目標是否真的達成143
7.2.5 是否真正滿足了客戶需求144
7.2.6 數(shù)據(jù)和模型如何使用145
7.3 結(jié)論146
第8章 可持續(xù)開發(fā)147
8.1 我們是否在正確的可持續(xù)節(jié)奏上148
8.1.1 放慢節(jié)奏149
8.1.2 加快節(jié)奏150
8.2 調(diào)整節(jié)奏的重要性151
8.3 可持續(xù)節(jié)奏與實時網(wǎng)站153
8.4 可持續(xù)節(jié)奏與多個開發(fā)地域155
8.5 結(jié)論155
第9章 技術(shù)卓越157
9.1 敏捷軟件工程實踐158
9.2 數(shù)據(jù)項目的技術(shù)卓越162
9.2.1 度量自身162
9.2.2 建立指標時開發(fā)模型165
9.2.3 為推理系統(tǒng)編寫測試166
9.2.4 自定義標注工具168
9.2.5 存儲和版本化訓練與評估數(shù)據(jù)169
9.2.6 管理模型170
9.3 數(shù)據(jù)項目的良好設計171
9.3.1 數(shù)據(jù)模型中的表示和標識173
9.3.2 表示不確定175
9.3.3 代表輸入176
9.4 結(jié)論177
第10章 簡潔178
10.1 勤于完成任務描述179
10.1.1 不明確的工作179
10.1.2 致命的連詞181
10.1.3 跨任務的依賴關(guān)系和假設181
10.2 盡早集成183
10.3 基線和啟發(fā)式方法183
10.4 認識到限制184
10.5 管理HiPPO185
10.6 快速失敗186
10.7 構(gòu)建、購買或使用開源187
10.8 結(jié)論189
第11章 自組織團隊190
11.1 團隊組成191
11.2 團隊由個體組成192
11.3 鼓勵團隊的個體特性194
11.4 跨多個自組織團隊的管理196
11.5 被授權(quán)的團隊可以推動團隊發(fā)展和產(chǎn)品演進197
11.6 好事如何出現(xiàn)198
11.7 培養(yǎng)自組織團隊199
11.8 工程原理與概念完整性200
11.9 結(jié)論201
第12章 調(diào)整202
12.1 回顧202
12.2 五個為什么204
12.3 調(diào)整指標205
12.4 展望未來206
12.5 結(jié)論207
第13章 總結(jié)208