大家好，我是IT修真院武漢分院第15期學員，一枚正直善良的JAVA程式設計師。

今天給大家分享一下，java專案中需要使用的敏捷開發流程

1.背景介紹

在很久以前，軟體專案的開發都是以年來計算的，這代表什麼意思呢 ？需求設計了半年多，方案設計做了半年多，開發了三年多， 測試了半年多，修改Bug用了半年多。總計花了很長很長的時間，然後上線後發現有很多需求已經不存在了，同時又出現了很多新的需求。 這是困擾軟體開發專案的最大的問題，越大的專案，參與的人越多，風險越大。文件越規範，維護起來的難度就越高，導致專案中遇到的問題越來越多。

2.知識剖析

敏捷開發(AgileDevelopment)是一種以人為核心、迭代、循序漸進的開發方法。怎麼理解呢？首先，我們要理解它不是一門技術，它是一種開發方法，也就是一種軟體開發的流程，它會指導我們用規定的環節去 一步一步完成專案的開發；而這種開發方式的主要驅動核心是人；它採用的是迭代式開發；

3.常見問題

提問一：什麼是迭代？

提問二：為什麼說是以人為核心？

提問三：敏捷開發包括了哪些內容?

4.解決方案

回答一

迭代是指把一個複雜且開發週期很長的開發任務，分解為很多小週期可完成的任務，這樣的一個週期就是一次迭代的過程； 同時每一次迭代都可以生產或開發出一個可以交付的軟體產品。


回答二

以前大多是瀑布開發模型，它是以文件為驅動的，為什麼呢？因為在瀑布的整個開發過程中，要寫大量的文件，把需求文件寫出來後，開發人員都是根據文件進行開發的， 一切以文件為依據；而敏捷開發它只寫有必要的文件，或儘量少寫文件，敏捷開發注重的是人與人之間，面對面的交流，所以它強調以人為核心。

老大強調的理念就是：產品和開發必須是一個Team，大家只是分工不同，角色不同，並不是兩個對立的團隊，出了問題，不要說這 是產品設計出來，這是開發團隊實現不了的。這是一個開發小組所有人的責任，這個後果是所有的人都需要承擔的。 如果我們認真的區分這是什麼問題，那麼也只是為了避免下次出現同樣的情況，而使用者只會知道是一個公司出了一款垃圾產品，沒有 人關心到底是產品還是開發的鍋。

這是做敏捷開發的大前提。或者不僅僅是產品和開發，責任共擔，One Team這個理念是貫穿始終的。 產品和開發必須是一個Team還體現在需求分期上，實際上，需求分期如果沒做好，敏捷開發只能流於形式。

在敏捷開發中職責明確，每個人要負責的事情必須清晰無誤，誰該做哪些事情，必須要提前講清楚。做為後端，專案進入真正的開發階段後，開發組的成員就應該是主動去控制專案的進度，和風險，以及主動去測試專案中存在的問題， 在這個階段，除了一些需求不明，或者是發生變動的情況出現，不應該去打擾產品經理。不要讓產品經理做開發團隊的保姆。 開發組的成員的目標就是做好專案的進度控制。

有風險就及時反饋給Leader，確保自己理解的需求是明確無誤的，確保自己的 測試是完整和嚴謹的，確認自己寫出來的程式碼是可以維護的。一定要理解清楚，一旦PM通過Story講解，將需求交付給開發組成 員，那麼開發組成員就應該主動而獨立的為這件事情負責。當專案完工以後，開發組成員應該交叉去做CodeReview， 並且給出效能測試報告，以及組織Demo。

回答三

1：需求講解
2：定義介面文件
3：方案設計
4：禪道拆分
5：方案評審
6：開發階段
7：階段測試
8：效能測試和Coderevivew
9：壓力測試
10：Demo
11：釋出測試環境，整合測試
12：釋出線上環境同時停止開發環境和測試環境
13：線上監控

5.編碼實戰

6.擴充套件思考

敏捷開發與傳統開發方法的優劣？

優勢：敏捷開發的高適應性，以人為本的特性，和輕量型的開發方法即以測試為驅動取代了以文件為驅動，這三個主要的特點， 也就是敏捷開發相對與傳統開發方式的主要有點。因為他更加的靈活並且更加充分的利用了每個開發者的優勢，調動了每個人的工作熱情。

劣勢：與傳統開發方式相比，敏捷開發的最主要的劣勢在於敏捷開發歡迎新的需求，而在每次新的需求產生時都可能引起整個系統的大幅度的修改。 因為開發者在開發上一個版本的時候，完全沒有考慮以後的優化將要如何進行。這樣的開發方式實際的軟體開發過程中，並不一定總是有效的。 而另一個方面，敏捷開發因為缺乏很多在敏捷開發中被認為“不重要”的文件，這樣在一個大型專案比如一個作業系統開發的時候， 由於其專案週期很長，所以很難保證開發的人員不更換，而沒有文件就會造成在交接的過程中出現很大的困難。

7.參考文獻

8.更多討論

今天的分享就到這裡啦，歡迎大家提問和探討!