第一章：概论
1.2.5节
问题：所谓的软件“足够好”指的是做到什么程度？
仔细阅读第一章后，还是存在一些疑问的，对于什么才算是“足够好”的程序和程序存在bug是好还是坏？存在疑问。我们运用目前为止所学的知识来编写代码，常常都会做出一些带bug的程序，那么我们是该把一个程序做的怎样的“足够好”后才发布呢？是没有存在bug了，还是尽管存在bug，但函数功能都实现了才上交呢？
答：可以实现基本的功能需求，加之大体上没有什么bug就可以了。
第二章：个人技术和流程
2.1.2节
问题:由结对编程或团队开发的程序，该由谁来写这个单元测试?
对于“单元测试”这个词语，虽然表面意思很清楚，但一开始我是不清楚的，百度了一下这个词的意思是指对软件中的最小可测试单元进行检查和验证。这个应该指的是个人技术，书中提到单元测试必须由最熟悉代码的人（作者）来写。
答：现在想想，答案很明显了，应该有编写该软件代最
第三章：软件工程师的成长
3.2.4节
问题：如何自我评估？
我们的目标大都是如何成为一个合格的软件工程师的，该如何去评估我们的现在的成长过程呢？
答：自我评估回顾自己做的代码，看看是否按时完成，我觉得还可以请队员去评价自己，自己也可去评价队员做的如何。
第四章：两人合作
4.5.4节
问题：如何更好地结对编程？
对于结对编程，我现在还是不能够很好的处理这个过程，毕竟两个人之间还是有差异的，有时对于编程的整个思路都有不同，该如何去处理？
答：我觉得私下的交流也是能更好的促进结对，增加结对伙伴的感情
第五章：团队和流程
5.3.2节
问题：瀑布模型适用于我们学生结对编程吗？
答:我认为可以值得一尝
第5.5章 开发流程
问题：5.3节我看了课本的一些开发流程，有很多，有瀑布开发流程、RUP和老板驱动流程还有渐进的流程，这些都是一个团队所运用的软件开发流程，那么在两人的结对编程中，可有哪些流程适用？
答：跟之前一样，我觉得这些流程都可以值得一试
第6章 敏捷流程
问题：6.2节敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。zai 6.2节中定义好任务究竟是什么？书上敏捷第三步中有个例子写道：”去你的,要改主意，也要等老子冲刺再说！“，这句话我不是很理解，万一产品负责人改变主意，重新确定好任务，那么程序猿还得将之前的任务继续“冲刺”下去吗？
答：负责人就应该明确一点，如果目标都不明确，那么这个团队还敢做下去吗
第7章 MSF(微软解决方案框架结构)
问题：7.2.5节看了第7章，里面故事挺多的，再7.2.5中重视商业价值，提供渐进的价值，我在想，开源的软件算不算是有商业的价值，如果开源的软件突然收费，用户又会如何选择，就如马云的阿里巴巴到现在为止都没有加收服务费，如果加收服务费后，他们的公司的前景会如何？
答：我觉得这是一种大胆的做法，不过有付出就应该有回报
第8章 需求分析
问题：8.6 在这一章节中，说的是计划和估计，我觉得这是编程最基础的问题吧，如果不能很好的估计出编程所要写的时间，就说明对编程没有足够的了解和认识，但是我在想，如果做一个工作量很大的软件，有些可能难以估计出时间的，而且还要整合各个人写的功能部分，这时该怎么去顾及呢
答：估计时理应了解队员的编程能力程度
第9章 项目经理
问题：项目经理就是PM，在这一章节中，内容比较少，在9.3节中，标题就写到PMzuo开发和测试之外的所有事情，那么PM岂不是要做很多的事情，会不会把PM给累坏了，书中写到PM是带领团队达成最重要的目标，并保持团队的平衡，其实PM要做的具体内容是什么呢？我还是不清楚
答：PM应该就是管理整个团队的，这个责任重大，还要兼顾其他基本工作
第10章 典型用户和场景
问题：在10.1.3中怎么才可以准确的定义用户典型呢， 还有如何去验证定义的典型用户是正确的
答：可以模拟用户场景
第11章
问题：在11.2.3节构建大师具体需要做额外的那些事呢
答：我的理解，顾命思义就是需要做构建这些方面的事
第12章
问题：在12.1.4这节中，说道短期刺激和长期影响，显示生活中，似乎短期刺激也许很没什么实际用点，那么短期刺激的功能是否值得去实现呢
答：可以一试，再看看效果如何
第13章 软件测试
问题：13.3.2节：在这一章中内容很多，很多都是有关软件测试的，那么测试文档中要写进什么内容？
答：写代码功能，结构，变量，等这些测试
第14章 质量保障
问题：14.1.3节;书中写到软件工程的质量会影响程序的质量，因此软件工程的质量很重要，那么何如去衡量软件工程的好坏
答：重要的是看最后做出来的成果
第15章 稳定和发布阶段
问题：我们团队编写代码完成一个程序后，该由谁来负责发布呢？
答：产品负责人
16章 IT行业的创新
问题：16.4节看了这个魔方小故事，怎么才能创新后不被别人超越呢？
答：创新后，又有买点
17章 人，绩效和 职业道德
问题：17.4节中，写了萝卜与白菜，萝卜是快了不洗泥，白菜是慢工出细活，一段时间后项目结束了，萝卜的绩效看来应该是比白菜高，到白菜做的功能比较稳定，没有需要特别多的修改，为萝卜虽然写的功能多，打死你bug也多，维护的时候就要花入更多的 时间去修复了，那么我们应该是做一个白菜还是做一个萝卜呢？
答：我倒是喜欢做个白菜