敏捷知識庫

企業為什麼要推動敏捷？從打造團隊、擴大敏捷，到運用敏捷創新與保持工作樂趣，真正重要的不是做了多少敏捷實踐，而是能否更有效地創造價值。 敏捷是工具，不是策略 企業開始推動敏捷時，很容易先討論方法：要不要採用 Scrum？ Sprint 要跑一週還是兩週？每天是不是都要開站立會議？應該使用哪一套管理工具？ 這些問題都很實際，卻不該成為最先回答的問題。 《打造敏捷企業》第八章提醒，企業應該先確定想達成的策略目標，再判斷哪些地方適合使用敏捷。 敏捷可以協助組織加快學習、降低創新的風險，也能讓團隊更快回應顧客需求，但它無法取代企業對方向的選擇。 如果組織沒有清楚的目標，再快的迭代也可能只是更快地繞路。 如果團隊不知道想解決什麼問題，再完整的敏捷儀式，也可能只剩下一套固定行程。 因此，真正的起點不是「公司要怎麼導入敏捷」，而是： 我們希望透過敏捷，改善什麼？ 回頭看前幾篇「鈦編讀好書」介紹過的鈦坦實務，不論是用小規模實驗驗證顧客需求、以看板呈現 IT 部門的工作瓶頸，或重新調整產品開發團隊的責任分工，都不是為了證明某一套敏捷方法有效。…

敏捷轉型為什麼推不動？先判斷人們處於哪個變革階段 文章內文 從兩次轉型經驗，談業務問題、關鍵角色與 Rick Maurer 的變革循環 高層已經宣布轉型，團隊也接受了培訓，新的流程甚至已經上線，為什麼大家還是不願意改變？ 問題可能不在方法，而在於推動者與組織成員根本不在同一個變革階段：高層已經準備全面推行，第一線成員卻還沒有看見改變的必要；轉型小組忙著設計流程，部門主管仍在懷疑這件事能否解決自己的問題。 這時候，繼續宣傳 Scrum、增加培訓或要求大家遵守流程，通常只會帶來更多抗拒。 我曾參與數位化轉型、流程改進與敏捷轉型。回頭看這些經驗，我逐漸形成一個判斷： 敏捷轉型不是導入一套框架，而是圍繞真實的業務問題，集結組織內可用的力量，並根據人們所處的不同變革階段採取行動。 因此，在討論如何推動變革之前，我們需要先回答兩個問題。 第一個問題：這次轉型要解決什麼業務問題？ 我第一次深刻體會這件事，是在一家銷售型企業導入…

和碩 AI 落地怎麼做？從第一個視覺檢測站花近 300 天，到方法逐步複製至百餘個站點，本文整理團隊如何以敏捷方式選題、快速試錯、與工廠現場合作，並安排 AI 上線後的維運責任。閱讀完整案例，了解製造業如何把 AI 從模型展示帶進真實產線。

在軟體測試圈，UI 自動化（UI Automation）一直是大家又愛又恨的技術。傳統工具（Selenium, Cypress）太脆弱，前端改個 ID、網路稍微延遲，測試就崩潰。最近 AI Agent 框架和工具大紅，有些號稱能「自我修復」並解決所有 Timeout 問題，這真的代表 RD 與測試工程師從此能高枕無憂嗎？ 我認為，這背後隱藏著一個巨大的「信任危機」。 當 AI…

25 年前，幾位軟體開發大老寫下了敏捷宣言。我把背後的 12 條原則翻譯成「人生版」，分享給每一個想把日子過得更有方向感的人。

六角學院創辦人廖洧杰分享如何從 AI 焦慮走向實際協作，解析 AI Agent 如何改變軟體開發、程式教育與團隊溝通，以及未來工程師需要培養的關鍵能力。

本一科技營運長范硯平分享 AI 如何走進醫療現場，協助護理師將半小時至一小時的文書工作縮短至約五分鐘，並談導入過程中的信任、資訊安全與人機協作，讓醫護把更多時間留給病人與家屬。