第五章做業

1.團隊模式和團隊的開發模式有什麼關係？

軟件團隊的模式包括：

（1）主治醫師模式：一人爲主，其餘人爲此人服務。

（2）明星模式：主治醫師模式到達極致，一人的光芒掩蓋全部人。

（3）社區模式：每一個人參與本身感興趣的項目，貢獻力量，大部分人不拿報酬。

（4）業餘劇團模式：在不一樣項目中每一個人扮演着不一樣的角色，可能隨着項目的改變，本身的角色也會發生變化。

（5）祕密團隊模式：一些軟件項目在祕密狀態下進行，別人不知道他們具體在作什麼。

（6）特工團隊模式：有一些有特殊技能的專業人士組成的團隊。

（7）交響樂團模式：人員工具齊全，準備充足的團隊。

（8）爵士樂模式：相對自由，有風險，人少且不靠譜。

（9）功能團隊模式：具有不一樣能力的同事們平等協做，共同完成一個功能。

（10）官僚模式：層層領導的團隊模式。

        團隊的開發模式與咱們目前所熟知的軟件開發模式，例如，瀑布、迭代、螺旋以及敏捷等等都密不可分，但它不一樣於單純意義上的軟件開發模式，由於這其中還加入了開發人員的因素，即「人」的因素。是更加貼近現實的，「接地氣」的開發模式。

        團隊模式和團隊開發模式這兩者的關係可作一個比喻，即爲：兩者共同構成了一我的，而前者是大腦，後者是身體。身體是行動的發出者和執行者然後者是身體的控制者和調度者。一樣是身體，有的團隊能夠開發出頗有價值的軟件，完成很困難的任務，並創造價值。而有的團隊則作不到這一點。由於，全部的軟件開發模式，只是單純的考慮到開發效率等問題，而最終可否成功完成任務，從某種意義上說，徹底取決於項目執行者，也就是團隊模式。所以，我剛剛提到的軟實力，就是一種無形的，蘊含於團隊成員心裏的力量，這股無形的力量卻能決定一個團隊可否作出有型的有價值的工做，將開發模式發揮的淋漓盡致。

2.若是你領頭開展一個全新的項目，你要怎麼選擇「合適的團隊模式？

    做爲一名team leader在選擇「合適」的團隊模式方面，首先要着眼於我將要組建的團隊須要那些角色的人，好比PO等等；其次，再根據這些不一樣的角色選取與其對應的性格和能力的人，來擔當此角色。在此，我把角色放在了能力的前面，由於，我始終相信一點，「性格決定一切，細節決定成敗」，一我的的性格決定着他的三觀，更覺定着他的職業道德，這對於軟件從業人員來講相當重要。

    最後，我想說，做爲一名team leader，組建團隊，須要的是營造良好的企業文化，強大的軟實力。這樣的團隊能時刻擰成一股繩，一塊兒拼搏。進而，纔是着眼於技術等實際的方面，否則，很容易形成，有技術的人，內心罵着leader ，又對同事不滿，最終就是團隊的break up into pieces。

三、不一樣的團隊模式如何影響團隊績效的評估

     不一樣的團隊模式，在團隊績效評估時，會考慮不少不一樣的因素。好比，一個很嚴謹，從上到下都是一板一眼的團隊，在對於其績效的評估時候，就會更加按照公司給的要求和客戶的反應等等來進行評估，而對於更加「人性化」的團隊來講，在作評估時，可能更多的會考慮人的因素，好比，當評估結果不理想時，可能出來在按照公司要求和客戶反應來反思的同時，還會可能想到「也許是你們最近太累了，或是負責那一不理想的模塊的人最近家裏有些事情等等」。

四、團隊精神和集體主義的區別？     你們回想在小學和中學的學習過程，你們在一個班集體，有多少工做是以「團隊」（Teamwork）的形式來完成的，有多少工做是以「工做組」（Workgroup)形式完成的？或許大部分工做都是以「非團隊」的形式完成的。「團隊精神」和日常講的「集體主義」有什麼區別？

     不一樣的團隊模式，在團隊績效評估時，會考慮不少不一樣的因素。好比，一個很嚴謹，從上到下都是一板一眼的團隊，在對於其績效的評估時候，就會更加按照公司給的要求和客戶的反應等等來進行評估，而對於更加「人性化」的團隊來講，在作評估時，可能更多的會考慮人的因素，好比，當評估結果不理想時，可能出來在按照公司要求和客戶反應來反思的同時，還會可能想到「也許是你們最近太累了，或是負責那一不理想的模塊的人最近家裏有些事情等等」。

五、閱讀《夢斷代碼》  (Dreaming in Code) 這本書，分析Chandler 團隊的形式和流程，它們各有什麼優缺點?

        Chandler 太過理想，推出太遲，很難贏得市場份額。但它蘊含的執着精神、始終未曾放棄夢想的實踐，則具備更大價值。從實用角度，做爲一款工具，你們可能都不太會去選擇Chandler。但從價值觀和信念角度，我以爲你們都應該去了解Chandler，瞭解他的內涵。

六、有人說 - 現代軟件工程分爲四個階段：和PM 吵和設計吵和測試吵和用戶吵；你以爲應該如何避免吵架?

        多溝通。在設計之初定好需求，明確需求。在編碼階段注意交流，隨時作出一些能夠工做的軟件交付給用戶和測試，讓他們給一些意見和建議，對於正確的意見和建議在接下來的編碼中改進。