家好，我是IT修真院武漢分院第15期的JAVA學員，一枚正直純潔善良的java程式設計師。 今天給大家分享一下，修真院官網Java任務10，深度思考中的知識點————什麼是敏捷開發流程？

1.背景介紹

為什麼需要敏捷開發？

在很久以前，軟體專案的開發都是以年來計算的，這代表什麼意思呢 ？需求設計了半年多，方案設計做了半年多，開發了三年多，

測試了半年多，修改Bug用了半年多。總計花了很長很長的時間，然後上線後發現有很多需求已經不存在了，同時又出現了很多新的需求。

這是困擾軟體開發專案的最大的問題，越大的專案，參與的人越多，風險越大。文件越規範，維護起來的難度就越高，導致專案中遇到的問題越來越多。

2.知識剖析

什麼是敏捷開發？

敏捷開發(AgileDevelopment)是一種以人為核心、迭代、循序漸進的開發方法。

怎麼理解呢？首先，我們要理解它不是一門技術，它是一種開發方法，也就是一種軟體開發的流程，它會指導我們用規定的環節去

  一步一步完成專案的開發；而這種開發方式的主要驅動核心是人；它採用的是迭代式開發；

什麼是迭代？

迭代是指把一個複雜且開發週期很長的開發任務，分解為很多小週期可完成的任務，這樣的一個週期就是一次迭代的過程；

  同時每一次迭代都可以生產或開發出一個可以交付的軟體產品。

為什麼說是以人為核心？

以前大多是瀑布開發模型，它是以文件為驅動的，為什麼呢？因為在瀑布的整個開發過程中，要寫大量的文件，把需求文件寫出來後，開發人員都是根據文件進行開發的，

  一切以文件為依據；而敏捷開發它只寫有必要的文件，或儘量少寫文件，敏捷開發注重的是人與人之間，面對面的交流，所以它強調以人為核心。

老大強調的理念就是：產品和開發必須是一個Team，大家只是分工不同，角色不同，並不是兩個對立的團隊，出了問題，不要說這

  是產品設計出來，這是開發團隊實現不了的。這是一個開發小組所有人的責任，這個後果是所有的人都需要承擔的。

  如果我們認真的區分這是什麼問題，那麼也只是為了避免下次出現同樣的情況，而使用者只會知道是一個公司出了一款垃圾產品，沒有

  人關心到底是產品還是開發的鍋。

這是做敏捷開發的大前提。或者不僅僅是產品和開發，責任共擔，One Team這個理念是貫穿始終的。

  產品和開發必須是一個Team還體現在需求分期上，實際上，需求分期如果沒做好，敏捷開發只能流於形式。

在敏捷開發中職責明確，每個人要負責的事情必須清晰無誤，誰該做哪些事情，必須要提前講清楚。

最為後端，專案進入真正的開發階段後，開發組的成員就應該是主動去控制專案的進度，和風險，以及主動去測試專案中存在的問題，

在這個階段，除了一些需求不明，或者是發生變動的情況出現，不應該去打擾產品經理。不要讓產品經理做開發團隊的保姆。

開發組的成員的目標就是做好專案的進度控制，

有風險就及時反饋給Leader，確保自己理解的需求是明確無誤的，確保自己的

測試是完整和嚴謹的，確認自己寫出來的程式碼是可以維護的。一定要理解清楚，一旦PM通過Story講解，將需求交付給開發組成

員，那麼開發組成員就應該主動而獨立的為這件事情負責。當專案完工以後，開發組成員應該交叉去做CodeReview，

並且給出效能測試報告，以及組織Demo。

敏捷開發包括了哪些內容?

1.需求規劃和分期

2. 需求評審

3. 需求講解

4. 方案評審

5. 每日晨會

6. 效能測試

7. CodeReview

8. Demo

9. 測試階段

10.線上Bug修改流程

3.常見問題

4.解決方案

5.編碼實戰

6.擴充套件思考

敏捷開發與傳統開發方法的比較：

1、優勢：

敏捷開發的高適應性，以人為本的特性，和輕量型的開發方法即以測試為驅動取代了以文件為驅動，這三個主要的特點，

也就是敏捷開發相對與傳統開發方式的主要有點。因為他更加的靈活並且更加充分的利用了每個開發者的優勢，調動了每個人的工作熱情。

2、劣勢：

與傳統開發方式相比，敏捷開發的最主要的劣勢在於敏捷開發歡迎新的需求，而在每次新的需求產生時都可能引起整個系統的大幅度的修改。

因為開發者在開發上一個版本的時候，完全沒有考慮以後的優化將要如何進行。這樣的開發方式實際的軟體開發過程中，並不一定總是有效的。

而另一個方面，敏捷開發因為缺乏很多在敏捷開發中被認為“不重要”的文件，這樣在一個大型專案比如一個作業系統開發的時候，

由於其專案週期很長，所以很難保證開發的人員不更換，而沒有文件就會造成在交接的過程中出現很大的困難。

3.敏捷開發和瀑布模型開發通俗比較

敏捷開發

• 客人到餐館來點菜（新專案）

• 不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的選單（客戶往往提不出具體的需求）

• 根據圖文選單，客人點了是個菜（根據原型和設計稿，基本確定了需求）

• 後廚開始準備（專案啟動）

• 配菜、炒菜，先上了兩盤，讓客人嚐了嚐味道（先提供可用例項給客戶用）

• 客人說還不錯，後廚繼續準備後面的菜，陸續上菜（不斷迭代，不斷測試）

• 上菜過程中，客人突然發現有個菜的味道太淡了，讓後廚加了點鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）

• 又上了兩盤，不夠辣，又拿到後廚加了辣（敏捷的壞處，需求沒有提前明確，反覆迭代，增加了工作量）

• 到最後兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變更）

• 客人吃完，很滿意（基本滿足了全部的要求）

瀑布模型開發

• 客人到餐館來點菜（新專案）

• 不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的選單（客戶往往提不出具體的需求）

• 根據圖文選單，客人點了十個菜（根據原型和設計稿，基本確定了需求）

• 後廚開始準備（專案啟動）

• 根據客人的下單配菜，炒菜（基本上不會主動去了解完整需求）

• 半個小時了，菜還沒上桌，客人餓極了（專案啟動後很長一段時間客戶什麼都看不到）

• 再過了二十分鐘，十個菜都一起上來了（專案最終一次交付）

• 客人說，有幾個菜挺好的，但是有個菜味道淡了，有兩個不夠辣，還有兩盤重複了想換掉（我是買單的，我要變需求）

• 這時候大堂經理來了，說，“味道淡了可以加鹽，不辣可以加辣，但是換菜不行，已經炒好的那兩盤菜也是要算成本的”（瀑布的壞處，需求變更比較麻煩）

• 於是，後廚只給客戶加了鹽，加了辣

• 客人吃完，不是很滿意，下次不來了（沒有滿足需求）

7.參考文獻

https://www.zhihu.com/question/39757751/answer/82927612?group_id=685376196313116672

https://www.cnblogs.com/yt96/p/5983265.html

8.更多討論

1.“敏捷開發” 知多少？

敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方式。

2.計劃紙牌的用處

計劃紙牌，它的作用是防止專案在開發過程中，被某些人所領導。

3計劃紙牌的怎麼用？

比如A程式設計師開發一個功能，需要5個小時，B程式設計師認為只需要半小時，那他們各自取相應的牌，藏在手中，最後攤牌，如果時間差距很大，那麼A和B就可以討論A為什麼要5個小時