諾，走向敏捷之路也許注定失敗。在很多時候，業(yè)務部門需要在這個轉變過程中扮演領導者的角色。
“業(yè)務部門代表必須真正介入并了解這個過程。是否這樣做了差異巨大（如溝通的術語、采用的方法等）。一旦他們了解了，他們將看到介入并主導開發(fā)過程的好處。同時業(yè)務部門還需要清楚地了解他們必須承受的東西，因為當他們看到每個迭代中暴露出來的問題時，他們可能會變得沮喪，如未完成的工作、團隊犯下的錯誤和其他各種問題，這些問題在其他方法中都被掩蓋了，因為業(yè)務部門參與很少，參與時間間隔很長?！?/span>
6．敏捷只是一種開發(fā)方法
跟前者類似的一種誤解認為敏捷只是一種開發(fā)方法，而不是項目管理方法和框架。這種認知很可能來自敏捷在早期時主要是開發(fā)方法，沒有或缺少框架和流程。但從那時起，敏捷已經越來越成熟，Scrum已經成為一種比較完善的方法和流程，并已經建立了相對完備的知識體系。
以下原因解釋了為何這種認知依然存在。
（1）在敏捷項目中，開發(fā)方法和項目管理方法直接的分界線有些模糊：
·開發(fā)過程并不是同需求管理和其他項目管理完全分開的，通常來說，它們緊密地結合在一起。
·項目管理方法沒有被正式地定義為同開發(fā)流程相獨立的流程，在很多時候，敏捷方法中根本就不用“項目經理”這個詞。
（2）敏捷方法作為組成部分之一，通過整合和擴展，構建了一個完整的項目管理框架。敏捷并沒有詳細地定義大型的和復雜的項目所需要的高層次的計劃制定和項目管理，但將其描述為僅僅是開發(fā)方法是不準確的。
1.7 敏捷不是萬能的
關于敏捷的誤區(qū)有多個原因。
（1）敏捷方法設計時不是規(guī)定式的：它們沒有告訴你需要做什么或如何去實施?？傮w來說，敏捷方法定義了一些基本原理而在具體情況下需要具體的解釋。例如，敏捷宣言中定義了4個價值觀和12個原則?！拔覀円恢痹趯嵺`中探尋更好的軟件開發(fā)方法，身體力行的同時也幫助他人。由此我們建立了如下4個價值觀：
· 個體和互動高于流程和工具。
· 工作的軟件高于詳盡的文檔。
· 客戶合作高于合同談判。
· 響應變化高于遵循計劃。
也就是說，盡管右項有其價值，我們更重視左項的價值?！?/span>
具體如何在具體的情景中詮釋這些價值觀取決于做實施的人，他們將決定如何把它們應用到具體的業(yè)務和項目環(huán)境中。有時這些價值觀可能被錯誤解釋了。比如說，有些人會比較極端地解釋這些價值觀：
· 敏捷完全不需要文檔、流程和工具。
· 敏捷不適用于依據(jù)客戶合同的場景。
· 變更控制不適用于敏捷方法。
如此絕對化的解釋絕對不是起草敏捷宣言的人的本意，價值觀的描述原本就是相對的，關鍵就是你必須根據(jù)具體的業(yè)務和項目境況來解釋和實施它們。很不幸，通常的情況不是這樣的，而是敏捷方法被錯誤地實施或效果不佳。
（2）敏捷方法還在不斷成熟過程中，還需要了解哪些是正確的而哪些是錯誤的。實際上，敏捷是非常強調持續(xù)改善的，整個體系追求的就是不斷進化，隨著與敏捷相關的知識體系不斷發(fā)展，進化正在發(fā)生中。吉姆·哈史密斯把最終要的敏捷工具和方法劃分為以下4個層面：
· 技術實踐。
· 迭代管理。
· 項目管理。
· 組合治理。
敏捷方法深植于技術實踐當中，這個層面也是最成熟的和最確定的，有一個已經被廣泛接受的知識體系。但往更高層面上走，相對應的知識體系就變得越來越不成熟。例如，關于組合治理的書籍還非常少，而這個領域內又有很多需要學習了解的。
傳統(tǒng)的項目管理辦公室（Project Management Office，PMO）需要做出很大的改變以適應敏捷。很多時候，項目管理機構除了作為企業(yè)項目管理的流程和規(guī)章的制定者外，應逐步地將重心轉移到一個增值咨詢機構，以幫助企業(yè)實施更靈活的和自適應的流程。
關于敏捷很重要的一點是機械的教條式的實施注定失敗，你需要真的理解其背后的原理，才能有針對性地根據(jù)具體業(yè)務和項目來實施。這也是為什么沒有關于如何實施敏捷的規(guī)定的方法。
要選擇適合具體業(yè)務環(huán)境的方法（不管是敏捷的，還是非敏捷的），根據(jù)項目情況量體裁衣，非常核心的一點是對每種方法有深層次的理解（了解其原理）。這也就是本書所要做的。