簡介

過去的系統開發方法論就假設使用者很清楚需求，而且有足夠時間去收集需求，而且在開發的過程中或開發後需求都不會有重大的改變，然而，越來越多的情境是使用者不清楚需求、沒有足夠時間去收集需求或者需求經常會因為競爭對手或環境的改變而改變，敏捷式開發就是針對這樣的情境提出的解決方法。所以，敏捷式開發不是加速開發速度的開發方式，也不是生產力較高的開發方式，也不必然適合所有的情境。

甚麼是敏捷開發呢? 藉由幾個系統的開發經驗來說明一下敏捷開發與其他開發方式的不同。

輔仁大學前一代的選課系統是以telnet為主(不是透瀏覽器)，選課的方式，是以搶課(而不是分發)為主，系統剛開始時，原本的目標只是希望將系統改以瀏覽器選課，然而，我們發現利用瀏覽器搶課不只技術上困難，而且並沒有辦法真正解決選課的諸多問題。所以，我們決定將原本選課方式由搶課改為分發。當選課方式改變時，就必須考慮到很多的影響，也必須去了解所有問題的解決方案，所以，我們花了將近一年的時間去進行系統分析與設計，最後，利用將近半年時間進行開發，花了大概三個月進行測試。當時曾考慮過採用敏捷式開發，然而，選課規則動一髮牽全身，不太容易部分上線，不太適合採用敏捷開發。

第二個例子是生涯與就業協助系統(Career & Vocational Helping System, CVHS)的開發，這個系統算是以階段式開發，一開始主導的思峯老師對系統是有個完整的規劃，但是，因為並沒有足夠的資源，我們必須先開發部分的功能，讓這些功能運作，藉由這樣的方式去爭取更多的資源。雖然，在開發過程中，曾經重組過系統功能，但是，並不完全算是敏捷開發。然而，藉由初步的系統功能去爭取更多的資源，也是敏捷開發的特色之一。

第三個例子是大學選才與高中育才輔助系統(Collego!)的開發過程，雖然目標很明確，就是解決新課綱上路時的困擾，但是從一開始，團隊成員對於系統最後的樣貌有很不同的想像，所以，一開始我們其實是利用powerpoint(如果是現在，我們會使用figma)建構一個簡單的雛型去跟高中輔導老師溝通，再去跟大學端溝通。後來，我們發現powerpoint需要人去說明，就開發一個簡單的系統讓使用者直接體驗系統功能。透過這樣我們確認了系統的樣貌，然後，我們開始開發大學端的系統開發，由於沒有過去系統可供參考，我們先開發了一個資料輸入的版本，在邀請大學端系秘書使用之後，發現系秘書不只是想輸入還想看到呈現的樣子，所以，接下來開發了可預覽的版本，後來，又發現其實系秘書也想參考相關科系的資料，但由於我們並沒有任何資料，所以，我們先利用焦點群體法，選擇幾個科系，邀請同一科系多個學校的老師們來討論內容，再請高中端的輔導老師確認，透過這樣的方式讓系秘書們了解我們期待的內容是什麼樣子，然後，邀請幾個大學擔任種子學校，開始資料的輸入，同時間完成高中端的查詢功能 (就不需要預覽介面了)，在這期間，不斷的與大學端、高中端互動，不斷的從大學端、高中端回饋中調整系統功能。雖然開發過程中並未採用scrum或XP等方法論，但是，這樣的開發方式就比較像是敏捷的開發方式。

從這三個例子，大家應該可以感覺到開發的方式的不同，第一個例子(選課系統)是確認所有的需求之後才開始開發，開始開發之後，就凍結需求，所有功能開發完成之後才正式上線。第二個例子(CVHS)是開發部分功能之後就上線，持續開發其他功能。第三個例子(Collego!)是一邊開發一邊確認系統需求，透過已開發上線的功能去探索、確認需求，並規劃後續的功能。

瀑布式開發vs.敏捷

傳統的思維是系統要完成分析才進行設計，完成設計之後才進行開發，然而，就敏捷式開發而言，因為使用者可能也不清楚需求，就算清楚可能也會改變，那怎麼辦呢? 敏捷就是以先了解大略的需求，以user story的方式呈現。一般而言，過去常使用的use case是相當仔細而且描述使用者與系統的互動，所以，當需求很明確、清楚時，就很適合使用use case。而user story就不太一樣，一般而言，user story是由使用者寫，所以，是以使用者的角度與語言來寫，而且是簡單的敘述，如:「我是個店員，我希望能看到還沒有出貨的消費者訂單，而且訂單最好是依照下單的先後排序，這樣子我依照訂貨的先後順序出貨」。

敏捷的開發方式又有一些不同的做法(如:eXtreme Programming、Scrum、Kanban)，基本上精神是一致的，只是操作的方式與重視的實務有所不同。敏捷開發都以user story為需求的單位，也都會有Product Backlog來呈現，Product Backlog裡會有很多產品待辦事項 (Product Backlog Items, PBI)，每個PBI可以是一個功能性需求(如:use case或user story)、非功能性需求或bug。

以Scrum為例，在每個Sprint開始之前，會先決定這個Sprint要完成的項目 (Sprint Backlog Item, SBI)，每個項目大概花兩到三天的時間完成，如果太大，就將這個項目拆解為更小的項目。完成之後，所有完成的部分都是可交付的程式，而且都是隨時可一起上線(使用)的。而Kanban是不斷的循環，沒有Sprint的概念，每個user story完成之後，就繼續下一個user story。

敏捷式開發接受(或認為是理所當然的)不明確的需求，尤其是專案剛開始的時候，需求不明確是沒有關係的，所以，專案開始的時候，並不期待所有的PBI都是很明確的，通常是等到要排進開發時程時，才去深入探討與確定需求。

有時候的需求內容是相對的較大的，有些人會把較大的故事稱為史詩(Epic)，有些人將沒辦法排進一個Sprint的user story稱為Epic，所以，這樣的需求被排進Sprint時，就必須被拆解為更小的故事(Story)(詳參: Story Splitting Cheat Sheet)。

從敏捷式開發的觀點來看，需求有兩個面向，一個是從使用者觀點來看，由使用者描述希望系統能做些什麼以便達到什麼目的，另一個則是從開發者的角度，分析並統整使用者的需求。可以使用User story來簡單的陳述使用者的觀點(詳參: 使用者故事)，再以雛形介面或測試案例來做為需求規格 (詳參: 敏捷開發需要哪些文件?)。

Scrum

Scrum就簡單多了，最主要的概念在於將開發時程以Sprint為單位，跟傳統的做法不同的是，Scrum團隊的人數是固定的，每個Sprint的時間也是固定的(通常是兩週到四週)，小的專案就是由較少的Sprint完成，大的專案就是由較多的Sprint完成，每個Sprint一定要有具體完成的成果(可交付的程式)。因為敏捷式開發認為唯有透過具體完成的成果才能確認使用者的需求，並且透過每一個Sprint去開發新功能或回應需求的改變。(詳參: Scrum)

人員

Scrum強調開發團隊是個自我管理及跨功能的團隊，也就是團隊裡應該有人可以扮演使用者代表、系統分析師、系統設計師、程式設計師、測試人員的角色，而且每個人都應該有能力去支援其他人。團隊裡有兩個重要的角色:Scrum Master及Product Owner。Scrum Master是位對Scrum非常熟悉的人，而且專屬於這個團隊，可以帶領整個團隊利用Scrum完成專案，而Product Owner則是使用者代表，負責帶領大家開發正確的產品。

系統需求

就敏捷式開發而言，還是需要分析與設計，可是，敏捷式開發的情境是使用者可能也不知道需求，就算知道可能也會改變，那怎麼辦呢? 以Scrum為例，需求是以Product Backlog來呈現，Product Backlog裡會有很多產品待辦事項 (Product Backlog Items, PBI)，每個PBI可以是一個功能性需求 (如:use case或user story)、非功能性需求或bug。當需求相對清楚的時候，可以利用use case作為PBI，當需求相對較不清楚或確定時，可以採用user story。與傳統的作法不一樣的是，敏捷式開發接受(或認為是理所當然的)不明確的需求，尤其是專案剛開始的時候，需求不明確是沒有關係的，所以，這時候的需求內容是相對的較大較不清楚的，有些人會把很大的故事稱為史詩(Epic)，這樣的需求被排進Sprint(通常是2~4週)時，細節也必須被確定，或者被拆解為更小的故事(Story)(詳參: Story Splitting Cheat Sheet)。

在每個Sprint開始之前，會先決定這個Sprint要完成的項目 (Sprint Backlog Item)，每個項目大概花兩到三天的時間完成，完成之後，所有完成的部分都是可交付的程式，而且都是隨時可一起上線(使用)的。

eXtreme Programming

eXtreme Programming (XP) 提出了很多敏捷開發的實務 (詳參: The Rules of Extreme Programming、What We Have Learned  About Extreme Programming)，以下列出幾個常被提到的實務是:

• On site customer (詳參: The Customer is Always Available)

• User story (詳參: User stories)

• Iteration (詳參: Iterative Development)

• Stand up meeting (詳參: Daily Stand Up Meeting)

• Collective Code Ownership

  • Refactor (詳參: Refactor Mercilessly)

  • Pair programming (詳參: Pair Programming)

  • Move people around (詳參: Move People Around)

  • Continuous Integration (詳參: Integrate Often)

• Unit test first (詳參: Code the Unit Test First)

Kanban

Kanban三大原則:

• 視覺化 (Visualize)

  • 看板方法介紹（3）：Kanban方法的六個實務做法--Visualize與Limit WIP

• 限制Work In Progress (WIP)

  • 限制同時進行的工作項目數量

  • 看板方法介紹（3）：Kanban方法的六個實務做法--Visualize與Limit WIP

• 管理工作流程 (workflow)

後來又加上了三個概念﹐成為六個實務做法:

• Visualize

• Limit WIP

• Manage Flow

• Make Policies Explicit

  • 看板方法介紹（5）：Kanban方法的六個實務做法—Make Policies Explicit

• Implement Feedback Loops

  • 看板方法介紹（6）：Kanban方法的六個實務做法—Implement Feedback Loops

• Improve Collaboratively, Evolve Experimentally

  • 看板方法介紹（7）：Kanban方法的六個實務做法—Improve Collaboratively, Evolve Experimentally

參考資料

• Agile

  • Agile software development

  • Agile Manifesto

  • Agile by Mike Cohn

  • Gullo, Daniel James 莊弘祥 譯 (2017) Real World Agility: Practical Guidance for Agile Practitioners 碁峯出版

  • 實戰敏捷開發 Practices of an Agile Developer (1) 專業態度篇

  • 實戰敏捷開發 Practices of an Agile Developer (2) 需求篇

  • 實戰敏捷開發 Practices of an Agile Developer (3) 測試篇

  • 實戰敏捷開發 Practices of an Agile Developer (4) 程式篇

  • 實戰敏捷開發 Practices of an Agile Developer (5) 除錯篇

  • 實戰敏捷開發 Practices of an Agile Developer (6) 團隊開發篇

• Scrum

  • https://www.scrum.org/

    • The 2020 Scrum Guide

  • Scrum by Mike Cohn

  • Scrum懶人包

  • Scrum是甚麼?

  • Scrum (software development)