什麼是敏捷產品開發?

敏捷軟體開發宣言：敏捷軟體開發的發展史  

雖然我們不知道敏捷開發原則的確切起源，但可以確定這個詞完全成形的時間點。敏捷軟體開發宣言於 2001 年發佈，17 位軟體開發人員齊聚一堂，討論輕量開發思維模式的潛力與相關策略。從起源來看，可以得知這是一種單純用於軟體開發的方法。這份宣言可細分為 12 項核心原則與 4 大價值觀，目標都是提高協同合作程度與透明度，以及加快交付產品。

敏捷軟體開發宣言發佈後，敏捷開發迅速成為軟體領域的慣用方法，許多人認為是絕佳的通用開發方式。敏捷開發的設計思維模式確實能提高生產力、縮短產品交付時間，並加強團隊之間的溝通 (尤其是在工作團隊分散各地的情況下)。

雖然軟體開發領域受惠於這些優點，但在硬體領域，仍有許多人懷疑敏捷開發是否適用。敏捷開發方法會將工作拆分為多段「衝刺」，也就是預先設定期限的工作項目，通常在進行幾週後，最終會產出可交付的產品。這種方式在開發軟體時可行，但似乎無法套用到硬體開發；這是因為每段「衝刺」只有幾週時間，而且最後的預期成果必須是可用的產品。

但如果仔細檢視敏捷開發的價值觀和原則，會發現只要稍加修改，就能採用敏捷方法來開發硬體產品。接著我們就來仔細探究這些價值觀和原則，進一步了解敏捷開發的思考邏輯。

敏捷軟體開發宣言的 4 大價值觀

• 個人與互動重於流程與工具
• 可用的產品重於詳盡的文件
• 與客戶合作重於合約協商
• 回應變化重於遵循計劃

敏捷產品開發的 12 項核心原則

先前曾提到敏捷開發的 12 項原則是著眼於軟體開發，不過這些原則的精神多半也適用於開發硬體，只是可能需要稍加修改，以符合建立實體產品 (而非數位產品) 的流程。我們將在下文詳細說明。

1.及早並持續滿足客戶需求

「我們最優先的任務，是透過及早並持續地交付有價值的軟體來滿足客戶需求。」

在敏捷開發中，溝通是首要之務。客戶應該及早並持續地參與產品開發流程，才能根據自己的願望和期待提供真實的意見回饋。如此一來，就能降低偏離客戶需求的風險，團隊也能在必要時，更快向客戶告知相關的挑戰或阻礙。

2.變更是好事

「竭誠歡迎改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，以維護客戶的競爭優勢。」

敏捷開發無論何時都接受需求變更。在傳統瀑布式開發流程中，後期變更會產生嚴重的影響；如果採用敏捷開發，即使需要在後期開發階段進行變更，也應該全心接受，因為這能反映現實的需求，畢竟市場、競爭勢態及客戶需求本來就會一直變動和演進。隨著專案的推進，也應適時在最終設計中納入新資訊。

3.快速交付可用的產品

「經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。」

敏捷開發的重點是簡化產品開發。這份宣言中列出一項目標，也就是每隔幾個月就要交付一次產品。在硬體設計的領域，尤其是對複雜的大型產品來說，或許不可能設定這麼短的期限，但開發人員還是必須為專案訂立明確的目標和特定檢查點，以收集意見回饋並滿足需求。

4.鼓勵每天協同合作

「業務人員與開發者必須在專案全程中天天一起工作。」

採用敏捷開發方法時，沒有人應該在孤立的狀態下工作。相關負責人與開發人員應該經常溝通，以確保專案擁有所需的資源，並按照進度進行。常見的做法是舉行每日立會，並妥善運用 Slack 頻道這類協同合作工具，以及其他即時雲端解決方案。

5.營造積極正向的工作環境

「以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工作。」

敏捷開發的一項要素是賦能；個人與團隊都應該感到自己對專案的成功有所貢獻，並獲得所需的支援，而能專注於工作中。這項原則不會將失敗或錯誤看得太重，而是認為團隊應該有能力承受經過計算的風險、嘗試不同的事物，然後討論特定做法能否帶來成果。如果希望分階段改善產品，那就必須在推動每項專案的過程中互相學習。

6.面對面溝通效果最佳

「面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。」

根據這份宣言，沒有任何方式能取代直接溝通。在 2001 年，對一般人而言，視訊通話還是一項未來趨勢而非現實，如今則已經非常普及。對分散各地的團隊或個人而言，如果想要降低不確定性、強化團隊協同合作，沒有一種方式能取代直接面對面互動。

7.應根據可用的產品來量測進度

「可用的軟體是最主要的進度量測方法。」

這項原則也可以套用到實體產品開發中，所謂「可用的產品」是相對而言。要開發出符合所有規範的新醫療設備可能需要兩年時間，但若採用敏捷開發方法，就可以將這樣的大型專案拆分為更多管理單元和目標，並在過程中定期收集意見回饋。這種做法與其說是為了打造可用的產品，更像設定多個期限，以達成推出可用實體產品的終極目標。

8.敏捷開發必須能夠持續

「敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的步調。」

敏捷開發是漸進式的，也就是說採取一致穩定的步調來開發產品。這種方法會研擬進度計畫，將可用的資源和專案需求納入考量。專案中應該安排足夠的時間，確實完成各項任務並反省整段流程。

9.優越的技術與優良的設計可強化敏捷性

「持續追求優越的技術與優良的設計，以強化敏捷性。」

這項原則是持續性的目標。開發人員應該在過程中注意各項細節，以確保始終一致套用最佳工作模式，如此即使意外遭遇障礙，也能輕易轉變方向或進行調整。

10.尋求簡單的解決方案並不丟臉

「精簡或最大化未完成工作量之技藝，是不可或缺的。」

這項原則能輕易套用到產品設計，因為簡單的設計通常是更優良的設計。

11.能自我組織的團隊是最好的團隊

「最佳的架構、需求與設計皆來自於能自我組織的團隊。」

如果團隊有能力自行想出完成工作的方式，就可望創造最佳的成果。

12.定期自省

「團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為。」

敏捷開發流程會反覆執行，因此在過程中需要不斷反省和調整。如此一來，就能營造追求成長和正向改變的氛圍。

敏捷開發適用於硬體領域的理由

了解敏捷開發原則之後，接著我們來討論如何套用 (並合理化) 這些原則到今日高度競爭的實體產品市場。

首先，敏捷開發中的多次改版概念乍看無法套用到產品開發，因為不可能在生產一項可用的產品後，又立即在後續的「衝刺」中一再改版，直到推出最終版本為止。許多製造商因此認為，敏捷開發是只適合用於軟體領域的工具。

但實際情況沒有這麼簡單；歸根結柢，問題出在應該要「直接採用」還是「修正後採用」這種方法。如果直接照字面套用敏捷開發原則，可能會讓硬體製造商面臨不合理的需求。相反的，若按照硬體開發的特性來修正敏捷開發原則，這些原則就能為製造業帶來諸多好處。以下將進一步說明。

所有類型的產品開發都要經歷從概念發想到產品發行的生命週期，而「衝刺」只是用來區分不同生命週期階段的另一種方式。「衝刺」的主要目的是確立一項直截了當、可達成的目標。在軟體領域中，「衝刺」最常見的實際應用方式是發佈產品。但在硬體領域，不必按照字面意思來設立終極目標，只要能夠評估進度就夠了。如此也能將複雜的硬體開發流程拆分為彼此關聯的明確區段。

即使是醫療照護等須遵守嚴格法規的產業，也能運用敏捷開發方法。假設平均產品開發週期為兩年，製造商應該思索的是在六個月以內能實際達成哪些目標，也就是將兩年週期拆分為四段「衝刺」，每一段都包含進度檢查和產品評估步驟。只要運用敏捷開發，製造商就能為自己設定基準、檢查團隊進度，並更深入了解硬體開發流程。

敏捷產品開發的真相

離散硬體製造不是新的概念，事實上對許多公司來說，離散生產模式數十年來 (可能更久) 根本就是常態。敏捷產品開發說穿了，其實就是為硬體製造商提供現代化的工具，協助他們大幅提高離散工作型態的生產力。這種方法不只是運用 Zoom 及其他視訊會議軟體而已，還牽涉到心態的轉變，將跨團隊協同合作列為首要之務，並改善內部溝通及合作。

比起以前，溝通及協同合作現在更加重要。市場上的不確定性越來越高，有一部分是因為客戶期待的變動。客戶知道自己想要什麼，而且希望馬上滿足需求，這使產品預期上市時程大幅縮短。此外，組織也必須準備好因應供應鏈的不確定性、不斷變動的全球情勢，以及許多其他問題。

敏捷產品開發方法吸取了敏捷軟體開發宣言的精華，並套用到硬體開發領域。這種方法的好處包括加強部門和相關負責人之間的內部溝通、經常檢查產品開發進度、設立明確的目標，以及能自我組織、動機強烈的團隊結構。

組織無需完全採用敏捷開發方法，就能享受到相關的好處。每家公司都不一樣，而敏捷開發方法原本就能彈性調整。我們先前曾提過，專案之所以成功，往往是因為「修正後採用」，而非「直接採用」。敏捷產品開發能協助組織加快創新速度，同時生產品質優良的產品，並在變幻莫測的環境下因應不確定性的影響。

敏捷產品開發的主要優缺點

任何產品開發方法都有優缺點。只要事先了解敏捷開發的優缺點，就能協助您的團隊妥善利用這種方法的優勢、避開任何潛在的缺點。如果要深入了解，歡迎閱讀「敏捷產品開發的 3 大好處」。 

主要優點：

• 提高協同合作程度：能力強大的跨部門組織團隊是敏捷產品開發的骨幹。您不必採用先讓設計團隊製作原型並敲定設計，再向製造團隊展示的做法，而是讓這兩個團隊協同合作、分享各自的觀點，如此就能在流程中盡早發現挑戰。
• 經常與客戶和相關負責人互動，並收集意見回饋：敏捷開發的其中一項特色是能夠推出示範版，以便根據更遠大的目標，展示當前的進度。這種做法的其中一項主要原因，是可以每隔一段固定時間收集客戶、使用者和相關負責人的意見回饋。如此有助於優先推出下個產品版本，並讓團隊全力滿足客戶的期望。
• 適合用來推動「衝刺」：敏捷開發能將大型專案拆分為多段較小型的「衝刺」，讓團隊集中心力完成議定的目標。這種做法讓大型專案感覺更容易處理，而且會在過程中持續納入意見回饋，因此也能改善成果。

主要缺點：

• 在敏捷開發專案早期需要耗費心力學習：對許多人來說 (尤其是產品開發人員)，敏捷開發是一種全新的工作方式，因此可能需要花點時間進行調整，才能幫助每個人順利上手。
• 極度仰賴溝通：所有團隊成員都需要充分溝通，並彼此協同合作。如果溝通不良，可能會導致重複作業。
• 需要大幅改變文化才能大規模採用：敏捷開發的其中一項特色是需要組成跨部門組織團隊。如果要在公司全面導入敏捷開發方法，組織中就必須有成功的案例。

順利推動敏捷產品開發流程的 4 大秘訣

1.傳達敏捷開發價值觀和原則

團隊和公司如果採用敏捷開發方法，可能會使產品開發模式發生轉變。為了幫助團隊順利上手，應該先討論敏捷產品開發的意義，尤其是這種方法的價值觀和原則，然後再找出在專案中實際應用這些原則的方式。

2.採用有助於導入敏捷工作方法的工具

敏捷開發需要跨部門組織團隊經常且即時進行溝通。此外，團隊也需要有助於導入這種工作方法的工具；複雜的大型產品設計檔案無法透過電子郵件處理。比起需要安裝/檔案型的舊式工具，雲端原生 CAD 和 PLM 解決方案這類工具更適合用於敏捷產品開發。您可以搭配這些核心產品，使用強化溝通與協同合作的工具，例如 Slack、Miro、Smartsheet、JIRA 等等。此外，如果共用相同的系統，也有助於相關負責人和團隊之間的協同合作，這些人員包括自由接案設計師、供應商及合作夥伴等外部參與者。

3.不需要全面改用敏捷開發

當團隊改用敏捷開發方法時，不需要全面採用。敏捷開發方法中可能有些部分就是不適用於您的公司，因此您可以放棄不適合的做法、選擇有效的做法，然後持之以恆地改善流程。

4.撥出時間檢查進度和反省

敏捷開發追求的是完成每段「衝刺」的目標，也會排定檢查點，以便分享示範版和專案進度。團隊除了推出新版產品以外，也應該保留時間提供關於流程的意見回饋。團隊在下一段「衝刺」的過程中，應盡力在產品和流程中納入意見回饋。由於團隊的心態是追求成長進步，因此不會害怕失敗，並能從錯誤中學習。

敏捷開發方法與瀑布式開發方法有何不同？

敏捷開發和瀑布式開發都是專案管理方法，用於執行和管理專案，但兩者的差異很大。

敏捷開發著重於漸進式開發，團隊會在幾週或幾個月內快速開發並微調產品，同時收集客戶的即時意見回饋。瀑布式開發方法中的每項流程則採取線性路徑：也就是分階段朝同個方向進行，幾乎無法回頭；即使可以，也因為成本太高昂而不實際或無法持續。這種方法著重在每個階段獲得最佳成果，然後才能進行下一個階段。

敏捷開發偏好重複進行專案階段。開發人員與相關負責人攜手設計產品，並在過程中提供意見回饋。每段「衝刺」都有既定的目標需要完成，這些目標通常直接取自客戶的意見回饋。客戶會提出所需的產品，然後團隊就據此進行「衝刺」，全力達成這第一項提出的目標。接著客戶會提供意見回饋，團隊再進行相關的變更，根據前一版的設計快速打造新版產品。「衝刺」的期間通常很短 (幾天到幾週)，而且著重於快速達成小目標，不會將推出重大成果列為首要之務。在敏捷設計方法中，意見回饋和對話是在設計階段就發生。

常見問題集

• 敏捷開發是否只適用於開發軟體？

不是。敏捷開發方法的原則與核心價值觀也能套用到軟體開發以外的領域。雖然這種方法源於軟體領域，但許多公司已經發現這種專案管理法更有彈性、更容易修正，而且有助於協同合作。

• 敏捷開發包含哪 5 個階段？

敏捷開發可分成 5 個階段，能為專案流程提供一些結構，但本身並不是需要採取的步驟。這些階段可能會彼此重疊，並在出現新資訊或需求時反覆進行。

1.期望

任何敏捷開發專案的這個階段都是用來奠定基礎，目的是定義預期達成的願景和專案基本架構。

在這個階段中，要回答的問題包括：

• 這項專案將交付哪些項目？有哪些需求和目標？
• 哪些人將參與？哪些人將完成所需的任務？哪些人將提供意見回饋？哪些人將負責管理專案？您應將參與專案的所有內部及外部人員 (例如客戶等等) 納入考量。
• 團隊成員將如何合作？將使用哪些工具來達成目標，並改善溝通過程？

如果先確立願景，將能掌握所有資源 (人員、目標、方法、時間)，如此就能開始詳細規劃後續的階段。

2.推測

這個階段要進行腦力激盪，每個人檢視現有的資源，並一起思考專案執行方式。經過眾人思考之後，就能按照專案性質 (資源、時間等)，確定可達成與無法達成的目標。
在這個階段中，團隊將確立專案初期的概略產品需求、每位團隊成員能承擔的工作負載、產品交付時間表規劃 (通常分成多個階段)、應降低的預期風險和相依關係，以及預估成本。

3.探索

在這個階段，專案已經展開，團隊會按照願景和時間表來開發產品。然而過程中一定會遇到障礙，這時正好能發揮敏捷開發的優勢。透過定期進度檢查和溝通，團隊能夠管理工作負載、遵循最佳工作模式，並因應任何挑戰。團隊成員應該視需要協同合作，並在自己擅長的領域貢獻心力。此外，也應該在產品開發過程的不同階段定期檢查所有相關負責人的進度。

4.修正

由於在產品開發流程中會不斷產生新的資訊，因此必須進行修改、變更及修正。這就是修正階段 (而且多半需要同步調整推測和探索階段)。這個階段的重點是向具備不同觀點和專業的相關負責人收集意見回饋。換句話說，當專案有了一些實質的成果，就需要進行分析，以了解是否達成目標。修正階段會考量這些不同的意見回饋、列出需要改善的項目，然後規劃下個產品版本。

5.結案

雖然敏捷開發會以漸進方式反覆進行，但每項專案最終都必須結案。當產品交付生產或推出重要功能更新時，您當然可以慶祝達成目標；不過請記得仔細檢視開發流程、進行分析並收集意見回饋，然後將學到的經驗套用到下一項專案中。

• 敏捷開發方法為何適用於產品開發？

敏捷開發方法非常有效，因為這種方法了解產品開發流程不是線性的，而能為團隊建立架構，以便有效因應變更、風險與不確定性。這種方法強調協同合作、包容性與彈性，也將客戶視為流程與產品的核心，因此最終能產生更優良的產品設計。

改用敏捷開發

運用敏捷產品開發方法打造實體產品的做法越來越普及。了解箇中原因，以及如何有效運用這種方法。

閱讀白皮書