敏捷开发、DevOps和云计算（四）
1.4敏捷實踐
敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法。
為什么說是以人為核心？
我們大部分人都學過瀑布開發模型，它是以文檔為驅動的，為什么呢？因為在瀑布的整個開發過程中，要寫大量的文檔，把需求文檔寫出來后，開發人員都是根據文檔進行開發的，一切以文檔為依據；而敏捷開發它只寫有必要的文檔，或盡量少寫文檔，敏捷開發注重的是人與人之間，面對面的交流，所以它強調以人為核心。
什么是迭代？
迭代是指把一個復雜且開發周期很長的開發任務，分解為很多小周期可完成的任務，這樣的一個周期就是一次迭代的過程；同時每一次迭代都可以生產或開發出一個可以交付的軟件產品。
敏捷開發的實現方式有很多種，最常用的是SCRUM和極限編程（ExtremeProgramming，簡稱XP）。Scrum和XP的區別是，Scrum偏重于過程，XP則偏重于實踐，但是實際中，兩者是結合一起應用的。
1.3.1 SCRUM
SCRUM是一種開發流程框架，也可以說是一種套路，是迭代式增量軟件開發過程。
Scrum的英文意思是橄欖球運動的一個專業術語，表示“爭球”的動作；把一個開發流程的名字取名為Scrum，我想你一定能想象出你的開發團隊在開發一個項目時，大家像打橄欖球一樣迅速、富有戰斗激情、人人你爭我搶地完成它，你一定會感到非常興奮的。
關于迭代和Sprint(沖刺)：
初涉敏捷開發的人，經常會混淆迭代和Sprint的概念，導致在各種場合混用這兩個詞語。
迭代：開發迭代是一次完整地經過所有工作流程的過程：需求分析、設計、實施和測試工作流程。它類似于小型的瀑布式項目。迭代開發本身是一種有計劃的修改策略：通過多次開發來改善正在構建的特性，逐步得出一個完善的解決方案。例如，對一個知之甚少的產品，開始時可以先創建原型以獲得重要知識，接著可以創建一個更好一點的修訂版，再接下來是一個相當好的版本。
Sprint：Sprint（沖刺） 是 Scrum 的核心，其長度（持續時間）為一個月或更短時間的限時，在這段時間內構建一個“完成的”、可用的和潛在可發布的產品增量。在整個開發過程期間， Sprint 的長度通常保持一致。前一個 Sprint 結束后，新的下一個 Sprint 緊接著立即開始。沖刺的另外一個特性則是在每個沖刺中一定要有計劃/評審/回顧/每日站會等儀式來確保沖刺能夠達到應用的效果。
1.3.1.1 Scrum開發流程中的三大角色
1.3.1.1.1 產品負責人（Product Owner）
主要負責確定產品的功能和達到要求的標準，指定軟件的發布日期和交付的內容，同時有權力接受或拒絕開發團隊的工作成果。
1.3.1.1.2 流程管理員（Scrum Master）
主要負責整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發工作之間的溝通障礙，使得客戶可以直接驅動開發。
該角色也被稱為“敏捷教練”：敏捷教練，從職責和影響范圍大體可分為四類：
● 技術教練（CI/CD，OO，微服務，Cloud 等）
● 團隊教練（團隊流程，團隊建設，團隊回顧等）
● 組織教練（組織級變革）
● 管理教練（戰略，人才等）
開發出身一般比較容易從技術教練做起。
產品，BA，QA，PM 一般可從團隊教練做起。
中高層管理者可以直接做組織級教練。
CXO 可以做管理教練
教練存在的形式有內部教練和外部教練兩種，一般從內部教練做起容易。
1.3.1.1.3 開發團隊（Scrum Team）
主要負責軟件產品在Scrum規定流程下進行開發工作，人數控制在5~10人左右，每個成員可能負責不同的技術方面，但要求每個成員必須要有很強的自我管理能力，同時具有一定的表達能力；成員可以采用任何工作方式，只要能達到Sprint（沖刺）的目標。
1.3.1.2 Scrum開發流程中的四種會議
四種會議指的是Sprint計劃會議、每日站會（Daily Scrum）、Sprint評審會議和Sprint回顧會議。
1.3.1.2.1 Sprint計劃會議（Sprint Planning）
在Scrum中，Sprint計劃會議有兩部分：
第一部分：需要完成哪些工作？
參會人員：團隊、項目負責人（Scrum Master）、產品負責人（Product Owner）
第一部分的會議，產品負責人向開發團隊介紹排好序的產品待辦事項，由整個Scrum團隊共同理解這些工作。
Sprint中需要完成的產品待辦事項數目完全由開發團隊決定。做多少工作只能由開發團隊決定，產品負責人或任何其它人都不能給開發團隊強加更多的工作量。
第二部分：如何完成工作？
參會人員：團隊、項目負責人（Scrum Master）
第二部分的會議，開發團隊需要根據當前的“完成的定義”一起決定如何實現下一個產品增量。他們進行足夠的設計和計劃，從而有信心可以在Sprint中完成所有工作。
決定如何完成工作是開發團隊的職責，決定做什么則是產品負責人的職責。
Sprint計劃會議最終需要Scrum團隊對Sprint需要完成工作的數量和復雜度達成共識，最終產生的待辦事項列表就是“Sprint待辦事項列表（Sprint Backlog）”。
Sprint待辦事項列表是一個需要在當前Sprint完成的且梳理過的產品待辦事項，并包括了一個團隊完成這些工作的計劃。
1.3.1.2.2 每日站會（Daily Scrum）
開發團隊是自組織的，通過每日站會來確認他們仍然可以實現Sprint的目標。
每一個開發團隊成員需要提供以下三點信息：
● 從昨天的站立會到現在，我完成了什么；
● 從現在到明天的站立會，我計劃完成什么；
● 有什么阻礙了我的進展。
每日Scrum通常不超過15分鐘。
每日Scrum中可能有簡要的問題澄清和回答，但是不應該有任何話題的討論。
每日Scrum既不是向管理層匯報，也不是向產品負責人或者ScrumMaster匯報。它是一個開發團隊內部的溝通會議，來保證他們對現狀有一致的了解。
1.3.1.2.3 Sprint評審會議（Sprint Review）
Sprint結束時，Scrum團隊和相關人員一起評審Sprint的產出。所有Scrum會議都是限定時長的，Sprint評審會議的推薦時長是Sprint中的每一周對應一個小時（比如，一個Sprint包含2個星期，則Sprint評審會議時長為2個小時）。
每個人都可以在Sprint評審會議上發表意見。產品負責人會對未來做出最終的決定，并適當地調整產品待辦事項列表（Product Backlog）。
Sprint評審會議向每個人展示了當前產品增量的概況。通常都會在Sprint評審會議中調整產品待辦事項列表。
1.3.1.2.4 Sprint回頊會議（Sprint Retrospective）
在每個Sprint結束后，Scrum團隊會聚在一起開Sprint回顧會議，目的是回顧一下團隊在流程、人際關系以及工具方面做得如何。團隊識別出哪些做得好，哪些做得不好，并找出潛在的改進事項，為將來的改進制定計劃。所有的Scrum會議都是限定時長的，Sprint回顧會議的推薦時長是Sprint中的每一周對應一個小時。
1.3.1.3 Scrum開發流程中的三個物件
三個物件指的是產品待辦事項列表（Product Backlog）、迭代待辦事項（Sprint Backlog）和燃盡圖（Burndown Chart）。
1.3.1.3.1產品待辦事項（Product Backlog）
在項目開始的時候，Product Owner要準備一個根據商業價值排好序的客戶需求列表。這個列表就是Prodct Backlog，一個最終會交付給客戶的產品特性列表，它們根據商業價值來排列優先級。Scrum team會根據這個來做工作量的估計。
Product backlog應該涵蓋所有用來構建滿足客戶需要的產品特性，包括技術上的需求。高優先級的一些產品特性需要足夠的細化以便于我們做工作量估計和做測試。對于那些可以在下個Sprint中完成的Product Backlog功能點，大約10人天的工作量的粒度就不錯了。對于那些以后將要實現的特性可以不夠詳細。
1.3.1.3.2迭代待辦事項（Sprint Backlog）
Sprint Backlog 是Sprint規劃會上產出的內容。當Scrum team選擇并承諾了Product backlog中要遞交的一些高優先級的產品功能點后，這些功能點就會被細化成為Sprint Backlog：一個完成Product Backlog功能點的必需的任務列表。這些點會被細化為更小的任務，工作量小于2天。Sprint backlog完成后，Scrum team會根據它重新估計工作量，如果這些工作量和原始估計的工作量有較大差異，Scrum team和Product Owner 協商，調整合理得工作量到Sprint中，以確保Sprint的成功實施。
1.3.1.3.3燃盡圖（Burndown Chart）
Burndown Chart 顯示了Sprint中累積剩余的工作量，它是一個反映工作量完成狀況的趨勢圖。
在Sprint開始的時候，Scrum Team會標示和估計在這個Sprint需要完成的詳細的任務。所有這個Sprint中需要完成，但沒有完成的任務的工作量是累積工作量，Scrum master 會根據進展情況每天更新累積工作量，如果在Sprint結束時，累積工作量降低到0，Sprint就成功結束。
1.3.1.4 Scrum流程圖
1.3.1.5 如何進行Scrum開發
1、我們首先需要確定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；
2、Scrum Team根據Product Backlog列表，做工作量的預估和安排；
3、有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間周期是1~4個星期，然后把這個Story進行細化，形成一個Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）；
5、在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，并且要向所有成員當面匯報你昨天完成了什么，并且向所有成員承諾你今天要完成什么，同時遇到不能解決的問題也可以提出，每個人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖）；
6、做到每日集成，也就是每天都要有一個可以成功編譯、并且可以演示的版本；很多人可能還沒有用過自動化的每日集成，其實TFS就有這個功能，它可以支持每次有成員進行簽入操作的時候，在服務器上自動獲取最新版本，然后在服務器中編譯，如果通過則馬上再執行單元測試代碼，如果也全部通過，則將該版本發布，這時一次正式的簽入操作才保存到TFS中，中間有任何失敗，都會用郵件通知項目管理人員；
7、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老板也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）；
8、最后就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結并討論改進的地方，放入下一輪Sprint的產品需求中；
上一篇：敏捷開發、DevOps和云計算（三）
下一篇：敏捷開發、DevOps和云計算（五）
總結
以上是生活随笔為你收集整理的敏捷开发、DevOps和云计算（四）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C语言易错点
- 下一篇： 计算广告（四）：合约广告