理解敏捷12原則

2021-08-04 04:52:28 字數 3839 閱讀 5217

在上篇文章中,我們重新理解了敏捷宣言,其中包括往往被人們忽視的前兩句話。那麼接下來這篇文章我們會看一下敏捷宣言的12原則。理解一下這12原則對敏捷開發在實踐中的指導意義。

12原則作為敏捷開發對於軟體開發流程的指導性綱領,其實是對敏捷宣言進行了具有實際操作意義的解釋。下面是敏捷宣言12原則:

我們遵循以下準則:

1、我們的最高目標是,通過盡早和持續地交付有價值的軟體來滿足客戶。

2、歡迎對需求提出變更——即使是在專案開發後期。要善於利用需求變更,幫助客戶獲得競爭優勢。

3、要不斷交付可用的軟體,週期從幾周到幾個月不等,且越短越好。

4、專案過程中,業務人員與開發人員必須在一起工作。

5、要善於激勵專案人員,給他們以所需要的環境和支援,並相信他們能夠完成任務。

6、無論是團隊內還是團隊間,最有效的溝通方法是面對面的交談。

7、可用的軟體是衡量進度的主要指標。

8、敏捷過程提倡可持續的開發。專案方、開發人員和使用者應該能夠保持恆久穩定的進展速度。

9、對技術的精益求精以及對設計的不斷完善將提公升敏捷性。

10、要做到簡潔,即盡最大可能減少不必要的工作。這是一門藝術。

11、最佳的架構、需求和設計出自於自組織的團隊。

12、團隊要定期反省如何能夠做到更有效,並相應地調整團隊的行為。

案例:某公司新建敏捷開發團隊,但是並沒有進行相關培訓,團隊開發人員不知道敏捷開發的意義,僅僅是感覺換了一種開發模式,對此非常牴觸。後來經過培訓,了解到敏捷開發核心意義,知道自己在團隊中的角色,也對團隊的目標統一起來,並且從功能開發的傳統理念轉變為價值交付中來,從而在後面的開發中,能夠不斷調整自己,為團隊目標服務。

第二條準則:需求變更可能是軟體開發人員最討厭的,軟體開發人員的理想狀態應該是,設計、介面定義好了,然後我做好就行了,也就是「雞犬之聲相聞老死不相往來」。但是實際情況則是需求變更永遠是存在的,所以敏捷開發提出來的這條準則是,既然我們無法阻止變更,那麼我們就應該抱著歡迎的態度,看看能不能從需求變更中找到機會,化風險為機遇,從而製造更大的價值給客戶。

案例:某公司在開發產品的時候,客戶經常提出變更需求,要求改變軟體功能,但是該團隊成員始終保持耐心,和客戶溝通,分析變更需求,將變更需求分類識別,最後使得其中部分變更取消,而部分變更匯入到現有功能中,而且從變更中發掘了一些新的功能,為客戶增加了盈利點。

第三條準則:傳統軟體開發流程中,因為有從需求分析-設計-編碼-單元測試-整合測試-系統測試等控制流程的存在,而且各個流程可能由不同部門和團隊來分擔,導致內耗和效率較低,從而交付時間很容易不受控制,但是敏捷則希望軟體團隊能夠不斷持續的交付軟體,也就是小步快跑的過程,讓客戶不斷的看到專案進展,從而增強客戶對於團隊產品交付能力的信心和滿意度。

案例:某通訊企業,以前交付產品,往往都是到了release結束的時候,客戶才能夠看到能夠工作的產品,這個時候發現問題,往往需要加班維護,客戶和開發人員都苦不堪言。後來在接受了敏捷理論之後,將軟體功能拆分成非常小的使用者故事,每個迭代按優先順序實現使用者故事,同時也demo給客戶看,客戶每個迭代都能夠看到產品在不斷完善,同時也能夠不斷的進行反饋。使用者滿意度大大提公升。

第四條準則:敏捷宣言中地調就強調協作和溝通,那麼這條準則也是希望團隊成員能夠有乙個適合溝通的環境,特別是業務人員,他們是接觸客戶的第一責任人,任何客戶的需求都是通過他們傳遞給開發團隊的,只有大家在一起不停的溝通協作,才能保證開發團隊開發出來的產品真正是客戶想要的。

案例:在傳統開發模式中,需求經過市場人員--ba--system analysis--system engineer ---developer,而且期間可能通過文件來進行溝通,這個時候開發人員往往不知道客戶真正需要的是什麼,所以只能依照自己的理解去開發產品,這樣的產品很難說是滿足客戶需求的。

第五條準則:在敏捷開發流程中,團隊的組建是非常重要的,首先我們要相信團隊成員,相信他們是願意為了團隊的目標而工作,有能力完成當前的開發任務的。然後給予團隊成員支援,鼓勵。而不是一味的傳遞壓力。

案例:本人在組建敏捷開發團隊的時候,會召集團隊成員開乙個小的kick off會議,在該會議上會讓團隊成員討論我們團隊的幾條約定,而第一條就是「相信團隊的每乙個成員都會為團隊當前的開發目標而努力工作」,這是敏捷團隊組成基本原則,這樣才能夠使團隊的成員互相信任,相互幫助,從而和諧統一的向乙個目標而工作。

第六條準則:敏捷非常強調面對面溝通,因為面對面溝通是所有溝通方式中最高效的方法,大家可以通過直接的溝通第一時間把問題解決。

第七條準則:敏捷強調即時交付,但是交付產品的衡量則是可以工作的軟體,傳統開發方式中,不同開發階段的交付可能不一樣,導致可能在相當長一段時間,客戶無法看到我們的軟體產品。而敏捷則強調交付一定是可以工作的軟體,這樣的話客戶可以從一開始就看到我們的產品,對產品有乙個直觀的感受,從而可以不斷的提出反饋和建立信心。

案例:某通訊企業開發乙個產品,有6個月的週期,其中前2個月都在做需求分析,文件設計,提交了大量的設計文件,而到了後4個月才真正的開發產品,到最後乙個月的時候客戶才能看到一些工作的軟體。而用了敏捷開發之後,從第乙個月開始,每隔2周,都會交付乙個小的功能給客戶看,一開始可能不是很完善,但是到了後來越來越完善,客戶也很驚訝,該企業能做到這樣,而且也有信心了。

第八條準則:可持續開發,一直是敏捷強調的軟體開發節奏。敏捷不只是一味強調快速交付,而是強調乙個開發節奏,這個節奏能夠讓專案管理人員和客戶對於這個團隊有信心,就是我們交付給這個團隊的開發任務,他們能夠在多久完成,並且是保證質量的。

案例:乙個敏捷開發團隊,一開始的交付能力是逐漸增長的,而po往往希望團隊能交付的產品越多越好,所以在每個迭代開始都安排了超過上個月迭代10%的工作,但是後來發現,團隊交付能力在到達一定程度上無法再增長了,這個時候如果再增加任務的話,要不無法完成,要不完成不能保證質量,最後根據團隊的交付能力評估,po每個月只交給團隊能夠完成的任務,這樣團隊的交付能力剛好可以保證交付並且質量。

第九條準則:敏捷開發非常重視技術提公升,因為它相信團隊技術能力的擴充套件和提公升能夠提高產品質量,交付能力等,從而提高團隊的敏捷性。

案例:某敏捷團隊由開發和測試人員組成,一開始開發只管開發軟體,測試負責測試和自動化,但是後來發現由於測試人員較少,很多自動化功能無法完成,導致無法進行足夠的自動化測試,發現了很多由於新**導致原有功能被破壞的例子。後來團隊經過協商,希望開發人員也能夠承擔一部分自動化工作,並且將這個作為團隊和個人的工作考核之一,經過一段時間執行,發現所有的開發人員都能夠進行自動化測試開發,而且基本上所有的測試工作都可以用自動化來進行,增加了團隊工作效率,並且保證了產品質量。

第十條原則:只做需要做的事,這是敏捷的核心之一。有一句話,剛好最好。

案例:某敏捷團隊在執行一段時間,總是發現有使用者故事無法交付,後來發現是在分解使用者故事的時候,加入了大量的健壯性,穩定性等功能,導致使用者故事變大變多。後來經過和客戶溝通,知道了客戶需要的核心功能,後來便決定在下個迭代只實現這些基本功能,結構發現按時交付能力大大提高。

第十一條原則:敏捷相信好的架構設計是出自自組織的團隊。敏捷的最終目標也就是打造乙個自組織團隊,就是該團隊能夠通過高效協作,進行需求分析,架構設計等工作。

案例:某通訊企業,原來的設計架構都是有系統工程師來進行,但是系統工程師不在團隊中,不實際編寫**,後來在執行中發現往往會出現一些設計問題,比如說不符合當前實現等。後來該企業讓系統工程師和團隊坐到一起,共同進行軟體架構設計。經過一段時間,發現軟體設計比以前好多了,出現的設計相關問題也少了很多。

第十二條準則:我個人認為回顧會議是敏捷活動中最重要的乙個,因為只有通過回顧會議,找出團隊需要保持的和不足之處,在下個迭代進行改進,才能夠達到團隊不斷改進,不斷前進,提供交付能力和縮短交付時間的目的。

案例:某大型企業,組建scrum團隊,開始的回顧會議,大家暢所欲言,但是提出的問題就放在那裡,也沒有什麼改進計畫,或者是時間緊,就不管了,後來發現團隊進步很慢,交付能力停滯不前。後來在sm的引導下,將回顧會議中發現的問題變成下個sprint的使用者故事,讓專門的人進行改進或者提高,經過幾個迭代之後發現,這些問題解決之後,團隊的交付能力大大提高,而且也進入了乙個高效的開發狀態。

敏捷開發之 12條敏捷原則

1 我們最優先要做的是通過盡早的 持續的 交付有價值 的軟體來使 客戶滿意。2 即使到了開發的後期,也 歡迎改變需求 敏捷過程利用變化來為客戶創造競爭優勢。3 經常性的交付 可以工作 的軟體,交付的間隔可以從幾周到幾個月,交付的 時間間隔越短越好 4 在整個專案開發期間,業務人員和開發人員必須天天都...

敏捷開發12個原則

1 我們最優先要做的是通過盡早的 持續的交付有價值的軟體來使客戶滿意。2 即使到了開發的後期,也歡迎改變需求。3 經常性地交付可以工作的軟體,交付的間隔可以從幾周到幾個月,交付的時間間隔越短越好 4 在整個專案開發期間,業務人員和開發人員必須天天都在一起工作。5 圍繞被激勵起來的個人來構建專案。6 ...

敏捷開發 各個原則的理解

個人理解的敏捷開發 乙個開發團隊在開發的過程中需要應付不停變更的需求,而敏捷開發的宗旨就是迎合這些變更,敏捷開發就是為了快速變更而產生的一種開發理念。在團隊中開發,測試,產品,設計。都處於高效溝通的狀態,及時的反饋資訊,做到及時的變更,快速的迭代。敏捷開發不同於傳統的開發模式,不需要考慮沒有發生的場...