背景
2025 年 4 月。六個人，一個學期，目標：用 Unity 完成一款完整的 2D 平台遊戲。
這款遊戲叫 Bubblo。你扮演一隻泡泡生物，在像素風格的奇幻樂園中探索，拯救被關在籠子裡的村民，同時對抗各種針型敵人——蜜蜂、跳躍蜘蛛、還有一隻非常想把你戳破的獨角獸。核心機制是泡泡物理：在關卡中彈跳漂浮，用你的柔軟特性同時解決移動和戰鬥問題。
我是專案負責人。我的工作是把一堆模糊的想法轉化為真正可以交付的遊戲細節——然後讓另外五個人在三個月內朝同一個方向前進，而且沒有人中途放棄。
我從 Cmoney 帶來了什麼
在這之前幾個月，我剛結束在 Cmoney 的後端實習，九個月的真實敏捷流程：衝刺規劃、每日站立、Sprint Review、回顧。我參加了夠多這些會議，對它們的用途有個淺層的理解。
所以開始 Bubblo 時，我有一套框架。我們會跑兩週的 Sprint，有正式的任務看板，做 Retrospective。我知道這些詞彙。
但我還不完全理解的是：這些詞彙背後有一套隱含的假設——關於人們如何安排時間、「可用性」代表什麼，以及一個團隊最主要的義務是什麼。
在公司，每個人最主要的工作就是這個專案。Sprint 是容器。敏捷儀式有效，是因為它設計的前提是全職投入。
在學校，這對任何人都不成立。
為什麼儀式不管用
我們的團隊成員有實驗室工作、其他課程、課外活動、實習申請要處理。有人在 Sprint 中途趕一篇研究論文；有人有兼職工作。每個人都是一個完整的人，在 Bubblo 之外有完整的生活。
要跑一場完整的 Sprint 規劃，意味著請人們拿出他們根本沒有的兩個小時。開回顧會議感覺很表演，因為真正的阻礙只是大家很忙、而且對此感到愧疚。每日站立變成焦慮的來源，而不是同步機制。
僵硬的結構在製造摩擦，而不是消除摩擦。
設計一個真正合適的工作流程
所以我把它拆解精簡。
任務看板留下來——這是最有價值的東西。所有人都能非同步看到「目前有什麼任務、什麼在進行中、什麼被卡住了」。維護這個看板不需要任何儀式，成本幾乎是零。
我用非同步確認取代了排程站立：每次工作時段開始時發一條短訊息，沒有格式要求，只是「今天在做 X，如果 Y 沒解決可能會卡住」。低壓力，大家真的會看。
每週同步變成一場有單一議程的會議：現在誰被什麼卡住了，我能在接下來三十分鐘內幫你解決嗎？ 不是進度報告，不是狀態更新。只有阻礙。跑二十到三十分鐘，阻礙清完就結束。
背後的原則是：尊重每個人的第一義務不是這個專案，但讓人們在有時間的時候容易貢獻。精簡，但不鬆散。
沒有人想要的 OOP 重構（但我們還是做了）
大約六週後，我們遇到了問題。角色行為的程式碼已經有機生長成一團亂麻。多個人在碰同一塊，一個地方的改動會在另一個地方產生難以追蹤的 bug。
我們重構了。Sprint 進行中。學生時程上。
在任何遊戲程式碼開始之前，我已經在紙上把元件架構設計成圍繞 Observer、State Machine 和 Command 模式。重構是要在實作中真正落地這些模式：讓狀態轉換變得明確、讓事件系統成為跨元件溝通的唯一真相來源。
這是正確的決定。重構之後，新增一種敵人類型或玩家狀態變成了一個有邊界的操作。Sprint 最後三分之一明顯比前三分之二不混亂。
時機感覺不對，但繼續修補一個纏繞的 codebase 會更糟。有些技術債複利速度夠快，必須提早還清。
AI 工具的時代背景
整個專案我們用 ChatGPT。那時候還沒有 IDE 代理工具——沒有整合的程式碼生成，頂多就是補全。主要用法是：描述一個問題，拿到一個草稿，再把草稿改成能用的東西。
一年後回頭看，工具已經完全不一樣了。今天這樣的專案看起來會不同——迭代更快，樣板程式碼的時間更少，出現不同種類的錯誤。我好奇的是隨著工具改進，什麼事情會變得更難，而不只是更容易。可能是架構決策——那些沒有明確正確答案、需要團隊決定方向然後承擔後果的決策。
我真正學到的事
遊戲交付了。600+ commits，五個可玩關卡，完整音效，60fps WebGL。我們為此驕傲。
但我帶走的不是 Unity 知識，甚至不只是設計模式——而是對工作流程設計的校準感。
敏捷不是公式。它是建立在對特定情境的假設之上的一套原則。當情境改變了——學生團隊和公司是非常不同的情境——原則仍然適用，但儀式必須從頭重新設計。問題永遠是：這個儀式究竟想達成什麼，有沒有更輕量的方式達成它？
另一件事：在同儕團隊裡做專案管理，大部分是情緒工作。讓人不被卡住，不只是任務協調——還要確保沒有人覺得自己的貢獻不重要，或者「我說要做的」和「我實際做的」之間的落差會被追究。這種安全感讓人在有時間的時候能夠出現，而不是因為這個專案感覺像罪惡感的來源而刻意迴避。
進來之前我沒有完全理解這件事。現在我懂了。