Microsoft DevOps 文件裡的文章（https://docs.microsoft.com/zh-cn/azure/devops/report/dashboards/cycle-time-and-lead-time?view=azure-devops）中的這張圖片在給我們介紹了 什麼是週期時間 以及它如何影響我的專案流時非常有影響力。
第一次輸入 "正在進行" 或 "已解決" 狀態類別到輸入 "已完成" 狀態類別，計算週期時間。 當開發人員編寫程式碼時，能夠快速驗證更改並進行修訂對於保持較短的週期時間至關重要。
豐田生產方式之父大野耐一曾經說過：我們唯一要做的就是降低從接到訂單到交付產品給客戶的週期時間。週期時間的降低可以有效保證軟體的按時交付 。所以週期時間是軟體交付的核心目標。
特別是微服務的設計和開發，通常需要達成下列4個目標：
- 構建的API 驅動設計的微服務
- 一切都可以在本地構建、測試和執行，而無需複雜的設定。
- 雲端和本地依賴關係的等效性
- 裝置環境無關，可以自由在Windows,Linux,Mac 之間切換。
我們藉助於Dapr 可以非常容易的達成以上4個目標， 使用 Docker Compose 和 Dapr 技巧進行本地開發，測試和生產環境執行於Kubernetes， Kubernetes現在是各大雲廠的標配服務。藉助於Dapr 的語言無關性，平臺無關性，我們可以在環境上儘量的縮短了時間，保持較短的週期時間交付軟體。
我們可以在大腦裡面來回顧一下我們的開發過程，對於每個任務/程式碼更改：
- 開發人員會將更改部署到生產環境
- 如果發現任何錯誤，請重新部署舊 映象
- 在本地修復所有更改
- 推動其分支以生成可部署的內部版本，然後返回到 （1）
只有當開發人員脫離這個迴圈時，他們才能將他們的程式碼簽入主程式。這個過程太瘋狂了！僅第 4 步在映象建立和部署之間就花費了大約 20 分鐘。兩三個遺漏的錯誤可能會使開發人員在一天中花掉大約1個小時，並且考慮到除了日常工作之外，我們都在從事這項工作，這扼殺了生產力。還有可能要考慮到部署對依賴項的更改所需的週期，此處的部署花費了更長的時間。