現代軟體工程討論第五章-第八章

標籤：style   os   使用   ar   strong   sp   資料   div   on   

第五章

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

團隊模式是指一個團隊的成員在一起合作的方式，而團隊的開發模式特製軟體Team Dev在軟體開發過程中所使用的合作方式。也就是說團隊的開發模式是一種特殊的應用在軟體開發領域的團隊模式。

 

2.如果你領頭開展一個全新的項目，你要怎麼選擇“合適”的團隊模式？

如果我帶頭做一個全新的項目，我會選擇特點不同的人，各自發揮自己的特長，類似功能團隊模式，大家各司其事，平等協作。如我擅長代碼編寫，資料庫設計，成員中還有負責需求分析的，負責文檔整理和總結的，負責測試等。

 

3. 吵架有很多種方式和原因，有的吵架實為討論，這樣的吵架其實也是有利於產品的進步的，是提高效率的一種積極因素，可以適當鼓勵；但有些卻是因為個人因素(如性格原因，推卸責任等)，這種情況應該避免和遏制。避免吵架的方法我覺得有以下幾種：

和PM、設計、測試的階段：

1）、每個人清楚自己的任務和責任，自己的問題在別人提示的時候應該及時改正並有良好的認錯態度，對於別人的問題應該理性的提醒

2）、就事論事，理性

和使用者階段：

1)、把使用者放第一位，產品是做出來讓使用者使用的，並期待得到他們的認證和肯定的，認真聽取他們的建議

2)、學術有專攻，很多時候使用者和產品開發人員關於產品需求等的討論是並不完善的，要懂得站在別人的角度(知識專業水平、表達方式)去看待問題，去瞭解使用者到底是想要什麼樣的東西

3)、把使用者當做協作開發人員是快速改進代碼和高效調試的無可爭辯的方式

大家都是為了做出更好的產品，不如將這一次次的爭吵當成對自己技術耐心的磨練，團隊都是在不斷的磨合中變得緊密優秀的。

 

4.團隊精神和集體主義的區別？大家回想在小學和中學的學習過程，大家在一個班集體，有多少工作是以“團隊”（Teamwork）的形式來完成的，有多少工作是以“工作群組”（Workgroup)形式完成的？或許大部分工作都是以“非團隊”的形式完成的。“團隊精神”和平常講的“集體主義”有什麼區別？

團隊精神更強調個人的主動性，團隊不一定有明確領導人，成員可以有決策權，團隊的每個成員還必須齊心協力，共同承擔責任，每個人都有不同的技能，進行互補等。

而集體主義更多強調明確的領導人，每個人目標相同，大家的技能也有可能相同，集體中的成員也有消極懈怠的等。

 

3.蜂窩模式，一群人開始寫代碼，沒有具體的分工，團隊的生產的產量較低，團隊之間沒有直接的交流，從而影響團隊績效的評估。

主治醫師模式：這個模式往往會演化成只有一個人在努力，其他的團隊成員只是擺著，導致團隊的整體生產能力的下降。

明星模式：明星的光芒往往會蓋過其他團隊成員的總和，不能達到績效的最大化，往往明星成員的績效影響到整個團隊的績效。

社區模式：這種模式下如果人人都貢獻力量的話，那麼團隊的整體績效肯定會到達提升，但是往往不是所有的人都願意為團隊做出貢獻，所以團隊的績效會受到團隊成員的自願程度和貢獻力量影響。

業餘劇團模式：角色的交替改變，使得團隊在不同的項目中績效的大小也會隨之改變，如果一個團隊的成員能夠充當正確的角色就會給整個團隊的績效帶來最大的利益。

秘密團隊：這種模式下不能對團隊的績效進行估計，所以需要團隊成員自己的努力。團隊成員和諧相處共同努力才能為團隊帶來良好的績效。

秘密團隊和特工團隊則團隊成員的自身能力是非常重要的，。

交響樂團模式顧名思義，指揮者指揮的好壞會直接影響到團隊的績效。

爵士模式，有團隊成員之間的即興發揮和狀態影響績效

功能模式影響團隊績效主要是成員之間的搭配，取得良好的績效。

官僚模式，顧名思義，只有具有良好的溝通能力才，主要影響其績效。

5.Chandler團隊的形式和流程過於理想化，很多東西都是想當然缺乏實踐的演練。但是Chandler團隊具有一個良好的團隊所具有的品質，他們執著，從不放棄夢想。 我們可以以從中得到一些經驗和教訓，對我們今後的職業生涯中有很大的作用。

 

第六章

我們看了這麼多方法論之後，一些同學一定比較困惑，到底選擇哪一種開發方法比較好呢? 這在實踐中不是難題，有學者還列出了一些簡單的問題來協助人們做決定：

表6-3 問題引出方法

問題	Yes – 偏向傳統的瀑布+文檔的流程	No –    偏向敏捷流程
1. 項目需要有明確的spec 嗎？
2. 項目沒有明確的使用者，也無法連絡使用者進行溝通
3. 軟體系統是大型的嗎？
4. 軟體系統是複雜的嗎？例如即時系統
5. 軟體的生命週期很長嗎？
6. 你使用比較差的軟體工具嗎？
7. 軟體項目成員是分布在不同的地區嗎？
8. 團隊是否有“文檔為先”的傳統？
9. 團隊的編程技術較差嗎？
10. 要交付的軟體系統是否要通過某種行業規定或行政法規的批准？
11.使用者是否在開發完成才看到結果？
12.項目是否一次性交付？

 

6.3.2 團隊建造軟體的方式

1.boss等人抓住市場動態，擷取需求

2.開發人員根據需求提出設計方案

3.討論方案可行性並加以改進

4.著手開始寫(做不到敏捷開發，socode and fix)

5.編碼同時伴隨測試，並結合使用者需求和開發找到平衡點

6.開發完成，投放市場，收取反饋並修改產品，進入下次迭代

第七章

第一題：Barry Boehm總結的軟體工程原則與MSF和Agile：

1、這個原則注重分階段的計劃，而MSF和Agile更加註重靈活的開發。

2、  這個原則要求持續地檢查認證，爭取在早期發現問題，而MSF和Agile也要求早期地發現問題，但是是通過儘可能早地做出產品來實現。

3、  這個原則堅持規範的產品控制，而MSF和Agile更加在乎的是成員之間的交流。

4、  這個原則以及MSF和Agile都使用現代的編程方法和工具，但是使用的方法和工具略有不同。

5、  這個原則的開發過程確保團隊成員能分階段，分模組，而MSF和Agile中的每個團隊成員都要為項目負責。

6、  這兩種原則都用少而精的人員，減少交流成本。

7、  這個原則通過總結來實現軟體過程和品質的提高，而MSF和Agile通過總結更多地會提高團隊成員的能力。

 

 

第二題：MSF原則和Barry Boehm提出的原則的區別：

MSF是敏捷開發，而Barry Boehm提出的原則偏向傳統軟體開發類型，強調明確的需求。

MSF預期變化，而Barry Boehm提出的原則是早期發現錯誤和問題，

MSF強調商業價值，而Barry Boehm提出的原則堅持規範的流程，

 

程式員的自身修養和工作素質是有不同層次的，軟體工程中的那些概念和工作原則只是一種評判的準則，旨在協助程式員在不斷評判自身和提高自身的，但也不能一味聽從於這些準則，因人而異，因事而異吧。

第八章需求分析

2題第二問你要寫一個企業管理軟體, 你要找誰去做使用者調研?請列出你認為重要的使用者類型和你認為合適的使用者調研的方式。

員工—大部分使用系統的使用者

老闆—需要從系統中瞭解公司的發展情況

系統管理員—負責管理這套系統的人

基層領導—在日常工作中與員工共同使用

員工和基層領導應該是最重要的使用者類型，因為他們是主要使用這個系統的人。

 

3、應該怎麼都不可能恢複到平均每天30小時的工作量，因為預定的時間已經用完。

 

4、我感覺這樣的專案經理比較好，因為使用太長時間來開動員大會這種事情確實浪費了大多數人的時間。因為在項目開始後，每個人對項目的目標應該都是很清楚，現在主要的問題是集中精力解決項目中遇到的具體問題，這樣子的開一天的動員大會完全是沒有必要的。專案經理更加為項目和項目成員考慮。

 

現代軟體工程討論第五章-第八章