當我開始我的數據科學家職業生涯時，我並沒有真正的工作流程。在公司、潛在客戶和我之間，沒有人知道在“現實”世界中實施統計模型或機器學習方法意味着什麼。但是每個人都對這個“大數據”感興趣，
所以我們很快就開始做工作，但沒有明確我要做什麼。當我們遇到一個看起來像一個項目的東西時，我就投入了進去。爲了快速交付結果，我將數據提取加載到 R 中，並開始在其上應用各種不同的模型和算法。結果最終出現在 R 腳本的代碼註釋中，這些腳本通常會增長到數百甚至數千行。我擁有的唯一系統是按順序對腳本進行編號。很快，我發現自己置身於數十個腳本和中間結果的數據導出中，這些中間結果不再可重現。我無限期運行的 R 會話有時被錯誤地關閉，或者它崩潰了（隨着使用的內存增加，這必然會發生）。發生這種情況時，我花了數小時甚至數天來重新創建結果。截止日期是一場噩夢；到那時爲止我所做的一切都必須在最後一刻加載、加入和比較。通常情況下，模型結果與之前提到的不同，沒有任何跡象表明我之前弄錯了，我現在使用了錯誤的數據，或者引入了其他一些錯誤源。回想起來，我不知道一個好的工作流程對於做更大的數據科學項目的重要性。
敏捷的起源 （The Origins of Agile）
敏捷軟件開發不是關於如何完成工作的特定方法、流程或處方。相反，它是一套信念、一種哲學，應該指導軟件開發團隊做出最佳決策。敏捷當然不是憑空產生的，它是對當時無處不在的稱爲瀑布（Waterfall）的方法的一種反應。
在 Waterfall 中，大型軟件項目被劃分爲特定的階段，每個階段都應該完成，然後才能開始下一階段。隨後的這些階段是問題分析、設計項目、編寫軟件、測試，最後是實施和維護。
Waterfall 的目標是提供完整且無故障的軟件。Waterfall 項目的重中之重是文檔，其中詳細記錄了軟件的每個要求和方面。潛在的信念是，當軟件的所有方面都預先決定時，它的編寫速度更快，質量更高。
然而，使用瀑布方法完成的項目有一個主要的缺陷。它們可能需要很長時間才能完成。順序性和完整性的結合可能會導致項目在交付軟件之前持續多年。每次在後期階段中發現錯誤或不完整時，項目就會返回上一階段進行修復。由於整個過程持續時間長，經常出現最終結果不再適合不斷變化的市場的情況。問題分析可能是幾年前完成的，同時問題已經發生了變化。
在九十年代，人們對笨重的瀑布產生了幾種反應。軟件開發領域的許多有影響力的思想家開始探索編寫軟件的不同方式。建議採用替代流程，例如 Scrum 和 Xtreme 編程。最終，2001 年，一羣 17 人聚集在猶他州，起草了敏捷軟件開發宣言。他們簡短聲明是：
我們正在通過做和幫助他人來發現更好的軟件開發方法。通過這項工作，我們開始重視：
個人和交互勝過流程和工具
工作軟件優於綜合文檔
客戶協作而非合同談判
響應變化而不是遵循計劃
敏捷思維通過識別瀑布式思維中的許多缺陷，對軟件設計採用了截然不同的方法。首先，在開始編寫代碼之前不可能考慮到複雜設計和架構的所有方面。相反，軟件必須有機地增長。其次，客戶通常並不真正知道他們想要從產品中得到什麼，直到他們開始與之互動。從法律上講，在上班前檢查所有方面可能是個好主意，但這不會讓客戶滿意。最後，如果在交付工作產品之前需要很長時間，客戶和利益相關者將失去興趣並失去項目將完成的信心。
宣言附有源自這些價值觀的十二項原則。它們比四個值更適用，因此是做出選擇時的主要準則。它們是（編號由我添加）：
我們的首要任務是通過早期和持續交付有價值的軟件來滿足客戶。
歡迎不斷變化的需求，即使是在開發後期。敏捷流程利用變化來獲得客戶的競爭優勢。
頻繁地交付可工作的軟件，從幾周到幾個月不等，優先考慮較短的時間範圍。
業務人員和開發人員必須在整個項目中每天一起工作。
圍繞積極進取的個人建立項目。爲他們提供所需的環境和支持，並相信他們會完成工作。
向開發團隊和在開發團隊內部傳達信息的最有效和最有效的方法是面對面的交談。
工作軟件是進度的主要衡量標準。
敏捷流程促進可持續發展。贊助商、開發商和用戶應該能夠無限期地保持恆定的步伐。
對卓越技術和良好設計的持續關注可提高敏捷性。
簡單性——最大化未完成工作量的藝術——是必不可少的。
最好的架構、需求和設計來自自組織的團隊。
團隊定期反思如何提高效率，然後相應地調整和調整其行爲。
敏捷（Agile）方法
我們瞭解到，敏捷與其說是一種工作流程或一種方法，不如說是一種在必須做出選擇時指導我們的哲學。敏捷提倡嚴格遵循工作流程至關重要，我們應該持續監控我們的工作方式是否最適合遵循敏捷價值觀和原則。如果不是這種情況，則應調整工作流程。這並不意味着沒有與敏捷相關的工作流。
Scrum
最著名和應用最多的工作流是 Scrum。它開發於八十年代末和九十年代初，是一種久經考驗的方法論。Scrum 與 sprints 一起工作，設置時間單位，在此之後可交付的產品應該準備好。大多數團隊使用兩週的衝刺，但它們也可以更短或更長時間。團隊是完全自組織的，他們決定在下一個衝刺中要做什麼以及如何做。要完成的任務都收集在產品日誌中，它們的制定方式都清楚地表明它們將如何爲產品增加價值。這些用戶故事採用“作爲角色用戶，我想要操作/功能，這樣我才能受益”的形式”。假設您運營的網站向所有客戶發送時事通訊，但目前還沒有選擇退出的選項。創建這樣一個功能的用戶故事可以是“作爲訂閱用戶，我希望能夠選擇退出時事通訊，這樣我只在我想要的時候接收信息”。
Scrum Master的職責是確保團隊制定衝刺目標。爲此，她必須有一雙警惕的眼睛。如果銷售經理想要完成某件事並試圖說服咖啡機的開發人員之一，他會被親切地重定向到產品所有者，以將其記入待辦事項。如果一些團隊成員缺乏一些必要的技能，她會和他們一起制定如何獲得這些技能的計劃。此外，她將是不同 Scrum 會議（稱爲儀式）的組織者和協調者。
該產品所有者負責的產品看起來像什麼。他監控客戶的需求和願望，因此他的主要職責之一是利益相關者管理。他將功能請求和改進計劃轉化爲用戶故事。因此，他維護產品日誌，按重要性對故事進行排序。
產品負責人決定應該做什麼，開發團隊（可能還有其他專家）決定如何做。它是完全自組織的。在每個 sprint 開始時，團隊都會評估哪些故事可以在即將到來的 sprint 中完成。團隊成員通常有不同的專長，但故事的完成是整個團隊的責任。
四個儀式（會議）是 Scrum 循環的一部分。在 sprint 的開始是sprint 計劃，其中定義了故事的範圍並確定了已完成的定義。在衝刺期間，每天至少有一次站立會議，團隊成員在會上快速分享他們正在做的事情以及彼此的需求。衝刺完成後，團隊會組織衝刺評審，向團隊以外的人員展示已完成的工作。最後是回顧，團隊討論上次衝刺中哪些地方做得好，哪些地方可以改進。
看板 Kanban
板比 Scrum 輕得多，流程也少得多。它不適用於固定的時間單位，但與 Scrum 一樣，它旨在實現連續的流程。就像在 Scrum 中一樣，要執行的任務在用戶故事中制定，但承諾一次只針對一個故事。故事收集在積壓日誌中，並按重要性不斷排序。每次完成一個故事時，下一個最相關或最緊迫的故事就會開始。
中央是看板，可以是物理的，也可以是虛擬的，至少有以下幾列：to do、doing和done。這可以根據團隊的願望和需求量身定製。與 Scrum 不同，產品負責人沒有正式的角色，儘管讓某人處理傳入的請求仍然很有用。這可以是指定人員或同時從事開發工作的團隊成員。團隊不應一次專注於太多任務；所有被拉出來做的事情都應該儘快完成。這確保了重點始終放在前面最重要的任務上，並且將多任務處理降至最低。
團隊可以對每列中可以包含的故事數量設置上限。
中心指標是完成一項任務通常需要的時間，即週期時間。有效的看板團隊週期時間短，他們能夠快速完成任務。較短的週期時間使團隊能夠自信地估計何時完成工作。就像在 Scrum 中一樣，整個團隊負責完成一個故事，而不僅僅是“指定”的工作人員。爲了儘快完成任務，團隊成員可能會不時完成一些超出他們舒適區的任務。
高度結構化的 Scrum 和輕量級看板是兩個工作流程，使團隊更有可能遵循敏捷原則。他們都旨在持續發佈工作軟件，而不是致力於一個主要版本。他們還專注於您現在正在處理的部分，Scrum 通過修復在 sprint 中完成的故事，而看板限制了團隊正在處理的故事數量。但也有一些顯着的差異。在 Scrum 中，團隊承諾在此 sprint 中選擇要完成的故事，並且建築物必須先着火，然後才能進行不在 sprint 中的工作。看板只對正在進行的故事數量規定了限制，先完成你開始的事情，然後開始新的事情。然而，爲了接下來的故事，一切都可能隨時改變。
這兩種方法都取得了巨大的成功，重要的是要記住它們是達到目的的手段，而不是宗教。敏捷價值觀和原則應該是主要的指導方針，在選擇其中一個工作流程時，你這樣做是因爲這是以敏捷方式工作的最佳方式，因爲它最適合給定的情況。團隊應該自己決定什麼是最好的工作方式，並應該隨着情況的發展監控選擇是否仍然是最好的。然而，一般來說，當團隊正在完成項目時使用 Scrum 更有意義，而看板的靈活性最適合處理大量傳入請求的服務團隊。