August 17, 2026敏捷轉型為什麼推不動?先判斷人們處於哪個變革階段 文章內文 從兩次轉型經驗,談業務問題、關鍵角色與 Rick Maurer 的變革循環 高層已經宣布轉型,團隊也接受了培訓,新的流程甚至已經上線,為什麼大家還是不願意改變? 問題可能不在方法,而在於推動者與組織成員根本不在同一個變革階段:高層已經準備全面推行,第一線成員卻還沒有看見改變的必要;轉型小組忙著設計流程,部門主管仍在懷疑這件事能否解決自己的問題。 這時候,繼續宣傳 Scrum、增加培訓或要求大家遵守流程,通常只會帶來更多抗拒。 我曾參與數位化轉型、流程改進與敏捷轉型。回頭看這些經驗,我逐漸形成一個判斷: 敏捷轉型不是導入一套框架,而是圍繞真實的業務問題,集結組織內可用的力量,並根據人們所處的不同變革階段採取行動。 因此,在討論如何推動變革之前,我們需要先回答兩個問題。 第一個問題:這次轉型要解決什麼業務問題? 我第一次深刻體會這件事,是在一家銷售型企業導入 Scrum 的時候。 這家公司的主要業務是辦公家具與影印機的銷售和租賃。產品使用與租賃週期很長,如果業務人員與客戶往來的頻率太低,很容易在下一次採購時失去客戶。公司因此決定發展辦公用品採購服務,希望透過更高頻的交易維持客戶關係。 當時,新的業務模式還沒有成形,客戶究竟需要什麼也不清楚。我們沒有先要求其他部門「配合 Scrum」,而是由開發團隊先建立兩週一次的交付節奏,持續與業務端核對需求,再根據回饋調整產品。…
July 13, 2026這幾年,軟體開發圈掀起了一股「規格即實例」的風潮。隨著 Spec by Example (SBE)、到最近火紅的 Vibe Coding,再加上生成式 AI 的強大產能,開發團隊比以往任何時候都更加興奮。我們常聽到這樣的對話:「太好了,AI 可以幫我寫範例!」、「我可以更快完成自動化!」、「Scenario 越多越安全!」。 然而,當這股熱潮席捲開發現場時,我觀察到一個令人擔憂的趨勢:大家幾乎把所有的精力都投注在「如何產出腳本」與「如何跑 CI/CD」,卻唯獨遺忘了最核心的那件事——實例化需求的核心不是為了「自動化」,而是為了達成「共同理解」。 迷思:開發人員的「單機自動化」秀 在許多敏捷團隊中,最常見的劇情是:開發人員在看完需求文件後,憑藉著卓越的理解力與 AI 的協助,迅速寫出一套美觀、格式正確的 Gherkin 場景,並引以為傲地展示 CI…
April 16, 2026本文作者:柯仁傑 (三叔公) 在實施 Scrum 的理想狀態下,Sprint Backlog 一旦在開發計畫會議(Sprint Planning)中確認,就像是一份神聖的契約:在 Iteration 中途不增加功能,也不隨意變更週期長短。 然而現實往往是殘酷的。業務急著說:「沒這功能客戶不簽約!」、產品經理焦慮地喊:「這不先做會流失市場!」甚至還有突發的嚴重線上 Bug(Hotfix)需要救援。面對這些「忽然插單」的要求,Scrum 團隊該如何處理才最合理?以下提供六個具體的應對策略與深層思考。 策略一:嚴格把關,別讓「黃牛需求」透支團隊 許多急件其實是源於溝通上的「通膨」。當 Sales 或 PM 聲稱「沒這功能就賣不出去」時,產品負責人(PO)必須發揮守門人的價值,仔細評估其商業價值與真實急迫性。 策略二:時間換空間,延後至下個…






