敏捷軟件開發團隊必須確保他們開發出來的產品質量能夠滿足要求，管理團隊也經常希望開發團隊能夠提高速度以實現為客戶提供更多的功能。本篇
文章中多個作者探討了質量和速度之間的關系，并提出了一些既能提高質量也能加快進度的方法。
Bob Galen曾今在他的博客中發表了讀懂我的唇語-敏捷并不快速的文章，在其中寫到了追求軟件開發進度下質量的重要性。
敏捷是一個“質量游戲”，如果你以正直，承諾以及平衡的心態來玩這個游戲的話，那么結果將會是非常好的“速度游戲”，但它（速度）卻并非沒有代價。。。
如果你無法玩轉這個質量游戲，你所采納的
敏捷開發方法甚至比你以前使用的開發方法更慢。
團隊必須致力于把
工作在一個迭代中完成，這也就意味著這些工作需要滿足定義工作完成的所有標準。
很多敏捷團隊允許返工 – 修復漏洞，完成
測試自動化，重構，或者設計不良導致sprint迭代的延誤。即使大多數的敏捷工具允許拆分用例故事以捕捉在sprint迭代中已經完成的工作對比延期的工作，我也還是認為這給團隊傳達了錯誤的信息，讓他們認為工作不在一個sprint迭代內完成是可以接受的。
讀懂我的唇語 – 并不是把所有事情做完，做完，做完！
正如Bob解釋的：一個組織不應該總是力圖讓進度變得更快，而應該更加注重質量。
因此，下一次當你聽到有人在激情澎湃的談論著敏捷代表了更快的速度時，請打斷他們，嘗試向他們解釋敏捷并不是一個“速度游戲”，而是應該強調敏捷是一個“或許能夠快速運轉的質量游戲”。
Tim Ottinger曾今寫過關于敏捷團隊進度的14個奇怪觀點，其中一個觀點中就提到了質量和速度之間的關系。
盡管大家通常會降低質量要求以求在較短時間內盡快完成工作，但是如果團隊所開發的代碼質量不高的話，經過全部sprint迭代后的進度最終都還是會被降低。
Stephen Haunts在他的題目為進度并不是目標或者目的博客帖子中，描述了當管理者設定團隊的進度目標后對質量會產生什么影響：
?。?#8230;）為了增加交付的功能點數目以滿足績效目標，團隊會犧牲掉系統的質量，但從長遠來看這樣最終還是會降低團隊的進度，并且會引入技術隱患。敏捷團隊最好關注正在開發系統的質量與流程過程（持續交付和集成等等），以及負責開發系統的團隊成員本身。
軟件開發者必須在進度和質量之間掌握平衡，正如Blake Haswell在文章什么是代碼質量中解釋的那樣：
雖然經常會有很多的外部壓力向進度方面傾斜，但是如果你不夠重視質量的話，進度最終還是會趨于緩慢以及停滯，以至最終整個項目走向顛覆?？紤]到一個項目的代碼質量決定了它能夠在多大程度上適應需求的變化，一個可以持續改進的事情是你需要花費一部分時間來優化自己項目的代碼質量。
Blake提供了一個可以用來檢查代碼質量的屬性列表：
可理解性： 代碼需要在各個層面上能夠被容易地理解。理想情況下，軟件應該非常簡單，并沒有非常明顯的缺陷。
可測試性： 代碼需要被編寫的非常容易被測試。
正確性： 代碼需要滿足功能和非功能性的需求。
有效性： 代碼需要有效的使用系統資源（內存，CPU，網絡連接，等）。
Hugo Baraúna在他的博客文章名為內部質量低下軟件的癥狀中解釋了軟件是如何因為變更而“變得更糟”的，最終導致質量低下并且降低進度。
假如你正在領導一家創業公司的技術或者產品團隊，你是首席技術官，并且已經推出了你們產品的第一個版本，做的還挺成功的。你們的業務模型已經得到了驗證，現在你們正處于快速發展期。這真是太棒了！但這也是有代價的，它帶來了一系列新的挑戰。
你們產品的第一個版本工作的很好，但是代碼庫卻無法滿足持續發展的要求。或許你的團隊進度并沒有像以前那樣好了，團隊成員一直在抱怨代碼的質量問題，首席執行官和產品經理想要一些新的功能，但你現在代碼規劃根本無法滿足業務的需求。
他提供了一個指示質量低下的癥狀列表，這個列表能夠幫助你來決定是否需要重寫或者重構：
所有事情都很艱難
進度慢
測試套件運行緩慢
無法避免的缺陷
你的團隊是消極的
知識缺乏共享
新開發人員成長周期太長
你又是如何平衡質量和進度的呢？
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters