敏捷開發下平衡質量和進度

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


相關文章