根據敏捷聯盟目前的董事會，敏捷方法「已經跨越鴻溝」，我想這表示它們正變得越來越普遍。雖然這有其優點，但也帶來問題。當一種方法論或設計方法變得流行時，我們會看到許多人使用它或教授它，他們專注於流行，而不是真正的細節。這可能會導致以敏捷的名義做出的報告，與運動創始人的原則完全相反。

敏捷軟體開發已打破需求分析、測試和開發之間的一些孤島。部署、運作和維護是其他與軟體開發流程的其他部分遭受類似分離的活動。DevOps 運動旨在消除這些孤島，並鼓勵開發和運作之間的協作。

幾年前，我與一位客戶交談，他告訴我他不喜歡我們使用的敏捷方法：「在專案的早期遇到這些困難感覺不對勁」。與他的反應相反，在我看來，這種早期的痛苦是敏捷或任何反覆開發流程的巨大好處之一。

極限程式設計 (XP) 是一種軟體開發方法，主要由Kent Beck開發。XP 是最早的敏捷方法之一，事實上，在 Scrum 在 2000 年代初成為主流之前，XP 是 90 年代後期和 00 年代初的主流敏捷方法。許多人（包括我自己）認為 XP 是引起人們對敏捷方法關注的主要催化劑，並且比 Scrum 更適合作為敏捷開發的起點。

許多人相信你在敏捷專案中無法執行固定價格合約。由於敏捷流程的重點在於你無法預測未來，這並非不合理的假設。然而，這並不表示你無法提出固定價格的敏捷合約，這實際上表示你無法提出固定範圍的合約。

最近聽說很多專案都搞得一團糟。情況如下

• 他們想要使用敏捷流程，並選擇 Scrum
• 他們採用 Scrum 實務，甚至可能是原則
• 過了一段時間，進度很慢，因為程式碼基礎是一團糟

如果你關心自己的工作，就會想要做得更好。這包括思考自己做事的方式，並嘗試新技術，看看它們是否能讓你做得更好。即使其他人推薦新技術，你唯一知道它們是否對你有用的方法就是自己嘗試，看看它們是否能提升你的表現。

一般的開發人員可以使用敏捷方法嗎？

一個常見的問題是大型專案是否可以使用敏捷技術。畢竟，許多敏捷方法都是針對較小的專案設計的，而它們所抗拒的重量級想法在較大的專案中更為需要。

成熟度模型是一種工具，可幫助人們評估個人或群體目前的成效，並協助找出他們需要進一步獲得哪些能力才能提升表現。在許多圈子中，成熟度模型已聲名狼藉，但儘管它們很容易被濫用，但如果使用得當，它們還是很有幫助的。

贊助軟體開發的人通常對開發指標（例如速度或部署到生產環境的頻率）不太感興趣。他們更關心軟體將帶來的商業利益，例如降低人工成本、提高銷售轉換率、提升客戶滿意度，也就是業務成果。以成果為導向的團隊是那些被授權並具備提供業務成果的能力，這些團隊擁有能夠執行所有必要活動以實現成果的人員。相比之下，以活動為導向的團隊既沒有設備也沒有授權這麼做。他們只能執行實現成果所需的幾項活動之一。

我習慣創造新詞來描述我在軟體開發中看到的事物。這是這個領域中作家們的共同習慣，因為軟體開發仍然缺乏許多有用的術語。建立術語時遇到的問題之一是，術語容易在語意擴散的過程中失去其意義，這也是我們術語中潛在新增內容的另一個例子。

在我最近的CodeOwnership文章中，我描述了我思考程式碼擁有權問題的方式。我的許多軟體開發朋友都是極端程式設計師，並且傾向於支持集體程式碼擁有權。然而，這些類型的實務並非絕對，並且應始終根據當地考量進行調整。我的其中一位同事寄給我一則備忘錄，其中包含以下故事，我認為這是一個很好的指標，說明即使你是 XP 的忠實愛好者，也必須改變你的實務。

守破離是一種思考如何學習技術的方式。這個名稱來自於日本武術（特別是合氣道），Alistair Cockburn將其引入作為思考軟體開發技術和方法論的一種方式。

人們時常質疑某個特定專業是否能以增量的方式使用：「你無法在敏捷專案中執行（安全性 | 使用者介面設計 | 資料庫 | 國際化 | *），因為這個面向必須在前期完成。」

在敏捷專案中，你會發現一個常見的事情，就是開發團隊坐在一個開放式的團隊房間裡。這是在極限程式設計中很早就提倡的，並在第二版中被稱為主要實務之一。敏捷主義者偏好開放式的團隊房間，因為它促進團隊成員之間大量的非正式且深入的溝通。

在我整個職業生涯中所見到的穩定主題之一，就是軟體開發的性質和重要性。幾年前，一位潛在客戶告訴我們的業務員：「軟體就像污水管，我希望它能可靠地運作，而且我不想知道細節」。這種方法就是 Nicholas Carr 在 IT Doesn't Matter 中所談到的。相反地，我們為許多企業執行工作，其中 IT 已成為更明確的策略性促成因素，讓他們得以進入新市場或大幅增加其市場佔有率。因此，IT 是像污水管一樣的實用工具，還是策略性資產？