理論上的知識我看的不多，沒有很準確的概念，我想無論哪種開發方式都有自己的理論基礎，和相應的方法步驟，比如 瀑布模型，增量模型，迭代模型，敏捷方法等，

並且由於專案不同，比如是否是新專案，二次開發專案，或者是維護專案，採用的方法也不盡相同，沒有固定不變的，不同的公司也可能不一樣，所以我只是說說我所理解的敏捷，和專案中用到的敏捷方法

我的理解是快速迭代，持續交付，一種輕量級，高效，低風險，更強調團隊協作和溝通的開發方式，客戶需求模糊或多變，

適用於中小團隊開發，每個團隊人員不宜多於6，7個，

敏捷我認為首先最重要的是溝通，就是 BA和開發人員，和QA的高效溝通，缺少任何一個都不會很有效率和效果

敏捷的過程中基本保證每個迭代都是可以測試並驗證的，專案上要有完成一個迭代的時間，比如2周，3周，這包括如下幾部分

1，BA，系統需求的人儘量要知道他要什麼功能點，也就是function point，

2，開發人員要理解這個功能點，並和BA做溝通，要保證自己能理解這個需求，如果不是很理解，就要進一步溝通，這個過程中溝通很重要，因為BA可能並不完全瞭解系統的資料流，所以互相之間可能有偏差，溝通的目的就是確保開發人員完全理解這個需求，並實現它，開發完成後，要有時間做單元測試，整合測試等

3，當上一步完成後需要BA去驗證這個功能點的正確性

4，當BA完成後，QA不僅要做這個功能點的測試，還要做一個系統相關性的會迴歸測試，保證沒有影響到其他功能點

但實際上，我在有一個專案中用到的敏捷，雖然從一開始就在用，但是也不是很流暢，我認為其中的原因就是，使用者的需求不能及時的得到溝通和反饋，其中的原因是BA和開發，測試的人，不在一起，不在一個時區裡，很多時候只能通過寫郵件的方式溝通，這顯然不是高效的方式，後來專案做了些改進，就是開發團隊開始有BA了，情況得到了一些改善，

所以我認為下面兩點很重要

1真正的使用者需求，

2軟體持續交付過程中的，全方位的自動化測試，你新加個功能還好說，如果不對現有的功能產生影響，只要保證這個新的好用基本就可以了，但是如果這功能需要修改已有的程式碼，那麼就不只要保證當前這個功能好用，還要對相關項做全方位的迴歸測試，從業務上，功能上，保證系統的可用性，


敏捷開發每個人每天要做的

專案裡要有個黑板，這個黑板每個人都要參與進來，用來跟蹤功能點的狀態，

找個時間，比如時間控制在10分，15分鐘內，根據實際需要或者專案組制定的流程，選擇性的做下面當中的一個或幾個

每個人都要做下面這3件事，

1昨天做了什麼

2今天做什麼

3有沒有什麼問題導致你不能往下開發

每個人都把自己的功能點的今天的狀態向大家說出來，說出來的目的是讓大家瞭解你做的東西和他們的有沒有相關性

每個人都把自己的功能點在黑板上挪動到你當前的狀態，之後把他風險提出來，大家看看有沒有遇到類似的問題，集思廣益，會後也許會有思路

這麼做的最主要的目的，我感覺就是儘早的發現每個迭代可能遇到的風險，做到提前預知和可控

我認為無論哪種方法，都是要達到快速，高效，準確，低風險的完成專案的目標，所以他的步驟並不是固定不變的，只要達到這個目的就可以了

我本身不喜歡所謂的流程，及文件，因為好的程式碼結構就是文件，文件適當記載系統大概業務及資料流向即可，因為如果文件不能一直維護就會成為麻煩。

但實際上，我認為最好的開發方式就是，BA在開發者身邊，有問題隨時溝通，做到快速，高效，

其他的所謂流程，步驟都不重要，只要完成的東西達到BA的要求才是最重要的