最近同事分享參與公司其它大型軟體專案的開發經驗，她認為軟體開發過程中，專案領導者其實並不擅長管理工作：雖然所開發的系統很單純，但每次都是整個專案重新開始；就算想把之前做過的程式碼略做修改，結果卻牽一髮而動全身幾乎整個系統都會被翻修到，要做到re-use根本就是不可能的任務。同事認為管理階層應該考量如何把系統模組化，才能增加開發的效率與生產力。
同事所提的問題其實我們都很清楚，公司很多大型軟體專案都有同樣的問題，也帶來慘痛的經驗與教訓。問題不在技術上，因為大專案能夠得到公司最多的資源，所用的技術是最新的，人員也是最優秀的，而是在開發過程中沒有發揮團隊綜效，大家都很努力做了很多事，但整合時卻問題叢生，似乎永遠有解決不完的問題。
軟體專案開發團隊具有多樣化特性（部門多樣化、任務多樣化及知識多樣化）。一般人以為利用任務分工可以讓團隊以比較有生產力的方式開發軟體，但分工愈細也就意味著工作相依性變高，整合也就變得更困難。一旦整合變成專案管理的瓶頸，再如何分工都沒有辦法解決困境，所以這是分工的迷思。缺少整合的分工並無法發揮團隊綜效！既然整合不可能省略，與其事後整合還不如及早整合，減少整合的難度與複雜度，這才是軟體專案管理的致勝關鍵。
所以，要以整體專案價值來看任務，而非以片面的作業流程來看工作，重新思考團隊的合作方式，使團隊績效得到顯著的提昇。然而，分工的關鍵並不在人多好辦事，而是要防止人多手雜，所以開發團隊應先建立起一些共享件，這些共享件包括程序、元件與人員。
記得我在《軟體開發能力的自我組織》中一文曾提過的：「專案實施Inspection時，成員的設計能力及software asset變得與日俱增，而且在團隊溝通上助益也很大」，就是一種共用件的有效運用，Inspection本身就是一種增進軟體品質的一種共享程序；同時透過團隊相互觀摩的良性循環，讓有經驗的開發人員分享設計與開發技巧，而達到共享人員的目的；最終的目的其實是要慢慢地形成如William所說的軟體資產（software asset）的目標，這不正是共享元件嗎？
除了Inspection以外，再搭配團隊持續溝通與整合，實施daily build、測試驅動開發（test driven devlopement）等實務。團隊績效馬上會發現得到一加一大於二的綜效，以我目前所參與的專案執行的成果來看，這是真實而不虛的呀！
自動引用通知: 同人的生活派對 » 讓 Application Log 更容易實現
自動引用通知: 同人的生活派對 » 建立互賴的軟體開發團隊
自動引用通知: 同人的生活派對 » 你憑藉什麼知識來「做」專案呢？
自動引用通知: 軟體開發領導與管理的弔詭 « 同人的生活派對
自動引用通知: 開發者的集體智慧 « 同人的生活派對