-- 會員 / 註冊 --  
 帳號:
 密碼:
  | 註冊 | 忘記密碼
3/26 新書到! 3/19 新書到! 3/14 新書到! 12/12 新書到!
購書流程Q & A站務留言版客服信箱
3ds MaxMayaRhinoAfter EffectsSketchUpZBrushPainterUnity
PhotoShopAutoCadMasterCamSolidWorksCreoUGRevitNuke
C#CC++Java遊戲程式Linux嵌入式PLCFPGAMatlab
駭客資料庫搜索引擎影像處理FluentVR+ARANSYS深度學習
單晶片AVROpenGLArduinoRaspberry Pi電路設計CadenceProtel
HadoopPythonStm32CortexLabview手機程式AndroidiPhone
可查書名,作者,ISBN,3dwoo書號
詳細書籍分類

敏捷分析:價值驅動的商業智能和數據倉庫系統開發

( 簡體 字)
作者:(美)Ken Collier 著類別:1. -> 程式設計 -> 綜合
譯者:
出版社:機械工業出版社敏捷分析:價值驅動的商業智能和數據倉庫系統開發 3dWoo書號: 38671
詢問書籍請說出此書號!

缺書
NT售價: 345

出版日:6/1/2014
頁數:220
光碟數:0
站長推薦:
印刷:黑白印刷語系: ( 簡體 版 )
加入購物車 加到我的最愛
(請先登入會員)
ISBN:9787111467021
作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 
(簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證)
作者序:

譯者序:

前言:

BI項目開始腐壞

大多數數據倉庫開發者都經歷過不太成功的項目。你甚至可能經歷過項目失敗的痛苦。幾年前,我為一家中型公司工作,公司想用一個正確架構的數據倉庫取代現有的本地報告應用。我的項目角色是首席架構師和技術總監。這個項目非常糟糕地結束了,我們的解決方案最終也被遺棄。一開始,項目呈現出成功和用戶滿意的態勢。然而,盡管開發人員、項目經理和利益相關者盡了最大的努力,項目超出預算并超過了計劃時間,用戶對成果也感到不滿。因為這個項目極大地激勵我去做到讓敏捷原則和實踐適應數據倉庫和商業智能(DW/BI)開發,所以我會做一個簡短回顧,為在本書中展現的敏捷DW/BI原則和實踐提供依據。它可能和你經歷過的項目有類似之處。

關于項目

本節概述了該項目的本質特征,包括下面的內容。

現有的應用程序。公司現有的報告應用程序在內部叫做“數據倉庫”,它明顯歪曲了用戶對數據倉庫應用會提供什么的理解。事實上數據模型是一個遺留操作型數據庫的部分復制。這個復制的數據庫不包含任何的數據清理,并且被大量自定義的用作生成報告的Java代碼填充。用戶在不同時期都要求增加新的自定義報告功能。應用因為那些很少使用的專業報告功能而變得不堪重負。所有報告都是一成不變的報告。系統沒有針對分析活動進行優化,也不提供先進的分析能力。

項目動力。因為現有的“數據倉庫”沒有按照數據倉庫最佳實踐來進行架構,所以它達到了持續滿足用戶需求需要的可維護性和可擴展性的實際極限。此外,如果一個新的計費系統正要上線,很明顯不容易調整現有的系統適應新的數據。因此,可見正確設計數據倉庫十分重要。

外部驅動。數據倉庫項目是一個銷售團隊的最初設想,這個團隊是全球領先的數據倉庫和商業智能軟件供應商之一的銷售團隊。在提供指導和售前支持時,這個銷售團隊幫助項目贊助商了解項目,并向擁有最好行業實踐知識、經驗豐富的商業智能咨詢師尋求幫助。雖然在銷售方面做了很多努力,項目的范圍、成本和進度的初步估計,顯得過于雄心勃勃。

開發團隊。開發團隊是外部數據倉庫承包商。因為公司現有的IT人員有其他優先的工作,公司沒有那些具備深厚商業知識或現有操作系統知識的開發人員。然而,開發團隊在公司找到了商業和技術專家,從軟件供應商那里獲得了技術專家。雖然最初的發現工作充滿了挑戰,但所有的利益相關者都積極參與了。

客戶。新數據倉庫的主要“客戶”是公司財務部門,項目由首席財務官提供資金。他們有一個相對集中的目標——獲得更可靠的收入和盈利信息。他們也有大量現成的報告,在常規基礎上用于商業分析,為需求分析提供一個合理基礎。

項目管理。項目管理(PM)由企業IT部門負責,他們使用傳統項目管理研究所/項目管理知識體系(PMBOK)實踐。IT團隊同時參與其他兩個大型開發項目,項目都直接或者間接地影響數據倉庫范圍。

托管環境。因為有限的資源和基礎設施,公司IT領導最近決定和一個應用服務提供商(ASP)合作,為新開發的生產系統提供托管服務。數據倉庫將托管在位于美國西海岸的設施中,而公司總部在東海岸。不能解決的問題是,地理分隔的確對大量數據移動有影響,因為操作型系統仍然在東海岸的企業IT基礎設施中。

項目成果

最初的項目計劃要求初始數據倉庫在三個月內完成,但這個發布周期太雄心勃勃了。在項目啟動之后,整整8個月才完成,晚了5個月!用戶驗收測試并不順利。用戶對項目延遲已經很惱火,當他們終于看到所承諾的功能時,得到的功能和期望的功能有著很大差距。由于項目延遲很常見,所以在努力回到正軌時,一般會增加開發團隊的人數。正如Fred Brooks說的“在延期項目內增加人員只會讓項目更延期”(Brooks 1975)。最終,項目成本遠遠超過預算,用戶不滿意,項目被擱置直到下一步計劃可以延續開發。

追溯

那么誰是罪魁禍首?每一個人!用戶感覺開發者“未擊中目標”,沒有實現他們的所有需求。開發者感覺用戶的期望沒有被妥善管理,項目范圍超出了控制。項目發起人感覺供應商過度承諾、較少實現。供應商感覺這個公司的內部政治和組織問題應該受到譴責。最后,組織中的多數IT人員感覺缺乏所有權,并偷偷地慶祝失敗。

項目最終淪為一系列的會議,在會議中進行合同和項目文檔的審查,看看誰應該承擔責任。你知道嗎?涉及的每一個人都應該承擔責任。除了數據倉庫開發的常規技術挑戰外,以下內容被確定為項目失敗的根源:

合同沒有平衡好范圍、時間進度和資源的問題。

需求是不完整的、模糊的和開放的。

批準的需求和設計文檔有相互矛盾的解釋。

開發者花很多個夜晚和周末試圖響應用戶更改和新要求,卻不斷地陷入混亂。

技術團隊害怕公開即將到來的失敗預警信號,繼續努力兌現不切實際的承諾。

開發者沒有充分理解用戶的需求或者期望,也沒有很好地管理需求更改。

現有的知識基于之前的報告應用,使得用戶對數據倉庫的目的有著明顯誤解(不是數據倉庫的好模型)。

供應商提出了雄心勃勃的承諾,開發者不能在預期的時間內按時交付。

項目經理沒有管理用戶期望。

IT人員隱瞞了開發者的重要信息。

ASP合作伙伴沒有提供開發者期望的連接性水平和技術支持。

事后看來,在項目的最后幾天,以下幾個事情是顯而易見的:

在開發者、用戶、利益相關者和內部IT專家之間的高度互動,可以確保正確地理解所有參與者的意圖。盡早且頻繁地交付可用的軟件,不論這些軟件多么簡單,都能大大降低用戶的誤解,提高他們預期的精度。更加注重用戶協作能夠避免對需求進行解釋時的前后矛盾。關注并響應變化的項目計劃比滿足一系列“凍結”的合同要求更有利于提高用戶對最終產品的滿意度。最后,不要去責怪誰,引起這個項目和其他數據倉庫項目失敗的根源,是開發者和用戶之間理解及期望的鴻溝。

關于本書

大約是同一時間,還沉浸在失敗痛苦項目的陣痛中,我遇到了Jim Highsmith,敏捷運動的締造者之一(《自適應軟件開發》、《敏捷軟件開發生態系統》和《敏捷項目管理》的作者,本書所屬系列的《敏捷軟件開發系列》的編輯)。Jim傾聽了我對項目困難的抱怨,傳授給我很多經驗,我開始思索敏捷方法如何適應DW/BI系統開發。不幸的是,我遇到Jim時已經太晚了,不能拯救那艘還在下沉的船。從那時起,我和Jim成了很好的朋友,幾乎每周都邊喝咖啡邊交換想法。當然,幾乎都是他分享很好的點子,我盡可能地吸納它們。Jim成了我的敏捷導師,自從我們第一次見面后,我暗下決心在今后的職業生涯中要確保再也不會遇到失敗的DW/BI項目。現在看起來這是個很大膽的目標,但是我相信人生苦短,不應該承受那些注定會失敗的項目;敏捷開發是一個我們所掌握的最好的項目風險緩解方法;敏捷開發是革新我們可用的高價值、高品質、可用的DW/BI系統的最佳方法。這就是本書所講述的內容:

緩解DW/BI項目風險

創新高價值的DW/BI 解決方案

玩得開心

從上一次痛苦的項目經歷之后,我有了很多很好的機會,使敏捷開發方法適應DW/BI系統開發的獨特特點。和一些非常有才華的敏捷DW/BI從業者共事,我成功地適應、實現和細化了一整套項目管理和技術實踐,并創造了敏捷分析開發方法。

這種適應是不平凡的,我們要面對很多重要且獨特的但是主流軟件開發人員不用面對的挑戰。DW/BI開發者需要處理集成了商業軟件和編寫自定義代碼(ETL腳本、SQL、MDX及常見應用程序)的混搭組合。DW/BI開發團隊往往擁有廣泛且方向不同的技術人員。DW/BI開發基于大量數據,并基于一個操作型、遺留和專業系統的復雜混合物。DW/BI系統開發平臺經常是高端專用服務器或者服務器集群,復制沙箱開發和測試就會更加困難。因為這些和更多其他原因,敏捷軟件開發方法并不總是能夠輕松地適應DW/BI系統開發,我遇到了一些放棄嘗試的DW/BI開發者。本書將介紹對敏捷DW/BI來說必不可少的關鍵技術和項目管理實踐。每個實踐將用一個例子徹底地闡述和論證,我將會告訴你如何修改每個實踐,讓它更好地適應具體情況。

本書的讀者對象是以下三類人員:

想學習敏捷技術、學習如何將敏捷技術應用到熟悉且復雜的DW/BI開發中的DW/BI從業者。我為這些讀者提供了涉及商業智能和以數據為中心項目的敏捷技術及項目管理技術細節。

那些想知道怎么把熟悉的敏捷實踐應用到DW/BI系統開發復雜性中的敏捷實踐者。為這些讀者我闡述了商業智能項目的特點,它們顯著不同于軟件開發項目的系統,我展示了如何讓敏捷準則和實踐適應這些獨特的特點。

有責任監督計劃投資組合的IT和工程管理者,包括數據倉庫、商業智能和分析項目。這類讀者既沒有深厚的商業智能技術專長,也沒有敏捷方法專長。我為這些讀者展示了對一個方法的介紹,這個方法可以幫助大家提高項目成功和取悅客戶的可能性。

雖然本書不是DW/BI系統基礎的引子,但是我經常會為了第二類讀者,偶爾偏移主題到DW/BI基礎上。那些熟悉商業智能的讀者可以輕松地跳過這些內容。

順便說一下,雖然我不是所有類型企業IT系統的專家,例如企業資源計劃(ERP)實現,但是我有理由相信敏捷分析的原則和實踐可以輕松地適應這些類型,在這些環境中很好地工作。如果你是一名IT執行者,你可能要思考組織中更廣泛的敏捷開發背景。

為什么是一本敏捷DW/BI的書

在過去幾年中,敏捷軟件開發運動持續爆發。敏捷成功的故事比比皆是。經驗證據持續增加,強有力地支持了敏捷軟件開發。敏捷社區在過去短短幾年中急劇增長,很多大型企業在他們的IT和工程部門都采用了敏捷。關于敏捷軟件開發各個方面的書籍也在增多。

不幸的是,在數據和商業智能社區,敏捷方法沒有得到大面積的普及。由于一些奇怪的原因,數據社區和軟件開發社區一直彼此獨立地成長和發展。在一個社區中發生的大突破在另一個社區往往不會發生。20世紀90年代面向對象的繁榮就是一個典型的例子。軟件開發社區把面向對象融入他們的DNA中,已經獲得了巨大的收益,但是面向對象的數據庫開發仍然是數據社區的非主流。

不論何時,在與DW/BI從業者和數據庫開發者交談時,他們常見的反應都是敏捷方法不適用于以數據為中心的系統開發。他們的論據是廣泛而多樣的,幾乎都基于神話、謬論和誤解,例如“發展和更改數據模型太耗時了。在開始開發報告和其他用戶功能之前,你必須完成物理數據模型。”

現實是,對于以數據為中心的系統,沒有任何特殊的地方會讓敏捷準則無關或者不適當。敏捷實踐必須適應挑戰,以數據為中心的系統開發必須采用不同的工具集。雖然目前很多關于敏捷概念和技術的書籍直接與數據社區有關,但是它們中的大多數并不直接與數據頭腦讀者對話。不幸的是,目前的很多敏捷書籍使用最新平臺、框架和程序語言,過于狹窄地專注于那些新的、零起點的軟件開發。這就很難讓讀者去推斷在這些書中展現的理念,到底是針對數據庫開發、數據倉庫開發、ERP實施,還是遺留系統的開發。

敏捷作家和數據庫專家Scott Ambler撰寫了關于敏捷數據庫開發和數據庫重構(一個敏捷實踐)的書籍,以促進數據庫社區進行敏捷對話。同樣,我寫本書邀請DW/BI社區進行敏捷運動,因為敏捷是一個在大型復雜DW/BI系統方面工作得更好的方式。2008年Ralph Hughes的書《敏捷數據倉庫》(Agile Data Warehousing)上架銷售(Hughes 2008)。Ralph為Scrum和eXtreme Programming(XP)技術適應數據倉庫的細微差別做出了杰出的貢獻,這其中的大多數概念也在本書中得以展現。此外,本書的目標是深入到很多需要以敏捷方式來開發的技術實踐中。

敏捷分析—我的用意是什么

我選擇“敏捷分析”(Agile Analytics)這個技術術語,除了它能精確地捕捉我的重點外,更多的是因為它朗朗上口、易于管理。它涵蓋了敏捷數據倉庫、商業智能和分析包。數據倉庫社區使用術語數據倉庫指代后端管理和數據分析準備;商業智能指代面向用戶的前端應用,從倉庫分析展現數據。術語“分析”經常用于表明包含數據定量分析(例如,預測建模、統計分析等)的更先進的商業智能方法。此外,行業術語“商業智能”有時候是一個含糊、包羅萬象的術語,包括任何與數據驅動商業流程(商業性能管理、客戶關系管理等)或者決策支持(記分卡、儀表盤等)有關的東西。

我使用敏捷分析的稱呼并不意味著敏捷方法只適用于某一類面向用戶的BI應用開發。敏捷方法對數據倉庫開發和商業智能以及分析應用開發都是適用和適應的。對于很多人來說,敏捷BI開發區域更容易想象,因為人們經常想當然地認為數據倉庫已經建好了、填充完了。當然,一個已經存在的數據倉庫簡化了建立BI應用的必要工作。然而,你不應該借此來認為數據倉庫必須比BI應用優先完成。實際上,敏捷分析是一個用戶價值驅動的方法,高價值的BI能力驅動支持數據倉庫組件的進化發展。這樣,我們就能避免過度構建數據倉庫去支持超過其預期的目的。

在本書中,我主要專注于DW/BI系統的核心—數據倉庫。本書中使用的“商業智能”術語或者BI術語應包括分析、報告和查詢應用。當使用DW/BI系統術語時,你應該推斷我的意思是核心數據倉庫和任何供應倉庫的性能應用,例如一個財務儀表板、一個預測門戶或者其他一些BI應用。然而,DW/BI的首字母縮寫有時候會比較笨重,我偶爾可能會單獨使用BI。大多數情況下,你應該認為我的意思包含DW。書中也涉及一些先進的BI概念,例如數據挖掘和數據可視化。我把具體BI項目(例如CRM實施)留給讀者去推斷實踐。所有原則仍然適用。

誰應該讀本書

敏捷DW/BI團隊不僅僅由開發者組成。它包含客戶(用戶)社區(提供需求);商業利益相關者社區(監視BI系統對業務改善的影響);以及技術社區(開發、部署和支持DW/BI系統)。這些社區由一個項目經理、一個業務分析師(或產品負責人)和一個贊助執行人聯系在一起。這些社區中的每一個都在項目成功中扮演著至關重要的作用,也都需要一套定義良好的有效敏捷實踐。本書將涉及一個或者多個社區的業務和技術讀者。

在本書中的一切不是對每個人都有意義,但是有一些內容對每個人都有意義。我和很多組織工作過,他們尋求敏捷訓練、輔導和指導。我偶爾會打消敏捷只適于開發者和技術人員的神話。

在一家邀請我去工作的公司里,贊助培訓的一個執行者這樣說:“如果我們的工程師開始敏捷開發,我們可以更快地完成項目,我們的客戶也會更開心。”這句話代表了一些不幸的誤解,可能會讓敏捷團隊掃興。

第一,成功的敏捷需要所有團隊成員的思維有所改變。客戶社區成員必須明白他們的時間被要求用于探索和練習新完成的功能,同時提供持續的寫入和反饋。管理團隊成員必須充分考慮項目風險和不確定性,調整他們的期望,團隊也要適應不可避免的變化。技術團隊必須學會整個包含大量紀律和嚴密性的新的工作方式。項目界面社區必須致力于日常項目解決,轉變他們的角色,給項目成功做出貢獻。

第二,敏捷并不總是意味著更快地完成項目。即使是最好的項目團隊在完成的工作范圍方面也會有局限性。敏捷實踐督導團隊,盡早傳遞高價值和最大風險的功能。因此,敏捷DW/BI系統能夠早點推出是可能的,前提是最關鍵的功能完成并被接受。然而,我建議不要明顯加快項目周期,尤其是在開始時。另一方面,相比傳統DW/BI開發方法,敏捷能提高質量和客戶滿意度。

采用敏捷DW/BI成功的底線需要所有上述項目社區的成員的認識、理解和承諾。出于這個原因,我嘗試把本書設計為提供一些和大家都有關系的內容。

本書是如何組織的

本書分為兩個部分。第一部分側重于敏捷項目管理技術和團隊協作,具體包括以下幾章。

第1章提供了DW/BI方法的概述和基線。

第2章介紹了一組有效的實踐,包括章程、規劃、執行和檢測一個敏捷分析項目。

第3章介紹了一組成立一個高度協作項目團隊的指導原則和實踐。

第4章介紹了故事驅動替代傳統需求分析,展現了如何使用案例和用戶故事驅使價值持續傳遞。

第5章介紹了一個團隊管理和領導的敏捷風格如何有效地替代傳統命令控制風格。

第一部分是寫給任何涉及敏捷分析項目的人,從贊助執行人、項目經理到商業分析師和產品負責人,再到技術總監和交付團隊成員。這幾章建立了一套核心實踐,可幫助敏捷項目社區開辟一條道路,一起走向成功。

第二部分側重于必要的、能夠持續傳遞商業價值并有質量保障的技術方法。這一部分包括以下幾章。

第6章展示了進化設計過程是如何工作的,確保產出高品質的數據模型和最小技術債務的系統組件。

第7章介紹了一組自動測試的實踐和工具,為了使用一個測試為先的方法,建立數據倉庫和商業智能組件。

第8章介紹了一系列保持整個DW/BI系統在版本控制下和配置管理的技術和工具。

第9章展示了如何把測試自動化和版本控制實踐組合起來,建立一個持續集成環境,保證不斷發展的系統的質量。

第10章包括一些剩余的因素和注意事項,它們對成功采用敏捷分析方法至關重要。

我把這部分作為現代開發實踐的集合,這些實踐用在每個DW/BI項目上,做到敏捷或者保持傳統(例如,瀑布式開發)。然而,當采用敏捷分析方法時,這些技術實踐是必不可少的。這些方法建立了最小化但足夠的一組必要的技術實踐,以成功地持續、漸進和進化地傳遞高價值的DW/BI系統。

當然,這些技術章節應該由技術團隊領導和團隊成員閱讀。然而,我也建議非技術項目團隊成員閱讀這幾章的每個導言部分。這樣做將幫助非技術成員建立對這些實踐目的的共識,能欣賞技術團隊努力的價值。

本書該怎么讀

我認為敏捷分析技術可支持下列要點。

敏捷DW/BI管理:一系列致力于幫助你運行項目的實踐,包括敏捷前兆、敏捷項目管理方法、敏捷團隊、開發者-用戶界面等。

敏捷DW/BI技術方法:一系列實踐,致力于開發和傳遞高價值、高品質、可用的DW/BI系統,包括具體的技術實踐,例如故事驅動開發、測試驅動開發、構建自動化、代碼管理和重構等。

各章被組織成這些主要部分。每一章專門針對一個關鍵實踐或者一組相關實踐,以本章要點的高層概述開始,逐漸深入主題。有些章內容足夠豐富,足以成為一本書。在這種情況下,我的目標是讓讀者對這個話題有堅實了解,并為其深入自學提供動力。

如果你想對敏捷DW/BI有一個高水平理解,那么閱讀每一章開頭的初步概述就足夠了。在這些概述中我的目標是為每一個敏捷DW/BI實踐提供一個準確的寫照,但是這些部分不講述所有必要的技術。

如果你是一個數據倉庫經理、項目贊助者或者任何需要很好地理解實踐而不深入技術細節的人,那么我建議你閱讀每一章的中間部分,尤其是項目管理部分。這些部分旨在提供對如何使用這些技術或者理解它們如何用于項目的足夠深入的理解。

如果你是一個日常項目團隊成員(項目經理、技術團隊成員、業務分析師、產品經理等),我建議你閱讀每一個項目管理章節(第一部分)的細節和例子。這些旨在給你一組具體的技術,以應用于你的釋放規劃、迭代集合和所有其他項目管理及用戶協作活動。如果你是技術社區的一名成員,第二部分就很適合你。

關于DW/BI技術有一句話:和技術無關。我使用很多技術棧來完成DW/BI的開發,這些技術棧包括IBM DB2為中心、Oracle為中心、SAS為中心、Microsoft為中心以及各種混合技術的技術棧。當某些技術能比其他技術更好地走向敏捷DW/BI時,我深信本書介紹的指導原則和實踐是技術獨立的,不論你的工具是什么,都可以做到有效。

數據倉庫和商業智能工具供應商的數目在不斷增加,他們標榜他們的商品為敏捷。前瞻性的供應商的工具和工具組,例如WhereScape、Pentaho和Balanced Insight等提供了成為敏捷的令人興奮的可能性。雖然我并不相信你一定得使用這些工具才能采用敏捷方法,但是它們肯定給敏捷團隊提供了一些巨大的好處。敏捷軟件開發社區從這些自動化困難的開發活動的工具中獲得了很大的益處,我也期待著我們的社區能夠隨時從供應商那里獲得益處。同時,我會告誡你不要相信在你開始成為敏捷之前,你必須擁有這些工具。相反,我鼓勵你以敏捷技術和實踐開始,在你確定工具足夠有益處時,逐漸地采用該工具。

致謝

沒有這些關鍵人物的貢獻,我永遠也不會得到我需要寫進本書的經驗和知識。我尊重和感謝這些朋友和同事,讓我和他們有許多非常寶貴的互動,并且得到最終在敏捷分析方法中運用的協作。

首先我的朋友Jim Highsmith是我開始敏捷之旅最信賴的顧問和導師。在我第一次遇見他時,Jim正著手撰寫《敏捷項目管理》的第1版,他讓協作看起來如此簡單,我覺得我也該試試。事實證明,這比看他做要難太多了。每周和Jim的早餐討論,是我書中概念成形的關鍵。他自愿擔當我的編輯,審查初稿,幫助我把文章變得更具凝聚力和連貫性。Jim不斷挑戰我的假設,給我新的想法和新的方法來思考開發的復雜性。就算寫書不是我的最高優先級時,他也沒有放棄。謝謝你,Jim。

Jim介紹我和Luke Hohmann認識,那時Luke正在尋找一個同時具備數據倉庫經驗和敏捷知識的人。Luke是我見過的最具遠見的人之一。我足夠幸運成為Luke創新理念的首席架構師:一個復雜的托管企業DW/BI 產品,由Luke的一個客戶提供。這個項目的復雜性和Luke深厚的敏捷技術知識,使我(和我的團隊)深刻理解了將敏捷軟件方法應用于DW/BI開發的精妙之處。本書中的概念源自在后續的項目上已經完善和成熟的經驗。7年過去了,Luke已經成為我很好的朋友,我非常珍惜他的智慧和遠見。謝謝你,Luke。

上述項目的團隊仍然是我經歷過的最好的敏捷團隊,不論是作為參與者還是敏捷教練。團隊成員包括David Brink、Robert Daugherty、James Slebodnick、ScottGilbert、Dan O’Leary、Jonathon Golden和Ricardo Aguirre。每個團隊成員都帶來了一系列特殊的技能和觀點,經過一個三年之久的項目,這些朋友和隊友幫我找出為DW/BI開發提供敏捷技術的有效方法。從那之后我有很多和這些朋友共事的項目機會,進一步完善了敏捷分析概念。這些團隊成員驗證和調整了在復雜和真實情況下的敏捷分析實踐,他們功不可沒。謝謝你們。

Jim Highsmith還介紹我和Scott Ambler認識。Scott領導了為以數據為中心的系統開發提供敏捷的變革。幸運的是,對于我們所有人來說,Scott是一個多產的作家,無私地在他的書中和他的ambysoft.com網站上,分享他的想法。我從和他的對話以及他的著作《敏捷建模》、《敏捷數據》、《敏捷統一過程》和《數據庫重構》(與Pramod Sadalage合著)中獲益良多。在早期關注DW/BI中的敏捷的日子中,Scott和我經常感嘆我們的觀念:數據社區不重視敏捷的益處,軟件社區不重視數據庫開發和系統集成的獨特挑戰。Scott花費了很多時間審閱本書。他讓我思考很多,和我分享我可能會錯過的理念。謝謝你,Scott。

在和Addison-Wesley的編輯Chris Guzikowski與編輯助理Raina Chrobak合作之前,我并不真正了解一個人有“圣賢的耐性”的真實含義。事實證明,我是一個痛苦的、進度緩慢的作家,并不擅長在寫作最后期限前應用敏捷原則。非常非常感謝Raina 和Chris,他們非常有耐心,我在最后期限之后才完成協作。希望以后有機會作為作家救贖我自己。

Ralph Hughes的《敏捷數據倉庫》在我寫本書時上架銷售。Ralph和我在那時結識,并成為朋友和同事。感謝他在這個領域的工作、和我進行的討論以及他分享給我的經驗。雖然我盡量不重復Ralph已經出版的內容,但是我深信我們的做法是一致的并且互補。期待在我們的思想成熟發展時,與Ralph合作。

最后,在本書中展現的觀點,從愿意審閱初稿的,并給我指導的那些聰敏、深思熟慮的人們身上獲益良多。除了Scott和Jim的審閱處,還要特別感謝Jonathon Golden,我的項目自動化大師,以及Israel Gat,敏捷先驅和技術債專家。還要感謝DW/BI專家Wayne Eckerson和Dale Zinkgraf,以及敏捷數據專家Pramod Sadalage為我提供的寶貴意見。他們的貢獻是無價的。
內容簡介:

敏捷方式,可以為任何數據倉庫(DW)、商業智能(BI)或分析項目帶來更多的創新、價值和更高的質量。然而,必須仔細地調整傳統的敏捷方式,以適應DW/BI項目的獨特之處。在本書中,敏捷先驅Ken Collier會告訴我們如何去做。
全書分為兩部分,共10章,從架構到管理,從自動化測試到持續集成,通過豐富的工作實例,系統而深入地講解敏捷DW/BI的基本原理、關鍵技術和項目管理實踐,為在真實商業智能和數據倉庫項目上應用敏捷分析方法提供系統實用指南。從管理角度,詳細介紹敏捷分析的基本原則,敏捷項目管理的有效實踐,包括章程、規劃、執行和檢測敏捷分析項目的有效實踐,以及成立高度協作項目團隊的指導原則和實踐,展現如何使用案例和用戶故事驅使價值持續傳遞,并講解團隊管理和領導的敏捷風格如何有效地替代傳統命令控制風格;從技術角度,深入講解能夠持續傳遞商業價值并有質量保障的技術方法,包括最優設計推進、測試驅動的數據倉庫開發、版本控制和項目自動化,以及應用敏捷分析時的一些注意事項。
本書內容全面,講解深入,并且涵蓋許多經過實踐檢驗的解決方案, 適合IT決策者、數據倉庫專業人士、數據庫管理員、商業智能專家和數據庫開發人員參考。



本書介紹了在平臺不可知的情況下整合基礎設施的敏捷解決方案,這些基礎設施包含不同運作方式、遺留問題,以及混合了商業和客戶代碼的專業系統。Collier通過豐富的工作實例展示了如何使用廣泛的技巧來管理分析開發團隊,如何支持巨大的和快速增長的數據量。無論你的項目是“后端”的數據管理,還是“前端”的商業分析,或是二者兼而有之,本書都將為你實現最優價值提供實用指導。
第一部分關注敏捷項目的管理技術和團隊協作,介紹有助于敏捷DW/BI項目團隊進行協作并取得成功的核心實踐。
第二部分側重于必要的能夠持續傳遞商業價值并有質量保障的技術方法,包括最優設計推進、測試驅動的數據倉庫開發、版本控制和項目自動化。
目錄:

譯者序

序 一

序 二

前 言

第一部分 敏捷分析:管理方法

第1章 敏捷分析概述2

1.1 阿爾卑斯風格的系統開發2

1.2 什么是敏捷分析5

1.2.1 敏捷分析的含義5

1.2.2 指導原則7

1.2.3 傳言與誤解7

1.3 數據倉庫架構和技能9

1.3.1 數據倉庫概念架構9

1.3.2 多樣化、截然不同的技能10

1.4 為什么我們需要敏捷分析11

1.4.1 第一個事實:建立DW/BI系統是困難的11

1.4.2 第二個事實:DW/BI開發項目經常失敗12

1.4.3 第三個事實:最好是快速失敗和適應13

1.4.4 敏捷真的很好嗎13

1.4.5 敏捷分析的困難14

1.5 FlixBuster分析15

1.6 小結16

第2章 敏捷項目管理18

2.1 什么是敏捷項目管理19

2.2 連續性分階段的DW/BI開發  22

2.3 設想—探索取代計劃—執行23

2.3.1 設想階段23

2.3.2 探索階段24

2.4 改變項目管理角色26

2.5 搞清楚敏捷“口味”的意義27

2.6 敏捷原則28

2.6.1 恰到好處設計29

2.6.2 同步日報30

2.6.3 把每件事都放到時間盒子中30

2.6.4 同處一室的團隊32

2.6.5 注重技術債33

2.6.6 計劃能力和監控速率34

2.6.7 跟蹤每日進展35

2.6.8 監控故事完成,而不是任務時間39

2.7 小結40

第3章 社區、客戶、協作42

3.1 什么是敏捷社區和敏捷協作43

3.2 敏捷項目社區47

3.3 信任等級49

3.4 協作機制50

3.5 消費者協作53

3.6 執行者協作56

3.7 決策者協作57

3.8 敏捷先決條件58

3.9 小結59

第4章 BI系統的用戶故事61

4.1 什么是用戶故事62

4.2 用戶故事與需求64

4.3 從角色到用例,再到用戶故事66

4.3.1 用戶角色67

4.3.2 用例建模69

4.3.3 在事件流中找到用戶故事71

4.3.4 用例場景72

4.4 分解敘事文72

4.5 什么是最短小、最簡單的用戶故事75

4.6 故事優先級和待辦事項管理79

4.6.1 基于價值來評定優先級79

4.6.2 基于性能來評定優先級80

4.6.3 評定優先級的過程80

4.6.4 待辦事項管理81

4.7 評估故事的分值82

4.8 停車場圖表85

4.9 小結87

第5章 自我規劃可以提升團隊表現88

5.1 什么是自我規劃的團隊89

5.2 自我規劃需要自律93

5.3 自我規劃需要責任共擔94

5.4 自我規劃需要團隊工作協議95

5.5 自我規劃需要遵守承諾96

5.6 自我規劃需要透明開發98

5.7 自我規劃需要遵守公司標準99

5.8 小結100

第二部分 敏捷分析:技術方法

第6章 不斷發展卓越的設計102

6.1 什么是進化設計104

6.2 需要多少前期設計107

6.3 敏捷建模108

6.4 數據模型模式110

6.5 管理技術債112

6.6 重構113

6.6.1 什么是重構115

6.6.2 什么時候重構117

6.6.3 如何重構118

6.6.4 關于重構最后的話119

6.7 部署倉庫更改120

6.7.1 藍綠部署121

6.7.2 數據庫版本化122

6.8 其他采用發展方法的原因122

6.9 案例研究:自適應倉庫架構124

6.9.1 產品演變125

6.9.2 架構概述126

6.9.3 觀察型消息模型128

6.10 小結135

第7章 測試驅動的數據倉庫開發137

7.1 什么是敏捷分析測試138

7.2 敏捷測試框架140

7.3 BI自動化測試143

7.3.1 BI測試過程144

7.3.2 數據庫測試工具145

7.3.3 測試什么148

7.4 沙箱開發150

7.5 測試優先的BI開發153

7.5.1 單元測試驅動開發153

7.5.2 故事測試驅動的DW/BI開發155

7.5.3 生成故事測試155

7.6 BI測試指引157

7.7 安裝時刻157

7.8 功能性的BI測試158

7.9 小結159

第8章 數據倉庫的版本控制160

8.1 什么是版本控制161

8.2 存儲庫164

8.2.1 什么數據要存儲164

8.2.2 什么數據不存儲165

8.3 用文件夾來工作166

8.3.1 什么是版本167

8.3.2 打標、分支、合并168

8.3.3 解決沖突169

8.4 組織管理存儲庫171

8.4.1 注釋文件171

8.4.2 目錄172

8.5 打標和分支174

8.5.1 什么時候打標和分支174

8.5.2 為標簽和分支命名176

8.5.3 保持簡單178

8.6 選擇有效的工具179

8.7 小結181

第9章 項目自動化182

9.1 什么是項目自動化183

9.2 快速入門185

9.3 構建自動化186

9.3.1 簡易自動構建187

9.3.2 更加先進的自動構建189

9.3.3 什么時候開始194

9.4 持續集成195

9.4.1 構建頻率195

9.4.2 預設構建196

9.4.3 觸發構建196

9.4.4 設置持續集成197

9.5 按鈕發布200

9.5.1 什么是發布200

9.5.2 準備發布200

9.5.3 綁定發布201

9.6 小結204

第10章 最后的話206

10.1 專注于真正的問題206

10.2 做到敏捷和執行敏捷207

10.3 粗糙問題209

10.4 新興技術210

10.5 采用的策略211

10.5.1 可預見的混亂211

10.5.2 領導責任213

10.5.3 目標和商業校準213

10.5.4 敏捷采用路標方式213

10.5.5 培訓和輔導214

10.5.6 衡量成功215

10.6 結束語215

參考文獻與推薦閱讀217
序: