第一章
问题：软件工程的一个重要任务，就是要决定一个软件在什么时候能够“足够好”，可以发布。那么足够好的程度是什么呢？
答：我觉得足够好有三种类型。第一种是你觉着你的程序一定要做到完美，即使对于有些事情做到完美是不太合理的。第二种是被迫使做到足够好，并非出于你自己喜欢或者自己的意愿，比如说老板的要求。第三种前提是你可以自由选择，但是你选择做到比需要程度更好。因为这能使你获得真实的满足，愉悦和欢乐。或者你觉着这样做能达到自我满足。
第二章
问题：我们应该编写单元测试和回归测试？书上说单元测试必须由最熟悉代码的人最来写，可是自己要怎么编写？怎么知道单元测试对错？怎样才能编写出好的单元测试？
答：单元测试是代码正确性验证的最重要的工具，也是系统测试当中最重要的环节。也是唯一需要编写代码才能进行测试的一种测试方法。在标准的开发过程中，单元测试的代码与实际程序的代码具有同等的重要性。每一个单元测试，都是用来定向测试其所对应的一个单元的数据是否正确。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
好的单元测试有以下几点：
能够协助程序员尽快找到BUG的具体位置
能够让程序员对自己的程序更有自信
能够让程序员在提交项目之前就将代码变的更加健壮
能够协助程序员更好的进行开发
能够向其他程序员展现你的程序该如何调用
能够让项目主管更了解系统的当前状况
第三章
问题：这一节讲了3个职业成长的版本，那么我们适合哪一个版本进行或者说应该综合3个版本来规划自己的成长？
答：我到现在认为比较适合我的是Steve CcConnell版本。
第四章
问题：编码的注释能够帮助自己记忆以及他人理解，那么在平时的时候我们的应该注释什么地方，在正式项目的时候注释应该注意什么？
答：最应该注释的是每个类的是用来做什么的，每一个变量的用途。在正式项目中注释应该注意的是注释是写给程序员看的，不是写给用户看的，不需要别的的，最重要的就是别的程序员能看懂。
第五章
问题：这一节讲了软件团队的模式，当工作的时候我们都会选择比较好的团队，那么好的团队应该具备什么条件呢？如果有两个团队邀请，比较好的团队的风格和自己不相同，一般的团队的风格和自己相似，那么这个时候我们应该怎么选择？
答：好的团队具有以下几点：
1、整个团队具有很强的成就取向，整个群体都具有做好工作的良好愿望，同时团队中每个成员都愿意为团队的发展作出贡献。
2、团队的工作追求卓越，整个群体都希望能以最卓越的工作方式来完成团队的使命，团队内部充满活力，团队成员表现出很强的灵活性，创新精神的竞争精神，团队具有很强的竞争能力。
3、整个团队都强调解决实际问题，整个群体都能从全局的利益出发来分析和解决问题。
4、整个集体都关心团队的名誉，团队内部的每个成员也都珍惜团队的名誉、所在单位的名誉，并经常自觉地与其它单位进行比较。
5、团队内部有一起追求现代化的动力，整个群体都关心团队能否为个人提供各种培训的机会。
6、团队的高级领导人注意人的管理，注重发挥人的潜能，并创造出一种相互的理解、相互尊重、相互支持的友好气氛。
7、每当有新的成员加入到该团队中来，团队都给予必要的帮助，告诉他们应该寄予什么样的期望，应该如何更好的工作。
后一个问题我认为是合适自己的就是最好的。
第六章：敏捷流程
问题：在敏捷流程的冲刺阶段，每天都要开一个例会来报告工作，那么例会中要注意一些什么问题，就像书中所说的，很有可能流于形式，我们应该在例会中报告一些什么，在开发过程中又要注意什么？
答：我觉得在例会中最重要的是让每个人都知道自己要做什么，什么还没有做到以及要怎么去完成没有做到的东西。开发的过程也是如此
第七章：MSF
问题：在7.2.4中，用一个下棋的例子来说明了各司其职，对项目共同负责这一点。那么在开发的过程的如果团队中的成员对你开发提出了不同的意见，要怎么办，虽然例子的最后说明了如果我是负责人，最终还要我自己拿主意。是不是说我们应该坚持自己的做法不要去理会别人的意见呢？
答：通过这次重头到尾的开发，我认为最重要就是一定要坚持自己的意见，不要问我为什么！
第八章.需求分析
了解用户需求是很重要的，但是用户无法描述或者说不能让我们理解他所想要的，而项目人员无法了解用户的真正需求，那怎么办？
答：这个问题其实是开发者与用户的问题，有些问题开发组认为难，用户认为简单，这是两个不同的世界，开发前我认为要有某某功能，其实到最后就会发现想要做出来很难，我相信很多人都有这个感觉。要解决这个问题，我认为只有让两个世界的人了解彼此吧！
第九章.项目经理
才能成为一名合格的项目经理，要做好哪些方面，具备哪些能力？
答：合格的项目经理要做到一下几点：
一、做好工作计划，具有项目的前瞻性
二、大胆管理及时总结
三、做到原则性和灵活性的和谐统一
四、注重工作内容兼顾工作形式
五、不要轻易改变已经形成的计划
六、注重平时的学习积累，提高管理水平
第十章.典型用户和场景
一个软件应该满足各种用户还是专注于某种类型的用户呢？开发者又应该从什么方面去考虑软件服务的用户和类型？
答：一个软件要做好必须先从某一点出发吗，也就是先专注某种用户，在做好这一方面之后在满足各种用户。
第十一章.软件设计与实现
在这一章中有提到每日构建这个问题，那么每日构建一定是每日都要的吗？每日构建中应该注意一些什么问题？应该做些什么？
答：这次的软件工程中我没有做到每日构建，其实每日构建要干啥我都不知道，所以不能回答。
第十二章.用户体验
这一章中有提到不要让用户犯简单的错误，其中提到了飞机上遥控器的例子，那么在我们平时设计软件的时候，要如何去发现这些不容易发觉却又是用户经常犯的错误呢？
答：其实要做到这些很简单，就是多融入生活，很多事情认为理所当然是不可取的，知道在生活中用过之后才知道一个东西的实用性以及怎么样才有便捷性。
第十三章.软件测试
软件测试有很多种方法，那么是不是每一种方法都要掌握，还是说对于不用的程序不同的测试方法比较好呢？
答：还是那句话，适合自己的是最好的！
第十四章.质量保障
在编写程序的过程中，一开始因为从无到有，程序一般很简陋，到程序完成的时候，又因为一开始程序的简陋反而要回去重新修改，那么是否重头到尾追求软件工程的质量，还是让工程大致完成再去追求质量呢？
答：从我自己微薄的经验来看，一开始就追求质量是没有好下场的，亲身经历，做事还是从最基本，最简单开始吧！
第十五章.稳定和发布阶段
发布之后——事后诸葛亮，这一个过程非常的重要，可以把很多开发过程中没有发现的问题发现出来，那么发现的问题应该如何处理？
答：发现问题当然要去解决啦，是尝试吧程序再完善还是在下个程序中解决就看你自己了
第十六章.IT行业的创新
要成为领域的专家，才能创新，这一段中最后提到为什么领域的专家有时候没有领域外的创新者那么有创意？难道是传说中的旁观者清？
答：当初我就认为这就是旁观者清！
第十七章.人，绩效和职业道德
在团队的磨合阶段到规范阶段，往往会出现磨合未成功使得团队处于崩溃阶段，那么要如何避免这个问题，如何面对这问题？
答：问题有时候避免不是最好的办法，我觉得应该去面对这个问题，有时候把问题提出来，反而会更好过。这种团队崩溃的问题是整个团队的问题，提出来大家一起反思为什么团队会接近崩溃，如果一个团队还有救的话大家都会努力的去提出意见去解决。如果没有人关心团队的问你，那么这个团队存在的意义是什么呢？就让他解散吧！