敏捷開發“鬆結對編程”實踐之一:人員結構篇(大型研發團隊,學習型團隊,139團隊,師徒制度)

轉自http://blog.csdn.net/cheny_com/article/details/6581517


本文是“鬆結對編程”系列的第一篇。(之一之二之三之四之五之六之七之八,此係列之九及之後文章請見欄目總目錄。)

傳說中的結對編程,大致結構是兩個人共用一臺電腦,一個開發,一個測試,以隨時評審來抵消返工時間損失。

傳說歸傳說,誰也沒有見過。問題出在哪裏?有兩種主要原因。

一是來自高層的,高層感覺兩個人只有一個人幹活,實在是有點浪費。“評審抵消返工時間”虛無縹緲,但每天只有一個人幹活卻是現實情況。

二是來自基層的,兩人若有高低,高手肯定覺得還不如我一個人乾的快;兩人若旗鼓相當,難免產生爭執。

其實在我們身邊一直有一種方法很像結對編程:“師徒制度”,就是每個新人來到公司,都指派一個師傅帶着,在技術與業務方面提供指導。他們既不用一臺電腦,也不是老死不相往來,這其實就是一種“鬆散”的結對編程。只不過多數企業雖然有這種制度或實踐,但卻很少有很清晰的定義,難免限制了這種實踐的效果。本系列的目標,就是從人員結構、計劃實踐、日常工作實踐、績效考覈等各個角度,來完整地思考和建立這種制度。

-------------------------------------------

挑選小組長(師傅)基本原則

樂於助人,有責任心,善於溝通,擅長管理,技術精湛,業務精通……很可惜,好詞彙越多,越難找到符合的人。不過,一些基本原則還是要考慮的:

1. 儘量找對業務有興趣的人

整體上偏業務的人未來有更好的發展(這是我2001年的上司的原話,事實證明很對),由於有行業壁壘也較少跳槽。由於小組長角色未來將被提拔爲更高的項目經理、產品經理,對業務的瞭解也會爲此做好鋪墊。

2. 儘量找善於溝通的人

善於溝通的程序員成長更快(還是那位上司的原話),也更能幫助別人成長。

挑選組員(徒弟)基本原則

1. 徒弟能力一定要低於師傅(應該說:師傅一定要高於徒弟)

很常見的一種做法是把幾個水平相當的人放在一起工作,認爲這樣他們可以互相學習,其實不然。

之前我們在的項目組經常發生技術“爭論”,發生的次數多了,我們發現一個規律:每次爭執不下的,都是兩個技術相當的人,而每次爭執的解決,都是一個水平更高的人給出一個截斷衆流的方案,然後大家散去。

2. 徒弟年齡不要太大

如果有兩個水平相當、月薪要求都是6000的程序員,當然找年輕的了,有發展潛力,後勁足。

挑選組長(大項目經理)基本原則

1. 項目經理必須喜歡業務勝過技術

項目經理是掌舵的而不是幹活的,因此必須對業務有深刻理解。

2. 項目經理最好精通技術

這裏不討論是否存在“不懂技術卻精通管理”的項目經理,但是如果目標是項目成功而非證明奇蹟的確存在,項目經理應該首選那些從小組長成長起來的既懂業務技術又精湛的人選。

這裏的“精通技術”不是從技術實現層面考慮的,而是從“技術想象力”層面考慮的,就是說他必須能想象到有某種技術存在。比如以前我們遇到一個程序員寫了一大堆重複代碼,原因就在於他的想象力受到了侷限,明明有虛函數、模板等各種方法來簡化代碼,卻沒有想到。“沒有學到”是無法避免的現實情況,但“沒有想到”是可以避免的。

團隊結構和運行理念

既然待在某個“位置”上,每個人必有不同的職責。這裏就不一一列出了,因爲猜都猜得出來(比如師傅要帶徒弟之類)。下面只列出鬆結對編程與一般小組的核心差異。

1. 對每個小組(師傅+1~3個徒弟)整體考覈

也就是師傅要負責到底,不能出現“他剛來所以把事情辦砸了”的情況。這裏的負責到底,包括計劃、估算、跟進、進度、質量、徒弟成長……等一干事情,本系列的其他文章中都將展開描述。

2. 在工作中學習

儘管“鬆”,但還是“結對編程”,學習和指導過程實在生產過程中集成的,因此師徒關係的成敗不只是人員成長,還包括任務和項目的成敗。這首先是一個生產團隊,其次纔是學習團隊。

------------------------------------------------

人員挑選好了,接下來就是要進行計劃、跟蹤等日常工作,請參考本系列的其他文章。

由於這是本系列的第一篇文章,請關注本博客blog.csdn.net/cheny_com。

 

點擊下載免費的敏捷開發教材:《火星人敏捷開發手冊

發佈了33 篇原創文章 · 獲贊 38 · 訪問量 26萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章