Chapter 5 團隊和流程
Chapter 5 團隊和流程
一、非團隊和團隊
1.非團隊:只是一群烏合之眾,臨時聚集在一起。
2.團隊:①有一致的目標。
②成員不一定要同時工作。(如接力跑)
③成員有各自的分工,互相依賴合作,共同完成任務。一個人的工作對另一個人有影響。
二、軟件團隊的模式
適用於不同的人員和需求的團隊的各種形式。
1.一蜂窩模式:(比較混亂)
就是大家一哄而上去搶。可能是一個歡樂而隨意的模式。
2.主治醫生模式:(1主多從)
有一個主刀的人,還有其他幫助他的人。
也就是有一個首席程序員負責主要模塊的設計和編碼,其他人從各種角度支持他的工作(後備程序員、系統管理者、工具開發、編程語言專家、業務專家)
3.明星模式:(是主治醫生模式的升級版,就是明星能有團隊意識)
明星的光芒蓋過了團隊其他人的總和。
*明星也是人,也會有錯誤,如何讓團隊的利益最大化,而不是明星的利益最大化,如何讓團隊的價值在明星隕落之後仍然能保持?
真正有巨大成就的明星都能意識到團隊的作用。
說實話,不是很明白主治醫生模式和明星模式的區別?
4.社區模式:(人多,分工合作,保證質量,不隨意
社區由很多誌願者組成,每個人參與自己感興趣的項目,貢獻力量,大部分人不拿報酬。
好處:眾人拾柴火焰高,但是也要每個人均勻的分工合作,並且提高質量。
並不意味著“隨意”。
5.業余劇團模式:(每次每個人的角色不同,有導演)
在每一個不同的項目中,每個人挑選的角色也不同。
且每個人在團隊中聽從一個中央指揮(導演)的指導和安排。
6.秘密團隊:(神秘)
項目在秘密狀態下進行,別人不知道他們具體在做什麽。
好處:團隊內部有極大的自由,較高的熱情,沒有外界的幹擾(不用每周給別人介紹項目進展,聽領導的最新指示等)。
7.特工團隊:(有特殊技能的專業人士)
由一些有特殊技能的專業人士組成,負責解決一些棘手而又緊迫的問題。
現在還包括專門做網站安全性服務的團隊。
8.交響樂模式:(種類多,統一,執行力強)
家夥多,種類豐富。
各司其職。
有統一的套路(譜子),同時看指揮。
曲子練習了多次,重在執行。
9.爵士樂模式:(個性化,互動,創意)
同交響樂模式似乎有些相對。
沒有統一的譜子。
沒有現場指揮。
即興發揮。
強調個性化的表達,強有力的互動,對變化的內容有創意的回應。
10.功能團隊模式:(能力不同,平等,交流頻繁)
具備不同能力的同事們平等協作。
在一個功能完成後又重新組合,和別的角色一起去完成下一個功能。
沒有管理和被管理的關系。
小組內的交流比較頻繁。
11.官僚模式:(領導和被領導)
幾個人報告給一個小頭目,幾個小頭目報告給中頭目,依次而上。
成員之間不光有技術方面的合作和領導。
組織上有領導和被領導的關系。
跨組織的合作變得比較困難,因為各自頭頂上都有不同的老板。
三、開發流程
一群人一起做軟件開發的方式方法。
1.寫了再改模式:(適用於小場面的一些程序)
就是不管三七二十一,先寫了再說,如果有問題就再改動不斷的進行修改。
好處:不需要太多其他準備或相關知識,大家上來就寫代碼,也許就能寫出來,寫不出來就改,也許能改好。
eg.只用一次的程序,看過就扔的程序,一些不實用的程序。
壞處:在要寫到比較有實際用戶、解決實際需求的軟件時就不適用了。
2.瀑布模型:(單向、不可逆)
硬件行業中:產品一般遵循:【分析->設計->實現(制造)->銷售->維護】的流程。
且一旦大規模生產,要再返回去修改時就非常困難,甚至是不可能的。
在設計大型系統時,要做相鄰步驟的回溯,解決上一階段未能解決的問題。
要讓產品成功,最好把這個模型走兩邊,先有一個模擬版本,在此基礎上收集反饋,改進各個步驟,並交付一個最終的版本。
用戶的及早介入、討論、復審是很重要的。要讓顧客正式的、深入的、持續的參與到項目中來。
軟件行業中的局限性:
①各步驟之間是分離的,但是軟件生產過程中的各個步驟不能這樣嚴格分離出來。
②回溯修改很困難甚至不可能,但是軟件生產的過程需要時時回溯。
③最終產品直到最後才出現。但是軟件的客戶,甚至軟件工程師本人都需要盡早知道產品的原型並試用。
適用範圍:
①產品的正確性非常重要,需要每一步的驗證。
②產品模塊之間的接口、輸入和輸出能很好的用形式化的方法定義和驗證。
③使用的技術非常成熟,團隊成員都很熟悉這些技術。
④負責各個步驟的子團隊分屬不同的機構,或在不同的的地理位置,不可能做到頻繁的交流。
3.瀑布模型的各種變形:
1)生魚片模型(各相鄰模塊像生魚片那樣部分重疊):
解決了各個步驟之間分離的缺點,但也有問題:上一個階段什麽時候結束的?
2)大瀑布帶著小瀑布(步步嵌套):
解決不同子系統之間進度不一,技術要求迥異,需要區別對待的問題。
要把各個子系統統一到最後做系統測試,用戶只有到了最後才能看到結果。
4.統一流程(RUP):
從瀑布模型開始的各種模型都有一個共同點:重計劃,重事先設計,重文檔表達。
團隊的各種成員要在不同階段做不同的事情,這些不同類型的工作在RUP中叫做規程或工作流。
包括:業務建模。
需求。
分析和設計。
實現。
測試。
部署。
配置和變更管理。
項目管理。
環境。
RUP四個階段:
①初始階段。分析軟件系統大概的構成。(開始階段)
②細化階段。分析問題領域,建立健全的體系結構基礎,編制項目計劃,按優先級處理項目中的風險。(具體的去做)
③構造階段。開發出所有的功能集,把功能集成為經過各種測試驗證過的產品。什麽是功能集???
④交付階段。確保軟件能滿足最終用戶的實際需求。
5.老板驅動的流程:( 由行政領導主導或是公司老板驅動。)
原因:老板的能力決定了一個團隊是否能獲得訂單。
在大型企業內部,軟件功能往往由行政體系來決定。
有些老板比一般人更懂市場和競爭。
軟件團隊尚未成熟。
缺點:領導對很多技術細節是外行。
領導未必懂得軟件項目的管理很有可能太過權威性。
領導管理是行政命令。
領導精力有限。
6.漸進交付的流程:(開發->發布->聽取反饋->根據反饋做改進)不斷的循環
(直到)軟件最後完成: 時間到了,錢花光了,用戶滿意了(或是不滿意不繼續給錢)。
但有問題是:產品團隊得到用戶的反饋太晚了。
MVP(最小可行產品,最小功能集):
把產品最核心的功能用最小的成本實現出來,然後快速征求用戶的意見。
指導思想與漸進交付相似,但是更強調更早獲得用戶反饋,為此可以在產品完成之前就發布,
也強調產品的核心價值,為了突出核心功能,不考慮輔助功能。
MBP(最強最美產品):
對用戶的需求了然於心,或者產品團隊比用戶更了解用戶的需求。
7.TSP(Team Software Process)的原則:
①流程中的每一步都是可以重復、可以衡量結果的。
②各個成員對團隊的目標,角色,產品都有統一的理解。
③盡量使用成熟的技術和做法。
④盡量多的收集數據。
⑤指定切實的計劃和承諾。計劃要由具體執行的角色來制定。
⑥增加團隊的自我管理能力。
⑦專註於提高質量。
Chapter 5 團隊和流程