很多企業、團隊都在提倡敏捷開發、DevOps運動，本人最近也有在瞭解DevOps的相關知識。結合自己的實踐，把對敏捷開發的一些理解，分享予大家，共勉。

敏捷開發強調的首先是人的變化，其次才是工具應用的層面。

一，人的變化（團隊），主要思想模式上的變化，比如：

沒必要等到全部確定才可以開始。只要大的框架需求、關鍵點確定之後就可以開始，沒必要等到弄清楚所有細節才開始，如果要弄清一切才開始，就是傳統的瀑布式開發了，那樣產品見面週期長，無法適應需求的快速變化。

不是一次性交付後就結束。敏捷開發，就是要分多個迭代交付，小步快走。

允許有不完美。不要一開始就想著很完美，而且也很難一開始就想得很完美，要清楚這是一個逐步最佳化的過程。

要擁抱變化。敏捷的目的就是能快速響應變化，以真正滿足業務的需求。當然變化是以真正體現業務價值為基礎的，不是以某個人的盲目意見為理由。

真誠溝通。與客戶建立親密性，真誠地進行溝通，客戶不是“談判對手”，也不是“上帝”，而是與團隊一起共進退的夥伴、合作人。

二，工具應用的層面

以故事場景的形式把需求描述出來，敏捷強調的是從客戶的業務場景角度，把需求講出來，不太強調具體的系統功能需求設計。目的就是為了能真實表達業務的需求和價值。

大目標需要拆分小目標，需要懂得把大目標拆分成各個小目標，縮短成品交付的週期，讓系統儘快出來驗證業務價值。

迭代交付，每個迭代是一個完整的閉環“計劃-開發-測試-體驗-釋出”。

每日站會，每日站會是為了讓團隊瞭解整個專案的情況，知道成員彼此的工作和困難，可以互相幫助。

任務看板，用來跟蹤專案進度的，特別是在衝刺階段特別有效。

定期回顧，回顧是團隊一起回顧，是規避，也是學習交流的機會。

具體實踐的一些感悟

1，與客戶親密溝通，站在同一陣線，很重要。

1）接到任何一個專案，我都會專心投入去思考：應該怎樣設計才是對業務最有價值的（那怕一開始不清楚業務，也會想辦法溝通弄清楚，然後思考）；

2）客戶的需求，不會拒絕。而是會去思考，這個需求的價值是什麼，如果是有價值的，我們就如實商量實施計劃；如果是沒有價值的，則會提出我的見解。做到這兩點，除非很惡劣的情況，否則一般客戶都是會講道理的。

2，拆解目標需要清晰，可靠。

專案的目標一定要清晰，然後拆解的子目標也要清晰、合理。一般情況下，我會從兩個方面考慮：

1）把故事轉成全功能目標圖；

2）明確業務意願的時間目標。

以上兩點，結合團隊資源的情況，按照系統本身特有的特徵和客戶的意願拆分目標。確保每個小目標可達。

3，定期回顧總結，反思。

迭代交付，一定要定期回顧，並反思，確保專案方向正確，目標可達，特別是要考慮總體目標也是在計劃中可達，如有偏離、或者出現風險，需要及時糾正。定期反思，一般我會考慮：離目標還差多少，交付的需求是否都是有價值的，目前有沒有出現隱含的風險等。

1.為什麼要敏捷

+ 現在的軟體需求已經從傳統的火箭演算法轉變為使用者多樣化需求，使用者研究已經成為一個單獨的課題；

+ 軟體的客群也從少數幾個人群體變化為千萬乃至億萬的龐大群體；

+ 網際網路的激烈競爭催化軟體系統的更新迭代速度；

+ 需求分析不再是進行幾次訪談就能確定的簡單過程

因此、急需一種可以快速試錯、幾時糾正、持續進化的軟體開發模型，敏捷模型也就應運而生了。

2.敏捷不僅是一個模型，更是一種思想

在運用敏捷之前、首先應該學習敏捷的思想。敏捷要承認一開始無法做到最好、因此、敏捷是一種漸進的、快速失敗的、並可以自動調整的思維方式。深入瞭解敏捷思想可以檢視一下敏捷宣言和12準則、這裡就不贅述了。

3.敏捷實踐

現在比較流行的敏捷實踐包括、SCRUM、XP、kanban、lean等等。SCRUM的應用尤其廣泛。事實上、這幾種實踐並非相互獨立、而是相輔相成的。比如：在SCRUM框架下引入極限程式設計也是可以的。