前言

這次 Hello World Dev Conference 聽了一場 殭屍敏捷來襲

『 Zombie Scrum 是指 流程看起來像 Scrum，但是卻死氣沈沈、毫無樂趣 』- 取自 喪屍 Scrum 生存指南：邁向真敏捷的復原之路 解釋

殭屍敏捷一詞也讓我想到 MOPCON 2021 的一場議程：Scrum 是新的死亡行軍嗎，裡面提到：
『 從專案開始，即一路掙扎，往失敗前進。這種狀況稱之為死亡行軍 』

# 可以檢視團隊符合幾項
1. 常常增加 Bug
2. 迭代目標常沒做到
3. 士氣下降
4. 互相指責變嚴重
5. 忽略好的作法
6. 難找到樂於幫助或是協作的人
7. 定期加班

可以參考 Spotify 的 Squad Health Check model – visualizing what to improve，讓每個人替每項指標都給出燈號 (綠燈：有趣、很棒，黃燈：普通，紅燈：無聊、很差)，最後再來解讀大家投票的結果

# 團隊溫度計參考指標
1. Support 團隊外部支援
2. Teamwork 團隊內部合作
3. Mission 了解並認同目標
4. Health of codebase 程式碼品質
5. Suitable process 合適流程
6. Delivering value 交付價值
7. Learning 學習
8. Speed 交付速度
9. Easy to release 容易發布
10. Fun 有趣

圖取自 Squad Health Check model – visualizing what to improve

Zombie Scrum

和死亡行軍的蠻類似的，講者也列出以下幾項可供團隊檢視健康度的項目：

1. Sprint 結束的時候，沒有可以 Work 或是 Demo 的產品一起來檢視
2. Sprint Retrospective 枯燥和重複
3. 團隊中大多數成員只在自己認領的事項上工作
4. Product Owner 對Product Backlog 中的內容和優先順序幾乎沒有發言
5. 產品的利害關係人很少參加 Sprint Review
6. 當 Sprint 不順利時，沒有人提出不好
7. IT 不知道業績相關訊息
8. Scrum 團隊中沒有令人興奮的事情發生
9. 每日站會只是一個由 Scrum Master 擔任主持人做任務狀態更新
10. 管理階層只關心 Scrum 團隊能做多少工作

不管是死亡行軍或是殭屍敏捷，都有種為敏捷而敏捷的味道。礙於某些錯綜複雜的原因，好像每一家公司都要用敏捷做開發、做管理，但又好像不是每種專案都適合？

敏捷管理、傳統專案管理差在哪？哪類專案不適合敏捷？ 整理了瀑布式和敏捷式的開發：

• 瀑布式專案管理
  • 適合需求和工作方法明確的專案，例如工程專案、舊有產品更新
  • 在專案全數執行完後，才交付成果，客戶開立完產品需求後，下次見面就是看到產品
• 敏捷專案管理
  • 適合複雜度高、技術不確定的專案，像軟體開發、新產品研發等
  • 強調「最小可用」的原則，在每個階段讓使用者看到雛形，確認產品對使用者產生價值

參考資源

Zombie Scrum - Symptoms, Causes and Treatment
如何做團隊流程回顧會議：Spotify 的健康檢查模型