從第一個項目開始，就一直在被敏捷，然而敏捷開發到底是什麼，應該怎麼做？其實也沒有一個真正的認識。直到後來開始系統地學習項目管理，再結合實際開發經驗，纔算有了一知半解。本文是筆者對學習和實踐敏捷開發的一個總結，由於個人能力和認識有限，不對之處，還望批評指正。
首先要強調的是，對於開發模式的選擇，並沒有最好的，而只有最適合團隊和項目當前情況的，甚至多種開發模式並用，也是可以的。而對於某種開發模式的具體實踐，也應該因人制宜，因事制宜，實事求是，切忌機械地照搬知名公司或者其他團隊的方法。本文所介紹的，也僅供參考，適當取捨。在開發模式的實踐上，需要考慮以下幾點：
1、是否符合當前項目和團隊成員的實際情況？
2、是否有利於項目快速、高質量的交付？
3、是否有利於降低管理成本、溝通成本？
4、是否有利於團隊（特別是新人）的成長？
5、是否有利於項目知識的積累（這很重要）？
當這些回答都是OK的時候，我們就開始“敏捷”。
一、開發前的準備工作：
1、“一個”團隊
“一個”團隊，重點在“一個”上，所有這個項目的參與者，產品、美工、開發、測試都屬於一個團隊，大家榮辱與共、同擔風險、彼此信任多加溝通。因爲項目交付的賽跑，比的不是哪個團隊最先到終點的人排第幾，而是最後一個到的人排第幾。在產品設計與需求變更的時候，應該考慮開發修改功能的週期和難度，而在開發過程中，也要儘可能多的考慮技術架構的靈活性，爲產品可能的修改留下空間。
2、一份不精美但結構流程完整的原型設計
原型設計比起功能清單（功能清單還是需要有的）要直觀得多，那是快速開發的開始。這份原型設計大可不必面面俱到，不需要精細到每個細節，每個功能點，但是通過原型可以瞭解整個產品每個頁面承擔的功能，頁面之間的跳轉關係還有每個頁面需要用戶輸入或者展示給用戶的信息。比如不需要把上一頁、下一頁這些按鈕畫出來，在這裏寫上“分頁”兩個字就可以了，不要花時間去調鼠標移上去時模塊背景的變化，代碼能做得更快更好。
3、一份整體風格一致的設計稿
所謂整體風格一致，就是說控件要能在不同的頁面或模塊裏交叉使用，而不會顯得突兀。比如目前已經有了一個帶表格的頁面，和另一個有用戶輸入和按鈕的頁面，這時候客戶需要臨時增加第三個頁面，有表格，並且可以通過用戶輸入進行搜索。顯然這個時候沒必要去重新對第三個頁面進行設計了，將第二個頁面的輸入和按鈕組合到第一個頁面就好了，直接在代碼層面實現。最後，原型設計與設計稿最好分開，即不要用設計稿代替原型去表達業務邏輯，也不要在做原型設計的時候因過度考慮美觀而消耗時間。
4、包含少量新技術的產品技術棧
一個項目，如果不使用新技術，會讓項目成員感覺一塵不變沒有提升，也不利於未來的技術更迭。然而過多的使用新技術，則會導致開發過程不可控，增加項目風險。故而在技術棧的選擇上，可以根據以後的項目變化和成員個人的目標規劃，適當選用新技術，但要在可控的範圍內，且準備一套成熟的備選方案。新技術最好也只集中在某個方面，比如前端使用新的框架，那後臺就不要再使用新語言了。
5、一份完備的開發規範
開發規範約束每個開發者的開發行爲，是代碼質量的保證。開發規範包含了統一開發運行環境、命名規範、註釋規範、接口規範、代碼結構規範、數據庫設計規範等等，根據項目的大小進行取捨。開發規範有利於降低團隊溝通成本，減少代碼返工和新加入成員快速理解項目架構並着手開發。
6、一份粗粒度的項目規劃
這份項目規劃沒必要細緻到每個人每個功能點，也並非粗到只有里程碑。這份規劃會將整個產品按照功能模塊進行拆分，並且描述功能模塊的開發順序、開發週期和人員分配。還要包含產品的迭代規劃、版本規劃、溝通計劃、風險計劃還有質量計劃等。
7、一次全員參與的深入交流
這次交流不一定是正式的項目啓動會，然而需要保證時間足夠充足，每個人都要發表看法、提出疑問並得到確定的回覆，討論的內容包含所有的準備項，而且儘可能是面對面的。如果成員比較多，也可以分批次分模塊的進行。目的在於讓每個成員明晰產品內容、技術架構、分工和時間節點，並且記錄他們認爲有難度和有潛在風險的地方。
二、開發過程中:
1、搭建基礎技術架構
並非是完成項目分工後，就大家該幹嘛就幹嘛去了。代碼是很自由的，開發者也經驗不同、風格各異，儘管有完備的開發規範，也很難保證最終各部分的代碼能很順利的整合到一起。故而在着手開發之前，搭建基礎的技術架構是很有必要的，他需要全體開發者共同參與。基礎技術架構通常會包含一些通用的公共的東西，比如所用框架、基類、數據表基本字段、頁面公共模塊、公共方法等。而之後的開發，都是基於這個基礎技術架構進行的。
2、任務分解與可視化
任務分解是一個技術活，他需要熟悉需求與技術架構，同時要兼顧功能模塊間的耦合和開發成員間的差異。這裏的任務分解是細緻的、短期的並且根據需求的變更隨機應變的。而kanban工具是敏捷開發中比較常用的任務可視化工具，這些被分解好的任務，則由kanban工具進行跟蹤，掌握當前項目的進度和瓶頸。
3、每日晨會
晨會即每天早上開工之前的一個碰頭會，可以是大家坐在一起，也可以是pm輪流與每個開發小組進行交流，目的在於瞭解今天的工作計劃、昨天的工作完成得如何、過程中是否遇到了什麼問題與困難以及引導大家（特別是新加入的成員）相互溝通了解（比如花幾分鐘聊聊今天中午吃什麼）。
4、持續集成與持續交付
持續集成即是每完成一部分更新後，都當即集成到主幹上，及時發現問題並進行修改。而持續集成則需要持續測試，不論是自動化測試還是人工測試。而且開發人員也要養成自己測試自己代碼的習慣。而當完成一個模塊的開發及測試之後，則有必要向客戶進行展示或試用，一則有利於客戶及時反饋問題進行調整，二則能讓客戶及時瞭解項目進度和前進方向，對項目的順利完成充滿信心。
5、及時響應
敏捷開發需要團隊快速高效的溝通，故而及時響應就意味着頻繁打斷、及時發現、快速決策和實時反饋。
頻繁打斷則是不懂就問，不論你在幹什麼，很多開發者在一開始並不適應這種方式，因爲你會發現自己根本不能安靜下來做好一件事，而當適應之後，你會發現這種方式非常便捷和高效。
同樣，PM需要及時的發現項目中的難題和瓶頸，而不要等待開發者主動告訴你他遇到問題了，因爲大多數開發者在遇到問題的時候都喜歡深入專研並自己解決，這種精神固然可嘉，然而卻無疑增加了項目的風險。故而，當一個問題在半天之內還沒有解決的時候，就需要整個團隊共同解決了（因爲很多問題在單獨某一端解決很難，而放在全棧卻相對容易），而當一個問題整個團隊兩天之內都無法解決的時候，就需要請求上級協調技術專家了。
6、Code Review
CodeReview是開發過程中一個重要的環節，有助於發現潛在缺陷、增進團隊成員之間的交流。同時也可以瞭解規範彼此的編碼習慣，對新人還有學習優秀代碼的好處。Code Review的形式多樣，也有相應的工具。而Code Review也不侷限於相同語音的開發人員之間，敏捷開發要求開發者一專多能，故而不同語言使用者（比如後臺和前端）之間的Code Review也有利於技術上的融合和設計模式的互通。
7、擁抱變化但引導需求
敏捷開發提倡擁抱變化，對需求或計劃的變更做積極的響應，並且從思想上接受這種變更。然而擁抱變化並不代表對於客戶任何的需求變更我們都欣然接受，特別是對於那些自己也不太清楚自己想要什麼的客戶。引導需求，即是我們不僅要關注需求本身，而更多的應該關注客戶爲什麼提這個需求，他想要通過這個需求解決什麼問題，而瞭解了問題之後，才能對症下藥，謀求最小的變動達到客戶的要求，引導需求需要深入瞭解客戶的想法並具備一定的溝通能力。
比如客戶昨天告訴我們他想吃清蒸魚，於是早上我們買了魚，這時候他卻說他想吃紅燒肉，此時我們可以問他是不是不喜歡口味太淡的，那紅燒魚可以嗎？同時列舉一些魚肉的好處。然而此時客戶依然堅持紅燒肉，繼續溝通，發現客戶是不喜歡魚刺，對口味其實沒啥要求，則可以建議做成清蒸魚丸如何。
8、用戶故事
在做功能交流的時候，我們經常被要求不要“介紹”，要“講故事”，而用戶故事則描述了一個用戶通過一連串的行爲達到某些效果的過程。用戶故事可以更方便通俗的對產品進行交流，且每個用戶故事都是短小的，簡明扼要的，可以評估出工作量的。用戶故事也不僅僅只用於與客戶溝通，團隊內部也可以使用用戶故事更形象的交流。
三、每個階段完成後的知識管理
敏捷開發並非摒棄文檔，只是更多的留下有用的文檔。知識管理是非常重要的一部分，特別是在軟件開發過程中，它是整個團隊技術的沉澱，也是項目重構和交接的重要依據。不擅長做或者壓根不做知識管理的團隊，經常會發生這樣的問題，很快的完成了一個階段的開發，而當進行第二個階段開發的時候，卻發現很多函數和字段的意義和用處已經記不得了，而需要重新閱讀代碼才能回憶起來，於是團隊會花大量的時間來回憶過去，而隨着開發時間的拉長，這種需要靠看代碼來回憶的東西也越來越多，進度越到後面越不理想。在知識管理中，建議保留以下內容：
1、產品設計文檔
2、需求變更記錄
3、技術架構與代碼結構
4、數據字典
5、開發運行環境說明（非常規的還可包含搭建步驟）
6、接口文檔
7、版本迭代記錄
8、使用的第三方庫及其版本
而有餘力的團隊還可以就遇到的疑難問題及其解決辦法、以及在項目過程的體會收穫進行記錄並共享。