2023年，kent beck和其他16位知名軟體從業者共同簽署了下面的這份「敏捷軟體開發宣言」:
我們正在通過親身實踐 以及幫助他人實踐的方式來揭示更好的軟體開發之路，通過這項工作，我們認識到：之所以有這份宣言的出現，是因為一部分人不滿足於傳統軟體開發過程為了適應需求變更而付出的昂貴成本。· 個人和他們之間的交流勝過了開發過程和工具
· 可執行的軟體勝過了寬泛的文件
· 客戶合作勝過了合同談判
· 對變更的良好響應勝過了按部就班地遵循計畫
也就是說，雖然上述右邊各項很有價值，但我們認為左面的各項具有更大的價值。
在現代經濟生活中，市場變化迅速、使用者需求變更無法控制、新的競爭對手不斷出現，因此很多情況下需求變更成為常態。
在傳統軟體過程中需求變更需要重新進行設計、修改、測試、評審並因此產生巨大的變更成本。為了適應這種變化，必須採用一種敏捷過程以拉低需求變更的成本。
敏捷資料科學能否照搬軟體的敏捷開發？答案是否定的。資料科學相比較於普通軟體開發增加了不確定性（即不確定早期建立的資料模型是否可用）、研究團隊和工程團隊的合作。
傳統的資料科學是一門嚴肅的研究，需要花費很長時間的從原始資料中構建有效的資料模型，這帶給應用開發者很大的壓力，因為等待資料模型完善的過程中，往往已錯過了最佳的上市時間，並且每一次需求變更都會帶來巨大的時間和其他成本。
因此誕生了敏捷資料科學，它的目標是記錄探索資料分析的過程並促進和指導這一過程，以期發現實現一款引人注目的資料分析產品的關鍵路徑，並沿著這條路走下去。
敏捷資料科學深入本質，關注探索資料分析的過程，並記錄在過程中收穫的認知。敏捷資料分析把這些當作產品的主要工作。通過抓住本質，我們把整個過程的焦點放在可**的事務上，而不是放在產品不可**的輸出上，這樣便於我們管理整個過程。
敏捷資料科學是一種圍繞網路應用開發展開的資料科學實踐。敏捷資料科學認為，適用於機構中發揮作用的資料科學過程的最有效輸出應為網路應用程式。它還認為應用開發是資料科學家的基本技能。
因此，從事資料科學變成了構建用於描述應用程式，包括快速的原型設計、探索性資料分析、互動式視覺化以及應用機器學習。
敏捷資料科學是圍繞下面這幾條原則進行組織的。
迭代，迭代，再迭代
發布階段性結果
原型實驗高於實施任務
在產品管理中仔細考慮資料的情況
上下求索於資料價值金字塔
找到實現殺手級產品的關鍵路徑並遵照執行
抓住本質
構建準確的用的資料模型可能需要經過多輪特徵工程和超引數調優。在資料科學中，迭代是提取、視覺化以及產品化不可或缺的環節。構建資料科學應用就意味著迭代。
迭代是構建分析型應用不可或缺的行為，這意味著每個週期結束時我們都會留下一些難以解決的遺憾。但如果我們不在週期結束前發布暫未完成的階段性作品，那就無法稱作敏捷開發。
在敏捷資料科學中，我們記錄和分享我們在工作中建立的未完成的資料。我們把所有工作都提交到**管理系統中，我們定期與團隊成員分享工作成果，也應盡快與終端使用者分享。
資料科學與傳統軟體工程的不同之處之一就在於它一般是研究一半是工程。在軟體工程中，產品經理讓開發者在某個階段完成一張圖表的開發。開發者將這個任務轉換為具體的**語句，並建立乙個網頁用於展示。在資料分析專案中這樣任務就完成了嗎？沒有，如此具體的圖表不大可能有什麼資料分析價值。
管理資料科學團隊意味著監督多個並行開展的實驗，而不僅僅是分配任務。良好的資料資產（**、圖表、報表、**）是作為探索性資料分析的結果出現的，所以我們應該多從實驗的立場思考問題而不是完成任務的立場。
能做成什麼與想做成什麼一樣重要。知道孰難孰易與知道需要什麼一樣重要。在軟體開發中，有三個方面需要考慮：客戶、開發人員、業務。而在分析型應用程式開發中，還有乙個方面需要考慮：資料。如果不掌握資料對於某個功能「不得不說的意見」，產品負責人就不算盡職。在產品討論中要始終考慮資料的情況，這意味著產品討論必須以視覺化為基礎，我們的工作重點在於通過內部應用程式進行探索性資料分析。
資料價值金字塔是模仿馬斯洛需求層次理論發展出的五層金字塔模型。它表達了原始資料經過**、圖表、報表到**模型的層層提煉所包含的越來越多的價值，每一層的目的都是提供更多行為依據或是改進現有的行為：
資料價值金字塔的第一層（記錄）與連通（plumbing）有關，目的在於打通資料集從採集到在應用中展示之間的流程。
圖表（chart）和**（table）層是資料優化和分析的起點。
報表（report）層提供沉浸式資料探索，幫助推理並了解資料。
**（prediction）層創造了更多價值，但要建立好的**模型，就需要進行特徵工程，這需要低層的支援。
最後一層，行動（action）層，它是人工智慧熱潮發揮作用的一層。如果你所得出的見解無法產生新的行動或是改進現有行動，那這個見解就不那麼有價值。
資料價值金字塔為我們的工作制訂了提綱。我們應該不僅僅要把這個金字塔當作要遵守的規則，還要時刻牢記在心。有的時候你會跳過一些步驟，有的時候你會搞錯順序。如果直接把新資料放到**模型中，而且不在底層把資料新增到應用的資料模型中使得資料集可以訪問且對於應用透明，那麼技術債就來了。你需要牢記，應該盡可能減少技術債。
為了盡可能地提高我們成功的概率，我們應該把大多數時間放在應用程式對於成功最重要的部分上。但是最重要的是哪部分呢？這需要通過實驗才知道。分析型產品的開發就是搜尋和追求移動的目標。
一旦確定了乙個目標，比如要做出**，我們就必須找到實現目標的關鍵路徑。如果這個目標被證明是有價值的，我們還要找到改進的關鍵路徑。隨著乙個又乙個任務的處理，資料被逐步提煉。分析型產品常常需要多個階段的提煉，涉及etl（提取、轉化、載入）過程、統計學技術、資訊訪問、機器學習、人工智慧、圖分析等。
這些階段的互動可以形成複雜的依賴網。團隊領導者應當掌握依賴網。他的工作就是確保團隊發現關鍵路徑，然後組織團隊按關鍵路徑完成。產品經理無法自上而下管理關鍵路徑，相反這應當由產品科學家自下而上找到。
如果我們無法輕易按照開發常規應用的日程交付做好產品，那我們交付什麼呢？如果不交付，我們就沒有做到敏捷。為了解決這個問題，在敏捷資料科學中，我們「抓住本質」。核心就是記錄分析過程，而不是我們要開發的應用的終極狀態。在迭代攀登資料價值金字塔的過程中交付階段性內容，遵循殺手級產品的關鍵路徑，這讓我們能夠敏捷。所以，產品到底從何而來？從記錄探索性資料分析的過程而來。
這七條原則共同驅動了敏捷資料科學方法學。它們為探索性資料分析，並且據此為構建分析型應用程式提供了框架和參考。可以說這是敏捷資料科學的核心。
《軟體工程》（原書第10版）
《spark 全棧資料分析》
大資料 專案流程
1.資料的預處理階段 2.資料的入庫操作階段 3.資料的分析階段 4.資料儲存到資料庫階段 5.資料的查詢顯示階段 reduce driver create table 表名 videoid string,uploader string,age int row format delimited fi...
大資料專案3
gmv 今天提交訂單的金額總和,不管是否支付 全站pv 頁面瀏覽量大砍一次就是乙個pv再重新整理一次又是乙個pv 全站uv 去重的訪客總和set mapreduce.framework.name local 本地 set mapreduce.framework.name yarn yarn set ...
在資料倉儲專案中實現敏捷
warren sifre是來自於allegient的一位bi解決方案架構師，他在部落格中分享了關於在資料倉儲專案中實現敏捷的觀點。他表示，為了實現這一目標，正確的團隊組成與心態是必不可少的。按照warren的說法，乙個資料倉儲專案包括以下開發任務 這些任務本質上存在著一些相互依賴，如果考慮在專案中實...