開發的規模可擴充性

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

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

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

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

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

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

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

但是，這樣的開發模式有什麼問題呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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