這裏是修真院pm小課堂,每篇分享文從程序員
【背景介紹】【知識剖析】【常見問題】【解決方案】【編碼實戰】【擴展思考】【更多討論】【參考文獻】spring
八個方面深度解析pm知識/技能,本篇分享的是:安全
【什麼是敏捷開發 】框架
你們好,我是IT修真院上海分院第4期的學員,一枚正直純潔善良的PM工具
今天給你們介紹一下什麼是敏捷開發。學習
目錄:測試
1.幾種開發方法編碼
1.1瀑布式開發spa
1.2迭代式開發設計
1.3螺旋式開發
2.敏捷開發
2.1 敏捷開發的誕生
2.2敏捷開發宣言
2.3 敏捷開發
3.敏捷開發方法
3.1 Scrum
3.1.1 什麼是scrum
3.1.2 Scrum 框架結構
3.2其餘開發方法介紹
4.敏捷管理工具
4.1禪道
5.實例:修真院敏捷開發流程
6.討論
7.參考文獻、
1.幾種開發方法
1.1瀑布式開發——瀑布模型(Waterfall Model)
1970年溫斯頓·羅伊斯(Winston Royce)提出了著名的「瀑布模型」,直到80年代早期,它一直是惟一被普遍採用的軟件開發模型。
瀑布模型要求軟件開發嚴格按按照需求→分析→設計→編碼→測試的階段進行,每個階段均可以定義明確的產出物和驗證準則。瀑布模型在每個階段完成後均可以組織相關的評審和驗證,嚴格的瀑布模型每個階段都不該該重疊,而應該是在評審經過後纔可以進入到下一個階段。遵循自上而下、相互銜接的固定次序,如同瀑布流水,逐級下落。
瀑布模型式是最典型的預見性的方法。
瀑布模型的優勢仍然是能夠保證整個軟件產品較高的質量,保證缺陷可以提早的被發現和解決.採用瀑布模型能夠保證系統在總體上的充分把握,使系統具有良好的擴展性和可維護性
瀑布式的主要的問題是它的嚴格分級致使的自由度下降,項目早期即做出承諾致使對後期需求的變化難以調整,代價高昂。瀑布式方法在需求不明而且在項目進行過程當中可能變化的狀況下基本是不可行的。
2.1 迭代式開發
迭代式開發也被稱做迭代增量式開發或迭代進化式開發,是一種與傳統的瀑布式開發相反的軟件開發過程,它彌補了傳統開發方式中的一些弱點,具備更高的成功率和生產率。
在迭代式開發方法中,整個開發工做被組織爲一系列的短小的、固定長度(如3周)的小項目,被稱爲一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法,在需求被完整地肯定以前就能啓動開發工做,並在一次迭代中完成系統的一部分功能或業務邏輯的開發工做。再經過客戶的反饋來細化需求,並開始新一輪的迭代。
1.3螺旋開發——螺旋模型(Spiral Model)
螺旋模型是一種演化軟件開發過程模型,它兼顧了快速原型的迭代的特徵以及瀑布模型的系統化與嚴格監控。螺旋模型最大的特色在於強調其餘模型所忽視的風險分析,螺旋模型很大程度上是一種風險驅動的方法體系,由於在每一個階段以前及常常發生的循環以前,都必須首先進行風險評估。。
一般螺旋模型由四個階段組成:制定計劃、風險分析、實施工程和客戶評估。
(1)制定計劃:肯定軟件目標,選定實施方案,弄清項目開發的限制條件;
(2)風險分析:分析評估所選方案,考慮如何識別和消除風險;
(3)實施工程:實施軟件開發和驗證;
(4)客戶評估:評價開發工做,提出修正建議,制定下一步計劃。
螺旋模型適用於龐大而且複雜,高風險的項目,需求不明確的狀況下,便於風險控制和需求變動。
2.敏捷開發
2.1 敏捷開發的誕生
程序員說,要有敏捷
——因而就有了敏捷。
敏捷這個詞被用的過於氾濫了,你們都在討論它,能夠把它視爲一種宗教。
美國在計算機行業已經走了幾十年,瀑布流、螺旋模型、快速迭代...各類各樣的軟件開發流程雨後春筍各領風騷一段時間。雖然不斷變化和完善,但互聯網的加速發展讓傳統方法顯得笨重,難以快速適應變化。有十七個程序員(程序員改變世界)在美國猶他州鹽城湖的一個風景區開了個碰頭會,找到了一個團隊耦合度高,流程極其靈活的方法,他們把它稱爲敏捷開發(Agile program development)。
2.2 敏捷開發宣言
.png](/img/bVblSqN)
![圖片上傳中...]
• 個體和交互重於過程和工具
敏捷方法認爲,人是軟件開發中最重要的因素,開發團隊要能作到團結協做,人與人面對面的交流、溝通,是最快速、最有效的途徑。
• 能夠工做的軟件重於面面俱到的文檔
文檔的意義在於爲程序服務,過多的文檔須要開發人員花費大量的時間去維護,並且還要確保文檔與代碼的實時性,不然就失去了文檔的意義。而問題也就在於,開發人員沒有把時間、精力放到最重要的任務上,能力、資源沒有最大化的發揮效能。敏捷方法認爲,文檔應當短小精悍、易於維護,並且主題突出。
• 客戶協做重於合同談判
作過軟件開發的人都知道,客戶對產品的需求是不斷變化的,試圖一開始就規定項目的細節和進度,顯然是不現實的,只有開發團隊和客戶彼此精誠合做,常與溝通,頻繁的客戶反饋,才能促使項目的成功。
• 隨時響應變化重於循規蹈矩
客戶的需求在產品的開發階段是不斷變化的,即便談判時肯定的需求,也可能會根據某些因素而發生巨大的改變。所以,敏捷方法認爲,在制定計劃時應儘量的簡潔、靈活,以適應技術和需求方面的變更。固然,全部的未知的因素是不可能考慮周全的,這就要求咱們在制定計劃時,留出必定的緩衝期,來應對這些未知狀況。
• 適應變化
傳統的軟件開發強調的是,足夠清晰的需求,制定詳細的文檔,按照預約的計劃逐一進行開發、測試。這樣的方式在制定好計劃以後拒絕變化,沒法應對客戶對需求的實時更改,後續的維護必將會付出巨大的代價。
而敏捷方法則是以最簡的方式來迎接變化,客戶在整個開發過程當中都是參與者,開發團隊可以在最短的時間內獲得客戶的反饋,不斷適應需求的變動,從而使得最終的產品可以充分的符合客戶的要求。
2.3敏捷開發
敏捷開發是一種應對快速變化的需求的一種軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同,相對於「非敏捷」,更強調程序員團隊與業務專家之間的緊密協做、面對面的溝通(認爲比書面的文檔更有效)、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、可以很好地適應需求變化的代碼編寫和團隊組織方法,也更注重軟件開發過程當中人的做用。
敏捷開發以用戶的需求進化爲核心,採用迭代、按部就班的方法進行軟件開發。在敏捷開發中,軟件項目在構建初期被切分紅多個子項目,各個子項目的成果都通過測試,具有可視、可集成和可運行使用的特徵。換言之,就是把一個大項目分爲多個相互聯繫,但也可獨立運行的小項目,並分別完成,在此過程當中軟件一直處於可以使用狀態。
敏捷開發能夠說是在迭代開發的基礎上發展造成的,它額外強調了溝通合做、以人爲本的思想。敏捷開發的缺陷可能在於團隊不能過大,通常少於20人,且要求成員都是精幹,有互相信任的基礎。
3.敏捷開發方法:
3.1 Scrum
3.1.1 什麼是scrum
Scrum 是當前最流行的敏捷軟件開發方法論和實施框架。
Scrum 是一種團隊管理工做的方式,其將工做分解爲較小的工做單元,並在週期性固定的時間段內持續地交付工做單元
上面描述的週期性固定的時間段,稱爲迭代(Iteration)或者衝刺(Sprint)。
上面描述的較小的工做單元,稱爲用戶故事(User Story)。
用戶故事可使用特定的格式來描述,其描述了一個對於客戶有價值的工做,並且能夠在一個迭代週期內完成。
3.1.2 Scrum 框架結構
Scrum敏捷開發流程主要包括:三個角色、三個物件和四個會議。
三個角色:
產品經理(Product Owner):主要負責肯定產品的功能和達到要求的標準,指定軟件的發佈日期和交付的內容,同時有權力接受或拒絕開發團隊的工做成果。
敏捷教練(Scrum Master):主要負責整個Scrum流程在項目中的順利實施和進行,以及清除擋在客戶和開發工做之間的溝通障礙,使得客戶能夠直接驅動開發。
開發團隊(Scrum Team):主要負責軟件產品在Scrum規定流程下進行開發工做,人數控制在5~10人左右。
三個物件:
一、product Backlog : 產品Backlog指根據初始需求分解出的任務列表,包括功能性和非功能性的全部功能。
二、Sprint Backlog ,這是一個迭代計劃會議的輸出,包含開發團隊在迭代週期內所要完成的工做列表。 若是說產品backlog是以story爲單位,文檔歸屬爲PM團隊,那麼Sprint Backlog 是以小時(時間)爲單位的,文檔歸屬爲開發團隊。
三、燃盡圖。
燃盡圖(burn down chart)是在項目完成以前,對須要完成的工做的一種可視化表示。燃盡圖有一個Y軸(工做)和X軸(時間)。理想狀況下,該圖表是一個向下的曲線,隨着剩餘工做的完成,「燒盡」至零。燃盡圖向項目組成員和企業主提供工做進展的一個公共視圖。(引自百度百科)
scrum基本流程(四個會議):
1.產品負責人負責整理user story,造成左側的product backlog。
2.產品發佈計劃會議:product owner負責講解user story,對其進行估算和排序,發佈計劃會議的產出就是制定出這一期迭代要完成的story列表,sprint backlog。
4.spring每日立會:天天,開發團隊和產品負責人都要進行一個短暫的溝通。團隊成員回答昨天作了什麼?今天計劃作什麼?遇到了什麼問題?
5.spring演示會議:在迭代週期結束時,開發團隊向產品負責人及全部干係人進行演示,並接受反饋。
6.spring回顧會議:在迭代週期結束時,Scrum 團隊經過會議來對迭代的過程進行總結,以促使團隊自我持續改進。
3.2其餘開發方法介紹
水晶方法,Crystal ,是由 Alistair Cockburn 和 Jim Highsmith 創建的敏捷方法系列,其目的是發展一種提倡「機動性的」方法,包含具備共性的核心元素,每一個都含有獨特的角色、過程模式、工做產品和實踐。Crystal 家族其實是一組通過證實、對不一樣類型項目很是有效的敏捷過程,它的發明使得敏捷團隊能夠根據其項目和環境選擇最合適的 Crystal 家族成員。
透明水晶方法,適合於一個小團隊來進行敏捷開發,人數在6人如下爲宜。
七大致系特徵:
•1. 常常交付
任何項目,不管大小、敏捷程度,其最重要的一項體系特徵是每過幾個月就向用戶交付已測試的運行代碼。若是你使用了此體系特徵,你就會發現,「常常交付」的做用仍是很讓人吃驚的。
項目主辦者根據團隊的工做進展得到重要反饋。用戶有機會發現他們原來的需求是不是他們真正想要的,也有機會將觀察結果反饋到開發當中。開發人員打破未決問題的死結,從而實現對重點的持續關注。團隊得以調整開發和配置的過程,並經過完成這些工做鼓舞團隊的士氣。
• 2.反思改進
在咱們的開發中,時常會出現這樣那樣的問題,技術難題、各類煩心事等等,這會在很大的程度上影響項目的進展。並且,若是其餘任務對這項任務有依賴的話,那麼其餘的任務也會被推遲,這就極可能會致使項目的失敗。
換句話說,若是,咱們可以常常在迭代會中及時的反思和改進,那麼,這種事情應該是不會發生的,或者說發生了,也可以很快的找到解決方案去應對它。事實上,從慌亂的平常開發中,抽出一點時間來思考更爲行之有效的工做方法就已經足夠了。
• 3.滲透式交流
滲透交流就是信息流向團隊成員的背景聽覺,使得成員就像經過滲透同樣獲取相關信息。這種交流一般都是經過團隊成員在同一間工做室內工做而實現的。若其中一名成員提出問題,工做室內的其餘成員能夠選擇關注或不關注的態度,能夠加入到這個問題的討論當中來,也能夠繼續忙本身的工做。
•4. 我的安全
我的安全指的是當您指出困擾您的問題時,您不用擔憂受到報復。我的安全很是重要,有了它,團隊能夠發現和改正自身的缺點。沒有它,團隊成員們知而不言,缺點則愈發嚴重以至於損害整個團隊。我的安全是邁向信任的第一步。有了信任,團隊協做才能真正的實施,開發效率也就會直線上升的。
•5.焦點
所謂「焦點」,就是肯定首先要作什麼,而後安排時間,以平和的心態開展工做。確保團隊成員清楚的瞭解他們本身最重要的任務是什麼,確保他們可以有充分的時間去完成這些任務。
• 6.與專家用戶創建方便的聯繫
與專家用戶持續創建方便的聯繫可以給團隊提供:對常常交付進行配置以及測試的地方,關於成品質量的快速反饋,關於設計理念的快速反饋,最新的(用戶)需求。
• 7.配有自動測試、配置管理和常常集成功能的技術環境
自動測試能夠爲開發人員在代碼修改後就能夠進行自動測試,而且可以發現存在的一些bug,以致開發人員可以及時的進行修改,對於他們來講,節省了時間,提升了效率,並且還不用爲煩人的測試而苦惱。
總結:
基於敏捷指導思想 ,造成了很多敏捷軟件開發方法 (例如XP、scrum、水晶方法等 ),它們大都強調適應性而非預測性、強調以人爲中心,而不以流程爲中心 ,以及對變化的適應和對人性的關注。
縱觀全部敏捷開發方法,其基本都具有輕載、基於時間、Just Enough、並行並基於構件的迭代和增量的特色 。
4.敏捷管理工具
4.1 禪道
禪道是一款國產專業的研發項目管理軟件,主要管理思想基於國際流行的敏捷項目管理方法—Scrum。
這是修真院裏學員使用的項目管理工具,實際操做帶你們瞭解一下。
5.實例:修真院敏捷開發流程
這裏結合修真院敏捷開發PPT講解。
最後再捋一遍:
敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。在敏捷開發中,軟件項目常常被拆分爲多個子項目或多個步驟來完成,而一個步驟又稱爲一次迭代,在每一次迭代完成以後,都會產生一個可交付的產品。這樣作有效的分解了整個項目的複雜度,便於實現產品交付目標,同時在項目的早起,就能拿出初具雛形的產品。
敏捷開發方法的核心思想歸納起來,就是「以人爲本」和「適應變化」。
本身目前仍是學習基礎理論階段,沒有實際項目經驗,講敏捷可能紙上談兵了,你們有什麼意見和補充歡迎提出。
6.討論
7.參考文獻