第一章：概论
问题：看完这章后，了解了一些程序员都知道的名言、推论等；像"程序=数据结构+算法”、"软件=程序+软件工程"这些。在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行业的创新
问题：软件工程的技术和实践如何帮助创新？创新的招数有哪些？
答：帮助：当然有很多，例如：快速原型，持续重构，在每一个里程碑之后做总结，等等。
招数：自选一个市场上的产品，或者某一大家熟知的公司及其产品，为其出谋划策，看看如何能够创新。
第十七章：人、绩效和职业道德
问题：在团队中如何避免“劣币驱逐良币”的现象？
答：在一个团队进行项目的过程中，什么事情都是有可能发生的，当然我们每一个人都不希望这种情况扰乱了团队的正常运转，所以要依靠团队中每一个成员的力量，去控制扭转他的出现。
)
