問題1：
構建之法page106中有這樣的描述「衝刺到一半的時候，產品負責人突然發現要馬上做重要的改動！或者某個大佬要看某個不在計畫中的功能的演示，怎麼辦？這種情況非常考驗scrum master。如果乙個運動員在跑一百公尺衝刺，但是跑到一半的時候，領導突然想看一百一十公尺欄的比賽，前面會馬上擺起欄架，大家要準備八步上欄！怎麼辦？乙個有正常頭腦的運動員和教練會說：去你的，要改主意，也要等到老子衝刺完了再說啊！」但是在實際的程式設計過程中，專案要進行重大的改動說明使用者的需求發生了重大的變化，這時依舊按照以前的計畫進行衝刺，是不是會有南轅北轍之嫌？衝刺所取得的結果會不會大打折扣？
問題2：
在page75中講到結對程式設計是為了能時刻進行**複審。但是在一些小專案中，也能提高效率嗎？比如在四則運算的結對程式設計中，我覺得並不會。在兩個人的程式設計過程中，即使進行了規範約束，我還是明顯的感覺到了由於兩個人程式設計風格的不同造成的閱讀對方**困難。在角色切換的過程中，會伴隨著程式設計思路被打斷的問題，反而使程式設計的進度變慢，不如獨自一人對**進行複審有效率。
問題3：
在軟體測試這一章節中，泛泛而提出了很多測試方法，比如單元測試，**覆蓋率測試，構建驗證測試等等，但我們還是無法對軟體測試的流程有乙個清晰的概念，我們到底應該進行哪些測試，我們不需要進行那些測試？都無法找出答案。
問題4：
在page15中，提出了乙個概念「足夠好軟體」，對於足夠好軟體，到底怎麼才是足夠好，對這個定義還是有疑惑的？書上用bug來衡量，其中又有列出使用者滿意度，可靠性等等，比如滿意度，每個人存在不一樣的要求。舉個例子，比如在分析必應詞典的時候，這個軟體是足夠好了，還是不好，有的人認為好，有的認為很差。這個足夠好是如何來衡量的？
問題五：
在第八章：需求分析中，明確的指出了軟體需求分析的重要性，然而，在我們的實際專案的軟體需求分析中由於時間的緊迫性，無專案經費等等問題我們所做出的需求分析要嗎調查樣本過小，沒有代表性，要嗎調查手段單一，問題不夠全面。應該如何解決這一問題？
c) 如果有明確要求，我可以做好。
2、主動解決問題。當看到不靠譜的設計，糟糕的**的時候，不要想「可能別人會來管這個事情」 ，或者「我下個月發乙個郵件讓大家討論一下」。要主動地把問題給解決了。
d) 一直主動這樣做
3、 經常給自己充電，身體訓練是運動員生活的一部分，學習是軟體工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。通過定期分享（面對面的分享，寫技術部落格等）來確保自己真正掌握了新技術。
c) 有時分享。
4、dry （don't repeat yourself）——別重複。在乙個系統中，每乙個知識點都應該有乙個無異議的、正規的表現形式。
a) 從來沒聽說過；
5、消除不相關模組之間的影響，在設計模組的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。
c) 想做，但是不知道怎麼衡量效果。
6、通過快速原型來學習，快速原型的目的是學習，它的價值不在於**，而在於你通過快速原型學到了什麼。
c) 不用原型，一直在產品中直接改。
7、設計要接近問題領域，在設計的時候，要接近你目標使用者的語言和環境。
c) 大概同意，但是怎麼接近使用者呢？
8、估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工作中要告知可能的時間變化，事後要總結。
c) 如果有明確要求，我可以做好。
9、圖形介面的工具有它的長處，但是不要忘了命令列工具也可以發揮很高的效率，特別是可以用指令碼構建各種組合命令的時候。
d) 一直主動這樣做
10、有很多**編輯器，請把其中乙個用得非常熟練。讓編輯器可以實現自己的定製，可以用指令碼驅動，用起來得心應手。
c) 沒有任何定製。
11、理解常用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，什麼時候用，什麼時候不用。
c) 每寫100行程式，我就盡量用乙個模式。
12、**版本管理工具是你**的保障，重要的**一定要有**版本管理。
d) 經常用
13、在debug的時候，不要驚慌，想想導致問題的原因可能在**。一步一步地找到原因。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在自己的**裡面加 log.
b) 只會printf；
14、重要的介面要用形式化的「合同」來規定。用文件和斷言、自動化測試等工具來保證**的確按照合同來做事，不多也不少。使用斷言 (assertion) 或者其他技術來驗證**中的假設，你認為不可能發生的事情在現實世界中往往會發生。
c) 想用，但沒有時間。
15、只在異常的情況下才使用異常 (exception), 不加判斷地過多使用異常，會降低**的效率和可維護性。記住不要用異常來傳遞正常的資訊。
c) 如果有明確要求，我可以做好。
16、善始善終。如果某個函式申請了空間或其他資源，這個函式負責釋放這些資源。
c) 有時這樣做。
17、當你的軟體有多種技術結合在一起的時候，要採用松耦合的配置模式，而不是要把所有**都混到一起。
d) 一直主動這樣做
18、把常用模組的功能打造成獨立的服務，通過良好的介面 (api) 來呼叫不同的服務。
c) 如果有明確要求，我可以做好。
19、在設計中考慮對並行的支援，這樣你的api 設計會比較容易擴充套件。
c) 任何**都應支援並行
20、在設計中把展現模組 (view) 和實體模組 (model) 分開，這樣你的設計會更有靈活性。
c) 沒搞清楚啥是v，啥是m。
21、重視演算法的效率，在開始寫之前就要估計好演算法的效率是哪乙個數量級上的（big-o）。
c) 不會有效率問題的，現在cpu 都快了。
22、在實際的執行場景中測試你的演算法，不要停留在數學分析層面。有時候乙個小小的實際因素 (是否支援大小寫敏感的排序，資料是否支援多語言)會導致演算法效率的巨大變化。
b) 想用，但不知道工具
23、經常重構**，同時注意要解決問題的根源。
b) 任何修改都可以叫重構；
24、在開始設計的時候就要考慮如何測試 ，如果**出了問題，有log 來輔助debug 麼? 盡早測試，經常測試，爭取實現自動化測試，爭取每乙個構建的版本都能有某些自動測試。
c) 專案沒有安排時間，我也沒有提這事。
25、**生成工具可以生成一堆一堆的**，在正式使用它們之前，要確保你能理解它們，並且必要的時候能debug 這些**。
c) 那些**沒有bug。
26、和乙個實際的使用者一起使用軟體，獲得第一手反饋。
d) 一直主動這樣做
27、在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。
c) 如果有明確要求，我可以做好。
28、如果測試沒有做完，那麼開發也沒有做完。
d) 一直主動這樣做
29、適當地追求**覆蓋率：每一行的**都覆蓋了，但是程式未必正確。要確保程式覆蓋了不同的程式狀態和各種組合條件。
d) 一直主動這樣做
30、如果團隊成員碰到了乙個有普遍意義的bug, 應該建立乙個測試用例抓住以後將會出現的類似的bug。
c) 測試用例不值得加
31、測試：多走一步，多考慮一層。如果程式執行了一星期不退出，如果使用者的螢幕解析度再提高乙個檔次，這個程式會出什麼可能的錯誤?
d) 一直主動這樣做
32、（帶領團隊）了解使用者的期望值，稍稍超出使用者的期望值，讓使用者有驚喜。
c) 如果有明確要求，我可以做好。
33、（帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設、對使用者的誤解或其他因素所遮擋。
c) 如果有明確要求，我可以做好。
34、（帶領團隊）把所有的術語和專案相關的名詞、縮寫等都放在乙個地方。
c) 大家看**就好
35、（帶領團隊）不要依賴於某個人的手動操作，而是要把這些操作都做成有相關許可權的人士都能執行的指令碼。這樣就不會出現因為某人休假而專案被卡住的情況。
c) 出了問題再說
36、（帶領團隊）要讓重用變得更容易。乙個軟體團隊要創造一種環境，讓大家有輕鬆的心態來嘗試各種想法 （例如，模組的重用，效能的提公升，等）。
c) 不必嘗試，失敗的可能性太大
37、（帶領團隊）在每一次迭代之後，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高。
c) 如果上級有要求，就做一下；
個人作業3 個人總結（Alpha階段）
2017 5 15 22 00pm，以部落格發表日期為準 我們在alpha 結束之後，每位寫乙個部落格，總結自己的alpha 過程，同時，大家一定會在過程中產生了很多問題，結合你的讀書 教材，部落格，參考書 實踐，提出關於軟體工程的 5 個問題。在每個問題後面，請說明哪一章節的什麼內容引起了你的提問...
個人作業3 個人總結（Alpha階段）
2017 5 15 22 00pm，以部落格發表日期為準 我們在alpha 結束之後，每位寫乙個部落格，總結自己的alpha 過程，同時，大家一定會在過程中產生了很多問題，結合你的讀書 教材，部落格，參考書 實踐，提出關於軟體工程的 5 個問題。在每個問題後面，請說明哪一章節的什麼內容引起了你的提問...
個人作業3 個人總結（Alpha階段）
我們在alpha 結束之後，每位寫乙個部落格，總結自己的alpha 過程，同時，大家一定會在過程中產生了很多問題，結合你的讀書 教材，部落格，參考書 實踐，提出關於軟體工程的 5 個問題。時刻明確團隊的最終目標 在設計軟體原型，編寫軟體 中，我們要做 實現需求規格說明書中所列的功能要求 這個最終目標...