敏捷開發
1、敏捷的含義
敏捷開發是一種以人為核心、迭代、增量的開發方法，在敏捷開發中，把一個大專案分為多個相互聯系，可獨立運行的小專案，并分別完成，在此程序中軟體一直處于可使用狀態，
上面提到3個關鍵詞，下面做個闡述：
以人為核心：眾所周知在瀑布開發模型中，會出現大量的檔案，開發人員往往都是根據檔案進行開發，一切以檔案為依據；而敏捷開發倡導少寫檔案，注重人與人面對面的交流，用溝通解決專案問題，所以它強調以人為核心
迭代開發：是指把一個復雜且開發周期很長的大任務，分解為很多小周期可完成的任務，這樣的一個周期就是一次迭代；同時每一次迭代都可以生產或開發出一個可以交付的軟體產品
增量開發：是指軟體每個發布的版本，都會新增一個用戶可以感知的完整功能，可以理解成，按照新增功能來劃分迭代
2、如何敏捷？
上面闡述的敏捷更多的是一種理念，但要實作敏捷開發有哪些實作方式呢？常見方式有兩種Scrum和XP，在講解具體步驟前，先說說它們的區別，
網上隨處可查的區別是：Scrum偏重于程序，XP則偏重于實踐，簡單解釋一下這句話，Scrum是從管理上，流程上設計一些方法來定義敏捷，XP是從具體的細節和某一作業的實作方法上深度挖掘了敏捷思想，區別詳細如下：
1. Scrum 和 XP 團隊都在迭代的方式下作業，但Scrum的周期一般是從兩周到一個月，XP的周期是一兩周
2. Scrum 團隊在一個sprint中是不接受任何任務變更的，而XP的團隊在一個迭代中，如果新的用戶故事跟原來的規模和大小差不多，可以用新的進行替換，
3. XP 團隊會嚴格按照任務的優先級來作業，所有的任務都被客戶劃分了優先級，團隊都被要求在該優先級下作業，但scrum團隊的人員會自己決定他們以何種順序來完成所有的任務，
4. Scrum并沒有定義任何工程實踐的方法，它只是提供了一個實踐的框架給你，但XP，極限編程卻會給你這樣的一些東西，比如測驗驅動開發， 自動化測驗，結對編程，簡單設計，重構等等，
Scrum流程
Scrum步驟：
1、我們首先需要確定一個Product Backlog（按優先級排列的一個產品需求清單），這個是由產品經理負責的；
2、Scrum 團隊根據Product Backlog清單，做作業量的預估和計劃；
3、有了Product Backlog清單，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story（用戶故事）作為本次迭代完成的目標，這個目標的時間周期是1-4周，然后把這個Story進行細化，形成一個Sprint Backlog；（PS：Sprint 表示一次迭代）
4、Sprint Backlog是由Scrum 團隊去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的作業量在2天內能完成）；
5、在Scrum 團隊完成計劃會議上選出的Sprint Backlog程序中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，并且要向所有成員當面匯報你昨天完成了什么，承諾你今天要完成什么，同時遇到不能解決的問題也可以提出，每個人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖，見下圖）；
6、做到每日集成，也就是每天都要有一個可以成功編譯、并且可以演示的版本；可使用工具實作提交、更新、測驗和發布；
7、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次迭代完成，我們就要進行 Srpint Review Meeting（演示會議），也稱為評審會議，每一個Scrum 團隊的成員都要演示自己完成的軟體產品；
8、最后就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，總結并討論改進的地方，放入下一輪Sprint的產品需求中；
XP敏捷實踐
XP即極限編程（Extreme Programming的縮寫），極限編程是一種強調團隊作業的作業方式，它是多種敏捷方式的一種，與Scrum不同的是，Scrum是一種作業方式的框架，從組織到團隊的設計，而XP關注的是具體的工程技術實踐，XP旨在通過工程實踐的合理搭配使用，使開發者們能夠自信地回應客戶需求，強調反饋環機制，客戶與研發團隊之間的反饋環，測驗與開發的反饋環，具體代碼實作跟單元測驗之間的反饋環，結對之間的反饋環，極限編程認為在軟體研發程序中，變化是無所不在的，人們不應回避變化，而應該適應變化，通過對反饋去適應變化，
XP工程實踐：
1、小型發布（Small Release）
每一次發布的版本應該盡可能的小，當然前提條件是每個版本有足夠的商業價值，值得發布，由于小型發布可以使得集成更頻繁，客戶獲得的中間結果也越頻繁，反饋也就越頻繁，客戶就能夠實時地了解專案的進展情況，從而提出更多的意見，以便在下一次迭代中計劃進去，以實作更高的客戶滿意度，
2、計劃游戲/規劃策略(The Planning Game)
計劃游戲的主要思想就是先快速地制定一份概要的計劃，然后隨著專案細節的不斷清晰，再逐步完善這份計劃，計劃游戲產生的結果是一套用戶故事及后續的一兩次迭代的概要計劃，“客戶負責業務決策，開發團隊負責技術決策”是計劃游戲獲得成功的前提條件，也就是說，系統的范圍、下一次迭代的發布時間、用戶故事的優先級應該由客戶決定；而每個用戶故事所需的開發時間、不同技術的成本、如何組建團隊、每個用戶故事的風險，以及具體的開發順序應該有開發團隊決定，
3、現場客戶(On-site Customer)
為了保證開發出來的結果與客戶的預想接近，XP方法論認為最重要的需要將客戶請到開發現場，因此，在專案中有客戶在現場明確用戶故事，并做出相應的業務決策，對于XP專案而言有著十分重要的意義，
4、簡單設計(Simple Design)
這個實踐看上去似乎很容易理解，但卻又經常被誤解，許多批評者就指責XP忽略設計是不正確的，其實，XP的簡單設計實踐并不是要忽略設計，而且認為設計不應該在編碼之前一次性完成，因為那樣只能建立在“情況不會發生變化”或者“我們可以預見所有的變化”之類的謊言的基礎上的，
5、結對編程(Pair programming)
所有的軟體都是由兩個程式員、并排坐在一起在同一臺機器上完成的，
6、測驗驅動開發(Testing）
撰寫單元測驗是一個驗證行為，更是一個設計行為，撰寫單元測驗避免了相當數量的反饋回圈，尤其是功能驗證方面的反饋回圈，程式員以非常短的回圈周期作業，他們將預先撰寫一個自動化測驗腳本，然后再編碼使之通過，
7、重構(Refractoring)
重構是一種對代碼進行改進而不影響功能實作的方式，XP需要開發人員在聞到代碼的壞味道時，有重構代碼的勇氣，重構的目的是降低變化引發的風險，使得代碼更優雅，
8、持續集成(Continuous Integration)
持續集成的含義則是要求XP團隊每天盡可能多次地做代碼集成，每次都在確保系統運行的單元測驗通過之后進行，這樣，就可以及早地暴露、消除由于重構、集體代碼所有制所引起的錯誤，一個人commit后，其它所有人都有責任進行代碼集成作業，
9、代碼集體所有權(Collective Code Ownership)
任何結對的程式員都可以在任何時候改進任何代碼，沒有程式員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其它方面的開發，
10、編碼規范（Code Standards）
XP方法論認為擁有編碼標準可以避免團隊在一些與開發進度無關的細節問題上發生爭論，
11、系統隱喻（System Metaphor）
它是系統的未來影像，將整個系統聯系在一起的全域視圖；它使得所有單獨模塊的所屬位置和外觀變得明顯直觀，如果模塊的外觀與整個隱喻不符，那么你就知道該模塊是錯誤的，
12、可持續的速度/每周40小時作業制（40-hour Week）
加班早已成為開發人員的家常便飯，也是管理者最常使用的一種策略，而XP方法論認為，加班最侄訓扼殺團隊的積極性，最終導致專案失敗，團隊只有持久才有獲勝的希望，他們以能夠長期維持的速度努力作業，他們保存精力，他們把專案看作是馬拉松長跑，而不是全速短跑，
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/296393.html
標籤：其他