敏捷軟體開發團隊必須確保他們開發出來的產品質量能夠滿足要求，管理團隊也經常希望開發團隊能夠提高速度以實現為客戶提供更多的功能。本篇文章中多個作者**了質量和速度之間的關係，並提出了一些既能提高質量也能加快進度的方法。
\\ bob galen曾今在他的部落格中發表了讀懂我的唇語-敏捷並不快速的文章，在其中寫到了追求軟體開發進度下質量的重要性。
\\
\\\敏捷是乙個「質量遊戲」，如果你以正直，承諾以及平衡的心態來玩這個遊戲的話，那麼結果將會是非常好的「速度遊戲」，但它（速度）卻並非沒有代價。。。
\
如果你無法玩轉這個質量遊戲，你所採納的敏捷開發方法甚至比你以前使用的開發方法更慢。
\\
\\\團隊必須致力於把工作在乙個迭代中完成，這也就意味著這些工作需要滿足定義工作完成的所有標準。
\
很多敏捷團隊允許返工 – 修復漏洞，完成測試自動化，重構，或者設計不良導致sprint迭代的延誤。即使大多數的敏捷工具允許拆分用例故事以捕捉在sprint迭代中已經完成的工作對比延期的工作，我也還是認為這給團隊傳達了錯誤的資訊，讓他們認為工作不在乙個sprint迭代內完成是可以接受的。
\\
\\\讀懂我的唇語 – 並不是把所有事情做完，做完，做完！
\
正如bob解釋的：乙個組織不應該總是力圖讓進度變得更快，而應該更加注重質量。
\\
\\\因此，下一次當你聽到有人在激情澎湃的談論著敏捷代表了更快的速度時，請打斷他們，嘗試向他們解釋敏捷並不是乙個「速度遊戲」，而是應該強調敏捷是乙個「或許能夠快速運轉的質量遊戲」。
\
tim ottinger曾今寫過關於敏捷團隊進度的14個奇怪觀點，其中乙個觀點中就提到了質量和速度之間的關係。
\\
\\\儘管大家通常會降低質量要求以求在較短時間內盡快完成工作，但是如果團隊所開發的**質量不高的話，經過全部sprint迭代後的進度最終都還是會被降低。
\
stephen haunts在他的題目為進度並不是目標或者目的部落格帖子中，描述了當管理者設定團隊的進度目標後對質量會產生什麼影響：
\\
\\\（…）為了增加交付的功能點數目以滿足績效目標，團隊會犧牲掉系統的質量，但從長遠來看這樣最終還是會降低團隊的進度，並且會引入技術隱患。敏捷團隊最好關注正在開發系統的質量與流程過程（持續交付和整合等等），以及負責開發系統的團隊成員本身。
\
\\\雖然經常會有很多的外部壓力向進度方面傾斜，但是如果你不夠重視質量的話，進度最終還是會趨於緩慢以及停滯，以至最終整個專案走向顛覆。考慮到乙個專案的**質量決定了它能夠在多大程度上適應需求的變化，乙個可以持續改進的事情是你需要花費一部分時間來優化自己專案的**質量。
\
blake提供了乙個可以用來檢查**質量的屬性列表：\\
hugo baraúna在他的部落格文章名為內部質量低下軟體的症狀中解釋了軟體是如何因為變更而「變得更糟」的，最終導致質量低下並且降低進度。
\\
\\\假如你正在領導一家創業公司的技術或者產品團隊，你是首席技術官，並且已經推出了你們產品的第乙個版本，做的還挺成功的。你們的業務模型已經得到了驗證，現在你們正處於快速發展期。這真是太棒了！但這也是有代價的，它帶來了一系列新的挑戰。
\\ 你們產品的第乙個版本工作的很好，但是**庫卻無法滿足持續發展的要求。或許你的團隊進度並沒有像以前那樣好了，團隊成員一直在抱怨**的質量問題，首席執行官和產品經理想要一些新的功能，但你現在**規劃根本無法滿足業務的需求。
\
他提供了乙個指示質量低下的症狀列表，這個列表能夠幫助你來決定是否需要重寫或者重構：\\
你又是如何平衡質量和進度的呢？
\\檢視英文原文：balancing quality and velocity in agile
\\ 感謝邵思華對本文的審校。
\\
敏捷開發 敏捷開發中的質量
有小夥伴就問，我們都敏捷了，我們是在效率和質量中找平衡，說敏捷開發中的質量是不容易控制的，要回答這個問題，我設計了乙個faq，內容如下 敏捷開發是什麼？敏捷開發是以需求為中心，以交付價值為目的，持續增量交付的一種軟體開發方法，至於什麼是敏捷，就去問問度娘吧。對於敏捷團隊來說，是乙個自組織的，有集體目...
敏捷開發一千零一問系列之三十七 進度與質量的衝突
本文是敏捷開發一千零一問的第三十七篇。欄目總目錄 問題 我有乙個問題，眾所周知敏捷實施中，每個task的時間是團隊自己定的，才能保證團隊有效的高質量完成，這是不是和客戶要求的deadline衝突了呢，團隊自己定的時間如果過多就會影響準時的交付，而如果不影響交付，必然會產生加班以至於質量問題。在實際中...
敏捷開發筆記 評估進度
度量真實的進度 待辦事項 估計任務真正花費的時間，可能前幾次估計的不准，比如第一次估計是2天完成，而實際上是6甜完成，那麼下次估計的時候，就乘上這個3這個係數。前幾次這個係數會波動，越到後面，這個係數會穩定，最終趨近於1 不要用不恰當的進度來欺騙自己和團隊 sprint，評估任務和資源，如果任務超過...