敏捷開發流程介紹
家好,我是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個小時