iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 17
0

https://ithelp.ithome.com.tw/upload/images/20190918/20106486ZXDiQIoHPM.jpg

『哎!我們跑了 Scrum 後,插件不減反增了?』
『Scrum 不是不會有插件嗎?』

常常聽到有人談論『插件』的定義與處理方式,我一直很想寫這一篇,但一直以來,我都把這件事放一旁,不是這件『插件』不重要,而是我想聚焦一些,前幾個月的 Medium 產物主題分別是『SEO』、『行銷』、『故事』、『遊戲』。所以這份『插件』就一直被我擱置,直到這週我想寫一些『敏捷』相關主題,『插件』果真被成了待辦事項。

清楚嗎?這份『插件』一直沒真正成為『插件』,因為它並沒有打亂我的原定計劃,『想要』不等於『需要』也不等於要『插件』。而現在我開始進行了這份『插件』,但此時的它也不是『插件』,因為他是我『規劃好要進行的文章』。

什麼是插件?

討論『插件』前,我們先來定義什麼是『插件』?一般的定義就是『不在預期內』且『會中斷』現在進行中已規劃好的工作的『額外工作』。但如果該『插件』是『預期內』或沒有『中斷』到預期中的工作,就不一定是『插件』了!

在 Scrum 中,什麼是『插件』呢?

在每個『產品待辦清單』(Product Backlog)中,會存在很多『故事』(Story)需求,有些『故事』已經進行了『產品精煉會議』後變得比較『清晰』、『可估計』了,這些『大小適中』且『重要』的『故事』們,就有機會被放到最近的『衝刺待辦清單』(Sprint Backlog)進行實作。每個『衝刺』(Sprint)中能排進『衝刺待辦清單』的『故事』,在『產品負責人』的心中必定是『最重要』、『最有價值』的『產品增量』(Product Increment)。如果這些『衝刺待辦清單』是『預期的』、『規劃內的』、『有討論過的』故事就不會被算為『插件』,反之不在『衝刺待辦清單』就是『插件』。

有比較清楚了吧?雖然概念簡單易懂,但是現實上,除非產品沒用人、還在開發階段還未上市的半成品、或者產品路線圖不會變動,不然總會碰到很多插件的案例。

插件有哪些呢?

比如說

  • 利益相關者(Stakeholder)發現市場的競爭對手提出一個新功能,為了減少之後的挑戰更大,要求產品負責人『插件』處理,算『插件』嗎?
  • 因應系統漏洞,需要緊急更新,算『插件』嗎?
  • 開發團隊發現一個線上的功能需要緊急修復,算『插件』嗎?
  • 客服收到客戶回報無法登入,算『插件』嗎?
  • 開發團隊,在進行『故事 A』時發現一個潛在的 bug,算『插件』嗎?
  • 算!都算,但重點不是算不算『插件』,而是要如何處理這些『插件』!

插件該處理嗎?

我個人認為簡單的原則是這插件『緊急』嗎?『重要』嗎?對『未來價值有影響』嗎?如果這三個條件有兩個符合,就可以請『產品負責人』與『開發團隊』協調是否需要在這個『衝刺』中處理。

  • 『緊急』且『重要』:這毫無疑問,因為很重要可能影響產品營運,所以要『越快修越好』。
  • 『緊急』且『未來價值有影響』:這部分可能不較容易理解,在商業的市場中,也些事情或許不是很重要,但處理好這件事可能會儘早獲得一些價值,比如說:B2B 或 B2B2C 的合作模式中,『信用』與『籌碼』就是靠修復一些『緊急』但不一定『重要』的工作來建立的。
  • 『重要』且『未來價值有影響』:這些事也許不『緊急』,所以相對上述兩種情況的『優先級』可以稍微低一點,但如果評估後需要『插件』也是可行的。

Scrum 中的插件如何處理?

在 KKTV 這個線上影音串流服務中,我認定的『插件』也是『非預期安排在衝刺待辦清單』中的『故事』或『任務』。哪一些事會被『插件』呢?

  • 客服回報,帳務處理上有錯誤,且無法透過後台人工處理。
  • 客服回報,播放上有錯誤,且無法透過其他方式回復正常功能。
  • 商業緊急需求,比如說:版權方要求緊急下架。

我習慣的處理方式有幾種

  • 設定緊急通道(Expedite Line)安排一位值日生處理,也就是 WIP 是『一個人』,這位值日生能同時處理多少事就依據他的能力有所不同。
  • 設定緊急通道(Expedite Line)但同時間只處理一件事,WIP 是『一件事』,我們在根據『事情的類型』找最合適的人員處理。
  • 『插件』的處理方式並不一定要找到『最佳方法』處理,而是以『最有效率的做法達到降低問題影響層級為目的』。如果能在『有限時間內』把『插件』處理好就值得處理,如果無法在『有限時間內』把『插件』處理好,那就需要先給『速解』爭取一些時間,再安排接下來衝刺中進行『釐清需求』(Spike)或『進行正解』。

我認為除非『產品』沒人用,不然每個『衝刺』中安排固定的人力處理一些『客服』或『商業緊急需求』是必要,且比較不會打亂開發節奏的一種方式。

另外需要反思的題目是『如果一直有很多插件,是不是先要讓系統穩定度優先處理呢?』,插件很多也是另一種值得注意的警訊!

但是,想一想這些『插件』在不是使用 Scrum 開發流程時就不會出現了嗎?

【文思不藏私】敏捷 30 天養成計劃~搶先看


上一篇
敏捷小班~估不估計是學問
下一篇
敏捷小班~哪些年我們一起追的半成品
系列文
敏捷 30 天養成計劃30

尚未有邦友留言

立即登入留言