Agile（敏捷）
以快速迭代、交付客戶價值的一種精神、思维
為了快速適應市場變化，不斷地評估需求、計畫和結果
通常被誤會為敏捷（軟體）開發（Agile software development）， 但其實不一定只能用在程式開發方面
Scrum
達成 Agile 的一種協同工作、管理框架
另一個常用且有名的方法：KanBan（看板）
永遠彈性調整，並優先做最重要的事情
團隊的所有人都要能「隨時掌握情況，幫助彼此解決問題」
專注在「如何於固定時間內，產生更多價值」
當一個案子被要求大幅度修改時，執行者的心中常會想： 「這樣，之前做的不就都白費了嗎？」 「為什麼當初不先講，現在才在那邊改？」 光是有這種想法，在 Scurm 中都是個大忌！
因為理論上，我們過去所做的，都是當時最好的決定， 只是因為現在情況變了，才做了不一樣的調整。
但是要注意彈性調整是否偏離大方向，若偏離大方向太大，代表當初的目標制定非常有問題！
因為是以團隊為核心， Scrum 中的每個執行人員，都該對所有任務負責， 不會有東西做錯應該是誰的問題。
一個運作良好的 Scrum 團隊，
個人能力不需要有任何顯著的提升，就能讓團隊的效率成長非常快速
Owner 負責人
Master 導師
Developer （工程師、設計師、業務、行銷）：約莫 7 人
Others： 使用者（ User） ：政府機關 利益相關者（ Stakeholder）： PMs
Backlog：Gitlab issue
Task： Gitlab issue board
Spec：Gitlab wiki
Sprint： Gitlab milestone
因為大家各自的專案忙完才有時間做，所以 每日會議不開，以 Line 群取代
Sprint 會議一次把 backlog、review 、檢討做完
建立通用後台 UI、制定規範、製作 Figma/Axure Template
建立後台模組： BpSidebar、BpTable、BpSearchbar、Keyword cloud…
新到職工程師練功
虎頭蛇尾工程師完全沒空做，放推一年半，變成 BPMS
解決什麼事、如何解決
「沒有按照時間進行」
「管理者無法全面掌握狀況」
「過多的討論會議」
「執行冗長的感覺」
「開發週期長，應變能力不足」
…more
Owner 負責人
負責人代表了客戶的意願
保證 Scrum 團隊在做從業務角度來說正確的事情
規劃產品 Road Map 將需求轉換成有價值的用戶故事 ( User Story )，並排出優先級，放入訂單 ( backlog )
Master 導師
主要任務：去除影響團隊交付衝刺 ( sprint ) 目標的障礙
確保 Scrum 過程遵循其初衷使用
是一個必須對產品開發流程以及溝通能力有一定掌握並具備一定的技術實力的角色
Developer （工程師、設計師、業務、行銷）
任務主要執行者
建議 5 - 9 人
騎士精神、互相協助、以團隊目標為目標
Others：使用者（ User） 、利益相關者（ Stakeholder）
需求清單 Backlog
Owner 會負責收集各方需求
統整出有價值的需求
並排列優先順序。
無法明確說明需求的可記錄但不做討論
全時段不停地收集
衝刺會議 ( Sprint Planning )
團隊討論 Backlog 的細節，無法明確說明需求的不做討論
利用 Poker 評估出任務需花多少工時，太多工時的要拆分任務，會後有需要再細分任務
估算下一期開發團隊可執行的實際工時
挑選下一期 sprint backlog
由開發團隊自行認領當任務負責人
訂出下一期 實作日程、Plan 、Review、修正、Release
Sprint 期間
依照團隊特性，通常為 2 - 4 週。
每天可能會有站立會議，15 分鐘內開完。
保持積極，若遇重大問題，即刻開會。
不討論細項，只提出需要眾人一起思考的事項。
透過燃盡圖監督，確保能完成本期工項。
Review
檢視成果
Code Review
測試
修正
Retrospective
好的可以保持
壞的如何改善
如果重來一次
...more
實例：
撰寫測試情境列表，以免功能越加越多，舊功能壞掉都沒人知，例如：
新增一篇文章
刪除文章
修改文章
依照測試列表完成測試，回報錯誤，後續進行修改。 錯誤修改視團隊決定，通常由該任務負責人修復，若牽扯太多功能則討論細項問題。
展示＋回顧 要事先先寫好 不要講過就忘 下一期之後都要 確實執行才會進步
每個團隊跑的內容跟使用工具都不一樣，所以 Copy 別人的跑法， 之後也要根據團隊特型做調整！ 例如： 內部專案 BPGCMS 曾經就是利用 Gitlab 當唯一工具使用，且跑法 的日程計算很不一樣。
