1.團隊模式和團隊的開發模式有什麽關系？
答：
　　首先來解釋一下這兩個名詞：
　　我查資料了解了一下，團隊模式，更偏向於多人合作的那種，而且我理解的“團隊”會是一種多人合作的情況下，長期磨合後的一個組織，他們是相互了解的，是擁有巨大的默契存在的。
　　對於團隊的開發模式我並沒有查到具體的解釋，但對於開發模式，是有查到幾種開發模式，比如瀑布開發模式、快速應用開發模式等等，我們在其他的課上有學過這些模式，所以我在這裏認為開發模式是更偏向於後邊的“模式”兩個字的，更註重方法，用什麽方法。
　　通過以上說明，我個人認為他們之間的關系是：團隊模式是一種組織的存在，而團隊的開發模式更註重於方法，團隊采用什麽樣的方法開開發項目。
2.如果你領頭開展一個全新的項目，你要怎麽選擇“合適”的團隊模式？
http://www.cnblogs.com/tjuscs2014/p/4023221.html
答：
　　首先，對於進入公司組建團隊來說，我的看法是，一個人要學會融入，對於剛入職的員工來說要盡快熟悉公司的環境，盡快找到合適的團隊加入，做開發我始終認為這是需要團隊的，不管一個人技術怎麽過硬，都是需要團隊的幫助和鼓舞的，對於團隊我認為長期合作相互了解的團隊才是好的團隊。
　　其次，對於“合適”一詞，從開發上來說，各個方向的程序員都有，完成這個項目需要什麽樣的技術的人，這是“合適”一詞體現的重點，這樣才能使項目更舒暢的開發。
　　對於課本上講的那幾種團隊模式，我會選擇“交響樂團”這種模式，因為我希望我們團隊的成員是多才多藝又是各司其職的，會的東西多，而且都有自己的專長。當然交響樂團演奏靠譜，同時看指揮的這一點，也體現了我們的一個觀點，就是一個項目團隊得有領頭人（項目經理），這是重要的一點。
　　最後，如果我是領頭人、項目經理的話，我會在最一開始就先組建一個大的團隊，不是為了開發項目，而是為了磨合，舉行適當的活動，增進大家的了解，然後再遇到具體的項目的時候從這些人中選出在技術領域更適合開發這個項目的人去組成小隊。而絕對不是當拿到一個項目的時候臨時找人去組隊，這樣不利於團隊更快的合作。
3.不同的團隊模式如何影響團隊績效的評估？
答：
　　不同的團隊模式，在團隊績效評估時，會考慮很多不同的因素。
　　比如，一個很嚴謹，從上到下都是一板一眼的團隊，在對於其績效的評估時候，就會更加按照公司給的要求和客戶的反應等等來進行評估。
　　而對於更加“人性化”（指要求上並不是絕對只按規章制度去做事的，有其靈活想的一面。）的團隊來說，在做評估時，可能更多的會考慮人的因素，比如，當評估結果不理想時，可能出來在按照公司要求和客戶反應來反思的同時，還會可能想到“也許是大家最近太累了，或是負責那一不理想的模塊的人最近家裏有些事情等等”。
4.團隊精神和集體主義的區別？
大家回想在小學和中學的學習過程，大家在一個班集體，有多少工作是以“團隊”（Teamwork）的形式來完成的，有多少工作是以“工作組”（Workgroup)形式完成的？或許大部分工作都是以“非團隊”的形式完成的。“團隊精神”和平常講的“集體主義”有什麽區別？
答：
　　首先“精神”一詞，我對其的了解是指人的意識、思維活動和一般心理狀態，它是刻畫在人的內在的東西。“主義”指最高理想和準則，比如說某某主義指以某某為最高理想和準則的思想體系。它有前提的要求，更加的體制化。
　　其次對於“團隊精神”和“集體主義”來說，前者是內在的體現，後者是有外在的約束的存在。對於內在的體現，由內向外的展示是存在自願的情感的，外在的約束是帶有一種強制的感情的。
　　回想我的小學初中或是高中有的內容是“非團隊”的形式存在的，比如說作業的完成。。。嘻嘻嘻嘻。有的是以“團隊”的形式完成的。
5.閱讀 《夢斷代碼》 (Dreaming in Code) 這本書，分析Chandler 團隊的形式和流程，它們各有什麽優缺點?
答：
　　首先，閱讀《夢斷代碼》這本書我在寫這篇博客之前的沒有做到的，希望自己以後有機會可以了解一下這本書。
　　其次，我在網上查了一下這本書以下是《夢斷代碼》的簡介：本書寫的是作者羅森伯格對OSAF主持的Chandler項目進行田野調查，跟蹤經年，試圖借由Chandler的開發過程揭示軟件開發中的一些根本性大問題。本書是講一事，也是講百千事;是寫一軟件，也是寫百千軟件;是寫一群人，也是寫百千萬人。任何一個在軟件領域稍有經驗的技術人員看完本書，必掩卷長嘆:做軟件難。軟件乃是人類自以為最有把握，實則最難掌控的技術。
　　好吧，我本想在網上查查這個問題然後Ctrl+v過來呢。結果並沒有找到這個問題的確切答案，我還是如實的說吧，，，這道題我先欠著，等我真正的讀了之後我定會回來補上它。 我現在就去找找資源，，，嘻嘻，（我比較窮買不起正版的書）好在資源被我找到了，現在也分享給大家，咱們一起學習學習。https://pan.baidu.com/s/14OIUiIDfTSDjJkA1DNEcVA 分享的網盤資源。
6.有人說 - 現代軟件工程分為四個階段：和PM 吵 和設計吵 和測試吵 和用戶吵； 你覺得應該如何避免吵架?
答：
　　“吵”是一種不和諧的體現，為什麽會吵呢，因為意見不合，為了避免吵架，就要相互多交談意見，針對不同的意見要心平氣和的交談，畢竟吵架是不能解決問題的，沒準還會讓問題更加的嚴峻，更不利於項目的發展。
7.軟件開發有流程，硬件開發和生產當然也有，請看硬件生產的流程（此流程不包括硬件設計）：http://dwz.cn/1W1qbn
這樣的“生產”流程和軟件“生產”的流程有什麽區別呢？
答：http://dwz.cn/1W1qbn這個網址我在網上搜了是
看來這裏說的硬件生產流程是指富士康生產手機流程。
對於硬件的生產流程，是從從一點點的芯片或是模塊開始一點一點的去組裝的，軟件的生產流程是從一個一個的功能模塊一個字母一個字母的敲打出來的，要說硬件生產和軟件生產的區別我認為最大的不同之處就是，軟件是一種根據人的思維，根據特定的算法創造出來的，硬件是現實中存在的東西，用這些東西去做的。
8.很多流程的目的是幫助大家減少風險，確保質量，但是流程未必全都是正面作用。請看下面的故事：
走六天流程改一行代碼：htttp://blog.jobbole.com/19772/
這種情況需要改進麽，如何改進？
答：
　　大家可以先讀一下上面超鏈接裏面提到的故事，6天時間只修改了一行代碼，這個故事確實向我們展示了在流程上面花費和占用了不少時間？但是可以看到其實裏面很多時間都花費在了兩個核心的地方。
　　其一是團隊成員沒有形成基礎的團隊詞匯表或者說對流程規範本身就不熟悉，
　　其二是在流程推行前期需要做的諸多基礎數據配置工作並沒有完成，而是等到流程需要的才在處理。
　　再次，我們對領導或經理出差狀況下相應的應急處理機制沒有明確制定，也導致了時間上的拖延。
　這種情況是絕對需要改進的，走六天改於行代碼，說明管理上存在問題，效率絕對低下。當我們談過程的時候更加強調了流程，人和方法工具技術三者之間的有機融合，這有這三者完美整合好，才可能形成一個高效率的體系。對於團隊成員對流程規範等方面要做好工作，要提前做好工作，對於領導的出差時間要做好記錄。這樣的相鋪相成才能提高效率。

第五章課後題