軟件團(tuán)隊和開發(fā)流程

　　非團(tuán)隊和團(tuán)隊

　　在講團(tuán)隊之前, 我們要講什么是“非團(tuán)隊”。王屋村里經(jīng)常發(fā)生這樣的一幕:

　　王屋村的大智要把一堆磚頭從村頭搬到村尾。 他到頂球酒吧前, 看到前面三三兩兩地蹲著一些人, 有些人前面放著一塊從包裝箱扯下來的紙板, 上面寫著“Java, 五毛一行”；“網(wǎng)頁前端, 不酷不要錢”；“專做PS，擅長人體”；“通吃SQL, NoSQL”等等。

[[45726]]

(來源: 論壇)

　　大智沖這些人喊了一嗓子: 搬磚的有沒有? 一百塊磚一毛錢!

　　地上蹲著的一些人抬頭看了看, 有一兩個人慢慢站起來了。

　　大智看了看人數(shù), 又喊了一聲: 中午有盒飯!

　　這時七八個人都站起來了, 拍拍屁股就湊到大智面前。大智就帶著他們走了。

　　這七八個人是團(tuán)隊（team）么? 不是，他們只是一群烏合之眾，臨時聚集在一起，各自完成任務(wù)就領(lǐng)錢走人(work group)。

　　下面是一些團(tuán)隊的例子:

[[45727]]

[[45728]]

可以看出, 這些團(tuán)隊有共同的特點:

　　1. 團(tuán)隊有一致的集體目標(biāo), 團(tuán)隊要一起完成這目標(biāo)。

　　一個團(tuán)隊的成員不一定要同時工作, 例如接力賽跑,

　?。ㄍ跷荽灏岽u的“非團(tuán)隊” 成員則不然, 每個人想搬多少就搬多少, 不想干了就結(jié)算工錢走人）

　　2. 團(tuán)隊成員有各自的分工, 互相依賴合作, 共同完成任務(wù)

　　（王屋村搬磚的“非團(tuán)隊” 成員則是各自行動, 自行獨立把任務(wù)完成，有人不辭而別, 對其他的搬磚人無實質(zhì)影響）

　　回過頭想想學(xué)生在小學(xué)中學(xué)的學(xué)習(xí)過程, 雖然大家在一個班集體, 但是大部分工作都是以“非團(tuán)隊”的形式完成的。 大家津津樂道的“團(tuán)隊精神”，“集體主義” 得到了多少鍛煉？

　　軟件團(tuán)隊的形式

　　軟件團(tuán)隊有各種形式, 適用于不同的人員和需求。第一感好用的形式未必是最適合的。例如幼兒園大班小朋友的剛開始踢足球的時候, 大家都一窩蜂地去搶球, 球在哪里, 一堆人就跟到哪里, 這是一個好的團(tuán)隊形式么?

　　要把一這群小朋友培養(yǎng)成一個團(tuán)隊（如下）, 需要時間:

　　體育團(tuán)隊從一窩蜂搶球演變到有明確的分工, 陣型, 戰(zhàn)術(shù)的團(tuán)隊需要時間。 類似地, 軟件團(tuán)隊的形式, 最初是混沌的一窩蜂形式: 一群人開始寫代碼, 希望能寫好好軟件。隨著團(tuán)隊的成熟和壞境的變化, 團(tuán)隊模式會演變成下面的幾種形式之一:

　　一窩蜂模式 (chaos team):

　　不能否認(rèn)，這樣的團(tuán)隊也有, 只不過他們在這樣的模式下存活的時間一般都不長, 沒有機(jī)會讓別人很好地觀察。

　　主治醫(yī)師模式: (Chief-Programmer Team, surgical team)

　　就像在手術(shù)臺上那樣, 有一個主刀醫(yī)師, 其他人(麻醉, 護(hù)士, 器械) 各司其職, 為主刀醫(yī)師服務(wù)。

　　也有首席程序員 (Chief-programmer)，他/她處理主要模塊的設(shè)計和編碼, 其他成員從各種角度支持他的工作 (backup programmer, admin, tool-smith, language lawyer, specialist)。Frederic Brooks Jr. 在設(shè)計IBM System 360 的時候就是采用這種模式。

　　主治醫(yī)師模式的退化: 在一些學(xué)校里, 軟件工程的團(tuán)隊模式往往退化為“一個學(xué)生干活, 其余學(xué)生跟著打醬油”

　　明星模式(Super-star model):

　　主治醫(yī)師模式運用到極點, 可以蛻化為明星模式, 在這里明星的光芒蓋過了團(tuán)隊其他人, 前一陣子喧囂一時的“翔之隊”就是一個例子。明星也是人, 也會受傷, 犯錯誤, 如何讓團(tuán)隊的利益最大化, 而不是明星的利益最大化? 如何讓團(tuán)隊的價值在明星隕落之后仍然保持? 這是這個模式要解決的問題。

　　社區(qū)模式(Community Model):

　　社區(qū)由很多志愿者參與, 每個人參與自己感興趣的項目, 貢獻(xiàn)力量, 大部分人不拿報酬。這種模式的好處是“眾人拾柴火焰高”，但是如果大家都只來烤火, 不去拾柴；或者撿到的柴火質(zhì)量太差, 最后火也熄滅了。 “社區(qū)” 并不意味著“隨意”, 一些成功的社區(qū)項目（例如開發(fā)和維護(hù)Linux 操作系統(tǒng)的社區(qū)）都有很嚴(yán)格的代碼復(fù)審和簽入的質(zhì)量控制。

　　業(yè)余劇團(tuán)模式(Amateur Theater Team):

　　這樣的團(tuán)隊在每一個項目（劇目）中, 不同的人會挑選不同的角色。在下一個劇目中, 這些人也許會換一個完全不同的角色類型。各人在團(tuán)隊中聽從一個中央指揮（導(dǎo)演）的指導(dǎo)和安排。在學(xué)生實踐項目或培訓(xùn)項目中, 這樣的事情經(jīng)常發(fā)生。

　　秘密團(tuán)隊(skunk work team):

　　一些軟件項目在秘密狀態(tài)下進(jìn)行, 別人不知道他們具體在做什么。Apple 公司在研發(fā)Macintosh 之后的系統(tǒng)時, 就有兩三個團(tuán)隊在不同時期進(jìn)入秘密狀態(tài)開發(fā)?，F(xiàn)在一些創(chuàng)業(yè)團(tuán)隊也是處于類似狀態(tài)。 這種模式的好處是: 團(tuán)隊內(nèi)部有極大的自由, 沒有外界的干擾(不用每周給別人介紹進(jìn)展, 聽領(lǐng)導(dǎo)的最新指示)，團(tuán)隊成員有極大的投入。

　　特工(SWAT) 團(tuán)隊:

　　就像電影電視中的特工組《加里森敢死隊》等等影片一樣，軟件行業(yè)的一些團(tuán)隊由一些有特殊技能的專業(yè)人士組成，負(fù)責(zé)解決一些棘手而有緊迫性的問題。例如2000 年之前很多公司都需要專業(yè)人士去解決Y2K 問題。這些團(tuán)隊成員必須了解傳統(tǒng)語言和老式系統(tǒng), 才能勝任這樣的任務(wù)?，F(xiàn)在還有一些團(tuán)隊專門做網(wǎng)站安全性服務(wù)。

　　交響樂團(tuán)模式(Orchestra):

　　大家看過交響樂團(tuán)的演奏。我覺得有下面一些特點:

　　· 家伙多, 門類齊全。

　　· 各司其職, 各自有專門場地，演奏期間無聊天走動隨意交流等現(xiàn)象。

　　· 演奏都靠譜, 同時看指揮的。

　　· 演奏的都是練習(xí)過多次的曲目, 重在執(zhí)行。

(來源hudong)

　　爵士樂模式(Jazz Band):

　　我自己沒看過很多爵士樂演奏, 唯一聽得比較多的是Miles Davis的一些曲子。下面是一個視頻, 曲子名字叫《So What》

[[45729]]

由于我是外行, 從外行看熱鬧的角度, 我看到的特點是:

　　· 不靠譜. 他們演奏時都沒有譜子

　　· 沒有現(xiàn)場指揮，平時有arranger 起到協(xié)調(diào)和指導(dǎo)作用（和Miles Davis 合作的arranger Gil Evans 也是很有造詣的音樂家）.

　　· 也有模式, Miles （姑且稱之為架構(gòu)師）先吹出主題, 然后他走到一旁抽煙去了, 其余人員根據(jù)這個主題各自即興發(fā)揮；最后Miles加入, 回應(yīng)主題, 像是對曲子的總結(jié)。

　　評論家歸納Miles Davis 的特點是:

　　individual expression, emphatic interaction, and creative response to shifting contents[link]

　　(翻譯) 強(qiáng)調(diào)個性化的表達(dá)，強(qiáng)有力的互動, 對變化的內(nèi)容有創(chuàng)意的回應(yīng)

　　這聽起來和“敏捷的開發(fā)模式” 有點類似。

　　這樣的團(tuán)隊模式和上面的“交響樂團(tuán)模式”有很有意思的對立, 但是兩種模式都產(chǎn)生了很受歡迎的音樂作品，因此不能簡單地說哪個一定好，哪個一定不好。

　　功能團(tuán)隊模式(feature team):

　　很多軟件公司的團(tuán)隊最后都演變成功能團(tuán)隊, 簡而言之, 就是具備不同能力的同事平等協(xié)作, 共同完成一個功能:

　　在這個功能完成之后, 這些人又重新組織, 和別的角色一起去完成下一個功能。他們之間沒有管理和被管理的關(guān)系.

　　大型軟件公司里的不少團(tuán)隊都是采用這種模式。

　　還有一個團(tuán)隊模式可以叫-

　　官僚模式(bureaucratic model)

　　下面的模式用來表示一個機(jī)構(gòu)的組織架構(gòu)是沒問題的, 但是把這種架構(gòu)搬到軟件開發(fā)中, 則會出問題。因為成員之間不光有技術(shù)方面的合作和領(lǐng)導(dǎo), 同時還混進(jìn)了組織上的領(lǐng)導(dǎo)和被領(lǐng)導(dǎo)關(guān)系?？缃M織的合作變得比較困難，因為有各自老板在各自頭頂上。

　　這種模式如果應(yīng)用不好, 最后會變成“老板驅(qū)動” 的開發(fā)流程, 見后。

軟件團(tuán)隊成員的投入

　　可以參見“豬, 雞和鸚鵡的故事” 一文:

　　如何衡量團(tuán)隊成員的績效

　　參見“軟件工程績效管理”一文:

　　思考:

　　團(tuán)隊模式和團(tuán)隊的開發(fā)模式有什么關(guān)系?

　　如果你開始一個項目, 怎么選擇“合適” 的團(tuán)隊模式?

　　不同的團(tuán)隊模式如何影響團(tuán)結(jié)績效的評估?

　　開發(fā)流程

　　一群人在一起做軟件開發(fā)，總是要有一些方式方法。就像我在概論中提到的,

　　我們在開發(fā)，運營, 維護(hù)軟件的過程中有很多技術(shù), 做法, 習(xí)慣, 和思想。軟件工程把這些相關(guān)的技術(shù)和過程統(tǒng)一到一個體系中, 叫“軟件開發(fā)流程”，軟件開發(fā)流程的目的是為了提高軟件開發(fā), 運營, 維護(hù)的效率；以及用戶滿意度, 可靠性，和軟件的可維護(hù)性。

　　寫了再改 Code-and-Fix

　　Steve McConnell 在[1] (下面的幾幅圖都來自于此) 里面提到了不少開發(fā)流程。第一個提到的開發(fā)流程– Code-and-Fix，看起來和一窩蜂團(tuán)隊模式非常像.

　　這個流程也有好處, 不需要太多其他準(zhǔn)備或相關(guān)知識, 大家上來就寫代碼, 也許就能寫出來, 寫不出來就改, 也許能改好。當(dāng)我們要做一些

　　· “只用一次”的程序，

　　· “看過了就扔” 的原型,

　　· 一些不實用的演示程序,

　　也許這個方法是有用的但是要寫一個軟件, 這個方法的缺點就太大了。

　　要注意的是, 許多學(xué)校里的軟件工程作業(yè), 就是符合上面那三點，所以難怪同學(xué)們覺得沒有必要用其他的開發(fā)方法, “寫了再改” 足矣！

　　瀑布模型(waterfall model)

　　當(dāng)軟件工程還是年幼的行業(yè)的時候, 它從別的成熟行業(yè)(硬件設(shè)計, 建筑工程) 借用了不少經(jīng)驗和模型。在那些”硬” 的行業(yè)中, 產(chǎn)品大多遵循[分析-> 設(shè)計-> 實現(xiàn)(制造) -> 銷售 -> 維護(hù)] 這個流程。 由于在硬行業(yè)中產(chǎn)品一旦大規(guī)模生產(chǎn), 要再返回去修改時非常困難, 甚至不可能的。因此這個模型描述了單向的, 不可逆的生產(chǎn)過程。

　　Winston Royce 在1970 年的論文“Managing the Development of Large Software Systems” (link) 第一次明確地描述了這個模型(雖然他沒有用waterfall 這個詞)。

　　但是要注意的是, Winston 并不推崇嚴(yán)格意義上的瀑布模型, 相反他指出了此模型的各種缺陷, 并提出了一些改進(jìn)的辦法。

　　例如, Winston 正確地指出了在設(shè)計大型系統(tǒng)的時候, 要做相鄰步驟的回溯，解決上一階段未能解決的問題:

　　又如: Winston 指出, 要讓產(chǎn)品成功, 最好把這個模型走兩遍，先有一個模擬版本(simulation of final product), 在此基礎(chǔ)上收集反饋, 改進(jìn)各個步驟, 并交付一個最終的版本:

Winston 還指出, 用戶的及早介入, 討論，復(fù)審是很重要的。他建議–

　　Customer involvement should be formal, in-depth, and continuing.

　　他也提到在這個模型下文檔的重要性: 下面的圖中顯示了8 種文檔:

　　有諷刺意義的是, 似乎其他人并沒有仔細(xì)讀這個論文, 一些人看了圖, 覺得很爽, 就拿來用了，而且希望waterfall 一次就把產(chǎn)品做好，同時產(chǎn)生出好些有用的文檔。 一時間Waterfall 傳播開來了。對于它的缺點, 一些人不正確地指責(zé)Winston。

　　可以看看網(wǎng)友做的漫畫, 看看Waterfall 的傳播和誤解：

　　the rise and fall of waterfall: Royce Winston

　　盡管狹隘定義的瀑布模型有這樣那樣的問題, 我個人認(rèn)為這個瀑布模型還是反映了人類解決問題的一個常用的模型。它在軟件工程中的局限性在于–

　　· 各步驟之間是分離的，（但是軟件的生產(chǎn)過程中的各個步驟不能這樣嚴(yán)格分離出來。）

　　· 回溯修改很困難甚至不可能, (但是軟件生產(chǎn)的過程需要時時回溯)

　　· 最終產(chǎn)品直到最后才出現(xiàn)，（但是軟件的客戶, 甚至軟件工程師本人都需要盡早知道產(chǎn)品的原型, 試用）

　　這個“最終產(chǎn)品知道最后才出現(xiàn)“是很令人頭痛的局限性, 考慮這個制造汽車的故事:

　　你(用戶) 提出要發(fā)動機(jī), 車身, 車窗, 方向盤, 加速踏板, 剎車, 手剎, 座位, 車燈…

　　生產(chǎn)商按照瀑布模型流程給你設(shè)計, 生產(chǎn), 六個月后交付。

　　看到樣車后…

　　你提出– 我當(dāng)初忘了一件小事, 要有倒車燈

　　§ 當(dāng)?shù)管嚨臅r候, 倒車燈會亮

　　生產(chǎn)商說:

　　§ 我要重新設(shè)計車尾部，加上倒車燈，把車底拆開，安裝線路, 修改傳動裝置把倒車檔和倒車燈聯(lián)系起來。。。我得重新開始

　　你說: 這不是很小的一件事么?

　　這是小事還是大事?

　　它有適用范圍么? 我認(rèn)為有:

　　· 如果產(chǎn)品的定義非常穩(wěn)定, 但是產(chǎn)品的正確性非常重要, 需要每一步的驗證.

　　· 產(chǎn)品模塊之間的接口, 輸入和輸出很好用形式化的方法定義和驗證。

　　· 使用的技術(shù)非常成熟, 團(tuán)隊成員都很熟悉這些技術(shù)

　　· 負(fù)責(zé)各個步驟的子團(tuán)隊分屬不同的機(jī)構(gòu), 或不同的地理位置, 不可能做到頻繁的交流。

　　瀑布的各種變形

　　為了解決瀑布模型的問題, 大家在實踐中提出了各種變形:

　　· 生魚片模型(各相鄰模塊像生魚片那樣部分重疊)

[[45733]]

　　這個模型解決了各個步驟之間分離的缺點, 同時也帶來了一些困擾– 究竟什么時候上一個階段結(jié)束呢?

　　· 大瀑布帶著小瀑布

　　為了解決不同子系統(tǒng)之間進(jìn)度不一, 技術(shù)要求迥異, 需要區(qū)別對待的問題。有人引入了子瀑布模型:

　　在這種瀑布群下, 要把各個子系統(tǒng)統(tǒng)一到最后做”System Testing” 的階段，難度不是一般的大啊! 但是在這樣的開發(fā)流程中, 用戶只有到了最后才能看到結(jié)果, 用戶真是等不起。

老板驅(qū)動的流程(boss-driven process)

　　在我和中國一些企業(yè)的軟件開發(fā)者交流的時候, 不少人提到開發(fā)流程事實上是由行政領(lǐng)導(dǎo)主導(dǎo), 或者由公司的老板驅(qū)動, 我們姑且把它命名為boss-driven process.

[[45734]]

(圖片來源: link)

　　這種模式也不是全無道理，我個人認(rèn)為有幾個因素:

　　· 當(dāng)軟件訂單的獲得不是主要靠技術(shù)實力, 而是靠個人關(guān)系, 或者暗箱操作的時候, 老板的能力決定了一個團(tuán)隊是否能獲得訂單, 既然軟件的具體功能并不重要（或者哪個團(tuán)隊做水平都差不多）, 老板說做什么就做什么。

　　· 在大型企業(yè)內(nèi)部, 軟件功能往往由行政體系來決定。

　　· 老板比一般技術(shù)人員更懂市場和競爭。

　　· 軟件團(tuán)隊尚未成熟, 不懂得如何獨立地進(jìn)行需求分析, 不懂得如何對行政領(lǐng)導(dǎo)有技巧地說“不”，也不知道如何說服利益相關(guān)者(stake-holder) 同意并支持正確的項目方向。既然團(tuán)隊成員不能驅(qū)動, 那只能靠外力來驅(qū)動了。

　　這種模式當(dāng)然也有它的問題:

　　· 領(lǐng)導(dǎo)對許多技術(shù)細(xì)節(jié)是外行，

　　· 領(lǐng)導(dǎo)未必懂得軟件項目的管理, 領(lǐng)導(dǎo)的權(quán)威影響了自由的交流和創(chuàng)造

　　· 領(lǐng)導(dǎo)最擅長的管理方式是行政命令, 這未必能管好軟件團(tuán)隊, 或任何需要創(chuàng)造力的團(tuán)隊

　　· 領(lǐng)導(dǎo)的精力有限, 當(dāng)領(lǐng)導(dǎo)很忙的時候, 團(tuán)隊怎么辦?

　　漸進(jìn)交付的流程(Evolutionary Delivery)

　　這個流程是Steve McConnell 在1996 年總結(jié)的，但是它其實已經(jīng)很接近現(xiàn)在大家談?wù)摰谋容^多的迭代式開發(fā)流程。在系統(tǒng)的主要需求和架構(gòu)明確之后, 軟件團(tuán)隊進(jìn)入了一個不斷變化的evolution 循環(huán)中:

　　[開發(fā)-> 發(fā)布-> 聽取反饋-> 根據(jù)反饋做改進(jìn)]

　　這個軟件什么時候才最后完成呢? 下面幾個條件滿足一個即可:

　　· 時間到了

　　· 錢花光了

　　· 用戶滿意了（或者很不滿意, 不再給錢了）

　　敏捷的流程(Agile Process)

　　這一節(jié)牽涉的內(nèi)容較多, 具體見幾個相關(guān)的博客。

　　[1] 各種模型的圖都來自于Rapid Development (1996), Chapter 7, “Lifecycle Planning” (p. 133)

原文鏈接： http://www.cnblogs.com/xinz/archive/2011/10/07/2200511.html

【編輯推薦】

1. 新手軟件項目經(jīng)理該如何入門
2. 項目經(jīng)理的力量應(yīng)該從哪里來？
3. 軟件項目管理總體流程設(shè)計
4. 新手軟件項目經(jīng)理之最后期限的迷局
5. 向新手軟件項目經(jīng)理推薦敏捷