P117 当自己想认领某个任务时，发现自己不具备足够的知识去完成这个任务，而团队里面其他成员对这个任务不感兴趣时，该怎么办？有些人认领的多，有些人认领的少，忙闲不均怎么办？
P142 高质量的代码在当用户改变了需求，并且这个需求非常模糊时，是否要舍弃掉之前的高质量代码，选择重新编写？
结对编程两人水平相差较大应该怎么协调？
团队模式会因为哪些因素而发生变化？
长期使用但逐渐厌弃该软件，这是用户的问题还是开发团队的问题？
在角色-PM这小节，有个标题“PM做开发和测试之外的所有事情”，之前也学了一点和产品有关的知识，发现PM至少要学会Axture、墨刀等这些软件来画产品原型图。除此之外，和程序员的沟通交流也十分重要，也有过这样的疑惑：对PM来说，开发和测试并不是硬性要求对吗？
本书第4章“两人合作”中介绍到：代码复审核查表的其中一项内容是“代码容易维护么？”因为容易是个相对的概念，于是产生了这样的疑问“代码的容易维护是站在复审人员认为的容易还是代码达到了团队规定的编译警告等级”？
讲义中将代码量比作树叶量，“代码量等于树叶量，当作如是观。 ”，那么，是否代码量越多，该程序员能力就越强？
为什么要进行单元测试？
书中第17章第4小结提出了一个萝卜与白菜的问题。大致对比了两种开发风格：一种是“萝卜快了不洗泥”，开发速度很快，但bug量惊人的萝卜类型；另一种是“慢工出细活”，速度较慢，但能赶上截止时间且功能稳定，bug量少的白菜类型。究竟哪一种类型的开发者更受青睐？
书中关于“代码复审”的章节有提到：鼓励不同职责的成员交叉相互进行代码复审，有利于相互学习。但如今大部分项目开发都奉行前后端分离的模式，各自专注自己精进的部分，甚至存在前端开发者不懂后端语言、后端开发者不懂前端语言的情况。这种团队协作的执行成本和对开发者的要求是否过高？
似乎大多数人都对官僚主义嗤之以鼻。而书中第5章第2节列举的十几种软件团队模式中，官僚模式格外显眼。软件开发团队中是否也存在官僚主义？这种官僚主义是否与在行政机关里很常见的官僚主义有本质上的区别？如何避免团队向官僚模式发展？
书中第3章第1节用足球运动员类比软件开发工程师。除了体能、技术、意识、配合、临场应变等专业领域的品质外，还需要良好的沟通能力。那么软件开发工程师除了必备的专业知识和技能以外，还需要具备哪些良好的品质呢？
计算机硬件的能力在快速发展，为何服从硬件的软件却没有提速？
一个工程师具有绘制完整UML图的能力，那么他是否具备对通用的软件设计思想的理解？
结对编程双方水平上的差距，不会导致决策权力偏向一方吗？
我看了书中p363的这段文字：
螳臂当车
在游戏中，经常有一两个同学逆历史潮流，提交一个99.999之类的分数。但是从大趋势来看，这些捣乱分子对大局影响不大。我经常看到几个同学面带微笑小声商量，一起提交几个最高分来搅局，但是G-number还是由大多数人决定。
作者的文字对搅局的同学带有贬义，但从另一个角度看，搅局的同学试图打破现状，实现颠覆性的创新。就好像对于电报来说，电话的出现是一种搅局；对于传统的制造业来说，机器的出现也是一种搅局。这种从传统的收敛于0的结果中跳脱出来的思维方式，难道不是创新者应该具备的吗？
我看了书中p363的这段文字：
赢者通吃
这个游戏规定第一名得到全部的分数，第二名（不管多接近）到倒数第二名都是0分，最后一名还要倒扣分。软件行业就是一个赢者通吃的环境，最后一名还要把自己的身价倒贴进去。
有这个问题：软件行业真的是一个赢者通吃的环境吗？赢者通吃，也就是所谓的垄断。举个最近的例子：华为开发的鸿蒙系统有望打破安卓系统的垄断。与其说软件行业是一个赢者通吃的环境，但所谓的赢者还会遭到后进者的打击。我更认为软件行业是一个不断创新迭代的环境。
文中说到：
“70% 的创新者说, 他们最成功的创新, 是在他们的拿手领域之外发现的。”，
虽然文章中举了些例子，但我对这个比例还是有疑问。按我个人的经验，一个外行人如何能在其他领域创新呢，在某领域创新难道不需要精通这些行业的知识吗？就算真的出于某些偶然的因素，他做到了，但这个比例也不应该是70%啊，难道大部分创新都是偶然？鉴于个人观点的片面性，我就这句话百度到了几篇相关文章博文，其中有赞同的，也有反对的。但并没有直接证据说明这句话的对错。