2026/01/24 (更新)
2026/03/04 (更新第二週課程內容)
2026/03/05 (更新第二週課程內容)
2026/03/17 (調整第五、六週進度)
2026/04/15 (調整第八週進度)
2026/05/01 (調整第十一、十二週進度)
2026/05/05 (調整第十一週進行方式)

• AI-Driven Development - 個人開發者的敏捷實踐 

  • Day 9 - Spec-Driven Development：讓 AI 真正理解你想要什麼 

• AI 時代的軟體開發工作流：從需求（PRD）到...

  • Ep.0 邊爬邊聊｜用 #Cursor 寫更精準的 #需求 ｜ #PM 的 #AI 協作前言篇 (13:21)

  • Ep.1｜還在手寫需求文件？ChatGPT 不夠精準？試試 #Cursor 跟 #AI 對談需求更精準 (17:47)

    • Spec-Driven Coding

      • 傳統工具的限制：為什麼改用 Markdown

      • Cursor簡介

      • 如何在一個既有的系統中寫需求文件

      • 列出痛點

      • 利用Ask模式跟Cursor對談需求，根據目前的PRD及痛點修改PRD，請cursor提問並回答問題

  • Ep.2｜用 Spec Template 寫出結構化 PRD！用 Cursor 寫出需求、用戶故事與驗收條件 (18:19)

    • Spec-Driven Coding

      • 利用Agent模式，並根據spec template寫需求文件 (一次一個user story)

      • spec template的介紹

  • Ep.3｜Cursor 進階應用：幫你畫 Prototype、建立 Jira 卡片！ (14:24)

    • Spec-Driven Coding

      • 產生雛型

      • 利用Jira MCP產生issue

  • Ep.4｜別再 Vibe Coding！試試用 Github spec-kit 開發正式產品吧！需求篇 (17:55)

  • Ep.5｜從規格到執行！用 spec-kit 完成技術設計、任務拆解與 AI 實作｜開發篇 (15:08)

  • Claude Cowork 太神了！不只會說還會做：高鐵報帳 PDF 小工具被取代＋搭配自寫 System Prompt 更精準 (16:25)

  • Vibe Coding 很快很爽，但成果不如預期：PM 該用 AI 把需求講清楚 (3:46)

課程介紹

• 在Gen AI的時代，敏捷已成為必然，傳統的敏捷與Gen AI時代的敏捷要解決的問題不太一樣

  • 在Gen AI時代，開發速度越來越快，也讓使用者對開發速度及更新速度的期待越來越高，敏捷的需求也就越來越高，但是，Gen AI也帶來了不同的開發方法，主要瓶頸不再只是開發者之間的溝通，而且是開發者與使用者及Gen AI的溝通。

• 了解敏捷開發的精神與實務

  • 以實作的方式體驗敏捷開發，將利用生成式人工智慧開發系統

    • AI增強開發工具 (吳老師的Notion教材)

      • GitHub Copilot設定

    • Scrum

• 小組學期專題實作

  • 請大家利用Tronclass許願

  • 113學年度的成果

    • 利用Next.js (React)開發，資料庫利用Firestore，部署到GitHub Pages

  • 111學年度的專案成果

    • 利用React開發，資料庫利用Firestore，部署到Vercel

    • 身為資管系的學生，我們需要什麼?

    • 如果每年都留下一點成果，各位會想留下甚麼?

  • 近幾年大學部專題成果

    • Deeplink

成績

• 小組學期專題實作 (80%)

  • 老師給全組分數，個人分數根據組內互評計算

• 個人 (20%)

  • 期末課程回饋與建議 (5%)

    • 印象最深刻的課程內容或活動 (2%)

    • 課程建議 (3%)

  • 課堂參與 (10%)

    • 期末全班互評

  • 閱讀心得 (自主學習週作業) (5%)

    • (待確定)選擇本課程相關之特定領域相關論文一篇，並且生成式AI幫忙摘要 (1%)

      • 論文的發現與實務(或課程中的)經驗的異同 (3%)

      • 對未來相關研究的啟發 (1%)

        • 如果要進行相關研究，我打算...

• Agile

• Scrum簡介

  • The Scrum Guide 

    • Team 

      • 組內角色分配 (PO、SM、開發人員)

        • 開發人員

          • PoC 快速實驗組

          • 後端與架構組

          • 前端與體驗組

          • 評估與數據組

    • Events 

    • Artifacts

• 從Scrum看時間管理與團隊整合 (deeplink分享)

• Sprint開始之前，我們的角色分配?

  • 需求評估組

    • 在系統分析與設計課程中使用Gemini

  • 開發工具評估組

    • GitHub Copilot

  • 開發技術評估組

    • Next.js (React框架) + Firebase firestore

  • Scrum/敏捷技術評估組

• 同學自我介紹

  • 覺得自己比較適合哪個角色

• 學期專題

  • 我們看看許願池裡的願望

    • 利用Gemini或ChatGPT進行評估

    • 怎麼評估? 競品分析? 利害關係人分析?

• AI增強開發工具 (吳老師的Notion教材)

  • GitHub Copilot設定

  • Github Copilot 基本使用

• User Story

  • Story name

  • As a (角色, who)

  • I want (需求, what)

  • so that (價值, why)

• 學期專案

  • 需求評估組

    • 我們來利用Gemini或ChatGPT練習寫User Story吧~

    • 在系統分析與設計課程中使用Gemini

  • 開發工具評估組

    • Github Copilot 基本使用

    • GitHub Copilot Agent Mode

  • 開發技術評估組

    • Next.js (React框架) + Firebase firestore

      • 前端框架 Next.js，CSS或搭配

        • Tailwind

        • Material-UI

      • 雲端資料庫

        • Firebase firestore (No SQL)

        • Supabase (關聯式資料庫)

      • 部署

        • vercel

        • github pages

        • firebase

  • Scrum/敏捷技術評估組

    • 利用GitHub Project管理User Story

  • 所有同學

    • 請先安裝VS Code、Git、Node.js

      • Git (持續性整合)

• User Story 

  • Acceptance Criteria

    • Specification by Example 

    • Behavior Driven Development

    • Test Driven Development

• 學期專案

  • 我們來利用Gemini或ChatGPT練習寫驗收條件吧~

    • 一般而言，是在Sprint Planning才會寫驗收條件，所以，等第七週才會正式寫驗收條件，我們先選5個user story練習一下就好

    • 在系統分析與設計課程中使用Gemini

• 持續準備工作

  • 安裝VS Code、Git、Node.js是否有問題?

    • Git (持續性整合)

  • 各組討論設計決策

    • AI增強開發工具

      • Next.js + Firebase firestore (No SQL) + vercel

    • 雲端資料庫

      • Firebase firestore (No SQL)

      • Supabase (關聯式資料庫)

    • 部署

      • vercel

      • github pages

      • firebase

• AI增強開發工具

  • 體驗GitHub Copilot

• AI增強開發工具

  • 體驗Git+GitHub Copilot

• Git

  • git新手入門教學  (deeplink分享)

  • Github介紹 (王曉瑜學姊提供) 

  • Git (Web程式設計教材)

• Scrum / Scrum Guide

  • 確定Product Goal及Definition of Done (DoD)

    • 一個User Story完成的標準

      • 通過單元測試? 通過E2E測試? 符合程式碼規範? 成功部署?

  • Sprint Planning 1

    • WHY:根據Product Goal，討論並確認Sprint Goal (PO)

    • WHAT:根據Sprint Goal產生Sprint backlog (PO)

      • 如何設定MVP?

    • HOW:討論這些工作項目如何完成 (SM) 及完成的標準

      • 驗收條件 (測試的標準)

        • Given (條件)

        • When (動作)

        • Then (應有的反應或結果)

• 利用Github project進行專案管理

  • 利用GitHub Project追蹤進度

    • 設定Sprint的起始、結束日期

    • 設定Sprint的User story (issue)

    • 完成驗收條件後設定狀態為Ready

    • 開始開發設定狀態為In progress

    • 開發後設定狀態為In review

    • Sprint review後設定狀態為Closed或回到In progress

• DevOps

  • CI: git+github

  • CD: 部署到Vercel

• 測試

  • 軟體品質 (系統分析與設計課程教材)

  • 驗收條件與測試

    • 測試 (進階web程式設計)

    • Copilot利用驗收條件撰寫自動化測試腳本，並進行自動化測試

      • GitHub Copilot Agent Mode

      • 測試

        • 單元測試

        • End-to-end測試

      • GitHub Copilot Skills

        • 以測試為例提供skill範例

  • 軟體品質 (吳濟聰老師 deeplink分享)

    • Coding Standard

      • 請參考Sprint 1實作裡的CONVENTIONS.md

    • Code Review

    • Code Refactoring

• 學期專題

  • Daily Scrum

    • 利用15分鐘進行Daily Scrum

      • 重點不在於進度報告，而是解決進度上的問題

        • 需求上的疑惑

        • 討論如何解決，而不是指責

      • 請記錄遇到甚麼問題以及解決方案

      • 是否需要進行優先順序、工作分配等調整?

    • 請持續整理所有的會議紀錄 (Sprint Planning、Daily Scrum)

  • 除了利用Copilot寫程式，也利用Copilot確保品質

• 學期專題

  • Daily Scrum

    • 利用github project看一下進度

• Code Refactoring

  • 為何敏捷強調Code refactoring?

  • 為何用Gen AI還需要Code refactoring?

  • 如何利用Gen AI進行Code refactoring?

    • 程式碼重整

• Scrum

  • Sprint Review 1

  • Sprint Retrospective 1

  • Sprint 2工作分配、交接

  • Sprint Planning 2

• 利用Github project進行專案管理

• 學期專題

  • Daily Scrum

• Test

• 由兩組互相進行獨立驗收

  • 由攻擊組填寫獨立驗收 (IV&V) 三輪戰報表

  • 防禦組提供Product Goal、Sprint 1的Sprint Goal (10分鐘)

  • 攻擊組根據生成式AI的建議，以及小組的想法，提出5個驗收條件 (10分鐘)

    • 產生驗收條件並提供給防禦組

    • 【攻擊手專用：雙層次規格生成 Prompt】

「這是一個正在開發中的系統專案，目前剛剛結束 Sprint 1 的開發。

我們的 Product Goal (最終產品願景) 是：【填入防禦組的產品願景】

我們本階段的 Sprint 1 Goal (當前衝刺目標) 是：【填入防禦組的 Sprint 1 目標】

請你扮演一位極度嚴格的系統分析師 (SA)。請在**『絕對不超出 Sprint 1 Goal 開發範圍』的前提下，為了確保系統未來能順利往 Product Goal 邁進，列出 5 條這個系統目前『必須具備、且最容易被忽略的底層邏輯』**的 Acceptance Criteria (AC)。請以 BDD (Given-When-Then) 格式輸出。請專攻異常流程 (Unhappy Path) 與資料狀態的防呆。」

• • 第一輪驗收

    • 防禦組有20分鐘準備第一輪驗收

    • 攻擊組有20分鐘進行第一輪驗收

      • 每組派幾位同學扮演攻擊手，根據剛剛給的五個驗收條件進行驗收，也可以進行臨時驗收，並記錄驗收結果

      • 其他同學擔任防禦員，接受驗收，並記錄驗收結果 (做為改進依據，不必繳交)

  • 第二輪驗收

    • 防禦組有15分鐘準備第二輪驗收

      • 針對前一輪驗收進行緊急修補

    • 攻擊組有15分鐘進行第二輪驗收

      • 每組派幾位同學扮演攻擊手，根據未通過的驗收進行補強驗收，也可以進行臨時驗收，如果第一輪完美通過驗收，請新增臨時驗收，並記錄驗收結果

      • 其他同學擔任防禦員，接受驗收，並記錄驗收結果 (做為改進依據，不必繳交)

  • 第三輪驗收 (重點在於針對Sprint 2的sprint goal，然而Sprint 2剛開始，所以，重點在於Sprint 2的準備)

    • 防禦組有15分鐘準備第三輪驗收

    • 攻擊組有15分鐘進行第三輪驗收

• 學期專題

  • Daily Scrum

• DevOps

  • 除了CI/CD之外，到底DevOps還有甚麼?

• Scrum

  • Sprint Review 2

  • Sprint Retrospective 2

  • Sprint Planning 3

• Code Refactoring

  • 為何敏捷強調Code refactoring?

  • 為何用Gen AI還需要Code refactoring?

  • 如何利用Gen AI進行Code refactoring?

    • 程式碼重整

• 學期專題

  • Daily Scrum

• Test Driven Development

  • 自動化測試 (吳濟聰老師Next開發筆記)

    • 測試 (吳濟聰老師進階web程式設計課程教材)

    • 自動化測試 (deeplink分享)

• 學期專題

  • Daily Scrum

• Test Driven Development

  • 自動化測試 (吳濟聰老師Next開發筆記)

    • 測試 (吳濟聰老師進階web程式設計課程教材)

    • 自動化測試 (deeplink分享)

• Scrum

  • Sprint Review 3

  • Sprint Retrospective 3

• 彈性多元學習週

  • 自主閱讀心得 (自主學習週作業) (15%)

    • 期刊或學位論文一篇 (6%)

    • 書籍一本 (9%)

• 彈性多元學習週

  • 自主閱讀心得 (自主學習週作業) (15%)

    • 期刊或學位論文一篇 (6%)

    • 書籍一本 (9%)

期刊/研討會論文 (大部分文章可以透過scholar.google.com找到，IEEE software比較新的論文可透過圖書館下載)

• 敏捷

  • Sutherland, J. (2001). Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies, IT Journal, 14(12), 5-11

    • Scrum of scrums (IDX Systems) 

  • Fairbanks, G. (2022). Two Kinds of Iteration, IEEE Software, 39(1), 114 - 117

    • design-focused iteration, code-focused iteration

• 需求

  • Gregory, S. (2022). What Does the Future Hold for Requirements Engineers?, IEEE Software, 39(4), 18-21

  • Kassab, M., Laplante, P. (2022). The Current and Evolving Landscape of Requirements Engineering in Practice, IEEE Software, 39(5), 76-83

• 測試

  • Ebert, C., Bajaj, D., Weyrich, M. (2022). Testing Software Systems, IEEE Software, 39(4), 8-17

• CI / CD / DevOps

  • Roche, J. (2013). Adopting DevOps practices in quality assurance. Communications of the ACM, 56(11), 38-43.

  • Wahaballa, A., Wahballa, O., Abdellatief, M., Xiong, H., & Qin, Z. (2015, September). Toward unified DevOps model. 2015 6th IEEE international conference on software engineering and service science (ICSESS) (pp.211-214).

  • Jabbari, R., bin Ali, N., Petersen, K., & Tanveer, B. (2016, May). What is DevOps? A systematic mapping study on definitions and practices. Proceedings of the Scientific Workshop Proceedings of XP2016 (pp. 1-11).

  • Callanan, M., & Spillane, A. (2016). DevOps: making it easy to do the right thing. IEEE Software, 33(3), 53-59.

  • Ebert, C., Gallardo, G., Hernantes, J., & Serrano, N. (2016). DevOps. IEEE Software, 33(3), 94-100.

  • Dörnenburg, E. (2018). The path to devops. IEEE Software, 35(5), 71-75.

  • Gokarna, M., & Singh, R. (2021, February). DevOps: a historical review and future works. 2021 International Conference on Computing, Communication, and Intelligent Systems (ICCCIS) (pp. 366-371)

  • Beetz, F. Harrer, S. (2022). GitOps: The Evolution of DevOps?, IEEE Software, 39(4), 70-75

  • Khan, M. S., Khan, A. W., Khan, F., Khan, M. A., & Whangbo, T. K. (2022). Critical Challenges to Adopt DevOps Culture in Software Organizations: A Systematic Review. IEEE Access, 10, 14339-14349.

• 軟體開發

  • Ebert, C., Montenbruck, J. M. (2022). Industry Survey: The Magic Triangle of the New Normal, IEEE Software, 39(3), 12-20

    • quality, cost, time -> need for innovation,  lack of competences, cost complexity trap

• 工具

  • Ebert, C., Avasthi, P. (2022). Technologies for Agile Teams, IEEE Software, 39(5), 21-27

學位論文

• 敏捷

  • 蔡慧蘭 (2014) 敏捷軟體開發方法於台灣資訊服務業之研究 輔仁大學資訊管理研究所碩士在職專班論文 **推薦**

  • 林于桔(2019) 應用敏捷開發法進行軟體專案管理之行動研究：以某組織委外開發 A 專案為例 輔仁大學資訊管理研究所碩士在職專班論文 **推薦**

• 測試

  • 廖家盛 (2015) 軟體測試應用現況之探討 輔仁大學資訊管理研究所碩士論文

• CI / CD / DevOps

  • 陳胤宏 (2014) 資訊系統持續整合應用之個案研究 輔仁大學資訊管理研究所碩士論文

  • 陳易昇 (2017) 資訊系統持續整合之障礙：組織與技術觀點 輔仁大學資訊管理研究所碩士論文 

    • 可透過輔仁大學博碩士論文檢索系統取得電子檔

  • 齊唯哲 (2023) DevOps運作現況之個案研究 輔仁大學資訊管理研究所碩士論文

書籍

• 敏捷

  • Martin, Robert C. (2020) Clean Agile : Back to Basics (Paperback) (無瑕的程式碼 敏捷篇：還原敏捷真實的面貌 盧國鳳、陳錦輝譯 博碩文化)

    • 【還少一本書】Clean Agile (搞笑談軟工/Teddy Chen)

    • 讀 Clean Agile ，思考敏捷的本質

  • 新加坡商鈦坦科技(2021) 鯨游藍海：鈦坦科技的敏捷之路 翻滾海貍工作室 **推薦**

• Scrum

  • Sutherland (2014) SCRUM: The Art of Doing Twice the Work in Half the Time (SCRUM：用一半的時間做兩倍的事)  **推薦**

    • Jeff Sutherland是Scrum之父

• Kanban

  • Hammarberg & Sundén (2014) Kanban in Action (看板實戰：用一張便利貼訓練出100分高效率工作團隊)

  • 李智樺 (2015) 精實開發與看板方法 (已絕版，請到圖書館借閱)

• 範疇、需求

  • Mike Cohn (2004), User Stories Applied: For Agile Software Development (Mike Cohn的使用者故事：敏捷軟體開發應用之道 使用者故事志工群 譯)

  • Jeff Patton (2014), User Story Mapping (使用者故事對照 楊仁和 譯)

  • Gojko Adzic (2011) Specification by Example-How successful teams deliver the right software? (Specification by Example 中文版：團隊如何交付正確的軟體)

  • Smart, John Ferguson,Molak, Jan (2023) BDD in Action, Second Edition

• 測試

  • Kent Beck 的測試驅動開發：案例導向的逐步解決之道 (Test-Driven Development: By Example)(TDD) 

• CI / CD / DevOps

  • Humble & Farley (2010), Continuous Delivery: Reliable software releases through build, test, and deployment automation (Continuous Delivery中文版：利用自動化的建置、測試與部署完美創造出可信賴的軟體發佈)

  • Kim, Behr, Spafford (2017), The Phoenix Project (鳳凰專案：看IT部門如何讓公司從谷底翻身的傳奇故事)  **推薦**

  • Kim (2019). The Unicorn Project (獨角獸專案：看IT部門如何引領百年企業振衰起敝，重返榮耀)  **推薦**

• DDD

  • Eric Evans(2003) Domain-Driven Design: Tackling Complexity in the Heart of Software (領域驅動設計：軟體核心複雜度的解決方法)

• 重構

  • Martin Fowler (2019), Refactoring, 2nd ed. (重構（第二版）：改善既有程式的設計 賴屹民 譯)

    • 第一版以java為範例，第二版改以Javascript為範例

網頁

• 敏捷

  • Ruddy Lee分享空間

• Scrum

  • The 2020 Scrum Guide (2020) / 2020 Scrum 指南  **

• Domain Driven Design

  • 為什麼需要 Domain-Driven Design

  • 搞笑談軟工 (Teddy)

    • [還少一本書] Domain-Driven Design

    • 領域驅動設計學習筆記（1）：學習的切入角度（上）

    • 領域驅動設計學習筆記（2）：學習的切入角度（下）

    • 領域驅動設計學習筆記（3）：實驗計畫

    • 領域驅動設計學習筆記（4）：Bounded Context

    • BDD（9）：DDD乍現

    • 從領域驅動設計看Tennis Kata（上）

  • 領域驅動設計 (Domain-Driven Design) 簡介 (1) - 貧血的領域模型

  • Domain-Driven Design: When is a Bounded Context no longer a Bounded Context?

• 專案管理

  • “Your app will be finished on Tuesday.” — which Tuesday?! 10 reasons why Software Development projects fail

• • 1. Poorly defined (or, god willing, undefined!) outcome

    2. Solving the wrong problem.

    3. Not enough communication.

    4. No plan or timeline.

    5. Lack of accountability.

    6. Moving the goalposts too often.

    7. Inadequate documentation and tracking.

    8. Badly defined system requirements.

    9. Poor preparation.

    10. Unrealistic expectations.

• 資訊安全

  • 5 most important vulnerabilities every developer should be aware of

    • SQL Injection

    • Broken Authentication

    • XSS (Cross-Side-Scripting)

    • Using Web components with known vulnerabilities

    • Sensitive Data Exposue