提出問題

快速通讀教材《構建之法》，并參照提問模板，提出5個問題。

問題一：

• p83有一段話：
  • 兩人在一起合作，自然會出現不同意見，每個人都有自己的想法，在兩個人平等合作的情況下，不存在領導與被領導的關系，如何讓能說服對方？
• 雖然不存在領導與被領導的關系，但如果是在兩方都不確定自己是最佳方案的情況下，是要說服對方還是要聽取對方的的意見？還是要兩個方案都嘗試？哪種情況才能最便捷直接的解決問題？
• 我覺得合作的雙方就算不存在領導與被領導的關系，也可能會有能力上的差異。就像這學期的結對編程一樣，并非所有的同學編程能力都是一個水平，有好的就會有差的，也并非低能力一定要聽取高能力，但是對于一個問題存有意見，還是應該提出來讓大家一起思考一下，不然之后發展成大問題就更麻煩。

問題二：

• p118：
  • 軟件團隊開會，領導說：我們要采用敏捷的開發流程。很簡單，就是木有計劃，木有文檔，馬上寫代碼，隨時發牢騷。
• 首先敏捷是什么？真的如文中所說沒有計劃文檔的情況下直接開始打代碼嗎？
• 課本所提及的敏捷是一股思潮，或者說是一種價值觀，涵蓋了好幾種軟件開發的方法論；這些方法論又是建立在許多行之有效的最佳實踐方法之上的。
• 敏捷的方法論有哪些？
• 愛撫弟弟（FDD）；史克朗姆（SCRUM）；極限編程（XP）；那這些方法論具體又是如何實施的呢？怎樣的思想才能算是敏捷呢？

問題三：

-p129：

• MSF團隊模型和MSF過程模型也是建立在“信息共享與溝通”原則上的。
• 什么是MSF團隊模型？什么是MSF過程模型？

• 課本所提及的MSF（微軟解決方案框架）有九個基本原則：推動信息共享與溝通；為共同的遠景而工作；充分授權和信任；各司其職，對項目共同負責；交付增量的價值；保持敏捷，預期和適應變化；投資質量；學習所有經驗；與顧客合作；那MSF團隊模型，經過查找后如下圖：
  

• 查閱資料后，得出了MSF團隊模型的好處：各子團隊的工作和職責相互依賴，這種相互的依賴性會鼓勵子團隊成員對由其他子團隊工作做出評論和貢獻，以確保該子團隊成員所有的知識、能力、經驗能夠被應用到解決方案里。項目的成功，屬于所有的子團隊成員。他們共同分享一個成功的項目所帶來的榮譽和回報。即使是一個不太成功的項目，也能做到全心投入并從中吸取教訓，以完善他們的專長。

• MSF模型如下：
  

• MSF過程模型是從傳統的軟件開發瀑布模型和螺旋模型發展而來的，它把瀑布模型中基于里程碑的規劃優勢與螺旋模型中的增量迭代的長處結合了起來。

• MSF過程模型的基本元素是階段和里程碑。

問題四：

• p214：
  • 規格說明書分以下兩種：1.軟件功能說明書，主要用來說明軟件的外部功能和用戶的交互情況。
    2.軟件技術說明書，又叫設計文檔，主要用來說明軟件內部的設計規范。
• 功能說明書和技術說明書都是必要的嗎？
• 軟件也會有常用和不常用之分，如果一個不常用的軟件，寫一份功能說明書以及技術說明書需要耗費大量的時間，那這時寫還是不寫？當遇到這些情況時，怎樣的決定才是正確合理的？
• 網上搜索后，得到了如下的解釋：軟件規格說明的使用者包括用戶、設計人員、程序員、管理人員等, 涉及產品鑒定、質量保證、配置管理、軟件維護、人員培訓、市場分析、軟件版權等諸多問題。可以把軟件規格說明看成是一個具有概述、圖示、例子等多視角的信息庫。它既是用戶和開發者的一份協議, 又是指導軟一件開發、測試和維護的依據。
• 因此我覺得規格說明書是必要的，即便是不常用的軟件，也總會有用到的時候，如果沒有這些規格說明書，將會浪費大量使用者的時間去了解如何使用運行軟件。

問題五：

• p230：
  • 當時他接到英國的求助電話?？蛻粽f，他們建立了一個模型，這個模型得到了客戶、管理人員和開發者的共同認可。但問題是，有了這個模型，他們卻不知道下一步該做什么！
• 這種情況在我們學習過程中可以說是很常見了，就比如說拿到一個編程題，自己心里也有了一些思路，但就是不知道從哪里下手。所以我們遇到這種情況的時候，該怎么做才能快速的進入狀態？

轉載于:https://www.cnblogs.com/ohanna/p/8595566.html

總結

以上是生活随笔為你收集整理的软工网络15个人阅读作业2——提问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。