「怎麼隕石又來了！急件又來了？我該怎麼處理？」
面對這件事，我們的選擇只能是「加班」和「死命的加班」嗎？有沒有更好、更科學的處理方式，能幫助我們不加班的順暢解決呢？我整理往年的經驗，並條列如下的推薦給大家：
- 有效運用 Yesterday’s Weather：Scrum 是一個大量運用數據的科學管理方式，在重視數據管理的現代，請記得務必要估算前三個 Sprint 的 Velocity 平均值，以便了解團隊以往的概略狀況，用於預測下一個 Sprint 的大概能處理的任務 Story Point 總量。而推薦這項作法的原因在於，第一、平均值是統計學中最常見的統計方法，它能用來表達要觀察的數據值相對較集中的數據位置。第二、它是目前最簡單好理解，以及最快速的統計工具，在面對快速變化的市場和環境，我們要盡可能地簡化自己在其他方面的複雜處理，減少複雜性，就能減少暴露在風險中的機會，也才能讓事情能快速且有效的進行。
- 有效運用 Interrupt Buffer：鑑於 Scrum 的科學化管理原則，以及面臨市場和環境變化的迅速，請記得務必要估算前三個 Sprint 的插件平均值，並扣除 Yesterday’s Weather 的數值，以便快速預測出下一個 Sprint 的比較接近實際的任務 Story Point 總量。
- 落實重視 Product Owner 的專業判斷：Product Owner 是面對需求方、利害關係人（或老闆們）的重要窗口，所有需求都需要經過 Product Owner 的裁定判斷，才能落到團隊身上，以便執行。若所有的需求都是說來就來，沒有經過最理解產品狀況和 domain know-how 的Product Owner 的判斷，那麼產品勢必會走向一團混亂，技術債快速的債台高築，影響到產品發展，即使組織內業務和行銷單位再強，也無法避免掉不好用的產品評價。要記得，產品使用者才是產品能存活在市場上的最最重要核心。
- 強化與利害關係人的有效溝通：當急件來的時候，非常需要 Product Owner 與利害關係人的有效溝通（甚至 Scrum Master 也應該加入溝通協調），以便讓利害關係人知道產品是否需要這樣的需求，以及團隊目前的狀況，這樣的目的在於讓「資訊保持公開透明度」，並塑造 Scrum team 整體的聲譽，當團隊給人的印象是可靠誠信、資訊通透清楚，那在與利害關係人進行溝通時，便能有效地讓其知道是否真的有必要這麼做？若沒必要做而需要拒絕需求時，對方也能真心理解和接受。要記得，「誤解，來自於對彼此的不理解」，保持資訊公開透明度，尤其是組織各單位運作時，非常最重要的基本元素。
- Scrum Master 與 Product Owner 的良好協作：Scrum team 的成員為 Scrum Master、Product Owner 和跨職能的 Developers（指UX、UI、BA、QA、Engineer 等各種跨職能的產品開發團隊成員），當急件發生時，請 Product Owner 務必與 Scrum Master 溝通好事情的前因後果，與該如何與 Developers 溝通的適當對策，讓 Scrum Master 協助 Product Owner 與 Developers 討論為什麼會有這項急件？做了急件對公司和產品有什麼好處？這項急件要完成什麼樣的內容？確保整體 Scrum team 都能理解急件的完整內容，以便讓團隊能一起將這項重責大任儘早完成。
- Trade-off 掉與插件大小差不多 Story Point 的較不重要任務：一天只有 24 小時，MIB 電影中提到的一天有 48 小時的這種事，不存在於彼此的現實生活中，因此，任務不是盡量塞好塞滿就好，而要考量到團隊能承擔的狀況，所以務必把「和插件估算出來差不多的 Story Point 的較不重要任務」（即這任務是「相對於其他任務來講，相對較不重要的任務」）從當次 Sprint 中剔除，延後到其他 Sprint 中處理。要記得，人是組織內最重要的資產，如果不善待「人」，只把人當成「工具」，那麼終究只會獲得高流動率且不忠誠的員工，而組織就只能不斷地經歷 Bruce Tuckman 提到的團隊發展階段（Stages of Group Development）的 Forming 和 Storming，而永遠到不了能開始展現團隊績效的 Norming 階段，更不用談進入團隊發光發熱的 Performing 階段了！
這篇文希望能帶來一些新的視野。若你有一些經驗想與我分享討論，歡迎聯繫我！: )
— — —
希望這樣的分享，能幫助大家對好需求怎麼寫能產生啟發，甚至有不同的新觀點！若想給予我feedback，或有受到啟發，或甚至產生行動，請務必讓我知道，我很樂意跟每一位對我的分享有興趣的新舊朋友們聊聊：https://www.facebook.com/kaitlyn.peng.56
