关于第4章的结对编程部分，首先谈一谈我的理解，我认为这种方式处在单人编程和团队编程的中间地带，其兼具了两者的一些优点，同时也多了一些缺点。优点很明显，因为人数少，沟通成本较低，不需要考虑团队编程中沟通的问题（关于这一点文中也做了详细的说明）。而人数少不代表效率低，相较于单人编程，结对编程可以分工合作，产生1+1>2的效果。我的问题来自于文中的观点：结对编程是一个渐进的过程，一开始可能不比单独编程效率高，但是度过学习阶段后会有明显改善。那么我可以认为结对编程的一个关键是如何快速地度过有效阶段？关于这个问题文中也说了很多技巧（4.6节），但是这些技巧都是注重花费时间来培养两个人的默契，帮助更好地合作的。这就带来了结对编程的一个缺点：找到一个适合自己的伙伴不容易，相互之间培养默契度过学习阶段也需要时间，在这之前，可能效率不如单人分开编程。人数少的一个缺点是如果有人中途离开，那么很难在短时间内找到一个合适的替代者，毕竟他可能承担了50%的任务！我想知道有没有一些较为有效的方法能够快速度过学习阶段？如果结对的伙伴中途离开，或者中途换人，有没有有效的解决方法？现在的编程很难有两个人一直长期合作，培养默契需要时间，经常变换不利影响大，换人带来的后果比团队编程严重得多，我想知道现在开发者结对编程的多吗？
关于第9章项目经理的部分，提到微软PM负责开发和测试之外的所有事情，其中包括了产品市场定位、优化方向、和各方面沟通等等职责。关于这一部分，我有一个很大的疑问是他们是否也是一个多人组成的团体？他们是否也应该要有一个精细的分工？
在我的认知中，产品定位、市场发展的重要性远远高于软件的开发和测试，毕竟一个不符合主流、不符合需求的软件项目是不会被市场接受的，一旦因为产品定位的问题导致整个团队多个月的成果白费，责任在谁？
在一个10人以下的小团队中，PM负责了客户、开发者之间的沟通交流，还负责了项目开发流程的管理，总之是开发和测试之外的所有事情，如果因为某些原因，该PM中途离开，那么可能直接导致这个项目失败，毕竟PM可能就他一个人！相较而言，开发者的离开可以很快地找到下一位替代者，或者由其他开发者代劳，而PM的离开，导致短时间内开发者需要直面客户，可能之前所有沟通的成果都没有了，新来的PM并不能短时间内接上上一位PM的工作，而且新来的PM可能要更改工期的安排，又会打乱各方面的工作进度。我想知道，有没有比较好的办法可以降低更换PM所带来的坏处？比如更换了一个开发者，新的开发者只需要看懂需求文档等各种文档就能很好地上手工作，而更换了PM，可能会出现更严重的后果，比如新的PM可能认为之前做的工作不符合市场定位，要重做等等情况。
如果有小公司（比方叫A）创新发展出新的产品，在膨胀期或者迷茫期时大公司（比方叫B）中途插入开发一个类似的产品，用自己庞大的用户量来挤压A公司产品的空间，那么A公司该如何继续发展下去呢。如果长期如此，A公司花费心血研发出产品后反而大部分的收益被B收入囊中，A公司还能继续研发创新吗？（事实上也确实不缺乏此类例子，例如近几年大火的自走棋模式，原版刀塔自走棋在腾讯推出云顶之弈后，热度就开始一直持续下降）
在结对编程时，有时候伙伴的某方面的能力会不匹配，我记得在我一开始跟我们的小组进行人工智能课程的实践时，因为我在一开始忙着处理别的事情，在水平上没有跟上组内的一名成员，导致整个项目几乎没给他提供帮忙。个人疑问：如果在结对编程时出现这种情况，是不是应该先让两名成员在项目所要用到的知识水平上处于一个相对平等的状态。然后如果两个对于一个问题起了争执变成了谁嗓门大谁说了算该怎么办。