助教老師好：希望你能夠指點指點，其實這些回答有的以前就回答過了，有的是補充上去的
1章. 在1.1節中我從阿超給兒子寫了個程式到越來越複雜的功能擴充套件到應用軟體的過程中，覺得這本書挺有趣的，但是有一個疑問！我們知道軟體=程式+軟體工程，那麼就阿超這個逐漸完善的程式來說，是什麼時候開始，程式就變成應用軟體的？
回答：我通過在課堂上問杜老師，我的理解是，當程式功能做大的時候，我們要用到軟體工程的方法的解決，要按照（軟體需求分析，設計，實現，測試等）來做，那麼我們就可以把所做的程式叫做軟體。
1章. 1.1.2在說飛機模型的時候，提出了我們平時討論的程式問題是在表1-1中的哪個層次上談論"程式"呢？
回答：自己還不是很確定，應該是玩具模型的層次吧。
1章感想：之前上課的時候只知道軟體=程式+軟體工程，但是在具體的專案中到底程式和軟體的區別點是什麼還是懵懵懂懂，通過第一章的閱讀使得自己更加了解它們之間的區別。
2章.在2.1.3迴歸測試中，不知道“迴歸測試的自動化”是什麼？
回答：自動化迴歸測試平臺是用來實現對上海移動BOSS計 費系統發生版本變更時進行全量測試，並確保新增功能及資費變更準確且不會對原有功能造成破壞性影響的關鍵系統；該系統採用測試引數配置化、測試結果自動比 對及多種測試用例排程測試，實現對上海移動目前23類業務話單從測試話單準備、解碼、解析、批價、入庫、上發過程中各個環節的自動迴歸測試。
3章. 在閱讀3.2.4職業成長-自我評估的時候，說到CRUD需要一些核心技術和許多控擴充套件的知識，那麼作為軟體工程的學生，在學校除了學習專業知識之外還有什麼方法可以快速掌握那些核心技術呢？
回答：主要是要學習一些軟體工程的理論知識，然後為以後的團隊開發做實踐指導；
4章. 在4.5.2如果兩個人合作，其中一個人老是處於愛理不理的狀態，那麼還有必要合作嗎，或者怎麼讓同伴的積極性加大？
回答：我知道了兩個人合作的重要性，瞭解了影響他人的一些技巧，極限程式設計看起來很厲害。
5章. 5.2.1那裡有很多的軟體團隊的模式，那麼作為學生團隊可不可以用主治醫師模式呢？，這樣會不會讓強的更強，而弱的更弱？
回答：我覺得主刀醫師的能力比較強，其餘的可能只是打醬油，應該不可以。
5章. 5.2.1那裡說業餘劇團模式經常是學生在培訓專案的時候採用的，那會不會學生就挑自己會的知識來做，導致自己的知識沒有提升？
回答：可能會,但是這樣也能夠提升學生的興趣吧。
6章.
問題1、敏捷的自我管理會不會讓整個專案下來一團糟，我不敢確定？
回答：這個不會，因為敏捷本來就是來解決整個專案一團糟
而產生的
問題2、產品負責人和scrum master工作是不是重複了，可不可以工作就讓一個人來做？
回答：不可以，這樣的話就會使得工作加大；
6章 感想：我完完整整地看完了6章之後，還是覺得其它的好理解，就是6.2節看不怎麼懂，因為那裡有點枯燥，其它的比較幽默，還是很有興趣的，我覺得這一章讓我懂得了敏捷流程大概是怎麼回事了，知道它的一些原則之類的
7章.
問題、在7.3節那裡，團隊內部人員，例如負責使用者需求的人員要新增一個功能給開發人員，如果開發人員不爽，最後吵得不可開交，會不會各自拍拍屁股就散了？
7章感想.讓我比較深刻和顛覆我的世界觀的是7.3節第134頁，居然團隊內部會有利益衝突，"例如，使用者代表...會被開發人員鄙視的。"這一段中，覺得我們不是要一起互相來完善的嗎！
回答：團隊內部是有矛盾的，這是因為利益驅使的，每個人都希望自己能夠減少負擔；
第八：需求分析，我覺得需求分析挺重要的，一個需求分析是指對要解決的問題進行詳細的分 析，弄清楚問題的要求，包括需要輸入什麼資料，要得到什麼結果，最後應輸出什麼。可以說，在軟體工程當中的"需求分析"就是確定要計算機"做什麼"，要達 到什麼樣的效果。可以說需求分析是做系統之前必做的。需求分析確定了整個團隊的方向，那麼怎麼多好需求分析呢？
第九：專案經理，專案經理名字好像好高大上，之前覺得專案經理沒有什麼用，現在覺得專案經理有著敏銳問題的能力，察覺未宣告的假設以及解決人與人之間的衝突，同時還需要更多的系統化的管理技能。那麼怎麼才能夠坐上這個位置呢
第十：典型使用者和場景，這一章用了一些容易理解的例子來講，生動有趣，容易理解，暫時沒有什麼問題
十一章：軟體設計與實現
工作時要懂得平衡進度和質量。我一直有一個困擾：像我們團隊這次做 男神女神配 社群交友網，我負責主頁的設計及內容模組，有個隊友負責網站的註冊和登入模組，有個隊友負責搜尋模組，有個隊友負責活動檢視模組。但是一個專案是一個整體的，每一個人所負責的每一個模組都必須關聯起來才能成為一個整體，例如我的主頁完成了50%後，為了檢視整體效果， 發給隊友與他的模組連線起來，如果對方在我的程式上修改了部分，然後同時我也繼續編寫我剩下的內容，雙方都在我那個原本完成了50%的進度模組上做了修 改，那接下來的工作，到底用誰的？實際上兩邊的修改都要用上，然而我不可能等對方修改後再繼續做下一步工作，而對方也不可能等我完全100%做完我負責的 模組後才檢視修改或連線，因為這樣會導致工作效率大大的下降。這個我覺得這個彷彿有點像我們學習 作業系統 時的那個 售票系統 ，幾個視窗同時都要給顧客售票，總得有一個機制管理剩餘的票數，因為不可能能同時幾個視窗成功售出同一張票。
把程式碼修改記整合到程式碼庫中
將開發人員手頭上的經修改過的大碼簽入原始碼控制系統的步驟：
1、根據場景和開發任務來決定整合的次序
2、互相依賴的任務要一起整合
3、在測試場景時，要保證端到端的測試
4、場景的所有者必須保證場景完全通過測試，然後把場景的狀態改為“解決”
開發人員的標準工作流程：
參考《構建之法》P205
在書本中提到了一點，小飛說他在辦公室裡做了10個小時：然後真正能花在開發工作的時只有3個小時，然後工作進展大概只有；兩個小時，他說他的時間 主要是被一些隨機事情干擾了，然後就耗費了許多時間。其實在我的思維中，我一直覺得只要有關本次專案程式的事情，都不算是隨機事情，比如在寫程式的時候， 遇到了一個關於有效性的問題或者是完善的問題，我或許就會改變方向先將這方面做完，我覺得這點並不算是隨機事情，畢竟以後釋出的正式版本還是需要考慮到這 點問題。早考慮晚考慮，早晚都要考慮，老師你覺得呢？你認為這樣想可以嗎？
課後練習與討論：如何對付客戶不買賬的行為？
在我個人看法中，如果遇到這點，我覺得首先我會想是不是我和客戶溝通上出現了問題，在早期我可能會先耐心下來與客戶再次好好溝通（畢竟客戶就是 上帝）,儘可能達到客戶的需求，只要能在我們小組工作範圍之內的，可以理解的要求我們都儘可能的滿足，儘快給客戶一個滿意答覆。但是，如果我們所遇到的是 一位喜歡刁難的客戶，每次都提出一些極端的要求，那麼我覺得對於這類客戶，我們之間也沒有必要有合作的餘地了。
十二章：使用者體驗
-
我們要做一個好的設計，就要做到：
♠誰是你的目標使用者？
♠他們會在什麼時間使用你的產品？
♠目標使用者會在哪裡和你的產品互動？
♠你的產品是什麼？而使用者的期待是什麼？
♠使用者為什麼要使用你的產品？他們的動機是什麼？
♠在眾多競爭產品中，使用者為什麼會選擇你的產品？
♠使用者是如何與你的產品發生互動的？他們怎麼用？在使用過程中有出現什麼問題嗎？
使用者體驗這章，也正是我們小組專案當前正在進行的內容，看完本章對於我們小組接下來的工作有了很大的幫組。
使用者體驗的要素：
1、使用者的第一印象
在設計方面需要注意一下幾點：
1、我們所面對的典型使用者是誰？
2、使用者初次體驗非常重要，這點必須要認真考慮。（在使用者使用次數少的功能上少花時間，要突出程式的主要功能，特色有價值的功能。）
主要涉及到5個“W"和1個“H”上:
即：WHO誰是目標使用者：
WHEN使用者何時會使用我們的產品：
WHERE使用者何地會使用我們的產品：
what我們的產品是什麼？特色在哪裡？
WHY使用者為什麼會選擇我們的產品，哪方面吸引到了使用者？
HOW使用者如何與我們的茶農發生互動的？
How :使用者是如何與你的產品發生互動的？他們怎麼用？在使用過程中出現了什麼問題？
2、從使用者的角度出發考慮問題
從書本上看到那個銀行假幣投訴的例子，簡直是無法理喻，這完全是阻斷了使用者使用的路徑。
3、使用者需要幫組，但是使用者沒有那麼蠢
一些簡答的解釋，如果太多了，就會變得冗餘重複囉嗦了。
4、軟體服務始終要記住使用者的選擇
經過書本上對於使用者設計的一些例子“類似於飛機上的服務遙控器”
其實這些問題看起來小，看完之後才感覺到，裡面含有許多大道理、這點，我們沒有實際遇到過，還真一時半會想不到，不過，我覺得在這方面，機組人員必 須經過一番專業培訓，然後在乘客登機的時候，應該告知乘客這些東西，更多的是一種互動的方式來告知乘客，這樣就或許能達到意想不到的效果。
<構建之法>第十三章到十七章有感
第13章:軟體測試方法有哪些？
主要講了軟體測試方法；要說有什麼問題就是哪種效率最高？
回答：每一種都是因人而異的，沒有說哪一種比較高；
第14章：質量保障
軟體的質量指標是什麼？
回答：軟體一個非常重要的指標就是：產品穩定可靠，而且使用者喜歡；
第15章：穩定和釋出階段
軟體的釋出是要有很多步驟的，需要注意哪些問題呢？
回答：主要注意軟體工程研發的各個階段，例如使用者需求啊；
第16章：IT行業的創新
創新一般是要有一定的基礎才行的，那麼怎麼樣能夠讓自己的創新能力發揮出來？
回答：那就是要加強自己的理論學習，而且要不斷實踐與總結；
第17章：人，績效和職業道德
我們以後如果從事這個行業的，那麼需要有什麼職業道德？
回答：首先肯定不要做出違法法律的事情，其次，做出來的軟體肯定要能夠服務人類的，而不是破壞人類的