{{ $root.errMsg }}

如何從管理中提升軟件開發的質素

(已刪除)

(已關閉)

(已標記為濫發)

(已保護)


早前,一個從事軟件開發公司的朋友向我傾訴,他正研究應如何提升他公司開發軟件的質素。原因是他發現公司的主要收入是靠新客戶維持,舊客戶很少回頭。在他詢問客戶時,聽到的多是投訴他公司開發的軟件經常有 bugs。每當聽到這些投訴,他便心如刀割。他認為若不提升公司開發軟件的質素,舊客戶便會持續流失,嚴重影響公司的盈利能力。

 

他問我要招聘多少個測試員,如何測試才可以提升他公司的開發質素。

 

我相信很多軟件開發部門的管理者均會同樣的問題:

 

要招聘甚麼資歷的測試員?數目是多少?怎樣測試才能提升軟件開發的質素?

 

我認為,這問題其實是本末倒置。為甚麼?因為,以我多年的軟件開發經驗,我深信:

 

測試員只能確認,而不能提升軟件開發的質素。

 

要提升質素,必要從開發的過程入手。

 

這裡,我會不討論在開發過程中應用什麼工具、開發方法或編碼技術來提高開發的質素,這最好交給你的首席開發員去決定。我想討論的,是如何從管理中,提升開發中的質素。以下幾項是我相信在管理中,能提升軟件開發質素的要點:

 

1)開發團隊貴精不貴多

 

若你曾管理開發團隊,相信一定有過這個經驗︰


你的開發團隊不斷要求你增加人手,指團隊越大越好,越大便越能準時交貨,越能減少 bugs 的發生。因為整個項目裡,有很多地方都是「揼石仔」,不需高開發技巧,卻需花較長時間。而測試也需由専人負責,需要足夠的測試時間等等。

 

在忽略成本的情況下,人多一般都好辦事。只是在軟件開發上,道理卻未必能套用。

 

軟件開發其中一項主要的任務,便是程式編碼,而程式編碼,其實是一項藝術,你會問,程式編碼對很多人來說,明明是一種高科技的行為,為甚麼會是一種藝術呢?

 

舉例說,寫作很明顯已是一種藝術行為。試想像,寫作其實是用你所認識的語言,把個別單字以不同的組合寫出來,從而表逹你的概念。然而在不同的作者手裡,儘管意念相同,寫出來的文章,有的字字鏗鏘,有的是卻不明所以。

 

同樣,程式編碼不也是把開發語言內不同的指令,組合出來以實現此軟件的目的嗎?相同的目的,不同的開發員可以有不同的指令組合,有些編碼精簡,效能暢順,方便日後維護。但有些則邏輯紋亂,效能極低,日後也不知怎樣維護。

 

可見程式編碼,是一種藝術。而藝術品的質素,則取決於所有編碼者的平均功力,而這很大程度上是取決於所有編碼者功力最差的那位。

 

何解?以比喻來說,有人用一些長短不一的木片做了一個水桶,那麼這個水桶能裝多少水便取決於最短的那一片了。同理,在程式編碼上,緃然其他組員功力深厚,但只要有一個功力有限的組員,整個軟件將會出錯的地方,大有可能便是這名開發員所負責的那部份。

 

若開發團隊的人數眾多,不單在溝通上複雜,還會令團隊的平均功力下降,試問一件好的藝術品,是不是越多人做,質素便越好呢?

 

經驗告訴我,一個項目的開發團隊,人數在 3 至 5 間是最理想的,而且最好是項目所需要的技術都至少要有兩人懂得。例如,項目需要 MongoDB 的技術,那團隊內便不能只有一位 DBA 懂得 MongoDB 的維護,團隊內至少要有另一人,即使 MongoDB 的知識沒有那位 DBA 強,也懂得 MongoDB 基本的維護。

 

既然是 3 至 5 人,那麼他們便應該是「一個打十個,精通十八般武藝。」的精英。若你是管理者,話許會認為一個「精英」的工資往往很高,而 3 至 5 人的精英團隊,成本豈不是很高?是,但即便很高,也不會比你請一隊「庸材」,或一個「精英」帶一隊「庸材」的團隊成本高。因為一個「庸材」團隊,他們往往給你的是客戶會設訴的產品,一個不知甚麼時候才能真正完成的實際開發時間,和一些永遠都是這樣不成,那樣行不通的意見。

 

也許你會問︰這樣的「精英」存在的嗎?我怎麼能找到這樣的精英?這些問題我不打算在此討論,我只認為,這和作為管理者的你往常怎樣管理你的開發員,怎樣培養他們,與及你的人際關係及網絡等等有關。我必需指出,我所說的精英開發員不一定要是有很多年工作經驗的開發員,不要以為看完我這些理論後便不用再請那些剛畢業的大學生了。要知道程式編碼不是年資越高便越出色,年資高的開發員,可能從未接觸過最新的技術,可能來來去去也只是在維護一些恐龍時代的系統,而剛從大學畢業的,可能小學時已開始在玩編碼,畢業時便已是十項全能的高手。要發現這些高手,不能從年資方面看,要看的是他過去的項目,哪怕是學術上的項目,和他對軟件開發的熱誠。

 

2)開發任務的編排

 

這裡我不打算討論項目管理開發的方法,我只想指出一個 3 至 5 人的精英團隊應如何編排任務來確保開發質素。

 

由於開發團隊人數不多,所以要更有效地管理開發的時間,儘量減低重複的開發。所謂重複的開發,便是對同一的功能、邏輯、或界面開發完之後,因為用戶需求的轉變,或疏忽了系統其他部份的配合,而要作出對該功能、邏輯或界面的修改。我說要儘量減低,是因為在實戰中,這些修改是無可避免的。

 

減低重複的開發,除了降低開發時間外,也減低對產品質素的損害,因為每一次修改,均有產生 bugs 的風險。

 

我過去行之有效減低重複開發的方法,與時下一般開發者喜愛的敏捷開發 (Agile Development,https://en.wikipedia.org/wiki/Agile_software_development) 有些出入。敏捷開發鼓勵先開發系統最困難的部份,而我的方法則是先開發系統內日常最多使用者使用的部份,然後開發產生這界面所需的數據的輸入界面,隨後是配合這界正的其他功能,最後是系統內其他的部份,並由複雜的做起。

 

我喜歡敏捷開發,我認為這是實戰中有效的方法,不單可及時照顧用戶需求的改變,還可有效地管理開發的進度,但我不打算在這裡討論敏捷開發。我在過去的開發管理中,多數也依照敏捷開發的方法,只是先開發用戶經常使用的界面那部份。

 

敏捷開發鼓勵開發團隊每週與用戶代表演示一次,收集用戶的反饋,這點我絕對支持,只是我認為用戶在每週的演示中,未必能在剛看到的界面作出合適的反饋,更甚的是有機會由於用戶沒有用心考慮,作出一些日後會反悔的建議。

 

先開發最常用的界面,(若還沒有數據的話便可用假的數據,日後提供數據那部份開發好後,再改回用真的數據。)可使開發者和用戶在往後整個開發過程也可看到這個界面,使他們在開發的過程中有充足的時間去感受這個界面的好處與不足的地方。要批評一個界面不好的地方其實不難,但用戶往往忽略了界面好的地方,這些好的地方,往往要使用者使用這些界面一段時間後才能感受到的,不會在一次的演示便看得出。若日後提供建議或反饋時,為了補充系統不足的地方,而破壞了好的功能,這就不值了。

 

這樣,由於減低了用戶提出日後會反悔的意見的機會,於是降低了重複開發的需要。

 

3)開發團隊的每朝例會

 

系統在開發過程中最通常出錯的,便是某開發員修改了系統的一部份,本來系統的另一部份能正常運作,現在卻出現了錯誤。

 

要解決這個問題需要好的測試員,和有效的測試程序去驗證系統其他部份有沒有出錯,所以往往只修改一處小的地方,便需要整個系統重新測試,很是花時間。只是為確保開發的質素,這些時間是一定要花的。可是,若在測試時找到真的有另一地方出錯,豈不是要立刻修改?修改完成後豈不是又要再次重新測試嗎?那可是雙倍測試的時間。假若修改那另一錯處後,再次測試的結果發現是在第三處地方出錯,那豈不是很令人沮喪?

 

要縮短測試的時間,便應該從開發時入手。通常不同的開發員,會熟悉系統內不同的地方,很大機會,若開發員甲知道開發員乙在他負責的範圍作出某些修改,他(開發員甲)便會意識到這些修改會對他負責的範圍有甚麼影響而作出配合,或通知開發員乙作出配合。就算當時不知道,日後開發員甲對他的範圍作出修改時,也會留意會不會被開發員乙的開發影響,或相反的影響他的開發。

 

所以,充份的溝通對整個開發過程尤其重要,我喜歡用 Scrum 這種敏捷開發方法,它需要每天早上所有開發員有一個短暫的站立會議,(為甚麼需要這個會議,請看 https://en.wikipedia.org/wiki/Scrum_(software_development)。)這個會議對 Scrum 的好處暫且不提,每天早上透過這個會議,每位開發員都能知道其他開發員會做甚麼開發,這對開發的質素很重要。

 

管理者應該鼓勵每位開發員在這會議中簡短地描述他的開發會如何進行,(這或許會和 Scrum 的每天例會所舉行的方法不太一樣。)其他開發員若聽到所作出的改動會影響自己的開發範圍,便應主動提出。其目的是要令其他開發員知道並作出協調,但所有意見應儘量簡短,亦未必需要當時立刻下結論。

 

總之,開發團隊間充份的溝通,對避免日後其他地方出錯十分重要。

 

4)代碼審查 (Code Review)

 

人本是會經常出錯的動物,多麼出色的開發員,也總會有一時疏忽或大意的時候,這些不小心,或許會在測試員的測試過程中被找出來,代價是再修改、再測試,多花了時間。而然最大問題卻是越出色的開發員,那些「不小心」的錯誤,便越難被找出,若測試員找不到的話,日後便會由客戶轉告了。

 

要避免這些「不小心」,便要進行代碼審查了。

 

這裡所說的代碼審查,是開發員甲完成一段編程後,開發員乙去審查開發員甲的代碼,找出錯誤,有沒有漏了甚麼邏輯,甚至是審查代碼的質素。例如有沒有重覆的代碼出現在多處而不用子程序去實行;或是效能不好,或過多迴圈,從而令到程式運作過慢;或寫了重複的邏輯,而不呼叫現成的程序庫程式等。

 

管理者或許會問,開發團隊人數已是貴精不貴多,開發時間亦有限,哪有時間人手來做代碼審查呢?沒錯,代碼審查會令開發時間增加,但這些額外需要的時間,即額外需要的成本,相對於日後測試員找到錯誤,再修改和再測試的成本,甚至將來由客戶轉達過來的錯誤所帶來的成本,哪個比較重呢?

 

未曾試過代碼審查的開發團隊,也許會用種種理由反對進行代碼審查,骨子裡其實是害怕自己的代碼被別人審查。管理者應鼓勵開發員坦誠相告審查後的意見,而被審查者亦不要對審查者有惡感,務求令到各開發者明白代碼審查是提升軟件開發質素的重要一環。代碼審查不止能立刻找出連測試員也找不到的潛在錯誤,也能提升代碼的質素。

 

程式編碼是一項藝術,代碼本身是一件藝術品,代碼審查是提升這件藝術品的有效方法,使代碼日後更加容易維護,軟件運行得更加流暢。

 

還有,透過代碼審查這行為,開發者亦可以互相學習,無論是從對方錯誤中學習,或從對方出色的編碼中學習,整個開發團隊的平均功力將會不斷提升。這對公司,或對自身,均有好處。

 

以上四點,是為提高開發團隊的開發質素,從管理人處出發所能做的。除了這四點,當然還有很多其他值得管理人注意的地方,但我認為這四點是首要的。希然透過這文章,能幫到一些開發團隊的管理人,提高他管理團隊的質素。

 

management   software development  


{{ ctrl.votes | shortNumber: 0 }}
寫於 {{ '2017-07-19T08:59:34.248Z' | calendarTime }} 修改於 {{ '2017-07-19T08:59:59.292Z' | calendarTime }}

{{ $root.errMsg }}