理論上的知識我看的不多，沒有很準確的概念，我想無論哪種開發方式都有自己的理論基礎，和相應的方法步驟，比如 瀑布模型，增量模型，迭代模型，敏捷方法等，
並且由於專案不同，比如是否是新專案，二次開發專案，或者是維護專案，採用的方法也不盡相同，沒有固定不變的，不同的公司也可能不一樣，所以我只是說說我所理解的敏捷，和專案中用到的敏捷方法
我的理解是快速迭代，持續交付，一種輕量級，高效，低風險，更強調團隊協作和溝通的開發方式，客戶需求模糊或多變，
適用於中小團隊開發，每個團隊人員不宜多於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的要求才是最重要的
我所接觸的敏捷開發
自從進入這個專案以來，我們採用的是敏捷開發，本部有八個專案組成員，客戶那邊有乙個on site，剛開始專案leader進行資料庫設計，以及任務模組分配，每個人都分到乙個或者幾個模組，然後進行開發，從頁面做到資料庫，這樣子下來每個人都對整個專案結構有個大概了解，隨著專案的進行，隔著一段時間，發布乙個版...
我所認知的敏捷開發
實習的第乙份工作是在某一線遊戲公司做遊戲客戶端實習生，大的公司或許在管理制度上的確要更加完善先進，這是不可否認的，整整實習了一年，差不多是半年的客戶端實習生，半年的專案管理實習生，那麼談談我自己對敏捷開發的看法。一.每日站會 剛到公司的時候，每天早上我都發現旁邊的伺服器組準時在10點，所有人站在一起...
恆生DBB 我所理解的敏捷開發
敏捷開發作為一種團隊協作方 高效與清晰是兩個特別明顯的特點，保持敏捷開發的理念開始sprint工作的團隊，一定有正向的開發buff加成，我們需要面對的是如何將敏捷開發的流程執行到位，最大化的獲取加成收益。我很認同敏捷開發對於精英團隊的加成是最大化的，因為大家目標清晰，技術能力完善，執行力強，這是最理...