4/27/2016

軟體專案品質控制的三要點


老馮是軟體專案經理,在專案進行的某一天,被高層找去開會。高層:「最近雲端計算很火紅,你的專案既然是跟Cloud有關,看能不能早點完成」。老馮就問:「那可不可以auto-scaling的功能不做?」。高層:「沒有auto-scaling哪能算雲端計算平台,當然要做啦」。老馮就又不死心地說:「怎麼可能功能不減少又要早點完成?我們都已經是早9晚9在加班」而老馮心裡沒說的是,加班也絕對不是解決的方法。高層:「那就看你們的能力啦,不然我在多加3個人給你好了?」。老馮:「...」


專案管理過程中,品質是最容易忽略的項目。在狀況複雜的專案,品質常常是自動被犧牲的事情。在沒有良好控制的專案,品質是最容易被省略的事情。

品質Quality的定義其實有點複雜(參考這裡)。基本上,在軟體上,一個可接受的品質通常是指:功能如預期的正常運作,並且沒有不預期發生的壞事。

例如,一個手機購物程式,在你執行登入,往下捲動查看最近的商品目錄,點選商品,下單,這幾件事情都如預期的運作,就表示功能沒問題。從看到商品到購買,整個過程沒有讓你覺得很慢,那就算是沒有不預期發生的壞事。

又例如:當你點選商品之後,看到商品大的照片,接下來你就橫向擺放手機,照片因而旋轉之後,再轉回原來的正向,結果手機程式就當機直接跳出,這就表示功能有問題。當你點選商品到購買,整個過程讓你等得很心煩易燥,每個動作都要5秒鐘的等候,那就算是不預期發生的壞事。



軟體專業經理人,應該都知道一條鐵律:品質,範圍,成本,三者不可能兼具。

軟體專案的成本指的是:時間,人力,金錢或其他投入的資源。

軟體專案的範圍指的是:軟體的功能,規模,支援的硬體範圍等等,範圍修改自然就是功能增多或減少。


三者不可兼具,指的是要顧全某一項或者某兩項要素,就一定會犧牲另一項。例如:某APP可以支援google+ 以及facebook 帳號登入,後來因為時間(減少成本)考量,最後決定僅支援facebook登入。又例如,某APP原本可支援google+ 以及facebook帳號登入,後來又希望可以額外支援維博登入,這時候就決定花錢(增加成本)找外包廠商實作此功能。

軟體專案中,另一條鐵律是:試圖三者兼具者,會自動犧牲品質。例如:某APP可以支援google+以及facebook帳號登入,而後又想要支援維博帳號登入。專案經理想要在不增加成本,又不減少其他功能的情況下,又不增加實作時間。硬是要額外增加此功能的結果,必定是品質會自動犧牲。

不知道品質會自動犧牲的專案經理,必定不適合做軟體的專案管理者。

軟體專案品質控制有三個要點:

要點一:來源


品質的來源是整個開發過程,從一開始的計畫以及團隊組成,就已經決定了品質的一半。

一個簡單合理有效的計畫,可以控制改變,掌握進度事實。開發方法是不是採用Scrum並非最關鍵。重要的是,計劃中的開發方法是否簡單並合理的被團隊認知。

舉例來說,傳統SI常會有RFC,也就是需求變更的管理計畫。在開發過程中,如果有需求變更,基本應該是1.先填一份表格,2.在專案會議中與客戶討論,3.互相同意修改之後進行變更。換言之,有需求變更(RFC)管理的情況下,必定是前期的架構,設計細節,規格等等都先完成了,才會開始進行開發,因此,就不可能使用Scrum的開發方式。


假如團隊的組成是可以選擇的,那這件事情也是掌握品質的關鍵因素。



要點二:架構


在實作上,架構是另一個品質的主要關鍵因素。一個優良而且簡單的架構,比較有可能在多人而且複雜的開發情況下,獲取最容易達到的品質。

精煉的軟體架構設計表面上容易,實際上困難。架構的設計要素,眾所皆知:內聚力高,耦合力低,不同模組之間首重介面溝通。

然而,任何有3至5年工作經驗的程式設計師,都可以規劃出極為複雜的架構,普通並且沒有實務經驗專案經理,會容易「讚嘆」這種複雜的架構。這會在不久的未來讓品質很快降低。

實務上,只要沒特別的控制以及重構,正在運行的軟體的熵(entropy)值通常會隨著時間越來越高。同時也讓軟體品質越來越低,或要花很大的成本達到高品質。



要點三:創意


在品質控管中,創意是最被人所忽略。特別是在傳統的開發環境裡,負責品質的相關專業人員通常傾向於「找到問題」,事實上,這的確是QT或者QC的主要責任,但軟體專案中,作為QA(Quality Assurance)扮演的任務就不僅如此,而是在整個開發過程中確保品質符合規格(註一)。

而有創意的QA是第三個重要的品質來源。

普通的QA會執行QT/QC的任務,在開發過程中參與設計討論,並且撰寫測試案例(test case)。在功能完成之後,會認真執行測試案例,或者撰寫測試程式碼以便自動化測試,而在過程中找到並且記錄問題,並督促程式設計師修正錯誤。以上這些都很好,而且也沒什麼不對。

但是!當時系統複雜,時間壓力大,程式設計師能力參差不齊等等困難情況發生時,普通的QA流程並不會對「範圍」以及「成本」有所幫助,因此很容易被壓縮或者犧牲。

有創意的QA會根據專案的情況,找出最好的解決之道。而非死命地抱著舊有的測試流程,在確定有問題的情況下還不進行改善。

創意的可能行動有很多,但總之就是要有「行動」。空想的創意是沒有意義的。有創意的QA行動,可分為技術類型和非技術類型:


技術類型


例如:透過pair-programming主動參與開發;除了自動化測試之外,撰寫當介面改變時的監視程式;對於程式設計師的commit做自動化分析...這些都是透過QA的技術能力,提早發現可能的問題並提早解決。


非技術類型


例如:著重架構的精煉與簡化;改善測試流程;利用其他資源(例如業務人員)進行測試;改善code review的方式;簡化bug記錄以及追蹤方式...等等,這些都是透過QA的協調作業能力,縮短或減小品質差距。


簡而言之,絕大部份的軟體專案品質控制,其實是需要有創意的QA,才能突破既有限制,創造更多價值。而QA要有創意也並不困難,只要願意嘗試,通常都有很好的效果。


參考:沒有QA?如何確保軟體開發品質

註一:ISO對於QA的定義:"part of quality management focused on providing confidence that quality requirements will be fulfilled"






沒有留言:

張貼留言