1.閱讀《構建之法》1-5章：
1).軟體工程為為什麼開始要用「工程」來形容？難道是因為做軟體的艱巨性嗎？出自：1.2 軟體工程是什麼；答：工程是做專案，做軟體確實挺艱鉅的；
2).個人開發流程中，軟體工程師能不能在接到任務之後，做乙個對普遍這種任務解決的系統來提高自身的開發能力？出自：2.3個人開發流程；答：當然可以啦
3).有些軟體工程師的技能為什麼得不到提高呢？原因很簡單，慣性思考的方式，讓他們變成不用經過大腦的自動操作，並沒有真正去思考。出自：3.3技能的反 面;答：慣性思考的方式，讓他們變成不用經過大腦的自動操作，並沒有真正去思考？其實是因為他們熟練了，不需要機械的做事；
4).為什麼**的規範性總是需要人為的去解決，為什麼計算機不會根據使用者輸入的**而自動匹配規範？出自：4.3**的規範性；答：計算機需要人給它乙個標準，乙個方法，它才能做好人想要它做的事；
5).如何才能把非團隊和團隊的優勢相結合一起？出自：5.1非團隊和團隊；答:吸其精華，去其糟粕；
2.軟體開發流程------閱讀《構建之法》第5.5 第6 第7章
1.一些專案需要很多暗箱操作和政治角力才能搞定，既然scrum會吧這些矛盾都擺到明處，我們如何才能把風險降到最低？出自6.42敏捷流程的經驗教訓。 答：書上有答案，多理解；
2.我還是分不清敏捷開發和msf敏捷開發根本性的區別是什麼？答：看書吧。
3.閱讀《構建之法》第三10、11、12章
對於1我有乙個疑問：市場上有那麼多不同的使用者，如何規定不同使用者的價值和需求才能使其得到廣泛使用？答：根據絕大多數的使用者的價值和需求就可以使其得到廣泛使用；
4.閱讀《構建之法》第13-17章
第13章-軟體測試
我覺得本章多處講到各種中不同的測試，若測試人員全部型別的測試都要嘗試，那不就降低了軟體開發的效率嗎？而現在的使用者都是急性子的，很多時候開發人員需要的時間比使用者需求使用該軟體的時間長，這不就造成了供不應求的現象嗎？答：一般不會出現這種情況，一般使用者不能接受開發人員預期的時間，那這筆買賣時做不成的，何來的供不應求；
第14章-質量保證
從p266可看到乙個公式：軟體質量=程式質量+軟體工程質量，那麼問題來了：p270中提到的例子，很多任務程師都把大多數時間花在軟體質量上。一貴不變是無法創新的。如何在保證質量的情況下，又得到創新呢？答：這個就要看開發人員的能力和資歷了；
第15章-穩定和發布階段
第16章-it行業的創新
創新需要什麼外在條件？答：靈感的觸動；
第17章-人，績效和職業道德
17.5-團隊合作的幾個階段，其實跟我們現在的組隊階段差不多，但是出現了十分不可磨合的情況時，應該怎樣完善團隊？答：那就要看全部隊友怎麼想的了，如果都是為這個團隊好的，那麼問題就好解決的。如果都不想乙個團隊了，早散早好。
看到以前自己問的問題，自己都覺得好傻。哈哈！！！
回答自己的提問
第一章 問題 電腦科學與軟體工程有什麼區別？回答 前者範圍更廣，包括計算機硬體與軟體，網路工程，資訊工程，嵌入式技術，也包括軟體。後者更偏向軟體的測試與開發，應用。第二章 問題 為什麼開發軟體要先寫單元測試？回答 1.幫助理解需求 單元測試應該反映use case，把被測單元當成黑盒測試其外部行為。...
回答自己的提問
第一章 概論 問題 看完這章後，了解了一些程式設計師都知道的名言 推論等 像 程式 資料結構 演算法 軟體 程式 軟體工程 這些。在1.2.3這節內容上知道軟體工程與電腦科學是息息相關的，那麼在那麼多的電腦科學領域中，我們應該往哪個領域走才能夠學得更快，更好，更實用呢？答 我覺得吧，電腦科學領域中的...
回答自己的提問
第一章 myeclipse.exe 第二章 有潛力的專案 第三章 可以去接單然後和同學團隊一起做 第四章 應該是一人乙個功能，最後再一起除錯 第五章 如果是鍛鍊的形式，一般接單做就可以了 第六章 當然是要實用 第七章 非常重要 第八章 應該認真分析客戶的最終要求是什麼。第九章 私底下告訴他，不要當眾...