创新真的要顾及到一部分人的利益吗？我感到很困惑，书中提到了很多人都讨厌创新，因为这可能会影响到其他大部分人甚至自己的利益，可是，如果不创新，怎么能开发出新的市场？我觉得这样顾此失彼的做法是有待商榷的。
如何实现单元测试的自动化？这一次的作业中使用到了单元测试，可是我对单元测试还是不太了解，文中提到测试最好使用自动化，可自动化是什么呢？和自己手动测试有什么比较大的不同呢？
什么阶段最适合“效能提高”？
34页：“大家也要注意避免没有做分析就过早地进行“效能提高”，如果我们不经分析就盲目优化，也许会事倍功半。”
书中说到如果太早的进行“效能提高”，可能会导致盲目话，可我认为如果不能再最开始就进行一个完善的算法思考，最后进行提高的话不仅会增加工作量，而且会导致大规模的代码变动，这样难道会更合理吗？
是否在项目正式启动前确定代码风格？每个程序员都有属于自己的代码规范，那么在集体编程的时候，是应该按照一个统一的代码规范来编程，还是按照自己认为正确的代码规范来编程呢？
一个对算法熟悉的程序员和一个对算法一知半解的程序员差别有多大？
如何避免自己成为鹦鹉？
有些人是 鹦鹉 - 他们有漂亮的羽毛, 能说会道, 联系广泛, 能提出很多建议, 很多点子. 但是他们
不执行, 除了一些人云亦云的观点和一些关于架构的空谈之外, 他们没有其他投入. 一旦项目失败, 他们就会
飞到另一个项目中去。 他们的投入级别是 – 围观 (bystander).
遇到技术上的困难时，应该自己解决，还是应该去问别人？
不同用户需求矛盾时如何处理？对于一个程序某个功能，有的人认为是bug，影响个人使用，有的人认为这个功能不错。如何取舍呢，根据用户比例吗？
敏捷流程发生人员变动怎么办？一个团队自然会碰到离职，请假等，敏捷流程要求“冲刺”，但人员变动影响原来任务的分配，其次，缺人手后新人加入也会带来问题，给其他人带来压力，这种情况下如何“冲刺”呢?
每次软件版本更迭都需要需求分析吗？随着软件的不断发展，用户量不断增加，当这个软件越来越大后，用户好像离不开这个软件（竞争者都被干掉了）。软件的发展似乎不再需要用户提什么需求，而是软件想给用户什么功能，用户只能“自己承受”。 需求分析随着软件发展成熟后还有必要吗？现在许多app功能越来越多，偏离了最初的目的，如何看待这种情况？
PM与团队平等相处是幻想还是可以实现？在产品设计过程中可能会发生许多分歧，谁也说服不了谁，这样是不是反而影响效率？表格中一个团队可能有多个PM，这些PM发生分歧又该如何解决？如果出现一个PM有了决定权，那么是不是就无法平等讨论？
测试人员在什么时候进行测试？书本上说测试人员进行测试几个模块之间的联系，具体时间如何确定呢？开发人员利用单元测试进行测试基础功能，如果测试人员也要进行测试，开发人员能否不再进行单元测试，把工作都丢给测试人员。如果测试人员等到开发后期进行测试，则可能导致整个程序改动。如何确定测试人员开始测试的时期呢？
在第五章团队中的角色和合作中提到“开发项目的时候才觉得实际情况和书上讲的都有一些出入，偏偏一些重要的出入书上没有提。我们很多人是边看asp.net的书, 边开发asp.net的项目，这相当于一边看医学书一边动手术。”在我看来这个是初期项目开发者都会遇到的问题，其实在一定程度上确实影响了自身的开发效率，那面对这样的情况应该要怎么处理呢？
在第五章的团队不同的投入中作者提到团队中有一类人为鹦鹉：“他们有漂亮的羽毛,，能说会道，联系广泛，能提出很多建议，很多点子但是他们不执行,除了一些人云亦云的观点和一些关于架构的空谈之外，他们没有其他投入，一旦项目失败, 他们就会飞到另一个项目中去。”这种类型在团队其实是很影响队员效率的，那应不应该适当的提醒她呢？或者应该怎么处理这样的情况呢？
在第九章创新方面作者提到了两种如何在一个创新性的市场上后来居上的观点，分别是“改变游戏规则”和“转换目标用户”。其实我认为“居上”最多也就是几乎齐头并进，但是还是无法超越之前的产品，这样的想法是否正确呢？对于这个观点，我觉得最好的例子就是拼多多的崛起，在淘宝已经占据了绝大部分市场份额的时候，拼多多以一个“砍一刀”的规则重新进入了大众的视野，同时商品定位比较亲民，他利用了大众心理制定的政策，果不其然，确实很成功。同时，在后续的使用过程中我们也先后发现了其他app也出现过类似的板块。这其实就正好契合作者所提到的这两个创新的办法，但是在市场上看淘宝还是大部分用户的第一选择，因为前者可以向新的创意学习，可能两者的起点就是不同，但是不可否定的是拼多多的创新确实做的很成功。