練習五

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天時間只修改了一行代碼，這個故事確實向咱們展現了在流程上面花費和佔用了很多時間？可是能夠看到其實裏面不少時間都花費在了兩個核心的地方。

 

　　其一是團隊成員沒有造成基礎的團隊詞彙表或者說對流程規範自己就不熟悉，

 

　　其二是在流程推行前期須要作的諸多基礎數據配置工做並無完成，而是等到流程須要的纔在處理。

 

　　再次，咱們對領導或經理出差情況下相應的應急處理機制沒有明確制定，也致使了時間上的拖延。

 

   　這種狀況是絕對須要改進的，走六天改於行代碼，說明管理上存在問題，效率絕對低下。當咱們談過程的時候更增強調了流程，人和方法工具技術三者之間的有機融合，這有這三者完美整合好，纔可能造成一個高效率的體系。對於團隊成員對流程規範等方面要作好工做，要提早作好工做，對於領導的出差時間要作好記錄。這樣的相鋪相成才能提升效率。