
3355 模式是 Scrum 敏捷開發核心策略,透過反覆的「查看與調整」,讓強迫團隊在短週期內全速衝刺,完成迭代開發,打造預期的產品,讓團隊在變化莫測的市場中立於不敗之地。
Scrum 的三本柱
Scrum方法論建立在三大支柱之上,透明(Transparency)、檢查(Inspection)和適應(Adaption),這三項原則是Scrum實施過程中不可或缺的要素,它們共同支持著團隊達到更高的工作效能和反應速度。
透明(Transparency)
透明性要求所有的Scrum過程和工作進度對所有團隊成員公開。這確保每個人都能夠看到全面的項目狀態,包括進展、挑戰和即將到來的需求變更。透明化的工作環境有助於建立信任,並使得負責任的決策成為可能。
檢查(Inspection)
Scrum鼓勵團隊定期檢查項目進展和工作成效,以確保活動正朝著衝刺目標前進。這種持續的檢查可以在發現偏差時迅速進行調整,避免問題的累積並及時解決。
適應(Adaption)
當通過透明化的檢查發現問題或偏差時,Scrum框架要求團隊必須能夠迅速適應,調整工作方向或方法。這種靈活性是Scrum的核心,使團隊能夠對外部變化作出快速反應,從而最大化項目成果和效率。
3355 是指角色、工件、價值觀與事件
Scrum 的精髓集中於 3355 模式,三個角色、三個工件、五個事件與五個價值觀,徹底貫穿整個流程,驅動團隊走向成功。
Scrum的三個角色
Scrum方法論包括三個基本角色:產品負責人(Product Owner)、Scrum Master和開發團隊。
產品負責人(Product Owner)
產品負責人就是產品的掌舵手,產品的生死成敗都在他手中!他們必須毫不妥協地掌控產品的發展方向,確保每一個需求都切中商業價值與市場定位。決策必須果斷,容不得任何猶豫或模糊不清,而且你他媽的一定要拿到「100 %的授權」,因為你不能告訴團隊「我不知道」。
Scrum Master
Scrum Master 是 Scrum 的「框架」守護者,他們的使命就是清除一切阻礙,為團隊鋪平前進的道路!無論是流程的卡點還是跨部門的扯後腿,都要果斷處理。
他們不只是旁觀者,而是敏捷精神的實踐者,隨時帶領團隊保持戰鬥狀態,可惜很多台灣老闆讓團隊成員擔任 Scrum Master 的角色,最終都變成了丑角。
團隊(Development Team)
團隊是由「多功能」的專業人員組成,包括開發、測試等等,他們可以協作完成所有交付項目,讓這個團隊負責的產品待辦清單(Product Backlog)轉化成高品質的增量開發模式。
團隊必須具備自我管理的能力或有潛在的自組識能力,能夠在不斷變化的需求中快速適應和回應,特別是團隊成員是需要被「挑選」出來的,而不是老闆隨意塞進來的。
Scrum的三個工件
Scrum 的工件是透明化與進度掌控的利器,讓團隊無時無刻清楚掌握現況,然後,我也不知道為什麼大家都叫「工件」,但我知道「工件」就是指在工作或製造過程中,被加工或處理的物件。
產品待辦清單(Product Backlog)
這是一份產品需求的動態清單,產品負責人必須不斷更新,以適應市場變化,產品待辦清單中列出了所有功能、改進和修正的任務,並按照優先級進行排序,這也是團隊的核心參考文件。
衝刺待辦清單(Sprint Backlog)
每個衝刺開始時,團隊會從產品待辦清單(Product Backlog)中挑選需要完成的優先項目,並將其分解成具體任務,形成衝刺待辦清單(Sprint Backlog),這是團隊在衝刺期間的任務,確保成員清楚目標與分工。
增量(Increment)
增量是指每次衝刺結束後完成的產品成果,必須符合既定的完成定義(Definition of Done),且每個增量都應該具有可交付價值,能夠直接應用或展示給客戶。
我們的規定,是每一次的 Sprint 完成的任務,是可以達到「上線」讓用戶使用並取得回饋的。
Scrum的五個價值觀
開放(Openness)
坦誠相對,挑戰與進展毫無隱瞞,例如,團隊成員 C 和 D 在技術方案上意見不合。C 在會議中坦誠說:「我認為方案 A 不適合,因為它在壓測中表現不佳,但我願意和 D 一起分析方案 B,找到折衷點。」
這種透明溝通方式有助於快速解決分歧,建立互信。
尊重(Respect)
認同並尊重每個人的專業能力與貢獻,促進協作,但這是台灣人最缺法的價值,那就是尊重別人。
像是在有一次衝刺回顧會議中,測試人員提出產品在使用某些邊界情況下會出現錯誤,建議增加測試案例和改進「完成的定義」(Definition of Done),團隊認真考慮並採納了建議,改善了測試流程。
勇氣(Courage)
敢於面對困難與挑戰,勇於承擔責任並調整策略,好比,團隊在衝刺目標中預計完成一個新功能,但在中途發現技術難題,無法如期完成該功能。
團隊在每日站會中討論困難,並且召開技術會議尋求解決方案,他們可能尋求專家幫助或調整方案(例如,先完成基礎功能,次要功能留到下一個衝刺),他們還可能向產品負責人(Product Owner)反饋,重新排列優先級,確保高價值功能仍能按時交付。
透過透明溝通和策略調整,團隊能在困難中持續前進,並維持衝刺的價值輸出,而不是從第一天騙到交付的哪一天才說是 PO 講不清楚。
專注(Focus)
目標明確,全力以赴,不受任何干擾,例如,有一個技術債清理目標是團隊發現 code 裡有許多史詩級的技術務(例如性能瓶頸、老舊框架),影響到新功能開發,因此,團隊設定目標,在一個衝刺內完成部分重構工作。
所以,所有開發人員都按照「完成的定義」(Definition of Done)進行重構,並進行回歸測試。
承諾(Commitment)
全心全意投入目標,致力於持續交付卓越成果,而 Scrum 中的「承諾」(Commitments)並不是指「答應這個任務就非完成不可」,而是指產品目標(Product Goal)、衝刺目標(Sprint Goal)以及定義完成(Definition of Done),這些承諾的目的是幫助團隊保持目標明確,對齊大家的工作方向。
不要被亂玩 Scrum 的人搞死了,說「你有承諾這個東西會做完」,你叫他那個人去問一下 Scrum 的組識成員。
Scrum的五個事件
衝刺規劃(Sprint Planning)
- 目的:確定即將開始的衝刺期間的工作內容和目標。
- 參與者:產品負責人(Product Owner)、開發團隊、Scrum Master。
- 主要輸出:衝刺目標(Sprint Goal)、要完成的產品待辦清單項目(PBI,Product Backlog Items)及工作計劃。
不負責任的白話文翻譯:這是衝刺的起點!大家坐下來,把目標講清楚、任務排好,衝刺目標(Sprint Goal)要訂明白,產品負責人、開發團隊、Scrum Master 全員到場,不容有誤!衝刺要幹什麼,誰幹什麼,全都安排妥當。PO 要講清楚要做什麼,團隊要講清楚怎麼做。
每日站會(Daily Scrum)
- 目的:讓團隊成員同步進展、調整計劃,並討論如何解決當前障礙。
- 參與者:團隊(Scrum Master 可觀察但不強制參與)。
- 時間:最多 15 分鐘。
- 內容:
- 昨天完成了什麼?
- 今天計劃做什麼?
- 有哪些障礙需要協助解決?
不負責任的白話文翻譯:每天 15 分鐘,同樣時間、同樣地點,這是團隊的同步會議,讓你每天都能緊跟計劃!
衝刺評審(Sprint Review)
- 目的:向利害關係人展示本衝刺完成的增量(Increment),收集反饋。
- 參與者:產品負責人、團隊、利害關係人。
- 輸出:產品增量的展示,並討論下一步的需求或變更。
不負責任的白話文翻譯:衝刺結束後,接下來就是展示成果的時刻,讓利害關係人看得見摸得著的產品增量來了。完成多少、效果如何?都要攤開來,接受反饋,不要假裝一切都完美。
衝刺回顧(Sprint Retrospective)
- 目的:檢視團隊在本衝刺中的合作和流程,找出改進機會。
- 參與者:Scrum 團隊(產品負責人、開發團隊、Scrum Master)。
- 內容:
- 可以採取哪些改進措施?
- 本衝刺中哪些做得好?
- 哪些可以改進?
不負責任的白話文翻譯:衝刺評審(Sprint Review)剛完,馬上進行回顧會,做得好的,給點掌聲,做得爛的,直接檢討!
問題找出來,方案想清楚,該怎麼改下次就怎麼改,別再重蹈覆轍。
衝刺(Sprint)
- 目的:這是 Scrum 的核心事件,持續 1 到 4 週,是完成產品增量的開發階段。
- 輸出:可用、符合「完成的定義」(Definition of Done)的產品增量。
不負責任的白話文翻譯:這就是整個 Sprint 週期的主戰場,在 1 到 4 週的時間裡,團隊就是要拼命開發符合「完成的定義」的產品增量。衝刺裡的每個任務、每個進展,全都圍繞 Sprint Goal 展開,衝刺完成時,成果要經得起驗收。
Scrum在台灣的應用
在台灣,許多公司已經將 Scrum 框架作為主要的開發方法論,但實施 Scrum 時,這些公司卻沒有辦法有效運用,甚至於把Scrum 掰成老闆喜歡的形狀。
這主要的問題,就是礙於自身的 Scrum 觀念不正確,Scrum 的高度透明性、靈活性和強調持續改進的文化,讓人員沒有辦法「藏」,PO 沒有辦法不直接面對團隊,導致於 Scrum 方法論常常被用來向上級長官交代、應付我們有在跑敏捷的說詞,這真在讓人覺得很可惜。