第一章：概論
問題：看完這章后，了解了一些程序員都知道的名言、推論等；像"程序=數據結構+算法”、"軟件=程序+軟件工程"這些。在1.2.3這節內容上知道軟件工程與計算機科學是息息相關的，那么在那么多的計算機科學領域中，我們應該往哪個領域走才能夠學得更快，更好，更實用呢？
答：我覺得吧，計算機科學領域中的理論計算機科學在我們當今社會中是比較實用，更快，更好的！
第二章：個人技術和流程
問題：看到這章時，首先吸引我的是這句話“你的RP是由你的程序質量決定的。”雖然我不是很理解這句話，但好像說的好有道理;那么問題來了，一個好的單元測試有沒有唯一的標準？除了課本是介紹的，其他的還有是什么？
答：一個好的單元測試是沒有唯一的標準的！這要看自己的認知了！
第三章：軟件工程師的成長
問題：對于3.2軟件工程師的職業發展這一節，作為一個學生，我們現在所學習的知識是很有限的，該怎么選擇在哪個方面追求“專和精”，在哪個方面達到“知道就好”的水平，我們該用什么方式來實踐去豐富自己的經驗？
答：首先想表達的第一個觀點就是選擇比努力更重要。正確的選擇是如此重要，沒有明確選擇的行動就是我們平時所說的瞎折騰,瞎折騰的結果就是無序導致無效。
第四章：兩人合作
問題：在4.5結對編程中，有這么一句話——沒有“我的代碼”、“你的代碼”或“他/她的代碼”，只有“我們的代碼”。那么問題來了，既然是結對，那兩個人應該如何分配好工作，兩個人在一起工作總會有意見分歧的時候，該聽誰的呢？要怎樣才能做到有效率的結對編程？
答：這個就要看主要負責人的做法了，按照個人的特長分配好工作才能更好的完成任務。當有意見分歧是時，要冷靜分析問題，結合實際，選擇更好的意見。結對編程為軟件開發團 隊帶來的好處已經廣為人知，但是要有效率的實施結對編程，不僅需要團隊的成員相信結對編程的益處，更重要的是，要全身心的投入。
第五章：團隊和流程
問題：一個好的團隊能夠使我們更有效的完成任務，能學到更多的知識，更能促進隊員之間的感情。那么在眾多的團隊模式和流程中，我們該怎么選擇適合自己的團隊呢?團隊在開發流程中，應該注意哪些主要的問題？
答：我想應該選擇擁有了一支具有很強向心力、凝聚力、戰斗力、的團隊，彼此間互相鼓勵、支持、學習、合作！才能不斷前進、壯大。
團隊有一點是共同的，即需要有規章來進行自我控制。規章對于團隊的成功起著關鍵作用，它在團隊發展的最初幾個月里便確定下來，一旦被確立，它們就不會輕易更改或修 正。團隊規章的任何變更需要大量的時間，而且常會引起其成員的不安。團隊負責人在確立規章方面起著重要作用，團隊通常以其成員遵守規章的程度來評價他們；最遵守規章 的成員最受尊敬。
第六章：敏捷流程
問題：什么是敏捷，而在軟件開發流程中，是不是都會選擇用敏捷的做法？該如何選擇敏捷的適用范圍，又該怎么衡量一個開發流程是否對當前的項目或團隊有效？
答：敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備 可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。
在軟件開發流程中，并不是都會選擇用敏捷的做法的！還是會有選擇用其他的方法！
衡量一個開發流程對當前的項目或團隊有效的衡量是非常重要的！要根據自己的實際情況來衡量這些的！
第七章：MSF
問題：MSF團隊模型中每個成員角色都是同等重要的，那么要如何保證每個角色發現的問題都能得到處理？當角色的利益發生沖突時該怎么辦？
答：這個嘛，畢竟每個人的任務是不同的，而出現的問題也不是一下子就能解決！要妥善的處理好才能完成下一個任務。當角色的利益發生沖突時要及時處理好，不然后面的任務就 很難的完成下去了！
第八章：需求分析
問題：在8.6節內容上說到需求的復雜程度和技術的復雜程度，不是很好理解書上說的，有簡單些的說法嗎？
答：如果一個程序員已經做過多次相關的銀行項目，其實不像外人看的那么難。
第九章 項目經理
問題：是不是所有的好功能都是由PM主導的？PM又如何找到需求呢?
答：并不是所有的好功能都是由PM主導的！還有一些好的功能是有其他主導的！
PM要找到需求得做好準備工作，確定產品的目的，確定用戶原型、用戶目標和用戶任務等！
第十章 典型場景和用戶
問題：怎么樣確定用戶類型,用戶的真實需求是什么？
答：通過和用戶接觸溝通然后拿到數據，把一些設計的原型拿去讓用戶試用，或者給用戶類似的同類產品讓他們去用來確定用戶類型！
要警惕初始用戶需求，其往往只是靈光一現的想法，需求的產生具有隨意性，其可靠性和穩定性往往值得懷疑。用戶的需求是會隨著產品使用的深入而不斷被檢驗的，去偽存 真，要依靠有效的用戶反饋才能把握真實用戶需求。
第十一章 軟件設計與實現
問題：如何對付客戶不買賬行為？
答：首先要跟客戶好好的談談，問清楚原因，為什么不要這的開發，是有哪些地方做得不滿意嗎，要及時改進，給客戶一個滿意的答復！
第十二章 用戶體驗
問題：好的用戶體驗當然所有人都想要的，如果它和產品的質量有沖突，怎么辦？犧牲質量去追求用戶體驗么，用戶能接受嗎？
答：對于這個問題，我想用一個故事來回答會比較容易理解吧！
“在1990年代, 韋爾奇注意到核磁共振機器的通道特別狹窄， 在長達幾十分鐘的檢查過程中, 病人常常有得了幽閉恐懼癥的感覺。 杰克做過類似的檢查, 深有體會。
他問, 能不能把通道做得大一些? 專家說那樣會降低掃描成像的質量。他又問, 對于那些不需要太多精度的檢查, 能否犧牲一些成像質量, 換取用戶的良好體驗呢?
專家說, 他們會考慮的… 然后就沒有下文了。不久, 日本的日立公司推出了寬通道的掃描設備, 并奪取了大量的市場份額。 GE 被動迎戰, 花了兩年時間才趕上對方。”
第十三章：軟件測試
問題：軟件在超過設計負載的情況下是否仍能返回正常結果？會不會產生嚴重的副作用或崩潰？
答：軟件在超過設計負載的情況在仍能夠返回正常結果，而沒有產生嚴重的副作用或崩潰。
第十四章：質量保障
問題：為什么一些成功的公司不用測試人員？團隊應該如何安排QA和測試工作？
答：對于一些成功的公司為什么不用測試人員：
a) 全公司人員經常使用自己的軟件產品！（如果你開發的軟件是航天飛行某控制模塊，你怎么能經常使用呢？）
b)使用log來分析問題可能出在哪里。（我們的一些程序員寫程序都沒有log，那大家看什么呢？）
c)利用用戶的反饋和實時狀態分析（比較過去一小時和上周同一時間的數據來判斷是否有bug。）
d)應用開發商給Facebook報bug。（開發商其實比較不爽，但是FB有時就是無預警地修改API，你除了趕緊報bug，還能怎么著？）
e)很多人自愿給Facebook報bug，這位貼主自稱每月給他的前雇主報13,000個問題。（沒錯，是每月一萬三千個！）
f)最后這位前雇員還加了一句：還有一個原因是，Facebook大體上也不需要搞出太高水平的軟件。
當你的公司也能有a）到e）這樣的文化、流程、開發商和給力的前員工，而且你的軟件“大體上也不要太高質量”，你的確不需要什么全職測試人員！
團隊應該如何安排QA和測試工作：
- 在初始階段（新項目，團隊進入一個新領域，人員剛進入一個項目），每個團隊成員都要盡量打通各個環節，多負責，把所有事情都搞懂，培養通才。
- 當項目/產業發展到一定階段（進入陣地戰的時候），要大力提倡分工合作，培養專才。同時，要把好的工具和流程集成起來，從每日構建，到基本功能的自動化，都要盡快實現。
- 把自己項目的架構和流程做好，讓所有人都能比較容易地進行QA工作，這樣，團隊的“軟件工程質量”才會有提高。
- 培養“大家都要做QA，專人負責量化的Test，有條件多做測試自動化”的文化。
- 要明白自己項目的特點，避免照搬別人的做法。不要聽說某某偉大的項目的開發/測試比例是多少，因此就哭著喊著也要同樣的比例。
- 如果一個團隊是認真嚴肅地做軟件，那他們一定要考慮如何保證程序的質量/軟件工程的質量，以及達到這些質量，需要多少成本。
第十五章：穩定和發布階段
問題：有哪些招數讓我們能以比較大的共識、比較小的痛苦走完“血腥”的流程，需要什么樣的血型團隊才能按時推出優秀軟件？
答：招數：設計變更，ZBB，最后回歸測試，砍掉功能，修復BUG的門檻逐漸提高，逐步凍結。等等！其實任何血型的團隊都可以按時推出優秀軟件的，主要是要靠團隊中的每個人的努力，要團結一致，互相幫助！
第十六章：IT行業的創新
問題：軟件工程的技術和實踐如何幫助創新？創新的招數有哪些？
答：幫助：當然有很多，例如：快速原型，持續重構，在每一個里程碑之后做總結，等等。
招數：自選一個市場上的產品，或者某一大家熟知的公司及其產品，為其出謀劃策，看看如何能夠創新。
第十七章：人、績效和職業道德
問題：在團隊中如何避免“劣幣驅逐良幣”的現象？
答：在一個團隊進行項目的過程中，什么事情都是有可能發生的，當然我們每一個人都不希望這種情況擾亂了團隊的正常運轉，所以要依靠團隊中每一個成員的力量，去控制扭轉他的出現。
文章列表
留言列表
