軟體開發和團隊”最小模式”初探2－6人模型（下）

金剛合體和巨人肩膀

6人模式是必須的,而且請注意我這裡盡量用了”人”這個名詞而不是”角色”,為什麼?很多人認為既然是角色,就可以兼職,比如管理兼構架,構架兼需求,設計兼開發,開發兼測試. 這樣一個團隊就變成2-3人了,也能形成合理的6”角色”模式.

真的如此嗎? 但我要提醒大家的是,這6個最基本的人(或者角色),她們面臨的內容角度是不同的,她們自己互為影響和監督,輕易把任何角色集於一身是要付出一定的代價的.

更少人的團隊模式不是不能成功,軟體成功是一個複雜的概念,不一而足,但不完整的團隊絕對不能苛求更多甚至於完美; 比如: 無管理就不能苛求時間品質可控,無構架就不能苛求技術統一合理;無需求就不能苛求無返工無爭議;無設計就不能苛求軟體介面優美t統一,功能精妙易用;無編碼(這個…,基本不可能);無測試就不能苛求極高的品質和無暇的品質.

但我也深知很多團隊都處於一個“巧婦難為無米之炊”的窘境，沒有6個人，或者沒有6個合適的人，該如何去做，是否可以以更少人去開發一個軟體，關於這個問題，我原則上是不贊成的，但我會給出我的看法。

如果需要更少的人，我們一般有2個辦法。

一個人擔任2個或以上角色，這個就是“金剛合體”。

我認為，金剛合體有2個主要的原則：

1：不同性質的工作不能合體，這裡的不同性質主要是指，交流為主的工作不能和技術為主的工作混合，原因大家都應該可以理解，交流工作偏開放，需要交流和主動；而技術偏封閉，需要一個相對安靜的環境來獨立思考，這2種工作不易輕易混合。

2：利益相悖的工作不能合體，管理和其他角色，因為有相互監督的關係，不易合并，否則就是自己管理自己？ 構架和開發不易合并，構架可以參與底層的或者範例的開發，這個是沒有問題的，但如果還是項目的主力開發，承擔了大量的工作，那麼構架人員就難免為了減輕工作壓力而降低構架的水準。

管理和其他角色不利於輕易混合，管理以交流協調為第一要務,而技術工作需要時間和空間,管理和其他角色必然相互影響,導致事倍功半. 所以我建議管理必須獨立存在.

構架是純技術角色,它需帶有交流屬性的需求和設計會相互影響,而開發呢,構架進行部分開發還是可行的,但要注意,首先構架人員其能力和主攻方向必然是不斷提高項目的構架水平,除非項目的構架已經十分的穩固,犧牲構架的大量時間去開發是得不償失的,況且在有可替代資源的前提下,讓構架這樣的進階資源去做普通資源的工作,無論對進階資源的心理感受和普通資源的培養這些角度來說,都是相當的不利.我的建議是,構架可以作為一個主程的身份參與部分編程,比如通用類或者底層代碼,但必須嚴格控制工作量,嚴禁涉及大量的具體開發工作單位.而需求設計和構架不宜合并.

需求由於也具有交流特性，如果和構架，開發結合必然會影響其工作效果. 但需求的交流又和管理不同,需求是交流商務邏輯,而管理是資訊疏通,人際關係為主,另外需求還是有一半技術分析的部分,這個和管理又是相互影響的.另外需求和設計開發具有互斥性,如果需求來做設計和開發,一則會使需求人員過早陷入細節,而降低他對整體業務的把握;二則設計和開發的困難會反作用與需求,迫使需求讓步與設計和開發中的困難. 我的建議是需求要儘可能的獨立存在.他可以服務於多重專案,但不要在一個項目裡面身兼他職.

設計本身也具備交流的需要，前面說了,設計工作不利於和需求合并,所以很多時候這個接力棒就會交給開發,但很多開發不願意交流而寧可靠自己的想象去設計，這就是技術工作影響交流工作的一個範例. 而如果迫使開發人員出設計文檔又變成自編自導,加上時間壓力,開發人員的設計常常是倉促了事,但一點必須明確,設計即使被合并了也並沒有消亡,只是這個設計被開發人員隱藏了起來,變的不可控制,不可積累.這個不但造成了當前項目的隱患,對團隊日後的不斷提高也設定了障礙.我的建議是在人力資源允許的情況下,分開開發和設計,讓略強的開發去做設計而不要實際動手,然後讓他們去評審開發的工作是否合理.

測試,一般的合并方式就是有開發代勞了,這個我是不太認同的.完美的代碼也需要測試，因為測試的角度是需求審核者,他的責任是確認在經過了設計和開發以後，需求有沒有丟失；那麼需求以後的設計和開發就不適宜帶著自己的理解來審核自己的工作，所以他們不適宜做測試;但需求者是可以測試的,但很遺憾的是,一般需求者不會願意幹這個髒活累活,另外技能也需要重新學習.我的建議是,要麼需求者來測試,要麼就獨立存在.

 

除了金剛合體,另外一個可以減少角色或者其壓力的方法是”巨人肩膀”.

巨人肩膀來自於2個方面:

l  公司積累

l  業界標準

由於軟體項目的獨特性,管理,需求,開發與測試由於和實際項目的獨特需求有關,即使存在可供使用的標準,也只能作為工作的指南,而不能成為工作結果本身.比如已經達到CMMI3水平的團隊也不可能去除管理,因為每個項目的管理內容不同,遇到的情況也不同;

我認為,能夠利用巨人肩膀的是構架和設計.在一個特定的軟體領域,如果公司已經形成的相當的積累,或者說業界已經有了相當成熟的標準,那麼構架和設計大可不必親力親為,而可以穩穩的站到巨人的肩膀之上.如一個成熟的遊戲公司,其開發一個新遊戲的構架基本可以沿用以前的構架,另外一個網站的設計背景構架,完全可以沿用業界已經成熟的方案.

那麼,如果有了巨人的肩膀,是否就可以省略構架人員和設計人員了嗎,我的答案還是否定的.

首先,公司的積累絕對不是無中生有,它就來自於公司每個項目中的構架和設計人員的點滴汗水,公司的積累和構架設計人員的存在本身就是一個悖論,因為有了他們的存在,公司才得以積累下一些財富,而財富的不斷增加才使得他們的壓力得以解放,反而言之,一個從開始就不重視構架和開發人員的團隊,根本無從積累,所謂的”公司積累”這個巨人只是鏡花水月.

那麼”業界標準”呢,拿來主義能不能代替自己的構架設計人員,我認為也是欠妥的.牛頓的”巨人肩膀”之說其實只是一個謙詞,牛頓本身就是巨人,在登上巨人肩膀以前,你自身必須能夠爬上巨人的手臂.業界的標準模式,構架體系只是熟菜而已,它們比生菜是有所進步,但還是需要消化以後才能進入團隊,成為團隊適用的財富,而這個消化人就是我們的構架和設計人員.

總之,我認可”巨人肩膀”的存在,如果運用恰當,的確可以大大減少構架和設計人員的壓力,但我認為,巨人肩膀的存在不是對構架設計人員的否定,相反,優秀的構架和設計人員才是巨人肩膀的前提, 當一個團隊得以踏上巨人肩膀的時候,恰恰是構架設計人員辛勤耕耘得以回報的時候.

簡易團隊構建指南

第一步:尋找領航者.

在團隊中尋找一個管理者，並賦予他一定的權力，我對這個管理者的建議是：

1. 具有一定的交流能力，不能是“純技術人員”（大家懂的）
2. 如果沒有管理技能要進行一定的專案管理培訓，磨刀不誤砍柴工。
3. 開發技能不能空白（這個與我的理論稍微矛盾，但我認為小團隊的領導開發技能不能完全空白，而且一般的團隊裡面選拔出來的管理者也不可能空白）
4. 有一定的資曆和威信。
5. 最重要的一點：儘可能的分離他的非管理工作，讓他去管理！

 

第二步:確定技術制高點

我們搞技術的，大家心裡都有一杆秤，誰更厲害點，一目瞭然。所以尋找團隊技術高點不是問題。問題是要把這個技術高點搞成構架人員才有困難。我對構架人員的建議是：

1. 必須是團隊技術最高者（除非有嚴重性格問題）
2. 大家可以對構架集思廣益，但構架者才是決策人，他是技術的領導。
3. 盡量減少其具體開發，讓他可以思考，總結和寫文檔。如果有更多的人手，讓他去教別人，審核別人，不要讓他做。（在次級人員水平差距太大的情況下，他可以寫通用和後台代碼）
4. 鼓勵他儘可能總結，思考，寫文檔，培訓，審核，而不是具體開發。

 

第三步:需求分析師

         選拔對客戶交流有特長，同時也是團隊裡面的技術骨乾的人來做需求，最好有5年以上的經驗，不要拿新人去做需求。

1. 願意並且也有和客戶交流的特長。
2. 技術能力不弱，能理解構架者的技術選擇。
3. 擅長需求開發方法和工具（比如UML）。
4. 盡量不參與具體的設計和開發，保持其需求全域感。

 

第四步:進階開發來設計

         設計一般來自比較進階的開發，但比較糾結的是開發往往不夠，但這不應該是理由，因為即使沒有設計，所有的開發也必須自行設計，所以抽出1－2個開發做設計是磨刀不誤砍柴工。完整明確的設計可以省下開發一半的考慮時間。

我的建議是：

1：開發中的高手，對系統設計有合理的認識。

2：能在美工的協助下做原型

3：一個設計可以對2個開發，設計規範成熟的團隊可以對3－4個。

4：設計可以審核開發的代碼，並引導他們理解自己的設計。

 

第五步:培養我們的開發

前面的文章我已經說了一個大概的思路。

1. 通過一定的編碼規則磨練其自律性。尤其是注釋。
2. 不斷自檢：Code Review 和單元測試。

 

第六步:加入最後的防線

儘可能的加入測試人員，來協助開發人員。我的建議是：

1. 測試開發比例，1：1達不到，就1：2或者1：3，再少就壓力太大了。
2. 培訓基礎的測試技能。

 

 

6人模式還僅僅是起步

        CMMI3的最底限度團隊是20人,6人團隊僅僅是吊絲們沒錢又想過上好日子的一點自我掙紮;別人是針對千萬級項目的,而我們僅僅是拿來做10萬級項目.

         那麼我們就說CMMI2吧,CMMI2已經要求完成組態管理,需求管理和QA的監督,6人團隊誰來做,有人會說,不是有專案管理可以做配置,需求分析可以做需求管理,測試可以QA嗎; 我只能苦笑. “又要馬兒跑,又要馬兒不吃草”,這已經是一個笑話了,現在還要馬兒能飛,是不是想締造一個神話呢? 我的看法,還不如先讓馬兒跑起來看看吧,至少還是在跑了. 所以說6人模式,也就一個CMMI 1.5 的水平,再上去不過是自欺欺人而已;但我覺得無需氣餒; 我所知道的是: 6人模式已經可以讓團隊初窺門徑,登堂入室,讓團隊中的每個人都能夠慢慢的思考,細細的品位,一個真正健康的軟體團隊應該需要什麼,如何去做,自己的職業生涯方向何在,為團隊和個人的進一步發展,開啟一扇天窗,做到了這一步,已經是非常了不起的進步了.

最後說一個題外話，一個團隊的長期穩定的健康發展最終還是取決於2點：

l  團隊的自我發展和積累

l  個人的上升通道

         我提出的6人模型也考慮了這2點，為團隊的未來未雨綢繆：團隊的積累來自與每個分工明確的角色對自身獨特技能的不斷鑽研，並在實際工作過程中的不斷總結，一個分工明確，空間充足的模型，為每個角色上的人提供了獨立思考的機會，他們經驗的匯聚，形成了團隊的自我發展和積累。另外，開發－設計－需求－構架－管理，正是一個開發必經的發展之路，只有腳踏實地，步步為營，才能在自己的職業生涯中走出一個個堅實的腳印。

最後，我還有點夢想，我夢想我們的軟體人能夠突破環境和條件的約束，以自身的遠大理想為基礎，加上對軟體開發的無限熱情，勇敢的去開拓自己和公司應該去走的道路，絕不能渾渾噩噩，得過且過和固步自封，不管以什麼樣的模式，都必須去尋找軟體開發的真諦。

 

註：以上不是結束語，後面的章節，我還會對我現在正在實踐的流程做一些方面的展開，把6人模型推向實用化。