ix

前言

《Agility 成功法則》為有時令人覺得怪異，且經常令人困擾的敏捷世界提

供了一本清楚又簡單的旅遊指南。

這本書對每個來到敏捷、Scrum、Kanban 和精實的世界的人都十分有用，

特別是那些對感到不安，覺得困惑的人們更是如此。這個世界有許多商業學校

裡沒有教過的怪異詞彙（至少學校還沒開始教），還有一些各位應該知道卻還

不知道的行內笑話、許多與其他組織相反的做事方式。各位也許會聽過敏捷不

適合膽小鬼，的確如此，各位會發現敏捷的某些面向的確十分困難，會感到敏

捷的某些部份不適合自己的組織。各位真的能夠確定奉獻與堅持一定能獲得回

報嗎？該怎麼找到自己獨特的方式？

只要有個有智慧又可靠的導師，這一切就不再是問題，導師能夠隨時在各

位的身旁，充滿愛心又有洞見的回答一切的蠢問題，但各位並沒有適合的導

師。你可能會問，要是有這麼一個導師，透過書本的形式回答問題？要是這本

書是用口語、生活化、務實的作法寫成，就像是個在真實世界實作的人一樣

呢？

《Agility 成功法則》就像是個有智慧的導師，能回答各位的問題，如同身

邊有個真正的導師一般；從他在真實世界的敏捷體驗中長遠又深入的經驗，

Daniel Gullo與讀者分享每個來到敏捷世界都不可避免會遇到的重要問題之

洞見。

書裡有與敏捷地界本質相關的非正式問題的答案，敏捷到底是什麼？怎樣

才能夠搞懂各種不同風格的敏捷？認證到底有什麼意義？有用嗎？

書裡也討論了有很大爭議的問題，敏捷有沒有辦法擴大規模？該怎麼看待

SAFe？面對不支持敏捷的組織文化該怎麼辦？

x 前言

書中也籬清了每個剛接觸敏捷的人都會遇到的令人討厭的小問題，例如，

為什麼所有的行內笑話都會提到雞跟豬？

其中也討論了一些麻煩的操作議題，該如何將待辦事項清單拆解到

sprint？為什麼每次增加的程式碼都必須要對使用者有價值？ sprint 的週期

該有多長？故事點又是什麼？「完成」所代表的意義為何？

本書同時也提到了一些更廣泛的管理議題，該如何將敏捷團隊混搭到現

存的管理階層？ ScrumMaster 與產品負責人或專案經理間又有什麼關係？

ScrumMaster 能夠是團隊的成員嗎？為什麼 Scrum 要求這麼多的會議？

本書也包含來自各行各業成員分享的敏捷旅程。在這些故事裡，讀者能

夠找到與自己所處情況與問題類似的故事，更重要的是，從中找到解決問題

的方式。

本書更囊括了一份包含常見敏捷詞彙的列表，也為想要更深入敏捷世界

的讀者準備了一份閱讀清單。

本書涵蓋了廣泛的領域，提供其他作者不願碰觸的爭議問題之洞見，並

不是每個專家都會同意本書的所有觀點，但每個人都會同意這些意見能夠作

為使對話更有意義時有用的錨點。

本書直白的告訴讀者什麼重要、什麼不重要，也告訴讀者哪些問題十分

關鍵，必須特別注意、哪些問題則是有比較好，但事實上就是場球賽。

各位再也不用獨自在敏捷當中掙扎，你們將會理解其中的各個主題。這

就是未來。這本書將會說明你這一切的原因。

—Stephen Denning 《The Leader's guide to Radical management》作者

xi

序

「現在你腦子裡對敏捷／ Scrum 最想問的問題是什麼？」

我從事敏捷產品開發的教練與訓練服務已超過八年，對象包含個人、團隊

及組織，我發現儘管市面上有許多敏捷主題相關的書籍，仍然沒有辦法回答人

們提出的所有問題。我開始想要記錄這些尚未獲得解答的問題，看看自己能做

些什麼，能不能從中發現任何模式？或是從中找出任何有用的資料？

我開始透過遊戲，從參加課程、工作坊的學員，以及使用者會議的參加者

中引出這些問題，將這些問題加到我自己在 Excel 上記錄的問題庫。在過去兩

年留下了超過 2000 個問題，全都是從一般程度的敏捷實作者所提出，涵蓋了

十分廣泛的敏捷領域。

儘管這些問題本質上十分不同，但對我而言有兩件事十分明確：1) 有許多

問題一再重複的出現，以及 2) 人們尋求實際、直接的建議，讓他們能夠將大

量理論著作落實為實際的行動。

我決定寫作本書，依據自己超過十年真實生活的經驗，透過幽默、務實、

直接的寫作方式，用自己的風格回答這些問題，我心目中的願景是：「要是我

自己剛開始或是有一定程度的敏捷經驗之後，想要看的是什麼樣的書？」

我試著透過本書為敏捷方法提供背景知識，同時提供個人經驗作為例子。

在剛開始寫作本書的時候，發現自己用很糟的方式引用客戶與雇主的情境，也

讓特定主題太過狹隘，我不想讓讀者認為：「哦，我們的狀況跟 XYZ 公司完全

不同，可以不用考慮這些建議。」

因此我在序的最後列出曾經合作過的組織，希望讀者能夠相信本書的內容

都源自於作者本身與這些組織合作的親身經歷，另外，由於保密協定的關係，

xii 序

技術上我不能直接提到其中某些組織的特定資訊，我的合作對象實際上是公

開資訊，只要沒有提到特定組織內使用的特定手法，就能夠在法律上被視為

合理的使用。

在我擔任個人與組織的教練時，會同時強調敏捷包含自己找出解決方

式，為組織找出適當的作法。由於敏捷也十分強調識組織的想法不受到拘

束，建立強調學習的文化，我會想到《萬世魔星》（Monty Python's Life of Brian）的場景，飾演布萊恩的 Graham Chapman 處理聚集在家門外的大量

人群：

布萊恩：「聽著，你們不用跟隨我，也不需要跟隨任何人，你們可以自己

思考！！」

人群：「沒錯！沒錯！再多教我們一點！！」

布萊恩：「不對！不對！重點是你們都是獨立的個體！」

人群中出現一個聲音：「我不是。」

人群：「閉嘴！！」

在各位的敏捷旅程中的某個時候，就會體認到沒有一定的答案，只有價

值觀、原則、實作、模式及想法，這一切都是為了帶來真正的重點：從群組

思想及為了慣例而慣例的作法中破繭而出，勇敢的創造與革新，承擔風險進

行實驗 ...

願你們平安

Daniel Gullo

1

Chapter 1

所謂的敏捷

剛開始學習敏捷（Agile）的時候，很容易弄混價值觀、原則及

實作，這主要是因為理想的組織與人類寶貴的本質大相逕庭，從本

能與本質來看，人類具有好奇心、喜好體驗、樂於探索、學習導向

等等的特質，但企業世界告訴我們應該遵守規則與程序：我們得要

守規矩跟聽話。

在轉換到敏捷式思維的過程中，人們能夠真正回歸自身創新的

本質，拋開程序與流程，尋找方法持續改善。

本章要介紹一般提到敏捷時經常談論到的許多不同方面與

概念，其中有些概念與 Scrum 有關，有些則與 Kanban、精實

（Lean）及其他被通稱為敏捷的方法有關，本章提到的問題與答案

哇， 真是太敏捷了！

2 Chapter 1 所謂的敏捷

都是在真實世界裡由真實的人所提出的真實問題，也就是說，我是原原本本

的轉述其他人告訴我的話，這些人包含了我的學生、客戶等等。

瀑布式與敏捷

瀑布式（waterfall）開發最早是在 1970 由 Winston Royce 開拓性的

《Managing the Development of Large Software System》一文中提到，文

章將這種作法描述為「... 高風險且容易失敗」（... risky and invites failure），

但人們經常忽略了 Royce 白皮書提出的重點，這個重點強調了循環式開發

（iterative development）比瀑布式開發更有效率。

瀑布式

一般而言，瀑布式一詞代表了階段式、單一循環（single-pass）的軟

體開發方法，工作流程中每個階段的成果彼此獨立，通常需要正式的

簽署程序，就像是瀑布的不同階層一樣，水流永遠不會回溯到瀑布的

上一層去。

本質上，瀑布式開發代表了階段式的開發方式，也就是只要在開發生命

週期中存在多個不同階段，每個階段完成時需要正式的交付與簽署程序才能

夠進入下一個階段，那麼所討論的就是瀑布式。

圖 1-1 是瀑布式開發的例子，描述為期十二個月的瀑布式專案流程。

請特別注意專案一直到第九到十二個月才有能夠測試的程式碼，這種情

況下得延遲到最後階段，而不是在專案的生命週期間逐步提供（參看圖 1-2）

要是在開發過程中抽離了資金，軟體也許不會留下任何有用的部分，之前的

投資全都白費了；同時，客戶與其他相關人等也無法確定產品帶來的價值能

夠符合投入的資源，也無法知道產品是否能夠符合期待，他們唯一得到的只

有軟體的外觀與行為的「承諾」。

瀑布式與敏捷 3

範例：

為期十二個月的瀑布式專案

程式碼

開始

文件

文件

未驗證

程式碼

未驗證

程式碼

未驗證

程式碼

未驗證

程式碼

未驗證

程式碼

產品水準

的程式碼

完整部署

的軟體

需求

設計

驗證（測試）

產品

實作

第二個月

第四個月

第九個月

第十二個月

瀑 布 式

圖 1

-1 瀑布式交付模型

4 Chapter 1 所謂的敏捷

Value Delivery (Usable Features by %)

1 2 3 4 5 6 7 8 9 10 11 12

100

90

80

70

60

50

40

30

20

10

0

交付的價值（可用功能百分比）

圖 1-2 瀑布式價值交付

理論上瀑布式開發十分符合邏輯，傲慢又自負的人類一向相信自己能夠

在開始進行任何開發之前，事先考慮到所有的意外、風險及其他未知的情

況，然而，歷史一再的告訴我們，我們在預測及估計未來上表現十分的差

勁，我們在預測與降低風險的能力並不算太好，這些風險包含了客戶需求、

市場方向的變動及技術上的失敗等等。

瀑布式開發適合專案需求十分明確且需求永遠不可能變動的組織，為了

滿足這樣的要求，必須要能夠完全的確定商業策略、客戶需要以及相關人員

的喜好，而且還要能夠完全的確定解決方案在技術上的設計、架構，以及實

作面對所有的變化時都不會有任何的風險，圖 1-3 是 Ralph Stacey 基於這些

參數對組織所做的分類。

簡單來說，瀑布式開發適用於沒有任何變動或不確定性，而且技術與願

景／策略又能夠完全一致且確定的組織。

瀑布式與敏捷 5

技術

混亂 （Anarchy）

繁雜 （Complicated）繁雜

（Complicated）

繁雜 （Complicated）

簡單 （Simple）

絕對一致

絕對確定

願景／策略

圖 1-3 Stacey 圖表 -- 組織的複雜度

只有極少數的組織能夠完全沒有任何變動或不確定性，相反的，大多數

組織都花費很大的成本執行固定、可預測的程序，也同樣面臨了各式各樣的

問題，包含使用者要求、技術進步、法律變化、社會變動、勞動力變化等無

可避免的改變，以及其他影響產品或服務開發或交付的因素。

為了更有效率的處理這些改變，甚至進一步將改變作為策略的一部分或

競爭的優勢，組織必須在產品或服務採取更多的循環式／遞增式開發與交付

的方式，這些方法也稱為敏捷（Agile）。

6 Chapter 1 所謂的敏捷

敏捷，嚴格來說指的是〈敏捷軟體開發宣言〉（Manifesto for Agile Software

Development，也稱為 The Agile Manifesto）中提到的價值觀與原則：

藉著親自並協助他人進行軟體開發，

我們正致力於發掘更優良的軟體開發方法。

透過這樣的努力，我們已建立以下價值觀：

個人與互動重於流程與工具

可用的軟體重於詳盡的文件

與客戶合作重於合約協商

回應變化重於遵循計劃

也就是說，雖然右側項目有其價值，

但我們更重視左側項目。

另外列出了以這些價值觀為基礎的十二個原則：

我們遵守這些原則：

我們最優先的任務，

是透過及早並持續地交付有價值的軟體，

來滿足客戶需求。

竭誠歡迎改變需求，甚至已處開發後期亦然。

敏捷流程掌控變更，以維護客戶的競爭優勢。

經常交付可用的軟體，

頻率可以從數週到數個月，

以較短時間間隔為佳。

業務人員與開發者

必須在專案全程中天天一起工作。

瀑布式與敏捷 7

以積極的個人來建構專案，

給予他們所需的環境與支援，

並信任他們可以完成工作。

面對面的溝通

是傳遞資訊給開發團隊及團隊成員之間

效率最高且效果最佳的方法。

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

敏捷程序提倡可持續的開發。

贊助者、開發者以及使用者應當能不斷地維持穩定的步調。

持續追求優越的技術及優良的設計，

以強化敏捷性。

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

最佳的架構、需求與設計皆來自於

能自我組織的團隊。

團隊定期自省如何更有效率，

並據之適當地調整與修正自己的行為。

優值觀與原則能夠用來描述與定義組織的文化，再搭配實作與其他要求，

就能夠開始看到組織文化的全貌。

敏捷本身並沒有定義任何的實作方式，這十二個原則僅僅指出正確的方

向，每個人需要決定自己願意相信與接受的原則。然而要是人員、管理者以

及組織文化三者之間並沒有相同的價值觀與原則，在施行敏捷實作時，不論

採用哪一種框架都會遇到困難。簡單的說：決定組織是否敏捷的要素在於其

信仰與核心價值，而不是採行的實作。

8 Chapter 1 所謂的敏捷

Scrum、Kanban，以及極致編程（xEtreme Programming， XP）等敏捷

框架提供了一些輕量級的「規則」，列出有助於組織接受價值觀與原則的實

作，能夠讓思考方式更加敏捷。

例如 Scrum 只定義了最低限度的角色、成品（artifact）與活動，結合這

些元素就能夠每隔一到四個星期產出有價值、能夠使用的軟體，在最糟的情

況下，開發團隊能夠每個月提昇一次可交付產品的價值，而不是每十二月提

昇一次。

在圖 1-4 可以看到為期 12 個月的專案採用 Scrum 的情況，注意到每個

Sprint 都會產出可交付的程式碼，在圖中的情況，Scrum 團隊決定每兩個

Sprint 才發行一次可交付的程式碼。

這種方式能夠強化利害相關人繼續為專案開發投入資源的意願，他們在

每個 Sprint 都能夠看到團隊交付更多的成果，而不是一再的看到不知何時兌

現的「空頭支票」。

想像你付了 $750000 美金請人幫你蓋房子，但建築師表示在完成之前你

看不到任何東西，也沒辦法看到實際進展，有很高的風險房子最後的樣子與

你想要的不同，你也許會想要改變櫥櫃或房子的格局，建築師可能誤解了你

的對布線的要求或是浴室裡固定設備的方向。

現在，想像建築師把相關的東西放在土地上相對的位置，邀請你實地「先

期體驗」，你發現自己想把房子的方向逆時針轉 45 度，接著在挖地基的時

候，你參觀地基與隔間，發現看起來很好也符合自己的期待。

隨著房子的建築進展，你在過程中能夠確認成果符合自己的期待，你也

有機會能夠做些細部的調整，甚至是較大的更動。

瀑布式與敏捷 9

範例：

為期十二個月的

Scr

um 專案

文件

可發布

軟體

完整部署軟體

完整部署軟體

完整部署軟體

完整部署軟體

完整部署軟體

完整部署軟體

可發布

軟體

可發布

軟體

可發布

軟體

可發布

軟體

可發布

軟體

可發布

軟體

可發布

軟體

可發布

軟體

可發布

軟體

可發布

軟體

可發布

軟體

文件

文件

文件

文件

文件

文件

文件

文件

文件

文件

文件

開始

第二個月

第四個月

第六個月

第八個月

第十個月

第十二個月

循 環 圖 1

-4

Scr

um 交付模型

10 Chapter 1 所謂的敏捷

Agile Value Delivery (Usable Features by %)

1 2 3 4 5 6 7 8 9 10 11 12

100

90

80

70

60

50

40

30

20

10

0

敏捷價值交付（可用功能％）

圖 1-5 從可用功能觀點的價值交付

這就像是 Scrum，讓客戶在團隊每次交付時都能夠看到獲得的價值（參

看圖 1-5），過程中客戶能夠稍微改變自己的心意，讓他們對最終獲得的產品

有信心。

因此，相對於傳統傳案交付方式而言，敏捷最大的好處在於敏捷能夠提

供檢視與調整的機會，並且在產品生命週期中的每個循環持續提供更多的價

值，不用等到最後。

「敏捷」實驗

我希望每位讀者都試看看以下這個實驗。

接下來一個星期，只要聽到有人在專案管理、軟體、開發等方面提到

「敏捷」的句子，就把敏捷換成以下的說法：

「敏捷」實驗 11

... 為自己著想 ...

... 告訴他人 ...

... 產生人們想要的東西 ...

... 看看所有的可能 ...

... 不要那麼混蛋 ...

... 用最簡單的方式解決問題 ...

... 讓客戶滿意 ...

... 誠實反應問題 ...

... 像創業家一樣承擔責任與發起行動 ...

這個實驗的目的是什麼？

我看到／聽到愈來愈多「半敏捷」（Hybrid Agile）、「控管式敏捷開發」

（MANAGED Agile Development）、「擴展敏捷」（Scaled Agile）等說法，

讓作者覺得大多數人沒有弄懂「敏捷」真正的意義，或是這個詞代表的精神。

也許敏捷宣言已經成為了口號？我們都能夠背出其中的價值觀，但我發

現許多自稱「了解敏捷」的人完全沒看過宣言背後的十二個原則，或是忘了

這些原則，但這些原則能夠為敏捷的意義提供更多的線索。

以上列出的詞句當中，我盡可能避免使用太多含意不清的詞彙，合作、

價值、革新、授權等詞彙已經變得失去意義也不被重視。提到這些詞彙時很

少會思考它們代表的意義與後續的影響，人們只想要得到好處與報酬卻不會

想到投資。

這些會不會讓你感到驚嚇？

希望會。

12 Chapter 1 所謂的敏捷

其中雖然帶點幽默，但也帶了幾分事實。

我並不是說敏捷的意思像是「嬉皮愛的慶典」（Hippie love fest）一樣，

但敏捷的確代表了與一同工作的人們以及服務的客戶有更良好的關係。

每個人的工作都是為了服務客戶，甚至可以將與雇主之間的關係視為服

務客戶。

在讀者進行這個實驗時，要是過程中發現這些詞句並不太適合用來替換

某些「敏捷」的標籤，也許真的就不是 ...

敏捷、精實、六標準差、PMP 與其他方法論的差異

這是個很大的題目，我經常在自己的課堂上收到這樣的問題。問題有

許多不同的型式，也就是說，課堂上遇到的問題並不一定都會包含上述的

方法論，有時會包含 Scrum、軟體開發生命週期（software development

lifecycle，SDLC）等等，我認為在分別說明上述各項之前，先清楚的定義方

法論（methodology）與框架（framework）十分重要。

方法論是指由方法（method）、工具以及實作（practice）所組成的系

統，明確的列出各個階段（phase）並且透過程序列出應該完成的行為。另

一方面，框架只是大致的定義實作及模式（pattern），提供彈性，允許在執

行實作與模式時自行調整。

在之前〈瀑布式與敏捷〉一節的討論中提過，敏捷本身既不是方法論

也不是框架，而是一組價值觀與原則的組合，代表對於交付價值的一種思

考方式與哲學。由於敏捷宣言的作者們在當時都是先鋒，於軟體開發方法

上各自提出了不同的見解，敏捷也就成為許多不同方法的總和呈現，但反

之則否；我將敏捷視為 Scrum、極致編程、Kanban、Adaptive Software

Development、Rapid Application Development 等方法的目的之總和，有點

像是個總括的詞彙，說明這些實作在信仰與精神層面目標的共同點。

敏捷、精實、六標準差、PMP 與其他方法論的差異 13

敏捷與精實在透過縮減浪費交付價值上有相同的概念，就某些方面而言，

精實與敏捷幾乎是相同的東西，但精實有十分明確的定義元素，例如五個

原則：

1. 確立價值（Identify value）

2. 識別價值流向（Map value stream）

3. 消費暢流（Create flow）

4. 拉式管理（Establish pull）

5. 盡善盡美（Pursue perfection）

同時，精實也列出了七種在任何生產程序中都存在的浪費：

1. 搬運的浪費

2. 庫存過多的浪費

3. 動作的浪費

4. 等待的浪費

5. 製造過多的浪費

6. 加工的浪費

7. 不合格品的浪費

接著再想辦法減少或避免浪費，同時並依據外部的相依性考慮制約理論

（theory of constraints）。也就是，我們依據無法控制的問題（issue）建立

系統，接著尋找最佳化整體系統的方法，而不是追求區域效能，追求區域效

能並無法增加整體的產出。

也就是說問題並不是在「Scrum 或 ...」或是「XP 或 ...」等方法論間選

擇，這些方法論並不是百分之百互斥。事實上，許多的實作彼此重疊，而沒

有重疊的部分也能夠互補或是能夠大幅度的相容。

14 Chapter 1 所謂的敏捷

六標準差（Six Sigma 或 6σ）是一組實作與工具，儘管更加著重在透過

量測與指標（metrics）而不是透過有機的回饋循環進行改善，六標準差的核

心實際上與精實減少浪費與最大化價值的核心相同。

然而，由於六標準差強調的是量化而不是質化的度量，許多敏捷倡議者

認為六標準差太過厚重（導致在實作上的誤解）。對於受到嚴格法規規範要

求限制的產業，六標準差能夠為改變與改善提供合理的理由。

對於風險不高、不影響人身安全或是社會福祉的軟體系統而言，效能上

的改善以及目的的合適性更常是透過與客戶的互動而不是檢查指標。

Kanban 是個框架，透過從頭至尾追蹤工作狀態的工作流程（系統）提

昇工作現況的透明度。Kanban 最主要的特色在於整個工作流程中每個狀態

的「處理中工作」（work in progress，WIP）都有數量的限制，這使得工作

流程從推送式系統（push system）轉變成拉取式系統（pull system）；對於

推送式系統，工作能夠忽略瓶頸與超載的條件持續的往下游送，但在拉取式

系統中，額外的工作必須等到下個工作階段有閒置的處理能量才能夠繼續前

進。唯一的例外是快速佇列（expedite queue），這個佇列能夠違反 WIP 的

限制，僅適用於極少數本身具有關鍵性的工作。

Kanban 能夠與 Scrum 一同使用並獲得一定程度的成功，特別是在開

發團隊專注在於符合「完成的定義」（Definition of Done）的功能建立一致

的流程，以及採取持續部署而不是批次性的可交付產品循環的情況。採用

Scrum 的原因是為了 Scrum 儀式（也就是活動，Activity）所提供的改善機

制（也就是回饋迴圈），例如，團隊會選擇固定的間隔反省自己的成長與成

熟度，討論改善團隊運作的方法。這在 Scrum 中稱為 Sprint 回顧（Sprint

Retrospective）；團隊也會固定的反省產品本身，以符合客戶與利害關係人

的期待，這在 Scrum 中稱為 Sprint 檢視（Sprint Review）。

極致編程（eXtreme Programming）則是由工程實作所組成，相較於

Scrum 在角色方面沒有正式的規定，其實作方式包含了持續整合、測試驅動

開發、配對編程、採取驗收條件（acceptance criteria）、重構、程式共同所

有權等等。

敏捷並不適合你... 15

還有其他的方法論，如 Rapid Application Development、Dynamic Systems

Development Method（DSDM）以及 Crystal Clear等等，這些方法論都對

敏捷宣言有所影響，甚至是 Rational Unified Process（RUP）的某些觀點，

〈The New, New Product Development Game〉（Takeuchi 與 Nonaka 著，

1986年）以及傳統專案管理都可能對敏捷有所影響。也就是雖然沒有明確的

提到專案管理，但「管理專案」自然而然的包含在敏捷的各個活動當中。

比這些更為重要的是組織必須要建立全新的文化，擁抱變化、學習、熱

情、願意成長、有好奇心、樂於嚐試、享受、推到極限（依照 Andy Stanley

在〈Take It to the Limit〉的說法）作為可接受的速度，以及其他改善客戶、員工以及全世界生活品質的關鍵動力。擁抱學習與鼓勵自由交換想法，不須

擔憂不良後果的組織在建立讓客戶耳目一新的創新產品上會獲得最傑出的表

現。

依據 Steve Denning 在其著作《Radical Management》中的說法，唯一重要的是追求客戶的讚賞，這個目標能夠透過特續革新達成，Denning 斷定

專注在利潤、成本以及股票價值都無法如預期般的提高利潤，只需要想辦法

交付能讓客戶欣賞的產品，利潤自然會隨之而來。

敏捷並不適合你 ...

抱歉，兄弟， 敏捷不適合你 ...