以前提问题的博客
对以往疑问的解答
第二章 个人技术和流程
单元测试必须由最熟悉代码的人(程序的作者)来写。
经过一次项目后，才知道单元测试可以由程序的作者，也可以由专门的测试人员写。但是基于敏捷开发，我发现还是由程序的作者来写最为提升效率和质量，每个人可以在写完一段代码后就将单元测试完成，这样不仅提高了测试的效率，也能将bug及时找出，无疑也提升了代码质量。
第三章 软件工程师的成长
这个毛病早就被归纳为“过早的优化是一切罪恶的根源”。
过早的优化是肯定有其缺陷的，在项目中，我们都是将基础功能实现后，并确保其功能正常实现后才进行优化体验，如果在刚开始就进行优化，无疑会使得代码繁琐冗余，可能最后甚至连基础功能都无法实现。
第四章 两人合作
驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间。
在经历过结对编程后，我发现结对编程这种形式本质上并不能明显提高编程效率，而是提高了代码质量，不断轮换角色，也就不断保持清晰的大脑，不断在全局和细节中跳跃，使得思维不会僵化，明显地提高了代码质量和水平。
第十四章 质量保障
分工之后，每个角色为了自己的绩效而优化，会出现局部最优而全局未必最优的情况。
如同我的第二个问题"过早的优化是一切罪恶的根源"，在项目中，需要一个PM来统筹项目进度，来避免这种情况，由PM来把握什么时候进行优化，优化哪个地方。
第十六章 IT行业的创新
这个游戏规定第一名得到全部的分数，第二名(不管多接近)到倒数第二名都是0分，最后一名还要倒扣分。软件行业就是一个赢者通吃的环境，最后一名还要把自己的身家倒贴进去。
我们的项目是物理实验网站，也有另一组是在做这个项目，但是到最后发现，我们的发展方向几乎完全不同，他们专注于做物理实验报告，而我们找到了另一个方向——物理题库，我们的方向不同，给用户传达的吸引点也就不同，最终我们有了自己独特的受众，或许在IT行业中，发展出自己的不同，找到自己的方向，也是一种生存方式吧，就如同QQ和微信，同样是社交软件，而它们都存活着，可能也是由于它们自己独特的特点吧。
学到的知识点
需求阶段
大家都知道做设计很重要，而了解用户的需求更是重中之重，它才是设计的前提，只有找到用户的需求点，才能得到用户的青睐，在这个阶段我学到了调研用户需求的一些方法。
设计阶段
我是我们团队的PM，我在设计阶段学到了很多，做设计不是说说就完事了，它需要详细认真的思考，考察用户的需求，考虑能否实现想要的功能，考虑功能的布局等等，最后还要考虑优化用户的体验，总之做设计是开发的前提，只有做好了设计，有了目标，大家才能开发出质量高的代码。
实现阶段
在实现阶段，开发代码是重中之重，而这时更不能缺少了例会，只有大家及时沟通交流，才能提高效率，如果只是一味的闭门造车，那么不但可能代码冗余(存在冗余的功能)，而且甚至可能需要推翻重来，这更是降低了效率。
测试阶段
测试最好在大家写代码的时候就顺便写单元测试，这样到最后测试才能顺利快速地进行。
发布阶段
在做完测试后，最好尽快发布，这样才能收集到更多的用户反馈，为下个阶段的开发做准备。
维护阶段
及时根据用户反馈，进行功能的优化以及用户体验的优化都是很重要的，这样才能让项目走的长远。
理解和心得
结对编程让我了解到了一种新的编程模式，它虽然做不到将效率变为1+1>2，但是它可以让两个人都发挥出自己的强项，使得每个人都能完成更高质量，更高难度的代码。
而在团队项目中，我担任PM，虽然在技术上的收获有限，但是学习到了一些团队相处的经验。在设计阶段考察用户需求，提出构思，经过团队例会讨论，确定团队目标，在开发阶段，及时组织例会，搭建起沟通的桥梁，监督队员进度，及时调整开发进度，动态分配开发任务，总之，通过这次团队项目，我收获了很多。