iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
佛心分享-IT 人自學之術

你以為自己很敏捷,其實連瀑布都沒做好——30 天從錯誤承諾、大神救火,到沒有大神也跑得動的開發方法 系列

一開始,我只是想搞懂瀑布與敏捷到底差在哪。後來才發現,很多團隊不是選錯方法,而是兩邊都沒做到:既沒有瀑布的需求基準與變更管理,也沒有敏捷的優先排序與回饋節奏,只剩 Sprint、站會與看板的外觀,流程的洞全靠少數資深高手用經驗與記憶補起來。專案成功了,組織卻學到錯誤結論:「你看,那些文件和流程都不需要。」其實不是流程有效,是有人代替流程解決了問題——我叫它「血脈壓制」。這 30 天,我會從瀑布與敏捷真正的差異談起,拆解大神如何撐起一套壞流程,再用一個去識別化的小型系統整合案例,看假敏捷如何一步步翻車,最後把同一個專案重新做一次。目標只有一個:大神請假,專案也跑得動。

參賽天數 27 天 | 共 27 篇文章 | 3 人訂閱 訂閱系列文 RSS系列文
DAY 21

Day 21|問題不是我們太敏捷,而是連基本工程責任都丟掉了

翻車清單上,沒有一條的兇手叫敏捷;每一條的兇手,都是一項沒人扛的工程責任。 下架之後的安靜 昨天的檢討會散場前,白板角落留著一個沒人敢接的問題:所以答案是...

2026-08-27 ‧ 由 notwisebenson 分享
DAY 22

Day 22|不要 Coding:先找出誰真的能決定需求

重來的第一步不是打開編輯器,是打開名單:這個需求的每一條規則,到底誰說了算? 重新開工的第一天 昨天說好了:同一個專案、同一批人、資深工程師依然被借調不在...

2026-08-28 ‧ 由 notwisebenson 分享
DAY 23

Day 23|先決定這一輪真正要解決什麼問題

「做退款功能」人人都點頭,因為它什麼都沒排除;一句真正的目標句,說出口的那一刻,就該有一半的想像出局。 兩場各半小時的對話 昨天花了兩天,第一次把「誰說了...

2026-08-29 ‧ 由 notwisebenson 分享
DAY 24

Day 24|MVP 不是做爛一點,是先縮小問題

「最小可行」四個字,很多團隊只讀了「最小」;MVP 縮的是問題的範圍,不是做工的品質。 越寫越長的「不做」清單 昨天散會前,目標句拍板了,Non-goal...

2026-08-30 ‧ 由 notwisebenson 分享
DAY 25

Day 25|User Story 不是魔法,真正重要的是 Conversation

同一張 Story 卡,有對話,是需求的起點;沒有對話,只是把一句話需求換上格式正確的衣服。 一張格式標準的卡片 昨天 MVP 邊界定案:信用卡、單筆、全...

2026-08-31 ‧ 由 notwisebenson 分享
DAY 26

Day 26|Acceptance Criteria:不要靠大神通靈完成條件

同一份完成條件,存在大神腦裡叫通靈,寫在牆上叫 AC;內容可能一模一樣,讀取權限差了一整個團隊。 第一版草稿,五分鐘就寫完了 昨天那場對話散會前,白板上留...

2026-09-01 ‧ 由 notwisebenson 分享
DAY 27

Day 27|Vertical Slice:不要再 Backend 做完等 Frontend

三條各自完成的水平線,疊不出一套能用的系統;一條從畫面通到金流、再回到畫面的細路,才是第一個可以驗收的進度。 又是三張 Ticket 昨天把「怎樣算完成」...

2026-09-02 ‧ 由 notwisebenson 分享