什麼是迭代開發？
在敏捷開發中，強調的是增量交付的開發模式，即在很短的時間內開發出一些功能，然後交付給客戶或產品負責人，每一次的交付就是需求的修正，把修正的需求放到下一個迭代中，以此反覆，最後拿到的成品距離客戶想要的基本八九不離十。
在傳統模式下，每一次先歷經一個很長時間的開發週期，或許1年，或許6個月等等，基本上每一次的交付都會引起大改動，或者推翻重做。
就好比你邊玩手機邊走路，傳統模式就好比一路看着手機一直走，等突然擡頭的時候，你走的方向和你的目標已經偏離了很長一段距離，那你不得不推翻重新走；敏捷開發模式就好比走兩步擡頭看看方向是否正確，發現方向的偏差也不過那一兩步，很容易修正。
如何安排迭代週期
一般來說，每一次迭代是2周，這是最常見的，具體的自己學習《敏捷開發》相關的知識。從某個版本的截止時間來反着推算，比如今天是2019年4月1日，項目v1版本的上線時間是2019年7月1日，總共是3個月的時間，那就差不多需要6個迭代週期（1個月是2個迭代）。
回到 Azure DevOps 中，我們需要事先配置好迭代。
先點擊【項目設置】，然後【項目配置】
根目錄是不讓修改的，就是你項目的名稱。它是一個父子級關係。
先配置好 1.0 版本的起止時間
然後添加你的迭代數量，然後再給每個迭代設置一個起止日期，鼠標移動到迭代上，旁邊會有一個【設置日期】
系統會根據你上一個迭代設置的日期週期，自動推算你這個迭代的週期，比如是2周
他自動給我推算出起始日期是從15號開始的。當你選擇好開始日期後，會自動給你填充結束日期。
現在都設置好了。
這個日期在功能上並沒有什麼作用，但它會在統計上自動計算出速率、燃盡圖、累計流圖等等，這些圖表都是幫助團隊更好的提高效率。
配置團隊（區域）
很多時候，我們要完成一個項目可能需要幾個團隊來配置，比如 Web 團隊，IOS 團隊等等
把剛纔項目中配置好的迭代，從這裏一一匹配出來，否則你在產品積壓（backlog）裏看不到你配置的迭代
然後我們回到【產品積壓（backlog）】
右邊就可以看到這些迭代了，這裏稱之爲【規劃】。
當你有足夠多的故事時，你就要開始考慮哪些故事要放在哪個迭代去做，只需要拖拽到迭代中即可。
或者打開某個任務時
開始迭代的工作
當這個迭代開始了，點擊【衝刺(Sprint)】
這裏就列出了當前迭代的所有故事，以及相關任務。
如何看衝刺面板
衝刺面板是用來 跟蹤故事下的任務的進度 的。在敏捷開發中，完成一個故事可能會細分爲各種各樣的任務，比如需要設計的圖紙，前端頁面，服務端邏輯，數據庫的設計等等。爲什麼會有這樣的規則在裏面呢？因爲用戶故事必須是獨立的，請參考《故事與估算》裏“如何寫用戶故事”。在開發過程中，某些任務是需要有前置條件的，比如前端必須得有設計圖纔可以做，服務端可能需要先完成數據庫的設計纔可以開始編碼。
通過這樣的方式就能知道，一個故事需要哪些人員的協助纔可以完成。
分任務的工作是由這個故事的所有人來決定。
好啦，敏捷中的每日站會也可以使用該面板來可視化跟蹤任務的進度，可以更新每一個任務的剩餘時間
這是剩餘時間，表示這個故事還剩下多少小時可以完成。
總結
通過這一個章節，基本就能掌握 Azure Board 的使用情況了，接下來就需要你們自己去學習有關敏捷開發的知識體系，畢竟 Azure Board 是基於敏捷開發的工作方式的一套產品。當然目前可能用的最多的是 JIRA，隨着你對敏捷開發的深入理解，你會發現 JIRA 已經慢慢不適合了，這也是我轉向 Azure Board 的原因，其次自然是收費問題啦，JIRA 配套不是一般的貴。