軟體開發週期—-如何提高軟體開發品質

昨天到新公司上班整101天，下午下班的時候開了一次部門會議。晚上回家思考軟體開發的團隊管理與過程式控制制，一些想法拿出來與大家分享，不妥之處，接受板磚............

作為一個軟體公司或相關機構，要盈利就必須在軟體開發方面提高品質，但如何提高品質，個人感覺很多公司還存在一個錯誤的概念----在規定的時間內做出符合客戶要求的系統為標準。的確，此觀點限制了很多公司與個人在技術發展的道路上走的更遠，進而把團隊與公司管理帶入了一個死胡同。並且隨著時間的推移，此邏輯會逐漸的在公司管理層面造成一種死結的局面----高層對底層的工作表現不滿意，而底層對高層的管理方式也怨聲載道。

軟體開發工作本身需要一個周期，而周期的內部則包含了很多因素，一個因素的不穩定在周期推移的過程中很可能會造成類似生物學領域的蝴蝶效應----非洲的一隻蝴蝶扇動翅膀造成美洲大陸的一場龍捲風。而當我們發現效應存在的同時，則已為時已晚，再去控制難度會直線上升，從而形成拆東牆補西牆的惡性局面，進而提高公司業務運作、團隊管理的時間、人力等各個方面的成本。

如何管理一個團隊？如何提高團隊的工作效率？如何保證待開發系統按部就班的度過開發週期的每個階段？如何........很多現實的問題擺在每個Team Dev成員的面前。本文就我們在開發週期內經常碰到的令人不解的一些問題就個人經驗談談自己的看法。

基本思路如下：
1、團隊的技能如何提高
2、如何提高團隊的協作能力
3、團隊行為的必要性
4、開發過程式控制制的幾個重要因素
5、我們的團隊是否可以應對大系統
6、如何提高系統的靈活性---即如何增強系統的可維護性、可擴充性
7、團隊成員的性格特徵是什麼

下面就這7個問題，分別談下自己的觀點。

一、團隊的技能如何提高

作為一個公司，要成立軟體部門，首要的問題就是從各種渠道招募人員。在招募人員結束後，一個基本的團隊的架構就形成了。但有人未必可以辦成事情，人僅僅是組成團隊的一個必要因素。要形成嚴格意義上的團隊，除了有人外，還有一個必要因素就是團隊中的成員必須具備一些基礎技能以及公司發展需要團隊成員具備的一些技能。

每個團隊成員的個人經曆不盡相同，對各種技能的掌握和理解廣度與深度也不盡相同。所以，即使一個團隊中的所有成員都具備了基本的軟體開發技能，但面對公司的項目要求，臨時抱佛腳的去研究學習的確可以解決時間成本上升的問題，但項目內容千差萬別，客戶需求千奇百怪，僅僅通過項目調研前後階段的短時間攻克周期去克服項目需求帶來的技術難題在某種程度上是對團隊發展與管理的一種幹擾因素。對於這種情況，個人結合自身的些許經驗，總結如下幾點。通過這幾點，可以逐步緩解項目需求對團隊技能形成的障礙，並逐步調解痛點攻克與團隊技能管理之間的時間、管理衝突：

1、瞭解每個團隊成員的性格。

所謂用其人，知其性。成員是資源，不是工具。要充分地發掘資源的能量，就必須瞭解每個成員的性格，瞭解每個成員的反應力、理解力、理解問題的方式等等與掌握技能相關的一些能力因素甚至還需要瞭解成員的性格----好靜還是好動。

或許有的人會說：有必要嗎？就我的個人經驗來說，答案是非常有必要。因為只有當我們瞭解了這些因素以後，才可能在日常團隊技能管理控制的過程中充分地發揮每個人的個人能力，從而避免導致把錯誤的人放在錯誤的工作目標上，避免對未來開發造成的負面影響。

而且，但就團隊管理者個人來說，通過多瞭解下屬成員的技能掌握能力相關因素，對自身也可以起到在瞭解過程中去粗取精的目的，並在團隊技能管理控制的過程中逐步篩選一些優秀技能，逐步擴充到整個團隊中。

2、瞭解公司的發展定位。

任何一個軟體公司都不太可能將自己的業務乏味囊括到所有的行業，勢必有自己的行業針對性。所以作為公司決策方向與內部開發能力之間的協調人這樣一個角色，有必要隨時瞭解公司的軟體開發行業定位。通過公司業務的行業定位，進而可以逐步擷取對應行業系統開發過程中會使用到的一些技術，最後未雨綢繆。

3、在團隊內部營造一種交流的氛圍。

俗話說的好：三人行必有我師。任何人的能力都是有限的，即使有的人能力無限但我想其個人的精力也是有限的。如果把能力比喻作吹到氣球裡的空氣，那麼精力就是這個氣球了----精力束縛著能力無限制的擴充。所以，最為一個團隊，為了保障整體團隊開發勢力平均層面穩步提升，需要在團隊內部形成一種交流的氣氛。

環境造就人。有些技術點並不是開發人員掌握不了得，只不過是因為自身長期所處的環境讓開發人員無法去接觸這些技術，所以“不敢輕易地和陌生人說話”。而當團隊中的每個成員都善於與人交流，提出自己的疑惑，說出自己的見解，相互取長補短，形成一種良性的競爭環境，對於團隊中每個成員的個人技能的提升都有很大的協助。而且在日常的定期與不定期形式的交流中，交流本身也潛移默化地讓團隊中的每個成員都相互磨合著----磨合著思維習慣，例如看問題的方式、解決問題的途徑等等。

所以，通過上面的三個途徑，作為團隊管理人員，在瞭解了每個成員性格的基礎上，自然而然的知道了什麼樣的成員適合做什麼難度層級的開發，同時通過瞭解公司業務方向的行業定位，知道了團隊在未來應該掌握哪些技術，再輔助逐步強化的交流氛圍，在交流中對不同性格特徵的成員側重不同針對性技術的不同廣度和深度探討交流，即可以逐步提高團隊整體的技能以及相關的管理水平。

二、如何提高團隊的協作能力

團隊中每個成員的技能提高意味著團隊有了戰鬥的基本能力。但現在的軟體開發早已告別了90年代個人英雄主義的時代，很難出現一個人寫最佳化大師，一個寫FoxMail的情況，取而代之的是協作式的開發。因為隨著軟體系統的規模增大，個人能力與作坊式開發已經完全抵禦不了規模化開發系統對風險與後期成本的管理控制要求。所以團隊成員整體技能的提高僅僅是組建有效團隊的第一步，接下來的事情就是要提高團隊內部成員之間的協作能力。

但如何提高團隊成員之間的協作能力呢？我想任何有過團隊管理經驗的朋友都在自己的工作中時刻審問著自己這個問題。下面是我的一些經驗：

1、交流可以契合團隊成員間的協作能力。

上述已經提及，不再贅述。

2、保持團隊成員的交流能力始終在一個穩定水平。

每個人有每個人的性格因素，有些團隊成員本身就是不善於交流的，對於這樣的團隊成員，應當盡量讓其明白交流的重要性----對技術團隊，對個人技能發展。但面對始終不融合的情況，從管理層面和整體發展層面考慮則只能採取要不放棄、要不弱化其重要性的方式來保障團隊成員交流能力的穩定水平。

有的人可能會說：這不成了只要馬屁精，不要老實人的情況了嗎？的確是會形成這種錯誤的直覺。但實際情況並非如此。作為團隊的發展，人品老實和固步自封是兩個完全不同的概念，前者一般會積極配合團隊的交流氛圍，努力朝著既定團隊技能發展方向前進。而後者多是以現有技能為滿足，拘泥於現狀。不懂發展就意味著是對發展型團隊的一個阻礙，同時此阻礙往往表現為團隊內部良性競爭環境受到阻礙或遭到破壞，因為部分技能在團隊內部、公司內部被私人化，造成了公司開發風險的提升。

作為一個團隊的成員選擇標準，我個人經驗與認識是：寧願吸收一個反應慢，技能有待提高但知道如何配合團隊發展的成員，也不要去吸收一個技能高但不懂配合不懂交流的成員。順便說一句，莫要理解成招聘人的80%原則！:)

所以，交流不單可以提高團隊的整體技能，同時對團隊的內部分工協作也起了至關重要的作用。作為專案管理人員或者團隊管理人員，不要自恃清高，在內部管理的時候應該多以志同道合的心態去主動交流。但要分清與進度管理的區別。而作為團隊成員，則更應該勇於發表自己的言論。當你通過交流發現你錯誤的同時，也意味著你離正確不遠了。

三、團隊行為的必要性

喜歡足球的朋友都知道90年代後期的巴西國家隊有個叫德.尼爾森的球員，技能超群----球擺在你面前，只要他的兩條腿來回的在球前晃幾晃，你可能就不知道球跑哪裡去了！當然說得有點誇張，但也不盡其然。提到這個世界級球星的目的不為別的，只為了說明即使巴西國家隊擁有如此一個技藝超群的球員，但巴西隊在世界盃的比賽中也未必就可以嘗嘗全勝戰績地舉起大力神杯。可見，個人行為與團隊性格也是兩個截然不同的概念。

軟體開發也是如此。一個人的能力只代表對如果存在的團隊交流有了一個契機----引入新技能、瞭解新思想的契機。但如果沒有團隊交流，個人的技能的價值就會打很大的折扣甚至在團隊的範圍內徹底失去其作用。

所以，作為一個團隊，不應該過分的強調個人的技能，因為個人技能是為團隊服務的。一個健康發展的團隊，首先看的是團隊行為，而也只有良好的團隊行為才可以應對軟體公司中規模越變越大的待開發系統的開發要求。

團隊行為的主要包含3個方面：
1、意識方面：團隊意識高於個人意識。團隊中良好的協作意識，管理意識應當被擴大化。
2、個人素質方面：團隊素質高於個人素質，同理好的東西要在團隊範圍內擴充。
3、技術思路方面：團隊中優秀的技術思路也應得到及時的普及。

四、開發過程式控制制的幾個重要因素

一個團隊在沒有整體團隊技能，沒有整體團隊協作能力以及沒有整體團隊行為意識之前不能算做一個真正的團隊，更確切的說僅僅是一個離散的人群。當這個離散的人群具備了團隊技能、協作能力以及行為意識後，這個團隊才完全具備開發規模系統的能力。所以，團隊管理重在儘快地讓團隊掌握整體技能，整體協作能力以及整體團隊行為意識三個方面。團隊管理的目標是要為過程式控制製做鋪墊。一旦過程式控制制開始，則需要嚴格按照過程式控制制規則來進行監督與管理。下面就自身在過程式控制制中認識的幾點體會提及一下：

1、開發過程重要的是人，而不是工具。

工具永遠都是工具，工具和人最大的區別就是工具沒有主動思維的能力。而現在很多的團隊重視的著眼點都在工具的選擇上。實際很多的團隊在選擇工具的時候的標準就是所謂的大流。選擇要有依有據，即使“我們團隊的人只會這個工具！有什麼辦法.....”這麼簡單的理由也是一個很充分的理由。所以，主流未必正確，且自己的選擇要很充分，否則容易被誤導，浪費不必要的時間和人力去做所謂的選擇。

建模未必就一定要用ROSE，如果你只會PD，完全也可以。天下沒有哪條法律規定開發必須要使用正向工程，也沒有哪條法律規定模式必須在代碼中體現到百分之幾。所以，一切的選擇在開發人員自己手中，合適的就是應該選擇的。其實目前業界流行的敏捷（XP、TDD等）其核心思想都是在告訴大家合適即可，全面未必就是最好的。

2、問題快速解決或確認的最佳方式是交流。