高效程序员的45个习惯：敏捷开发修炼之道（4）

沟通是项目顺利完成的基础，达成共识是项目顺利完成的保障。

问题一、编码过程中发现需求有问题，怎么办？

不能只站在开发的角度上来解决问题，要从业务的角度来做决策。在需求评审会上，我们没办法找出所有问题，有些问题只有在编码的过程中才会发现。这个时候最好的方式主动发起一个小范围的会议，产品负责人、开发负责人、项目经理一起讨论，先详细地解释遇到的问题，并一起讨论后做出决定。如果早上有晨会，可以在晨会上把问题抛出来，确定讨论任务和时间，但不做讨论。

问题二、敏捷开发就是不需要写文档？

错了，敏捷开发宣导的是“不要在前期做大量的设计”并不是说不要设计，这里的设计分两层，战略和战术。敏捷要求做好战略设计，设计关键流程。它能帮你深入理解需求。战略设计要求把总体框架描述清楚，而不需要深入到具体的细节。因为你当前需求的设计是基于当前对需求的理解，一旦开始编码，很多理解都会改变，设计和代码实现都是会变化的。所以为了避免前期设计时间过长，只做战略设计。具体哪些文档写，哪些不写，可以根据自己部门的情况来达成共识。

问题三、如何知道一个设计是好的设计？

代码很自然地为设计的好坏提供了最好的反馈。如果需求有了小的变化，它是否仍然容易去实现？如果小的需求变化就带来一大批基础代码的重构，那么设计就是需要改进的。

问题四、新技术层出不穷，如何决策要不要选择一个新的技术？

根据自己的需求来选择技术。首先你得明确你需要什么，要解决什么问题。根据具体的问题来评估使用新技术。其次，要了解新技术的利弊，每一个技术都是有局限性的。最适合的才是最好的。最后，你要清楚使用新技术需要付出的代价。

会议讨论必备工具：白板。