敏捷開發過程中如何開發高質量的軟體

08-20

敏捷開發過程中如何開發高質量的軟體

來自專欄敏捷視界4 人贊了文章

前言

什麼是軟體質量？很多技術同仁都認為軟體質量是軟體是否存在 Bug，是否性能高，安全性好等等。其實軟體質量的含義遠多與此。質量就是軟體產品對於某個（或某些）人的價值；價值是指創造利潤，又或是降低成本。總的來說，軟體質量是軟體的靈魂和存在意義。另外，我們知道現在敏捷開發日趨流行，其實敏捷開發也是順應市場的對價值的訴求和日益複雜的業務而產生的方法論，敏捷開發是追求高質量軟體的方法論和過程。

本文將和大家一起探討軟體質量的含義，以及敏捷開發中如何進行高質量軟體的開發。

軟體質量的理解

首先，我們先來看看什麼是軟體產品質量？先有了軟體質量定性的了解，才能介紹如何影響、控制和改進質量。

大師溫伯格在《質量·軟體·管理系統思維》說到：「質量就是軟體產品對於某個（或某些）人的價值」（某個或某些人文章中統稱之為用戶），這裡面包含兩個層次的質量含義，即「正確的軟體」及「軟體運行正確」：

「正確的軟體」是說，一個軟體要能夠滿足用戶的需求，為用戶創造價值。此處的價值可以體現在兩個方面，即為用戶創造利潤或者減少成本。如果一個軟體能夠滿足需求的用戶群體越大、創造的利潤越大或減少的成本越大，則該軟體產品的質量越高。反之，一個產品儘管運行良好，沒有 Bug，擴展性很強，性能很好，但如果沒有服務的用戶人群，沒有為用戶創造價值，則這樣的軟體儘管運行良好，也無任何質量可言。

「軟體運行正確」是說軟體沒有或很少 Bug，擴展性很強，性能良好，易用性高等。這樣的軟體是一個運行良好的軟體，但還不能稱之為高質量的軟體。只有在軟體符合用戶的需求的基礎上，運行良好的軟體，才是一個高質量的軟體。當然，如果軟體完全符合用戶需求，但不易使用，經常出錯，性能很差，這樣的軟體也不是一個高質量的軟體。

「正確的軟體」及「軟體運行正確」二者相輔相成，前者關係到軟體的成敗，後者關係到軟體的好壞。在現實的很多開發團隊中，特別是偏技術的開發團隊中，往往過分注重後者（軟體的 Bug 率，性能，可擴展性，架構等），經常陷入在軟體開發過程的細節之中，而忽略了前者（軟體需要符合用戶的需求），開發出的軟體經常能用但無用，不是最終用戶期望的軟體，這樣的軟體是能用但無用零質量軟體。

在產品開發中，能用但無用的現象尤為明顯。產品和項目不一樣，項目往往是為某個客戶而開展，有特定的需求來源，而產品往往是一個更廣泛的概念，是市場上某一類客戶群體的價值代表，沒有固定的需求來源，而且良好的產品往往要起到引導客戶需求的作用，超越現有客戶能提出的需求，所以對產品來說，「正確的軟體」更加困難，但也更加重要。

當然，「軟體運行正確」同樣非常重要，關係到軟體的好壞。Bug，擴展性，性能，易用性等問題會造成客戶想用但用不了，同樣造成軟體質量問題。

敏捷開發對軟體質量的影響

敏捷開發對軟體過程和質量控制產生了一系列的影響，主要來自兩個方面的影響，用下圖表示如下：

圖 1. 敏捷過程帶來的影響

敏捷過程帶來的影響

圖中的具體含義如下：

敏捷開發對「正確的軟體」的影響

敏捷開發擁抱市場變化，擁抱客戶需求變化，採用迭代反饋的方式管理項目。其背後的一個核心理念是：一個高質量的軟體，首先應該是一個「正確的軟體」，能夠滿足客戶的需求。

我們知道當今的世界產品極大豐富，不管任何產品都會有的競爭對手和替代產品，大家熟知的有瀏覽器大戰，輸入法血拚，視頻網站、博客滿天飛，國內外 ERP 系統競爭激烈等。所以，軟體的質量是要在市場化的競爭激烈的環境中去進行驗證，進行優勝劣汰，最終高質量的軟體產品被客戶接受。所以，一個高質量的軟體首先應該是一個「正確的軟體」，能在激烈的市場和競爭對手中找到市場定位，有客戶需求和市場銷量，能提高產品的使用者客戶體驗的軟體。否則，軟體做的再好、性能再快、界面再優美好用也不是一個高質量的產品。

敏捷開發正是符合這樣市場環境而誕生併流行，其迭代反饋、擁抱變化的理念和方法，能夠使得團隊更能開發出符合市場和客戶的高質量軟體。如上圖 1 中所示，左圖中的大半圓表示傳統的開發模式中，產品不能滿足客戶需求的風險。因為傳統的開發模式基於中央控制的計劃，沒有足夠的迭代和反饋理念和方法，猶如一次性的把所有的資金購買了一隻股票，導致質量風險大。上圖 1 中右邊的敏捷開發中，採取迭代反饋的原理，通過一系列的方法（下面會介紹）把市場和客戶的需求和期望分散到個整個軟體的生命周期中，猶如把所有資金進行資產組合，最後的軟體產品質量風險小，能夠較大概率的符合市場和客戶的需求，並帶來價值。

敏捷開發響應市場和客戶價值取向，但如果沒有完善的方法去收集和分析市場和客戶的反饋，也會導致嚴重的質量問題，如軟體隨波逐流，隨客戶朝夕更改；市場定位模糊，沒有核心競爭力；和競爭對手沒有任何區別，陷入艱難的紅海戰爭中等。所以，敏捷開發方法對高質量軟體也提出了挑戰，需要相應的方法和流程去執行和控制。

敏捷開發對「軟體運行正確」的影響

「軟體運行正確」是說軟體運行良好，沒有或很少 Bug，擴展性很強，性能良好，易用性高等。

軟體工程中有個經典的統計，即軟體生命周期的前期造成的 Bug 的影響比後期大的多，所以需求的變動影響是最大的。而敏捷開發擁抱市場變化的理念，會積極響應市場需求，這會對整個軟體，如軟體架構、編碼、測試、文檔都會造成很大影響。猶如長鞭效應，長鞭前端的抖動會逐漸放大到整條長鞭，而且波動會越來越大。這會影響「軟體運行正確」的高質量要求。

所以，我們不僅要看到敏捷開發帶來的高質量客戶價值的好處，如上圖 1 右邊敏捷開發的上部分波動所示，還要看到這些小波動導致的長鞭效應。如上圖 1 右邊下半部分所示。敏捷開發擁抱市場變化和客戶反饋會對整個軟體的架構、開發、測試造成很大的波動。如果控制不好，會使得項目失控，造成嚴重的質量問題，如錯誤 Bug 多，架構不合理，易用性不好，性能不好等等。

總的來說，敏捷開發的理念和方法，響應市場和客戶的價值，有利於發布符合客戶價值的軟體。下面介紹敏捷開發過程及質量控制最佳實踐，能很好的解決敏捷開發中的軟體質量問題，輔助團隊發布高質量的軟體。

敏捷開發過程及質量控制最佳實踐

敏捷開發的需要敏捷過程的支持才能快速響應市場需求，發布高質量的軟體產品。下圖是作者用過的敏捷過程（可以定製適合自己項目的敏捷過程），文章不詳細介紹下面敏捷開發過程，主要介紹其中的質量控制流程及最佳實踐，也是圍繞質量的兩個方面介紹質量控制實踐：「正確的軟體」及「軟體運行正確」兩方面。

下圖 2 中是一個軟體敏捷開發的迭代過程，每個迭代有需求，有變化，有架構，有設計，有開發，文檔等。其中深藍色背景，白色字體的是敏捷過程中質量控制流程。主要包括兩個方面的質量控制：「正確的軟體」及「軟體運行正確」兩方面。下面依次介紹：

圖 2. 敏捷開發過程及質量控制

「正確的軟體」的質量控制流程和最佳實踐

這個作者認為是敏捷開發中質量控制中最重要的一點，因為這是後面所有其他軟體質量的前提。如果軟體剛開始就是錯誤的，不能給客戶帶來價值的，就猶如路和方向就是錯誤的，那儘管在這條路上走的多好，多穩，也不會通向理想的目的地– 高質量的軟體。做正確的事情，說起來簡單，但做起來是最為困難和艱險的一件事情。猶如上文說到的長鞭效應，在這裡一步走錯，就會導致整個軟體的極大波動，導致項目失敗。因為產品定位和價值都錯了，那再如何努力開發和測試也是不可能交付高質量的軟體。敏捷開發強調擁抱變化，迭代開發，客戶反饋原則等也無非是使得軟體在正確的方向上前進。

下面作者敏捷開發過程中經常使用的幾種最佳實踐，能夠輔助團隊正確捕獲市場需求和客戶反饋，並進行需求分析及過濾，設計出能給客戶帶來價值的高質量軟體。包括上圖中的「需求」、「SWOT 分析和需求審核」和「CDD & User Story 審核」。

需求

需求又包括需求獲取和反饋，需求分析和需求創造三個方面

演示和原型

在軟體敏捷開發過程中，如何獲取市場的需求和客戶的反饋是高質量軟體的前提。敏捷開發中，除了正式的軟體開發及發布，我們還有專門的團隊開發演示和原型。演示是為了向客戶和業務人員展示產品功能，並獲取客戶反饋；原型是為了展示對產品未來的雛形和概念，便於與客戶討論和展示，並獲取市場需求。產品、原型和演示三者的關係如圖所示：

圖 3. 敏捷開發過程中的軟體、原型和演示

Persona 的方法論

Persona 指的是角色，也就是基於角色的方法論，強調一切從角色出發思考問題。我們知道，每個人的思考的角度都不一樣，客戶的思考問題的角度和開發團隊的思考角度不一樣，甚至不同客戶之間思考問題的角度也不一樣。團隊在設計和開發軟體的時候，容易陷入自己的思維角度，開發不符合客戶思維角度的軟體，而不符合客戶的需求。更嚴重的是很多團隊陷入這樣的慣性，而根本不知道錯誤在哪裡。

Persona 的方法論中強調，不論軟體的哪些需求，哪個功能模塊，甚至會議中的討論，請首先確認出 Persona。Persona 可能不止一個，所以需要分析並確認出不同的 Persona，並設定所有 Persona 的背景，需求，期望等。然後把討論的需求、功能模塊、會議的議題，對應到定義的 Persona 中。然後根據 Persona 的重要與否，Persona 的背景等，就可以進一步分析、確認需求。下面是一個 Persona 的簡單模板

Persona 的簡單模板：

Name
Photo
Brief Biography
Goals
Context scenario

確認出 Person，尤其是關鍵客戶的 Persona，然後盡量使軟體符合該 Persona 的價值需求。作者的經驗中，Persona 的方法論，非常有益於理清思路，特別是在需求分析和討論階段尤為重要。需求收集和討論時，不同的同事代表不同的 Persona（有的是客戶業務人員，有的是客戶架構師，有的是客戶技術人員）他們提出各種不同的假設、需求、改進、功能模塊。這時如果不從 Persona 的角度去思考和理清問題，就經常陷入混亂和口水大戰。而最終卻沒有滿足項目或產品的最重要 Persona 的需求，不能創造價值。可想而之，以此為基準的軟體將是能用但無用的零質量產品。

最高境界「跟隨需求，不如創造需求」

這點對軟體產品來說尤為重要，前面說過產品和項目不一樣，產品的需求更加模糊，而且一些新產品往往需要帶有一定的新特性。產品需求的最高境界是創造概念、規則，並由此創造需求。不管是軟體行業，還是其它商業界都是如此，如：

從 BP 機到手機，再到 iPhone；
從膠片相機到數碼相機；
從門戶廣告到搜索廣告；
從 Blog 到 Twitter 等

商業界創造概念、規則、模式，並由此創造需求，才能創造出藍海，並成為領頭羊。而其他跟隨著只能符合創造者的提出來需求。

在這個境界上，創新是最至關重要的因素，唯有創新才能打破規則，打破需求跟隨者的狀態，創造出符合未來用戶需求的規則和產品。

而這樣的軟體，也是最有價值的高質量軟體。

SWOT 分析和需求審核

敏捷開發中通過需求收集及客戶反饋得到了大量的客戶需求，如何進行有效的過濾並選出最有價值的需求呢？這是敏捷開發中高質量軟體的關鍵之一，因為沒有一個很好的以客戶和市場為中心分析方法，產品會隨客戶朝夕更改，市場定位模糊，散失穩定的核心競爭力。

開發團隊常見的誤差是從技術的角度來考慮哪一些需求價值大，哪一些需求緊急度高，造成的結果是有一些功能模塊投入了很多資源，但卻並不一定是客戶最想要的。

在作者的敏捷開發中，對產品的需求和模塊進行 SWOT 分析，分析的輸入是所有的 Persona 客戶需求、市場現狀、產業現狀、競爭對手現狀等，輸出是需求的重要度和緊急度，以及投入的成本。然後按照性價比可以進行排序，選出最能符合市場的模塊。SWOT 分析有益於以最少的投入研發出符合客戶和市場價值高質量的軟體。

下面是一個 SWOT 分析的事例：

圖 4. SWOT 分析事例

SWOT 分析事例

CDD 以及 User Story Review

CDD（Concept Design Document）指的是軟體的概念設計文檔，User Story 指的是用例細化的用例故事。

這二者發生在進一步細化需求並要轉換成軟體架構時，對這二者進行進一步的分析和審核，有益於保證從需求分析到架構設計的過度階段的軟體質量，降低客戶需求理解偏差的概率。

「軟體運行正確」的質量控制流程和最佳實踐

敏捷開發的擁抱變化，如上面的圖 1 中所示，會對軟體架構、編碼、測試、文檔都會造成很大影響，猶如長鞭效應，長鞭前端的抖動會逐漸放大到整條長鞭，而且波動越來越大。在敏捷開發中，為了快速響應變化，敏捷開發中的如下特性：

需求變化更頻繁
輕詳細設計，沒有那麼多的架構和設計的時間
反對冗餘繁重的文檔
反對冗長會議和電話會議

贊同代碼就是最好設計和文檔（Code is design and document），並通過重構自然呈現架構和設計

這些特性和傳統的進行大量的架構設計，然後通過文檔記錄並溝通的方式有很大差別。敏捷開發中這樣靈活的方式就更要求有嚴格的質量控制流程。否則，最終的產品的質量很大概率出現問題。如可擴展性、架構、可用性、測試穩定性 Bug 等。

下面是敏捷開發流程中控制架構、開發、測試等質量的流程：

架構和概要設計 Review

敏捷中輕詳細設計，但並非不注重設計，只是敏捷中架構的形式和內容發生了變化。敏捷中進行的架構設計是高層次的架構設計，如：組件的結構，軟體的層次，技術選型等。敏捷中沒有進一步的詳細設計。架構設計就顯得尤為重要，架構層次的錯誤，在後期需要大量的人力物力來彌補。架構和概要設計審核主要圍繞下面幾點：

組件結構是否清晰。圍繞組件的特性：「高內聚」、「松耦合」、「隔離性」、「顆粒度」、「分層」等特點，設計良好的組件結構。組件的抽取過程，可以在公司組織結構部門設立中找到似曾相似的影子。在公司組織結構中，任何事情重複或重要到了一定程度，就會產生一個新的部門，如做銷售的人多了，就產生了銷售部門，不同省的銷售多了，就產生了省分部門。在架構設計中也是一樣，任何功能重複的到了一定程度，就應該抽象出新的組件，甚至一個產品。在設計好組件結構後，就可以分工進行開發。
層次結構是否清晰。關係是否混亂？是否需要抽取單獨的層次？
是否符合 Do not repeat yourself 的規則。好的架構設計應該是「不重複自己」，並且「不重複已有的成熟組件」。尤其是當架構中有些功能有免費成熟開源框架或者標準可以依據，但架構設計時沒有採用考慮，而重新發明輪子，導致不能重用已有的標準或開源框架的優勢，這些都是不可取的。
技術選型是否合理。包括數據，模型，展現，邏輯等技術選型，以及使用框架，依賴產品等。

代碼審核，以及重構出設計

傳統的架構設計，包括架構和設計兩個方面、其中設計可以包含詳細設計，如詳細的 UML 圖（詳細的類圖，順序圖等），詳細的 API 設計以及介面描述，存儲層資料庫表欄位設計等等。敏捷開發中不進行詳細設計然後再開發，它推崇 Code is design，設計是通過對代碼進行重構自然產生。所以，敏捷開發中，代碼質量和可讀性很重要。是否能通過高質量的編碼，以及重構，自然呈現出軟體設計，關係軟體可維護性，Bug 出錯率和修改、可擴展性、穩定性、甚至性能等質量問題。所以，在敏捷開發中並非沒有詳細設計，而是詳細設計的方式和時機發生了變化：敏捷開發詳細設計轉移到了開發階段，也即是：Code is design。這樣既能擁抱變化，又規避風險，又 Don』t Repeat Yourself。

敏捷中代碼審核的質量規格應該類似與詳細設計的規格，要求開發人員能夠發布高質量的代碼及代碼結構。團隊可以設立統一的編碼規範，命名規範，代碼結構規範。確保代碼和代碼結構的質量。團隊也可以選用一些自動化的代碼掃描工具來分析代碼結構及存在的不合規範的地方。

開發規範是能提高代碼質量，好的代碼，結構清晰，讀起來毫不費力，是一種享受。好的代碼包括如下特性：

高質量代碼結構在於開發人員不斷重構，把代碼按照邏輯結構分成不同的包。
高質量的代碼格式一般可以通過工具中的編輯器的代碼模板和格式器來控制。
高質量注釋即是代碼的注釋，又是軟體的設計文檔。
這裡強調一點是高質量的命名，不管是包命名，類命名還是變數命名，命名時應該採用能夠讓人看懂的名字，名字長一些往往更好，盡量少用不清晰的縮寫。如：People 對象，應該用 people 等能夠一目了然的命名，而不是 p, pe 等簡短不清晰的命名。

測試流程

在講測試之前，我們重新回顧一下：什麼是「高質量」的軟體產品？只有統一了「高質量」的概念，測試人員才有測試的標準和最後交付軟體的標準。

「高質量」的軟體，可以認為是：能為客戶在最少時間內，帶來最大價值的軟體。測試人員在測試軟體的時候，應該在思想層次和終端用戶統一「高質量」軟體的認識，並且所有的測試標準也將圍繞這個「高質量」的衡量標準進行，否則測試結果為高質量的產品，對客戶來說可能就未必是這樣。

所以測試團隊在軟體測試的過程中，要時刻站在客戶的角度思考問題，設計測試用例，以及測試產品。敏捷開發中的測試包括功能測試、集成測試、性能測試、安全測試、可消費性測試和無障礙測試等，這些確保能夠按照設計發布高質量的軟體。這裡不細講每一個測試的環節。需要強調的是可消費性測試。

一個高質量的軟體，不僅要能夠按照既定的設計良好運行，還應該是一個很好用的軟體。只有客戶能夠方便的使用軟體，軟體才能為客戶創造價值，也才能稱該軟體為一個高質量的軟體。大家都很熟悉的 Windows 和 Linux 操作系統，從普通終端用戶的角度上考慮，無疑 Windows 是更高質量的產品，因為它能為客戶在投入最少時間的情況下，創造最大化的價值。而 Linux 我稱之為技術層面的高質量產品，對普通終端用戶來說，其綜合價值不如 Windows。

可消費性測試涵蓋了整個軟體生命周期，將在另外的文章中詳細介紹。下面的可消費性測試中易用性測試幾個常用的原則，它能夠幫助測試人員測試軟體的容易使用程度。

效率– 用戶要花多少時間，多少個步驟才能完成一個任務。比如註冊用戶，查找一篇文檔。

準確– 在操作的執行過程中，用戶犯了多少錯？測試人員要時刻記住，用戶在使用產品中犯錯，是設計人員的錯，而不是用戶的錯。
無需記憶性– 用戶第一次使用是否能容易的使用產品？或者用戶多長時間不用後，還能記得如何操作產品？好的產品設計是無需用戶記憶，一切使用規則是隱含在設計中。
情感反映– 用戶完成任務後的感覺是什麼？是放鬆，還是緊張，該用戶是否會推薦產品給用戶。用戶使用產品，就猶如和設計師對話，好的設計師處處為用戶考慮，用戶使用完產品後會很放鬆甚至興奮，會迫不及待的推薦產品給其他用戶。

測試計劃及用例 Review

上面講到，測試團隊在軟體測試的過程中，要時刻站在客戶的角度思考問題，設計測試用例。測試計劃及用例審核 Review，其目的就是為了檢驗測試用例的結構，計劃，及每個測試用例的測試點，確保一切從客戶出發。

審核過程中，應該有業務人員，架構師介入，甚至客戶介入。

文檔 Review

文檔是軟體的一部分，而且文檔能夠輔助用戶使用軟體的，也需要嚴格的質量控制。文檔的目的是讓人學會使用產品，所以高質量的文檔，不僅是一個沒有錯誤的文檔，還需要能夠快速的幫助用戶學會使用軟體。下面是高質量文檔書寫的幾點最佳實踐：

能用視頻少用圖片，能用圖片少用字。現在用 Flash 視頻教學是非常好流行的一種教學方式，盡量多用一些 Flash 視頻的教學方式，如果沒有視頻，也盡量多一些圖片，產品截圖等。
多一些例子，比如 Struts 框架提供了 show case 等一系列例子，教導用戶如何開發和使用技巧，這些比純文字的文檔形象直接，效果更是不可同日而語。
文檔中盡量少用縮寫，除非是人盡皆知的縮寫，如 IBM, EJB 等詞語。如果需要使用縮寫，需要在一些地方標記出全名。

文章來源：https://www.ibm.com/developerworks/cn/rational/r-cn-agilequality/