計算機科學的誕生，是世人為了用數字手段解決實際生活中的問題。隨著時代的發展，技術的進步，人們對于現實世界中的問題理解越來越深刻，描述也越來越抽象，于是對計算機軟件的需求也越來越高，越來越復雜，變化也越來越頻繁。
　　而軟件技術的發展也是隨著人們認知水平和抽象能力的不斷提高，從面向過程編程，進化到了面向對象編程，再到日漸紅火的面向服務的編程。伴隨著思維的不斷進步，實現軟件的技術手段也隨之變遷，從最古老的瀑布流程，到RUP統一過程，到敏捷軟件開發，它們的出現無一不體現了需求，變化，效率，時間與質量的多方博弈。
　　今天，我們的主角就是炙手可熱的敏捷軟件開發。敏捷軟件開發老早就炒的如火如荼了，本人歷經幾家公司，也都在不同程度上受到這個理念的波及。

敏捷思想

　　傳統瀑布模型的弊端很明顯：過于強調文檔，開發和測試介入較晚、風險高，無法快速響應反饋，修改和重構成本過高。敏捷開發就是針對傳統的瀑布開發模式的這些弊端而產生的一種新的開發模式，目標是提高開發效率和響應能力。
　　敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。

　　為了了解敏捷開發，需要先了解敏捷開發宣言，為了表示對各位先驅的尊重，特抄錄在這里：

個體和交互 > 過程和工具 可以工作的軟件 > 面面俱到的文檔 客戶合作 > 合同談判 響應變化 > 遵循計劃 雖然右項也有價值，但是我們認為左項具有更大的價值。

　　然后需要了解一下敏捷開發的核心價值觀：

溝通：不但包括團隊內部的開發人員之間溝通、還包括團隊和利益相關人員之間的溝通。 簡單：簡單的實現和設計。正因為簡單，隨著對軟件理解的加深，也更容易的改進。 反饋：更早更快速的從用戶獲得反饋，這樣能保證軟件在做正確的事。 勇氣：當需要做出重大的決策，放棄或重構(refactor)你的工作，修正你的方向時，勇敢去做。 謙遜：尊重每一個參與項目的人，無論是團隊，還是客戶，甚至其他的利益相關人員，他們對項目都有價值。

　　純理論的不想說太多，當你實踐過敏捷開發以后再回頭來看看這些簡單的字眼，你會發現它們簡直就是至理名言(不管你信不信，反正我是信了)。

敏捷實踐
　　偉大的哲學家王守仁先生最偉大的觀點就是：知行合一，所以接下來就來看看敏捷開發的實踐。
　　踐行敏捷開發理論的流程很多，但是要說最有名的，那應該還是Scrum和XP(極限編程)，前者重在管理流程，后者重在編程實踐。實際使用中，能把這兩者結合起來的公司是少之又少，大多數的公司都是使用Scrum去管理項目，而XP，更多的是程序員們自己的興趣和愛好。由于本文重在管理，所以重點解析Scrum流程。
　　Scrum的流程基本可以用下圖來概括：

按照傳統的記敘文的寫作方式(時間、地點、人物，事情的起因、經過、結果)來描述一下Scrum流程就是：

時間：每個Release和每個Sprint 地點：辦公室，這個毋庸置疑，至于站著還是坐著，那就看個人愛好了 人物：整個團隊，包括管理人員，市場人員，客戶代表，程序員，測試人員，設計人員，通常分為3類：Product Owner：通常包括產品經理，產品負責人，運營人員；Scrum Master：通常包括項目經理，項目負責人；Team Member：通常包括開發人員、測試人員、美工設計等全職能性團隊。 事情的起因：客戶或客戶代表提出需求或者產品的反饋，公司研究決定推出新產品或新版本。 經過：1.Product Owner把需求和反饋轉化成User Story放到Backlog中；2.規劃Roadmap，然后集合Team所有人員討論決定最終Overview；3.Product Owner規劃Release Plan，根據Plan中的時間劃分Sprint；4.開始每個Sprint(2-6周不等，視實際情況而定)：1).Plan Meeting (可進行多次)：a).整個團隊根據Product Owner設定的任務優先級，選定該Sprint中需要完成的User Story和要處理的Bug。b).整個團隊討論選定的任務中的功能，確保每個人對功能的表現都有相同的認識。c).Scrum Master與開發團隊拿出撲克牌，估算每個任務的時間和難點。d).開發人員領取任務(先估算，后領取是有道理的)。e).測試團隊根據每個任務的描述，設定驗收的標準和案例。2).編碼與測試a).開發完成功能，進行單元測試。b).測試完成功能測試，有問題的報Bug。3).Standup Meeting (每天，或每幾天一次)a).Scrum Master與開發團隊，測試團隊一起同步一下開發與測試的進度。4).Review Meeting (可進行多次)a).整個團隊討論一下該Sprint的執行情況，驗收完成的功能，需要調整的方面加入到Backlog中或Bug中。b).整個團隊反思與總結一下該Sprint的經驗、教訓。c).根據反思的結果，指定一些Action Item，分配給相關人執行。 結果：Release新產品或新版本 道具：這個通常很重要，這里主要是管理Backlog和Bug的工具，比如我用過的JIRA，Rally等等，當然看板，燃盡圖等工具也很有意義，不管使用何種方式，目的都是管理項目的進度。

Scrum反思

1.產品與文檔
　　瀑布模型的弱點之一就在于文檔驅動；能工作的產品才是王道，但是簡明扼要，清晰的文檔也還是很有必要的，特別是對于團隊的新人來說，但是文檔的作用又不僅限于此。很多時候，一份好的WIKI Page可以讓其他的人快速的了解產品的設計與功能。

2.合作的真意與以人為本
　　這是我所在團隊做的很不足的一點，很多時候QA(測試人員)并不知道某一個Feature(功能)的設計與表現是什么樣的，往往是在測試的時候才會去向Dev(開發人員)了解該Feature的全部情況。而且很多時候，PD(美工人員)與Dev在商量Feature的表現的時候，QA并沒有參與進來。我們也想了很多的辦法去改善這種情況，比如一個Feature完成的時候，Dev給PD，QA一起演示一下Demo，但最終這個方法并沒有得到執行，原因很多，大家的時間安排也不一樣。
　　看樣還是符合那句老話：計劃容易執行難。人天生就是懶的，特別是IT人士，如何提高團隊的認識和執行力還真是一個問題。不論什么做法，前提還是需要得到大家的一致認同，這樣才會有基本的執行力。

　　我認為，敏捷開發中合作的真意就在于那份人的責任感，那份以人為本的核心理念。大部分敏捷開發中的問題就是由于Team中的許多人還不是具有“敏捷”思維的人所造成的。沒有敏捷開發的思維，沒有工作的激情，只有領導自以為是的指示，和拼命趕進度的急促步伐，這可能是很多國內開發者與國外的敏捷團隊最大的差別，這也是國內很多敏捷項目失敗的根本原因。

3.Meeting的頻率與內容
　　開會很多時候是很無聊的，這個大家一定深有體會了；但是Sprint中的各個會不應該是這樣的。在敏捷團隊的會議中，不存在領導驅動問答的形式，而是整個團隊針對會議議題暢所欲言，主體明確，目的達到以后就應該結束。這樣就能提高開會的效率。而開會的頻率，特別是Standup Meeting的頻率，很多團隊固守每天一次的頻率，個人覺得沒什么太大的必要，我們采取的就是兩天一次，覺得感覺很好。

4.User Story和Developer Story
　　User Story自然不必說，那大多數來自客戶的需求或者是Team的反饋。還有一些任務是來自QA或者是Dev的需要，比如自動化測試，框架的探索與設計，這些我們通常是處理成Developer Story，也算有點道理，不過感覺總是怪怪的，因為從我的角度來說，這些應該是分解，合并到各自的User Story中去的。

　　此外，由于User Story基本都是Product Owner添加的，所以開發中的的很多情況它們并不完全清楚，因此整個團隊在每個Sprint之前需要對這個Sprint中所有的任務進行討論和初步的可行性研究。

5.簡單設計，迭代，重構與演進式架構
　　按照敏捷開發的核心價值觀，代碼應該盡量簡單直接，不用太多的去考慮以后的擴展性，因為未來是不確定的。這么說是不是就不用考慮軟件的架構了呢？答案當然是否定的。
　　架構與開發流程根本就是兩個不同的概念，架構是軟件的骨架，而敏捷開發是構建軟件的過程，敏捷開發可以影響架構的最終面貌，但是卻不能消滅它。敏捷開發出現后，軟件架構設計的方式只不過是產生了如下的變化：敏捷開發把原先軟件過程前期的架構設計，分散到了整個敏捷開發軟件過程中，也就是每次迭代中。
　　在每次的迭代中，隨著功能的增加，需要不斷的重構以便使代碼滿足擴展性的需求。在先讓軟件運行，再重構其代碼的過程中，軟件的架構隨著重構自然而然的在軟件過程中產生，這中做法通常就稱為演進式架構，以前是設計完后開發，現在是邊設計邊開發。

6.臆想的需求
　　在軟件的開發過程中，我們團隊經常使用的一個口頭禪就是“如果客戶這么做了，就有....問題了”，但是客戶是不是真的會這么做嗎？這么做對客戶有什么實際意義嗎？我們不知道，測試人員也不知道。這種工作我稱之為“臆想的需求”。有的時候，臆想出來的需求真的是會耗費太多的時間和成本。我想，敏捷開發中讓軟件盡早能工作，讓客戶或客戶代表參與到開發中，就是為了讓軟件能正確的工作，為了提高工作的效率，這些臆想出來的東西還是盡量少有吧，即使搞一些BrainStorm，如果真的要加入到軟件中，還是需要依靠真實的客戶數據去嚴密論證。

7.盡早的測試與反饋
　　這一點的重要性就不必說了，盡量早的發現軟件的問題，收到客戶的反饋，然后根據這些真實的數據做出調整，規避完敗的風險，這是相對于瀑布開發來說最自然的想法之一。

8.持續編譯與集成
　　可工作的軟件是軟件工程最重要的產出，持續的集成，持續的編譯，持續的測試，持續的反饋，持續的迭代，持續的重構，這是敏捷開發的核心，也是每個Sprint保證質量的前提。

9.應對變化
　　變化是唯一的不變，這又是我們常用的一句口頭禪。確實，變化發展是唯物主義最重要的觀點之一，擁抱變化不僅對人來說是一件困難的事，對于軟件來說，也是一大挑戰。為了滿足需求的頻繁變更，軟件工程不斷研究應對變化的策略，敏捷開發的核心思想就是改善流程，應對變化，規避風險。對于軟件技術來說，應對變化與重用也是其向前發展的最原始的動力，從過程的重用，到算法的重用，到對象的重用，再到方案的重用(設計模式)，這個過程中最根本的導因就是變化。

?

最后是一些參考的鏈接：

http://developer.51cto.com/art/200803/68222.htm

http://dearymz.blog.163.com/blog/static/2056574200881235317338/

轉載于:https://www.cnblogs.com/dxy1982/p/3594287.html

總結

以上是生活随笔為你收集整理的Scrum敏捷开发沉思录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。