第一章：
在阅读完第一章只有一个困惑那就是：1.怎样才算是一名合格的工程师？
第二章：
第二章的问题有较多。
1.单元测试要快，既然要快，那同时单元测试要测试API中每个方法以及每个参数，而且同时还要覆盖所有代码路径，那无疑会增加大量程序代码，如何做到快？（章节2.1.2)
2.学生毕业到走向社会成为职业程序员，这过程需要时间，而且国内的程序员又有一个35岁危机，那我们该如何对待？提前转行向管理或者其他方面？（2.3）
3.回归测试要怎样实现？而且还需要自动化？老师一直未讲过相关知识，这与社会发展趋向会不会背道而驰？
第三章：
1. 一个能力出众的程序员要如何融入到团队中去？而不是会被团队排外，不积极就会被看轻，而积极又会被误会抢风头，完全是因为国内环境导致吗？(章节3.2)
2.在3.2节的软件工程师的职业发展中，提到考级，而在社会工作中，实践经验比证书更重要，要是在大学期间就接受这种固定性思维成长，在将来工作中岂不是会影响到以后的工作模式的创新吗？
第四章：
1. 老师上课讲的注释三载代码后面加2个斜杠直接中文解释，更甚的是连变量都要加中文注释，，与4.2.9节中所讲的注释很不一样，那我们该如何选择？应付老师又有可能让这种行为将变为习惯。
2. 结对编程目的是相互监督，更好地开发，但我们在实验过程中却反而不是怎样，而是更容易被队员带入误途而越走越远，还远不如分模块写效率更高，时间更快，结对编程反而更费时，为何还要推行这个方法？（4.5.2）
第五章：
在5.3节的开发流程中，个人或者是小组中，大多都是使用写了再改模式，这也可以更快完成，在前面也提到要降低任务交付时间的标准差，这也能更符合，为何不提倡，而只说对实际用户，解决实际需求来说缺点太大？在团队中，写实际软件过程中，更多的也是分模块来写，并想不出有何缺点。
微软的软件团队的模式是什么？他们是如何开发的？
第六章：
敏捷流程在我们的学习过程中就是我们常用的想到什么写什么吗？
第七章：
在7.2.5中说商业项目要重视市场和用户，技术三第三位，当然这本就是商业在前面，但是没有高深的技术支持如何能更好让项目顺利完成，让用户体验一流的服务，在各种创业大赛中，所谓的商业项目也是来自于一个好想法好点子，难道这不更应该需要技术去实现吗？（顺提第六章的敏捷流程，看完后云里雾里，不懂，是我没抓到核心思路还是因为其他？）。
在7.2.2中提到：如果发现你做的事情对项目的远景没有帮助，你应该跟老板提出来。对于这种精神，可以应用到其他工作上，而前提却是老板给你安排的工作，是不是应该先想一想老板为什么这么安排，自己是不是还没发挥出来，是自己原因而没有做到正确的事。
“我的责任是把事情做出来，而不是讨好所有人，让他们知道我按照他们的意见做了”我更赞同前半段话，但“我按照他们的意见做了”是不是最终还是要按照别人的建议来做？（7.2.4）
对于MSF基本原则中的九条原则，第7条说投资质量，我觉得毫无用处，在程序员写代码的时候就已经有对自己代码质量的清楚认识，而不是放在这边而·另外提出来，而且学习所有的经验应该放在最后才更合理。
第八章：
在8.7中的分而治之里说需要一个角色出来，领导大家，PM的重要性在我们实验的团队中却显得没什么用处，
并没有体现出他的价值存在，然而也无法解决队员的一些人没事干的问题，我觉得一个团队中应该是有一个
实力够强的人物，不要队员实力偏差太大会比这个PM更有帮助。
第九章：
在PM中，我个人更赞同实力在团队中的中上游的人来担任，而不是只善于交际管理者，这样，信服力会更强，
而不是变成泛泛而谈，最终导致项目失败。特别赞同PM和队员因对项目投入的认识不同而产生的误解，高估
或者是低估队员能力。
第十章：
在前期花费时间做好的spec却说不能过于依靠，那为何不把时间直接用来开发新代码？
对于个别用户的要求超出团队能力，那要改如何做出决定？
第十章：
1. 在10.1.3中，经过分析，得出说要 “ 宁可从小部分人出发，要非常明确地定义谁是我们的用户 ” ，这不就是说要“ 玩情怀 ”了，
那后期为何还要去扩充功能，拉取更多的其他用户，那不更应该是把精力放在核心技术是完善我们原有情怀用户的体验？
2. 在10.2的规格说明书中，要认真做好，但现在的人（年轻用户群体）有问题都是网上百度，而不是自己看说明书，且以前的有
些功能变成现在很多人都有使用，却不加入说明书，那不就是说明员工没有很好的和用户沟通以及后期的跟踪调差咯？很明显的
一个列子：现在的android手机都有一个很经常使用的就是设置里的开发者选项，但是在所有的android手机的说明书中却一直没有加入，也没有介绍这个
第十一章：
在这一章中说到每日构建，但每日构建具体是什么？我还没有弄明白，是每日总结？小会议，工作啥的总结？or提纲？
第十二章：
用户的第一印象中最先提到的是用户界面，对于这个更多的应该是后期用户，只有他们才更关心眼睛看到的形色，而资深用户更关心
的是产品的内容，产品的简单流畅体验，这方面我比较赞同雷军的 “ 极致，快 ， 口碑 ” ，在拉取新用户前去做好更多酷炫的界面功能，
我们更应该是考虑原有用户的使用感受去提升程序的“快”。
第十三章：
对于这章的测试，我们只是简单提了一下单元测试，其他测试都没有，这章相对来说，几乎为零，看了也不知道怎么做。
问题就更别说了，等周末有时间在回头看看，再更新补上问题。
第十四章：
团队中角色越界要如何处理？团队的不相互体谅如何解决？
第十五章：
对于我们团队实验来说，在测试没有什么bug之后，完成打包apk，就没有继续去加入新功能，顶多就是改改界面而已，
完全无法做到像书上讲的那些。
第十六章：
创新是需要一定的资金预算，既然在原公司团队中被压制，不允许，那何不拿出一个雏形，再去找天使投资人？当然
在国内可能会比较难，但找到了相同想法兴趣的人再一起努力就应该更简单些了。
没有一定的专业基础知识而想出来的创新几乎是比较少的，就算他们说都是在他们拿手领域之外发现的创新，也是因
为他成为一个专家，想要成为应该专家，不可能只是单单涉及一个领域知识，你让你一个没有接触过计算机的人来创
新计算机方面的一个技术是几乎不可能的。
第十七章：
一个团队的融合最短可以缩小到多长时间？一俩个项目？在还没融合之前应该会在前面被当作“田园犬”，“野狗”踢出去了，
觉得自己的想法很危险，老是往相反的方向想，自己就属于“野狗”型。
在团队中，最难搞清的就是自己在团队中的投入级别，以及别人对自己的期望，而且现实中他人都会错估队员的实力，有
没有更好更快的方法找到自己的地位，以及其他队员对自己的认识？