第五——十三章的做業

時間 2019-12-11

標籤第五十三简体版

原文原文鏈接

第五章

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

答：團隊模式指團隊的分工模式，團隊內部的結構，團隊開發模式指團隊開發的流程及步驟程序員

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

答：根據團隊的能力和項目的結構，選擇合適的團隊模式。若是你們都比較自覺，且其中有一人能力較強，就會選擇主治醫師模式。若是項目比較複雜且每一個人都有本身熟悉的開發領域，會選擇功能團隊模式。若是項目在不一樣方向和領域都有任務，就會選交響樂團模式。若是是開放式項目，可能會選擇爵士樂模式。若是開發的人很是多，會選擇官僚模式。編程

3.不一樣的團隊模式如何影響團隊績效的評估？

答：主治醫師主要看主刀醫師的發揮以及其餘人的配合；明星模式主要看明星的發揮；社區模式看你們的熱情；業餘劇團模式是鍛鍊人的學習能力，若是隊員學習能力出色的話團隊績效會不錯；祕密團隊和特工團隊主要看隊員的能力；交響樂團模式看指揮員的指揮，通常績效比較穩定；爵士樂模式看隊員你們當時的狀態；功能模式看功能的搭配；官僚模式看溝通架構

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

答：團隊精神更強調我的的主動性，團隊是由員工和管理層組成的一個共同體，該共同體合理利用每個成員的知識和技能協同工做，解決問題，達到共同的目標。集體主義則強調你們共同性。二者具體區別以下：框架

1：在領導方面。羣體應該有明確的領導人；團隊可能就不同，尤爲團隊發展到成熟階段，成員共享決策權。工具

2：目標方面。羣體的目標必須跟組織保持一致，但團隊中除了這點以外，還能夠產生本身的目標。單元測試

3：協做方面。羣體的協做性多是中等程度的，有時成員還有些消極，有些對立；但團隊中是一種齊心合力的氣氛。學習

4：責任方面。羣體的領導者要負很大責任，而團隊中除了領導者要負責以外，每個團隊的成員也要負責，甚至要一塊兒相互做用，共同負責。測試

5：技能方面。羣體成員的技能多是不一樣的，也多是相同的，而團隊成員的技能是相互補充的，把不一樣知識、技能和經驗的人綜合在一塊兒，造成角色互補，從而達到整個團隊的有效組合。網站

6：結果方面。羣體的績效是每個個體的績效相加之和，團隊的結果或績效是由你們共同合做完成的產品。編碼

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

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

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

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

第六章

6.3.1 何時適合選擇敏捷？討論應該增長一些什麼問題，來幫助團隊選擇最合適的開發模型。

答：選擇合適的開發模型須要增長的問題：

1.團隊人員的對軟件的應用領域很熟悉嗎？

2.項目的風險高嗎？

3.項目的使用對象有些什麼人？

4.項目的需求明確嗎？

5.軟件的更新週期長嗎？

6.3.2討論軟件開發的思潮請從下表挑選幾篇關於軟件工程方法論的文章，仔細閱讀（包括相關的討論），根據你的軟件工程經驗分享你的見解。

答：在列舉的一系列文章中其中一篇文章講的是敏捷開發，強調了我的和互動高於流程和工具，工做軟件高於理解文檔，客戶協做高於合同協商，變化響應高於計劃遵循。在咱們進行軟件開發的時候，須要真正的落實敏捷開發的理念。用敏捷開發來作事，須要在開發的過程當中找到適合的位置，慢慢的向目標靠近。知道目標就要當即行動去實現，作到真正的敏捷，不要只是說敏捷這個詞，不能讓敏捷這個詞失去其意義。在軟件開發過程當中，要儘量的作到本身的責任。有付出，纔會有回報。有人負責纔會有質量。一個軟件的開發須要團隊全部的人共同的來負責，這樣才能作出好的軟件好的效果。

第七章

7.7移山開發方法——比TFS敏捷更精簡。你怎麼看二柱的觀點？

答：我對二柱觀點的見解是：軟件工程裏面確實有不少的概念和一些名詞以及流程，這些東西不是像二柱說的沒用，軟件工程的這些東西是前人經驗的總結能夠給咱們在開發的時候一個大的框架。程序員自身的修養和完成工做的素質確實是軟件開發中不可缺乏的部分，可是熟知了軟件工程裏面所講的概念，而且能運用到開發中才能成爲一個修養很高的程序員。

第八章

2．你要寫一個企業管理軟件, 你要找誰去作用戶調研?請列出你認爲重要的用戶類型和你認爲合適的用戶調研的方式。

答：老闆：有哪些功能，能如何幫助企業管理什麼事情，可否達到本身的需求

管理員：是否易用

員工：會管理哪些方面的事情，須要注意什麼

3．在一個軟件項目中，軟件團隊預計天天的進度爲 30 小時（即，完成了30小時的工做量）。當項目完成了一半的總工做量的時候，你們發現實際的進度爲15小時/天，問：在餘下的時間中, 團隊的進度要到多少，才能在項目結束時讓整個項目的平均進度恢復到天天30小時工做量？

答：不可能

4.一個目標/決心/估計的故事：某項目原本進行得很順利，大領導非要全體人員脫產開一天的動員大會，會議結束時, 領導熱情地問你們：你們對如期完成項目有信心麼? 這時，項目經理站起來講：咱們原本是能夠定期完成的，如今開了一天會，咱們已經延期了一天。

你們以爲這樣的項目經理是好仍是很差?

答:很差，容易引發團隊內的衝突，以及團隊與領導間的不融洽。團隊應該敢於適應變化，而不是照搬規律和計劃。

第九章

1．你有這些能力麼？

答：有

2．我是作PM 的料麼? 在校學生如何爲成爲PM作準備

答：都有點擅長是會不是

3．請分析各類交通工具的特性（長途汽車，火車，自駕，飛機，自行車，等）。

答：長途汽車：速度通常靈活性通常不便宜

火車：速度較快靈活性通常比較便宜

自駕：速度通常靈活性強比較便宜

飛機：速度很快靈活性通常貴

自行車：速度慢靈活性強基本免費

第十章

1．討論：下面的老闆犯了什麼錯誤?

答：只看到了用戶的語言和行動，沒有看到語言行動背後的動機

3．團隊要設計一個銀行自動櫃員機 (ATM) 的操做界面, 這個櫃員機擺在銀行營業廳的外面。你以爲會有多少種用戶來使用你的操做界面?

答：取錢的，查餘額的，轉帳的，改密碼的，存錢的，管理員

4．在你的項目中有作過頭的狀況麼?

答：沒有

第十一章

一、如何避免在產品開發後期不斷有重大修改，致使其它模塊的連鎖反應?

答：須要咱們在作需求分析的時候儘可能作的全面一些，不要漏掉一些重要的細節。在中途修改會帶來不少的額外工做量，給開發帶來極大的不便。

三、如何避免詫異的反應

答：當客戶對咱們的軟件不瞭解的時候咱們須要儘可能的給用戶解釋，並且咱們在設計軟件的時候也儘可能的要考慮用戶的感覺，從用戶的角度去考慮問題。

四、在這個時候是否碰到「團隊成員不給力」的問題?

答：團隊成員只要盡本身的力量去作了事情，通常都能完成預先計劃的任務。

五、咱們是在寫代碼解決問題呢，仍是在搭建宏偉的架構?

答：編寫代碼是爲了解決問題，一步步搭建起一個軟件的框架。

第十二章用戶體驗

一、何時開始考慮用戶體驗？

答：用戶體驗應該在軟件具備了初步的功能以後開始，根據不一樣的用戶人羣來設置不一樣的軟件使用方法，以及不一樣的功能。好比在設計老人使用的軟件的時候就儘可能要精簡，能達到主要的功能就好，在給年輕人用的時候就儘可能展示軟件的所有功能。

二、我的電腦界面的演變討論我的電腦界面的演變, 以及影響這些演變的各類因素

答：我的電腦從最初的有三個按鍵的鼠標，和最早的圖形界面的使用。到如今的最新版本的電腦經歷不不少的變化。軟件的界面也是咱們常用的軟件的見面word2003到word2007的界面就是一個很大的變化，軟件界面始終都是迎合用戶體驗來的，用戶有什麼要求，軟件設計就會盡可能的往那個方面發展。致使這些變化的緣由主要是由於如今計算機技術的發展，硬件的技術上升使得電腦能夠顯示的內容愈來愈豐富，編程技術的上升也使得如今的電腦能夠給用戶帶來更好的體驗。