例：
步驟1：讓我們擁有乙個由9人組成的scrum團隊，其中包括1個產品所有者，1個scrum master，2個測試人員，4個開發人員和1個dba。
步驟2：sprint決定遵循4周的週期。所以我們從6月5日到 7 月4 日開始為期乙個月的sprint 。
步驟3：產品所有者在產品待辦事項中具有優先順序的使用者故事列表。
步驟＃4：團隊決定於 6月4 日舉行「預先規劃」會議。
在所有討論之後，個人團隊成員回到他們的工作站和
總工作小時數= 9
減1小時休息，減1小時會議，減1小時電子郵件，討論，故障排除等
所以實際工作時間= 6.sprint
期間的總工作天數= 21天。
總可用小時數= 21 * 6 = 126.
該成員休假2天= 12小時（每個成員有所不同，有些可能請假，有些可能不會。）
實際小時數= 126 - 12 = 114小時。
這意味著該成員實際上可以在此sprint中使用114小時。所以他將打破他的個人衝刺任務，總共達到114小時。
步驟＃5： 6月5 日，整個scrum團隊召開「規劃會議」。
步驟＃6：sprint啟動後，根據分配的任務，每個團隊成員開始處理這些任務。
第7步：團隊每天開會15分鐘並討論3件事：
步驟＃8：scrum master在「burn down chart」的幫助下每天跟蹤進度。
步驟＃9：如果遇到任何障礙，scrum主管會跟進解決這些問題。
步驟＃10： 7 月4 日，團隊再次召開審查會議。成員向產品所有者演示實現的使用者故事。
步驟＃11： 7 月5 日，團隊再次召開會議，討論回顧
步驟＃12： 7 月6 日，團隊再次召開下一次衝刺的預先計畫會議，並繼續進行迴圈。
敏捷開發 工作流程的梳理
2019年08月09日，上海受颱風利奇馬的影響，晚間狂風大雨。在出公司大樓經過乙個拐角的時候，隱隱感覺這情形 裡的配置項會不會有問題，心裡很是忐忑，冒雨又折回。重新開啟電腦，再捋一遍 的時候，bug像一道匕首直刺心頭 臥槽，這個路徑竟然還是測試環境 的路徑！專案組是公司敏捷開發團隊，每週五都會有生產...
刪除乙個工作流
刪除乙個工作流 delete from wfprocess t where t.processname wotracking and t.processrev 18 delete from wfsubprocess t where t.processname wotracking and t.pro...
乙個成功敏捷團隊的失敗歷程
很多人可能疑惑，很多案例都是從失敗到成功，這個怎麼反了。很多成功背後都有其原因，可能很勵志，但從失敗中我們能夠獲取更多。畢竟我們的知識大多源於失敗而非成功。故事是這樣的 括號中的是筆者的情緒表達 在很久很久以前 某公司成立了乙個團隊，開發一款全新的產品。產品的開發模式是產品需求獲取和開發同步進行，團...