敏捷知識庫

科層一定僵化、敏捷就代表自由嗎？整理陳致瑋在行動影響力論壇的分享，談標準化、授權、決策與敏捷團隊如何在同一家公司共存。

AI 寫程式變快了，團隊卻更忙？整理 JUGG 談 AI 時代的敏捷專案管理，從需求探索、文件同步到驗收與注意力負荷，附直播回放重點導覽

AI 已經會寫程式，工程師接下來該學什麼？五倍學院院長高見龍從三十年的開發經驗出發，談 junior 與 senior 的新處境、AI 對學習的影響，以及規格、測試、權限與技術社群為何更值得投入。

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

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

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