對于為何采用敏捷軟件開發這個問題，企業經常提到的原因之一是希望能夠更快地交付軟件。研究表明敏捷項目能夠進行地更快，例如《敏捷項目的成功證據》一文中描述的哥倫布市敏捷工作效率基準項目。

\u0026#xD;\n

在博文《誰說敏捷項目不能更快一些》中，Matthew Heusser分享了他在Agile Testing Days大會上的討論：

\u0026#xD;\n

2012年11月在德國波茨坦舉行的Agile Testing Days大會上，《敏捷測試：實用指南》的作者Lisa Crispin和Janet Gregory大膽聲稱“敏捷意味著更快”是無稽之談。

\u0026#xD;\n

會后，Janet Gregory向Matthew Heusser解釋了她這么說是什么意思：

\u0026#xD;\n

她說，敏捷的關鍵不是速度。速度的提升可能是附帶產生的結果，但是不是一開始就會這樣。向敏捷轉型這個過程會托你后腿，至少短期內如此。并且這個期限不是一兩個禮拜，它可能有一兩年之久。

\u0026#xD;\n

Matthew提供了為何他認為敏捷可以更快的幾個論據。他講解了如何構建正確的事情，忽略那些不值一提的需求以便節省時間。使用敏捷的另外一個原因是“老辦法也不快”。

\u0026#xD;\n

對比敏捷團隊和傳統團隊，前者一年中無法完成的事情，后者可能能夠完成，但這么比較他們不合適。一年中，傳統團隊也許能夠完成12個半需求，但卻搞得一團糟最終啥也沒有發布。

\u0026#xD;\n

他在博文結尾解釋了為何不同意這個觀點，并闡述了對敏捷能夠幫助團隊更快交付軟件的看法。

\u0026#xD;\n

還遺留一個問題：是否是更快了？Crispin和Gregory可能認為這個無所謂，如果只關注短期的進度，長遠看來這么做只會導致過度簡化，帶來的是痛苦和低效。我認為團隊能夠在流程改進過程中盡量杜絕浪費，工作效率也會隨之提升。

\u0026#xD;\n

在《讓敏捷跑得更快》一文中，Chris Turner討論了敏捷項目可能變慢的一些原因。他描述了經常遇到的四個原因，并給出了一些處理意見。

\u0026#xD;\n

• 不合適的人：從團隊中剔除那些不遵循良好工程規范或是正在把事情搞復雜的人。\u0026#xD;\n
• 先定義流程：建立可以開放的溝通、自組織、授權的團隊。\u0026#xD;\n
• 使用了不當的技術：讓團隊有權決定使用什么技術，如果該技術妨礙了發布，允許團隊重新做選擇。\u0026#xD;\n
• 架構太復雜：重構，使軟件盡可能保持簡單。\u0026#xD;\n

\u0026#xD;\n

Neil Killick在他的博文《交付軟件最快的方式是保持可持續的節奏》描述了為何讓敏捷團隊加快交付速度會給軟件開發拖后腿。他講訴了關于敏捷團隊的一個故事，在為期兩周的Sprint中該團隊平均能夠交付10個用戶故事，但待交付的用戶故事卻增加了。

\u0026#xD;\n

現在想象一下，我們讓團隊每個Spring只完成一個用戶故事。那么，即便不能打包票，我們也能相當確信能夠交付這個用戶故事。我們還能相當肯定可以完成得很出色。

\u0026#xD;\n

現在我們要求這個團隊每個Sprint交付兩個用戶故事。即使該團隊極有可能能夠交付這個2個用戶故事，成功的概率也要比只要求團隊每個Sprint交付一個用戶故事時要低一些。所以我們就有了一點不確定性。

\u0026#xD;\n

現在再想象一下，合同大限將至，我們還在努力趕工，是不是該加把勁了。所以我們要求預計能夠交付10個用戶故事的團隊交付12個用戶故事（現在我們超負荷了）。甚至是14個？要求團隊步伐越快（或者說是越糟），交付軟件時無法預料的事情就會越多，最后交付的軟件很可能質量更差。

\u0026#xD;\n

他建議允許團隊保持一個可持續的節奏：

\u0026#xD;\n

讓團隊找到一個合適的平衡點、在他們能力范圍內交付高質量軟件，那么就創建了一個成功的軟件開發周期。

\u0026#xD;\n

查看英文原文：How can Agile make you Faster?

總結

以上是生活随笔為你收集整理的敏捷是如何使你跑得更快？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。