2.5　事实重于巧辩

确实存在一些与敏捷开发方法有关的、看起来比较玄妙的巧辩，我们会认同其中的一些，但要否定另外一些。这一节简要地检验其中一些最可能误导敏捷开发入门者的说法。接下来所列举的观点都用了“甲，但是乙”的格式。其中，甲指的就是那些巧辩，而乙则是规范敏捷交付方法所推行的策略。这包括以下几方面。
具体的产品需求可能在整个开发周期内持续变化，但是仍需在项目的最初阶段达成关于初始工作范围界定的共识。要做到这一点，你需要在一开始就对项目建立一个愿景。愿景需要在利益相关者的帮助下制定，并且双方需达成共识。为了制定愿景，需要进行一些初始需求预想，这其中就包括制定出高级特性清单。是的，这些细节很可能随时间而改变，但是你仍需要在项目初期就设定好项目的基本目标和你的开发范围。少数情况下，你可能受具体条件的限制，无法将所有必需之人聚集在一起来制定这个愿景，因此这样的情况应该归入重大的项目风险。
简单的设计往往是最优的，但是仍需在产品开发周期的最初完成良好的架构设计。有太多软件开发人员误认为“简化设计”的意思就是从无到有地创造全新的东西。但事实上，简单设计的意思往往是借鉴那些已有的东西，而要做到这一点，最好的方法就是和那些真正了解现有技术条件的人紧密合作。在项目最初，稍花些时间来做架构预想，这样团队就能及早发现他们能够利用的已有公司资源，发现其他可能的架构设计选择，并且从中选出最优的方案。随着时间的推移，可能会不断产生新情况，也可能在必要的时候需要对之前做出的决定进行修改。但是最起码，一个有纪律的敏捷开发人员会三思而后行。
团队应该处于自组织状态，但是他们仍受限（或得益）于整个组织的生态系统。脑力劳动者，包括专业开发人员，只有在他们能够对自己的工作内容和方法有一定发言权的时候，才会真正高效地工作。在遵循大组织行事风格，建立公共“DevOps”开发基础设施，同时遵循基本的商业和技术原则的前提下，开发人员的工作效率会得到更进一步的提升。
交付团队不需要对整个项目流程做精确说明，但是他们仍需一些高屋建瓴的指导来帮助他们组织自己的工作。专业开发人员通常都是具备高技能水平，接受过高等教育，并且有着多年工作经验的人。很明显，一组这样的人聚在一起，其知识范围可谓极其广泛。正因为有了如此广泛的知识范围，这些人通常极少会完全按照一份详细的流程说明来进行他们的工作。但是，他们通常仍会希望能够收到一些站在更高层面的建议，以此来帮助他们有效地组织自己的工作。每个团队通常都会受益于学习其他团队所使用的技术和模式，而这种互相学习的氛围是非常值得提倡的。
专业开发人员清楚地知道自己的任务，但是他们仍不是流程方面的专家。十几年前，机构中比较流行为团队提供详尽的开发流程建议，但是近来情况的发展走向了另一个极端，那就是几乎不提供任何既定的开发流程。过去几年，在敏捷开发领域中，比较流行让团队自行定义自己的开发流程，以此来保证流程设计更加适合每个团队的特性。但是这种做法显然不能达到预期的效果。究其原因，主要有以下两点：第一，虽然每个团队都有其特性，但显然也有很多共性，那么起码大家都能从一个高度概括的大致开发过程框架中受益，并以此为指导开始最初的工作。接受这样一条底线就意味着这个团队的工作至少有一个出发点，而这个出发点是从很多其他团队的成功经验中总结提炼而来的。这个团队大可以在此基础上对这个大致流程进行改进和优化，使之符合自身独特的价值理念。第二，虽然开发团队作为整体拥有极为宽广的知识面，但仍不可能面面俱到，天衣无缝，因此对团队最有利的无疑就是每个人都能发挥其所长，互为补充。因此，一个有灵活性的过程框架，例如“规范敏捷交付”，就能很好地将团队整合在一起。
专业开发人员应该自行对自己的工作成果进行验证，但是他们可能并不是产品测试专家，因此需要额外的帮助才能掌握必要的测试技能。在敏捷开发领域，一直流传着这样的说法，那就是对自己的工作成果要经常测试，尽早测试，最好从一开始就进行测试。结果，敏捷开发团队就必须推行“全功能团队”的工作方法，也就是由开发团队自己进行产品测试。这种工作方法能够有效的前提是，团队中有人具备良好的产品测试技能，更重要的是，他能将这些技能教授给团队其他人。最起码，你应该在开发团队中配备产品测试专家，而且应该考虑对团队成员进行有针对性的培训，并且指导每个团队成员提高其测试和质量管理技能。
规范敏捷团队采用“迭代式”工作方法，但是他们仍然遵循随时间变化的连续式产品周期规律。在任何一天中，在DAD项目团队中的人或许在进行分析、测试、构建、编程、开发或其他任何一种工作，然后周而复始地在这些工作中来回切换。但是，正如你在第1章中看到的那样，DAD的周期包含三个界限分明的阶段，需要依次执行。所以，DAD在微观上是迭代式，但在整个开发周期内，仍然是连续过程。