1 如何避免在产品开发后期不断有重大修改，导致其它模块的连锁反应?
这个问题是一定要尽量避免的，到了后期有重大修改，肯定是因为早期的需求分析以及设计分档部分就出了问题，然后会导致一系列的连锁反应。所以在设计文档的时候一定要进行多次复审，这是整个工程的蓝图，然后才可以进行代码的开发编写。但如果真的很不幸出现了重大修改，我们就只好进行代码重构了。我们可以使用第十三章介绍的一系列测试来进行代码重新覆盖。如回归测试，代码覆盖率测试，以及伙伴测试等，尽量把连锁反应降低到最少。
2 每周进度报告——还有多少事没做完
TFS 的“Remaining Work”是一定要看的，并且看敏捷流程的“燃尽图”。这样可以动态的查看完成进度。有利于对开发周期的把握程度。如果感觉花费时间增加并且人物缺陷缓慢增加，就会有很多可能导致了距离最后目标越来越远。很有可呢是一直不注意小问题，最后小问题从小强变成了庞大大物，拖鞋也无法消灭了。这从侧面也提醒开发人员不要轻视BUG,每一个bug的存在都是有原因的，一定要保持在一定阈值范围中，这样就可以保持整个项目进度了。否则当bug数量过多时候，就会严重的拖延整个项目开发周期。所以开发人员和测试人员一定要协调配合。
3 如何避免诧异的反应
诧异反应在实际与客户的交流中很容易发生。原因是很多客户本身并指导最终成品是什么样子，什么是他们真正想要的。拿我以前的开发项目经理来举例，曾经客户想做一个网上商城，问之要什么风格时候，客户也说不清，最后客户就说弄个和当当差不多那样的。。。差不多那样是哪样啊，当我们连蒙带猜的把完成的项目进行演示时候他们就会说这不是我们商量好的啊，要怎么怎么改，严重的影响了开发和库户需求的匹配。所以，这种时候， 这就要看PM的分析和说明能力了。同时，我们在需求说明中也要从用户的角度去描述问题和解决方案，这样用户才能了解他们最终会得到什么。
诧异反应也有可能反映在在项目开始之前, 有很多开发人员从未接触过此计算机语言。需要自学一段时间才能上手，这照样会造成工期的减慢，所以这种情况一定要规避，避之其所短。即使可以上手，效率也一定会特别低。
4 “团队成员不给力” 的问题
开发过程中除了硬件，软件，还需要有人件才行。良好积极的团队成员能让开发效率事半功倍，糟糕懒散的团队会让开发效率大打折扣。当全队成员都懒散的时候，无论是多么简单的功能模块都会实现的很慢。真是应了“不怕神一样的项目，就怕猪一样的队友”。要克服这个问题，就一定要有每日构建，并且每天都严格按照进度来走虽然书中提到了宽严皆误，但是当团队成员不给力的时候，严是一个非常好的办法。要有很严的规则和流程控制，每天强制完成代码量，这样才能克服成员不给力的问题。
5 我们是在写代码解决问题呢，还是在搭建宏伟的架构?
这的确是让很多开发人员头疼的问题。很多好的框架的确使用起来很方便，就节省开发时间，提高开发效率，但是学习这些框架本身也是很麻烦的事情。并且一旦出现问题就会不知所措，查看厚厚的API，看源码，想想就让人望而却步，所以很多人代码没解决，反倒成了免费的工人去帮别人免费搭架构。其实这种事情也有两面性，当深入了一个框架时候，就会找到乐趣。也许还能再次突破，改进框架，让框架更加友好，自己也成为了一个好的架构师。