问题1（第四章两人合作p88结对编程）
我看了这一段文字:
“每人在各自独立设计，实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会剩下很多以后修改，测试的时间。
具体地说，结对编程有如下的好处：
1.在开发层次，结对编程能提供更好的设计质量和代码质量，两个合作解决问题的能力更强。
2.在企业管理层次上，结对能更有效地交流，相互学习和传递经验，分享知识，能更好地应对人员流动。总之，如果运用得当，结对编程可以取得更高的投入产出比（Return of Investment）。”
根据我的实践有这样一个问题：（1）在公司中结对编程，两位程序员难免出现分歧，而且谁都不认同别人的看法时，只认同自己的观点。合作解决问题的效果不好，结对编程的效率会变低，结对编程是不是就没有优势了？（2）还有就是人都有自私心理不愿意和别人分享自己的劳动成果。如果两位程序员不交流，各自干自己的事怎么办？
我虽然认同作者结对编程的观点，但解决结对编程的分歧问题也是很关键的，我觉得由复审者进行代码复审是一种解决思路。对于程序员不分享就是专门规定开小组会，分别分享。（第四章两人合作p88）
问题2（第六章敏捷流程p118）
我看到这一段文字:
敏捷流程：第一步：找到完成产品需要做的事情–Product Backlog.
第二步：决定当前的冲刺（Sprint）需要解决的事情–Sprint Backog。
第三步：冲刺。
有这样一个问题：在敏捷流程中，每一步做的事情都考虑的很详细，但是真正的项目开发中总有些问题做不到的，或者短期很难完成，做不到敏捷怎么办？还有一个软件经常出错怎么办？客户能不能允许软件经常出问题？
总结：敏捷性流程不能适用于任何情况，如火箭发射程序不能出错，一旦出错，后果严重。敏捷性偏向产品可靠性不高，容忍经常出错，需求经常变化，团队人数不多，有资深程序员带队。
问题3(第五章团队与流程p107)
我看了瀑布模型流程：
系统需求——软件需求——分析——程序设计——编码——测试——运行
有一个问题，根据我的实践，我认为(1)瀑布模型这几大流程阶段是完全分开，做完需求，接着做设计，再做编码，没有穿插，但是在实际项目开发中，用户需求是不断在变化的，不可能一次就能把用户需求弄明白。做设计的时候可能需求变多。做测试时候，可能设计出现问题。所以我不认为这几步能够完全分离开。(2)瀑布模型没有收集反馈信息以及改进，这也是非常有必要的。收集反馈信息包含：用户需求是否明确，团队编码规范性，文档的规范性，实现的功能是否满足用户要求，测试是否有缺陷，效能分析。