在之前,我們談過了好幾次跟系統的規模可擴充性(scalability)的問題(<雲端上的規模可擴充性><從售票系統新聞事件談規模可擴性>),一個軟體系統是否具備規模可擴充性,關鍵並不在於程式碼在單機上運行得有多快,而是在於當你投入更多的計算資源(例如伺服器)時,能否提高服務規模。

通常,為了提高系統的規模可擴充性,系統架構要盡量避免任何形式的瓶頸,例如,盡量避免集中化的資料庫操作,如此一來,就可以降低資料庫操作成為瓶頸的機會,只要系統中沒有成為瓶頸的組成,系統就容易具備規模可擴充性。

系統如此,開發團隊也如此。系統有規模可擴充性,開發團隊也有。

一個人開發軟體的工作模式最單純,因為只要這個人開發得夠快,軟體就可以開發得夠快。這就像是一個單機運行的程式,只要這個程式執行得夠快,系統就會有效率。但是,當事情關係到多人一起組成團隊協同開發時,情況就會有所不同了。

仰賴少數程式高手的開發模式,後續規模的擴充性嚴重受限

在軟體開發的領域裡,有個特別的名詞稱為「英雄(Hero)」,代表那種寫起程式來非常厲害的頂尖高手,當然,高手除了寫程式品質可能很好之外,最重要的是寫程式的速度也很快。有很多軟體產品,甚至都是倚靠一個超級英雄,就得以發展出來,這種開發模式也被稱為英雄式的開發模式。

這種情況並不會少見,尤其現在許多新創軟體的規模,在一開始都不見得會很大,倚靠一個超級高手完成所有開發工作的情況,並非不可能。尤其對於一個首次發行的新創應用軟體來說,只要他寫得夠快、寫得夠好,並不會有什麼大問題。

但是,這樣的開發模式有什麼問題呢?

其實在我們的身邊也時常發生,故事大概是這樣上演的。當新創應用的軟體推出之後,收到市場了正面的回饋,於是決定繼續加碼在這個已經有一定基礎的應用之上,以便繼續攻佔下一個階段的灘頭堡,為此,要做的軟體的規模必須加大,此時,多半也得到了預算,得以支應開發更大規模的軟體,團隊得以擴編,面對下一個緊迫的時程,以及更大的開發範圍。

要讓「開發英雄」──或是臺灣IT鄉民口中的「大神」,繼續開發下一階段的範圍,並不是不行,但是伴隨著得到了預算(通常是資金的挹注),還有在第一階段的成功之後,對下一個階段成功的渴望,團隊通常會處於熱切於急速擴張的心理狀態,而事實上,商務上也必須如此。有道是打鐵趁熱,既然第一階段獲得了市場上的正面反應,就應該盡快乘勝追擊才是。

問題來了,若是繼續倚靠大神來開發,就算他再怎麼厲害,最多也就只能維持原有的生產力及開發速度,不可能倍增,甚至是提高到數倍的生產力,因此,當開發的範圍快速的膨脹時,是不能夠只倚靠大神來完成,而團隊也不會天真到這麼認為,既然預算及資源都有了,當然會希望投入更多的人手來擴編開發團隊。

這種情況就好像一個軟體系統,原本的服務規模不大,因此只需要倚靠一部伺服器就足以應付,但是隨著服務規模的提升,必須加入更多的伺服器,以增加計算資源,才能夠因應伴隨而來的用量。

人多不一定好辦事,於是又回到英雄主義下的開發模式

但是,就像加入更多的伺服器,不一定可以同時擴充服務規模一樣,加入更多的人,也不表示就可以增加團隊的開發能力規模,這取決於團隊本身的規模可擴充性,尤其是從英雄式開發演變而來的團隊,時常都會發生團隊規模可擴充性的問題。

原因為何?這通常是因為從英雄式開發演變而來的團隊,原先的所有開發產物都是由「大神」開發出來的,當其他的新成員加入團隊,要分攤大神原有的負擔,會需要花費一些時間來了解原有的內容,此時,若是時程比較緊迫的時候,大神可能還是一力承擔,把工作攬下,自己嘗試完成,因為他可能會有的想法是,要傳授新成員內容細節所花費的時間,可能還是比自己完成工作所需的時間多,不如就自己搞定了。

除此之外,大神可能還會有另一個想法就是,自己動手的品質比較好,他不能接受別人寫出來的程式碼架構,或品質不夠好,在力求完美的情況下,他最終還是選擇自己動手了。

於是,這些新加入的成員,往往只能負擔一些比較外圍的功能開發,至於原先的主體及核心,可能還是由大神辛苦地承擔著。

這種情況就跟一個軟體系統有了瓶頸一樣,大神就是整個團隊的瓶頸,因為他將太多的工作攬在身上,有很多的工作都非他莫屬,這些工作基於上述的原因,很難拆解出來,讓別人一起分擔。

人力集中有其好處,但也會成為擴充的障礙

就和軟體系統一樣,只要有了特定的集中化組成,就會導致這個集中化組成傾向,成為瓶頸,而瓶頸的存在,就會接著造成規模無法再擴展上去。

開發團隊也一樣,當工作的完成,都偏重在特定的成員時,這個成員就會成為開發團隊本身的瓶頸,也會同樣造成開發團隊的規模,無法真正的擴展上去,即使團隊中加入了新的成員。

當團隊中加入了新成員,卻無法讓開發的規模跟著提升時,就形同一個網站的服務,即使增加了伺服器,卻無法承載更多使用者的流量一樣,都是規模可擴充性出了問題。而且,愈是厲害的大神,常常愈傾向於成為瓶頸,正因為他解決問題的能力好,因此,工作就會傾向於被他吸走,最後才會導致太多的工作都掛在他的身上。

這樣的問題,不單是從英雄式開發成長而來的團隊中會發生,即使一開始就有多人一起協同開發的團隊,只要其中有能力比較好的開發者,這個開發者也都很容易成為工作的磁鐵,把過多的工作都吸附在自己的身上。

只要團隊中有了集中化的成員,他就容易成為瓶頸,也就造成團隊真正的開發規模無法提升。因此,永遠都要記得的是,不要讓任何一個人,成為團隊中的瓶頸,不論他能力再怎麼好,也都不應該把過多的工作交付給他。

大神可以處理最核心的工作,因為這些工作需要最高的品質,但是大神不需要是工作最沉重的,他的工作量和工作時間,最好都跟團隊中的其他成員一樣。唯有如此,工作才能夠盡可能的分散在團隊中每個成員的手上,團隊中沒有瓶頸,才能得到開發規模的可擴充性,才能夠隨著新人力的加入,而開發得更快、更多。

工作負載不均衡,效率無法最佳化

這道理其實不難,很多人都能明白,但是,最難的地方在於克服心理上的迷思和障礙。

迷思就是這工作只有大神可以做,而障礙就是為了符合一次又一次的短期里程碑,而一直不捨得把工作從大神的手上釋放出來。所以,就一次又一次地,讓工作繼續停留在大神手上,其他人的負載輕、大神的負載重,但是,多出來的人力,不能轉化成真正的生產力。

開發的規模可擴充性的意義,並不在於每個開發者可以開發得有多快,而是在於,即使團隊的開發者開發速度,都不像大神那麼快,但是,透過增加新的開發者,可以讓開發的整體生產力提高。想要得到開發的規模可擴充性,最關鍵的因素,還是要消除瓶頸的存在。

作者簡介


Advertisement

更多 iThome相關內容