第一章 《概论》
软件工程就是一项工程，那么在开始阶段，就要设计这工程的详细图纸，那么如何在还没开始“施工”时及时考虑到“施工”时会出现的问题或者遇到的困难呢？
答：设计这个环节就需要凭借我们之前做“工程”的那些经验来去判断新的工程可能出现的问题或者困难。
第二章 《个人技术和流程》
在单元测试中，有时候我们去测试时只考虑的比较片面，只考虑几组数据结果正确就认为程序正确了。但有时会出现特殊性的数据会使程序结果错误，那么如何去考虑好全面测试数据去测试？
答：可以分别给多个人进行多组数据的测试，因为如果只有一个人做这个”测试员“，那么肯定会存在局限性的，如果多个人多个思维去测试，那么效果就不一样了。
第三章《软件工程师的成长》
个人能力高低能否就在项目中起决定性作用？
答：个人能力在团队中起很大作用，但是并不能在项目中起决定性作用，因为项目是要整个团队来做的，需要的就是合作与沟通，并不去要那些”个人英雄“。
第四章 《两人合作》
当两个人合作时，如果出现不同的实现方法，但最终只能选用一种方法，那么双方都持不同的意见要选用自己的方案，那么此时如何解决？选方案时要考虑到什么因素？
答：那么就要看哪种方法的效率和可行性比较高，因为怕有一些方案难度比较高或者效率比较低，那么就可以跟对方说优先考虑放下这个方案了。
第五章《团队和流程》
当组建一支团队后，如何快速提高团队的工作效率？
答：先跟队员互相熟悉，了解各个队员之间的优点与弱点，然后进行优势互补，取长补短，形成一支有默契的团队。
第五章
第五章后面主要介绍了瀑布模型，和瀑布模型的变形。那么瀑布模型是否适应个人或者只有两个人的开发呢？
答：第一、瀑布模型不适合客户需求不断变化的软件开发，尤其是客户的业务管理的软件，业务随着市场变化，而软件初期的设计可能已经大大变化，而后期的需求更改成本是开始的10倍基数。在ERP盛行的软件市场里，一方面市场带动需求变化，另一方面初期客户对需求描述不清楚，都为瀑布模型的使用团队带来困难。
第二、瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣，工作很枯燥，没有激情，编程成了一种没有创意的机械劳动，这让一向以高科技为标志的高级程序人员大为恼火。面对以上的工作，所以瀑布模型并不怎么适合个人或者两个人的开发
第六章
6.2 在scrum meeting中如何做好总结和计划，其中需要注意些什么？
答：说明在之前遇到过什么样的问题，和是否能解决掉问题，如果不能则想出备用方法。
第七章
MSF基本原则中含有保持敏捷，预期和适应变化，那么它是如何在适应变化中保持敏捷的呢？
答：首先要保持敏捷，然后再开发过程中可能你会发现出客户还没发现的问题，然后跟客户或队员沟通好，看是否需要这样的修改。以免功能做好后客户又要提出这样的要求，那样的话就花上非常多的时间了。
第8章：
本章介绍了软件的需求类型和获取用户需求的常用方法和步骤等等。那么一些软件的获取方法的途径，但是一般我们软件开发某一类的系统，那么紧靠客户提出的要求和日常的用户的调查问卷等等就可以将系统的需求分析出来吗？对于任何一类系统软件，它都必须要方便到用户，让用户使用起来非常方便，可靠才行。那么我们应该怎样去切切实实把平时我们注意不到的细节功能发掘出来呢？
答：可以问相关职业的人员，或者对他们做个调查，看看他们平时出现什么需求再对比方案，看有什么需要改进的。
第9章：
本章讲述了项目经理的由来和需求和他的工作内容。那么一个好的项目经理必须具备哪种潜质？
答：有一定的项目概念和足够的开发经验，还有具备一定的组织能力。
第10章：
本章介绍了典型用户而和典型场景。那么我们怎样去写典型用户和典型场景？是根据设计者在需求分析的时候就模仿用户，设计场景还是怎样？
答：这个就需要看各个项目的需要，因为有的是需要在开始时就需要明确的目标，有的是需要demo做出来了后才能确定的。
第11章：
本章介绍了典型的开发流程和开发阶段的一些方法，如：每日构建，小强地狱、构建大师等等。小强地狱方法中的小强数量这个阀值怎样定义才算合理？
答：这个”阀值“就需要通过一系列的算法去确定，确保它不会被定义偏离标准太大。
第12章：
本章介绍了用户体验。考虑用户体验的各种角度。用户体验主要是来自用户和人机界面的交互过程，但是如何每个人的体验结果不同，那么我们如何去做呢？
答：我们就要参考绝度大数人相同的体验结果，而那小数部分就要我们自己斟酌看看如何去修改，达到给他们最好的用户体验。
第13章：
本章介绍了软件的各种测试方法和设计方法以及测试报告的文档编写。书本上提到说测试设计的说明书不要一味依赖于模板，那么如果不按照模板来写的话，那我们应该写哪方面的资料呢？如果测试过程中没有发现是否就不用写相关的文档呢？
答：那就要选取我们哪些是真正需要说明或者需要注意的事项，如果一味太依赖模板的话，有一些是无用的，写进去也是浪费大家的时间跟精力。
第14章：
本章主要介绍了软件的质量要衡量软件在功能、成本、时间三方面满足利益相关者的需求。软件开发过程中存在的各种风险，我们应该怎么样评估来预计风险？
答：我们在开始时就应该做足风险估计，如果出现了意外的情况，就要在这个三方面进行取舍了。
第15章：
本章介绍了软件项目的会诊和项目的总结、回顾以及软件按时发布的各种招数。如果软件因为某一些功能所耗的时间超过了预期，但是所剩下的时间已经不多了，那么这些功能是怎么办？是继续耗时间在上面还是从项目中去掉这些功能？
答：那么就先应该放下这个功能，把剩下的时间把后面的任务先完成再回顾解决这个问题。
第16章：
本章介绍了IT行业的创新，创新者的困境与时机和先发优势与后发优势的区别。那么对于像我们的开发者来说，目前还未对这个行业有太深的认识,而且这个行业在这几年来发展相当快，相当成熟，那么创新对我们来谈是不是言之过早呢?
答：那么我们现在就是观察目前的状况，然后看看是否缺少哪方面的发展，还有预测一下它的可行性等等，等到以后有机会再往自己想到的方面发展。
第17章：
本章主要介绍了软件工程师的道德规范，如果一个团队中出现一个核心人物，但是他不让其他人做事，那么我们应该怎样去处理？
答：要努力跟他做好沟通，虽然说是核心人物，但是也不能把团队放下，毕竟一个人能力是有限的。