軟件團隊和開發流程

　　非團隊和團隊

　　在講團隊之前, 我們要講什么是“非團隊”。王屋村里經常發生這樣的一幕:

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

[[45726]]

(來源: 論壇)

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

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

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

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

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

　　下面是一些團隊的例子:

[[45727]]

[[45728]]

可以看出, 這些團隊有共同的特點:

　　1. 團隊有一致的集體目標, 團隊要一起完成這目標。

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

　　（王屋村搬磚的“非團隊” 成員則不然, 每個人想搬多少就搬多少, 不想干了就結算工錢走人）

　　2. 團隊成員有各自的分工, 互相依賴合作, 共同完成任務

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

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

　　軟件團隊的形式

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

　　要把一這群小朋友培養成一個團隊（如下）, 需要時間:

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

　　一窩蜂模式 (chaos team):

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

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

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

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

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

　　明星模式(Super-star model):

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

　　社區模式(Community Model):

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

　　業余劇團模式(Amateur Theater Team):

　　這樣的團隊在每一個項目（劇目）中, 不同的人會挑選不同的角色。在下一個劇目中, 這些人也許會換一個完全不同的角色類型。各人在團隊中聽從一個中央指揮（導演）的指導和安排。在學生實踐項目或培訓項目中, 這樣的事情經常發生。

　　秘密團隊(skunk work team):

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

　　特工(SWAT) 團隊:

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

　　交響樂團模式(Orchestra):

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

　　· 家伙多, 門類齊全。

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

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

　　· 演奏的都是練習過多次的曲目, 重在執行。

(來源hudong)

　　爵士樂模式(Jazz Band):

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

[[45729]]

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

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

　　· 沒有現場指揮，平時有arranger 起到協調和指導作用（和Miles Davis 合作的arranger Gil Evans 也是很有造詣的音樂家）.

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

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

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

　　(翻譯) 強調個性化的表達，強有力的互動, 對變化的內容有創意的回應

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

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

　　功能團隊模式(feature team):

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

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

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

　　還有一個團隊模式可以叫-

　　官僚模式(bureaucratic model)

　　下面的模式用來表示一個機構的組織架構是沒問題的, 但是把這種架構搬到軟件開發中, 則會出問題。因為成員之間不光有技術方面的合作和領導, 同時還混進了組織上的領導和被領導關系。跨組織的合作變得比較困難，因為有各自老板在各自頭頂上。

　　這種模式如果應用不好, 最后會變成“老板驅動” 的開發流程, 見后。

軟件團隊成員的投入

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

　　如何衡量團隊成員的績效

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

　　思考:

　　團隊模式和團隊的開發模式有什么關系?

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

　　不同的團隊模式如何影響團結績效的評估?

　　開發流程

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

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

　　寫了再改 Code-and-Fix

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

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

　　· “只用一次”的程序，

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

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

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

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

　　瀑布模型(waterfall model)

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

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

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

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

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

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

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

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

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

　　可以看看網友做的漫畫, 看看Waterfall 的傳播和誤解：

　　the rise and fall of waterfall: Royce Winston

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

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

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

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

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

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

　　生產商按照瀑布模型流程給你設計, 生產, 六個月后交付。

　　看到樣車后…

　　你提出– 我當初忘了一件小事, 要有倒車燈

　　§ 當倒車的時候, 倒車燈會亮

　　生產商說:

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

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

　　這是小事還是大事?

　　它有適用范圍么? 我認為有:

　　· 如果產品的定義非常穩定, 但是產品的正確性非常重要, 需要每一步的驗證.

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

　　· 使用的技術非常成熟, 團隊成員都很熟悉這些技術

　　· 負責各個步驟的子團隊分屬不同的機構, 或不同的地理位置, 不可能做到頻繁的交流。

　　瀑布的各種變形

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

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

[[45733]]

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

　　· 大瀑布帶著小瀑布

　　為了解決不同子系統之間進度不一, 技術要求迥異, 需要區別對待的問題。有人引入了子瀑布模型:

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

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

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

[[45734]]

(圖片來源: link)

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

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

　　· 在大型企業內部, 軟件功能往往由行政體系來決定。

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

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

　　這種模式當然也有它的問題:

　　· 領導對許多技術細節是外行，

　　· 領導未必懂得軟件項目的管理, 領導的權威影響了自由的交流和創造

　　· 領導最擅長的管理方式是行政命令, 這未必能管好軟件團隊, 或任何需要創造力的團隊

　　· 領導的精力有限, 當領導很忙的時候, 團隊怎么辦?

　　漸進交付的流程(Evolutionary Delivery)

　　這個流程是Steve McConnell 在1996 年總結的，但是它其實已經很接近現在大家談論的比較多的迭代式開發流程。在系統的主要需求和架構明確之后, 軟件團隊進入了一個不斷變化的evolution 循環中:

　　[開發-> 發布-> 聽取反饋-> 根據反饋做改進]

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

　　· 時間到了

　　· 錢花光了

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

　　敏捷的流程(Agile Process)

　　這一節牽涉的內容較多, 具體見幾個相關的博客。

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

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

【編輯推薦】

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