如何敏捷架构

架构和设计是对需求的回应。某位大神曾经说过，超前架构和设计（Big Design Upfront）的问题是将导致浪费很多功夫——一项行业统计：35%的需求会产生变更，且其中超过一半的变更，实际上都用不上。

在Scrum实践中，我们因需进行架构设计。那些驱动着架构设计的非功能性需求通常也有比较高的价值，绝不能从product backlog中遗漏。我们必须能在每个sprint中构建至少一个面向业务的功能，所以我们仅构建足够的架构和设计来支持那功能，又用适当的架构设计来满足非功能性需求（稳定性，安全性，响应时间等等）。然后，在后面的sprint，随着对越来越多的业务功能的回应，越来越多的设计将浮现。这样做的目的，是仅构建对真实需求、高优先级业务需要呼应的架构设计。这么做我们能满足三个需要：证明架构设计是对的；从使用者得到反馈；以及改进我们的估算。随着项目或发布的进展，架构设计的工作慢慢减少，而实现的业务功能逐渐增加。

好了，前面这些说的，都是一些理论化的东西。在实践中，我觉得比较难拿捏的是：怎么样的架构设计才是恰当的？

例如说，如果“可修改性”是一个项目的需求，架构师就需要知道架构中的哪些元素时需要支持可修改性。这就必须有一点前瞻的分析和设计了。因此，对于架构和Scrum而言，我们改如何做？一个可以尝试的办法，就是考虑，花一到两个sprint周期来捕获high priority的功能性和非功能性需求，并设计一个high level的架构，放到后面再实现。当然，这个是架构师（在Scrum开发团队中，没有这个角色；架构应该是每个开发人员的共同责任；在这里，只是稍强调了一下职责。）在一到两个sprint中逐渐考虑的事情，而非一定有一个具体的task与之相对应。等到考虑充分、达成基本共识之后，就可以转化成一些技术task，通过refactoring的方式，或者在实现某些feature的过程中，逐一实现。重要的是，一定要坚持“尽可能小且必要”的价值最大化原则。

记住，"The only thing that is constant is change."，架构也要不断地审视和积极演变。否则，不用到6个sprint，就要撞墙了，不是吗？