背景
Etsy是我们最喜欢的一个从事手工艺品或古董在线市场的科技公司。该公司拥有稳定的技术团队，技术运维由约翰·阿尔斯帕瓦掌舵，其网站偶尔也经历网站中断。
2012年7月30日，发生了这样一件事，员工为支持多字节字符集的语言进行了数据库升级。一切都是按照计划进行的，他们先升级了一个生产数据库。数据库升级，尤其是改变静态数据的编码，存在着数据破坏或丢失的风险。为此，该小组精心制订了一个在一段时间内把剩下的服务器缓慢升级的计划。他们只升级一台服务器，而让其他服务器的升级基本上准备就绪。
Etsy往往有许多变更在排队进入生产环境。网站在夜间备份的时候速度缓慢，更快的备份方案正在排队等待实施的时机。为了推出解决备份问题的修复代码，Etsy的工程师们使用了自动化的工具，以确保服务器的一致性。经过测试后，他们使用该工具将修复的应用版本发布到备份中，在不干扰网站性能的基础上，期待着稍后确认备份的成功。他们当时并不知道部署改进备份的部分也同时升级了数据库的语言。
当意识到大约60%的Etsy的数据库服务器在升级字符集的同时仍然在服务用户时，他们迅速地关闭了网站，以防止数据损坏。回应这一事故的团队由多个部门的人员所组成。正如阿尔斯帕瓦说的那样，“不只是一个团队在响应事故”。在Etsy，很多人参与了24/7值班小组。没有问题管理者存在的必要，因为每个团队拥有自己所研发的服务。在某些情况下，如搜索团队，由来自不同领域的员工组成的敏捷开发团队作为一级响应。搜索团队首先接到警报，在必要的时候，把问题升级到的技术运维。
团队一旦能够确认数据库是正确的而且表现正常，就恢复网站的服务。同时，他们与社区通过EtsyStatus网站（http://etsystatus.com/）沟通。
这个例子显示出敏捷团队（5到12人的跨部门团队，由经理、工程师、QA人员、团队和DevOps人员组成）如何从架构设计开始到生产支持一直拥有自己的产品或服务。
本文将通过探讨功能和系统设计，来解释敏捷组织是如何实现系统相关的设计，以及独立的敏捷团队如何遵循标准。
敏捷组织中的架构
在功能型组织里，个人是按照技能、领域或专业组织起来的。然而，几乎每个项目都需要协调整个团队，这意味着跨部门协调。对SaaS提供商尤其如此，因为SaaS的责任不仅是软件开发和测试，还要运维和支持，所以属于公司的技术团队。这导致一定程度的情感型冲突。冲突的程度取决于许多因素，但我们希望尽可能减少这些因素。回想一下，情感型冲突是“坏”的，冲突集中在角色和所有权方面，涉及的问题往往是“谁”拥有或任务应该“如何”做？
这种类型的冲突具有破坏性，会导致团队成员身心疲惫。在身体上，它可以让交感神经系统（与下丘脑激发的打架或逃跑综合征相同的系统）释放压力激素皮质醇、肾上腺素和去甲肾上腺素。在组织上，团队可能会因为争夺产品和服务的所有权，导致封闭的思路和不良的结果。相反，敏捷组织打破功能型组织的斗争，并授权于团队，消除矩阵组织结构所面临的组织边界问题。
敏捷组织是由5至12人组成，拥有设计、开发、交付和支持面向客户的产品或服务所必需的技能。这些团队是跨部门和自成一体的。他们有权做出自己的决定，而且不需要外界的认可。他们有能力处理产品或服务的全生命周期。当团队以服务为主线跨部门组织起来，同时具有自主权，就可以显著减少情感型冲突。当团队成员拥有共同的目标，并且不再需要争论谁负责什么或谁应该执行某些任务时，团队就会荣辱与共。每个人都会负责确保所提供的服务符合业务目标。
在SaaS产品服务方面，创新的增加往往是通过度量更快的市场响应时间、更好的产品质量和更高的可用性来确定的。这种创新的驱动力降低了情感型冲突，提高了认知型冲突、多样性和授权管理的水平。敏捷的组织结构提供了所有这些驱动力，其结果往往是创新的显著增加。
架构的所有权
创新、更大的自主权和更少的情感型冲突听起来很棒。然而，与更大的权力伴随而来的是更大的责任。这些敏捷团队拥有服务或产品的架构。换句话说，他们不依赖独立的架构团队，而靠自己完成产品的设计和实施。在实践中这是如何实现的呢？
敏捷团队由拥有所需全部技能的人员组成，确保团队能进行产品的自主研发。典型的团队成员包括产品经理、几个软件开发人员、质量保证工程师和DevOps工程师。如果该公司有软件架构师，架构师也被放在敏捷团队里。这样的团队构成应该让你想到第13章的JAD过程。如果敏捷团队设计和研发高可用和可扩展的产品与服务，其成员需要任何完成同样任务的其他团队相同的技能。JAD像一个乐队助理，在以功能为导向的团队里，创建跨领域设计是敏捷团队的内在特质。
