[转]你们的Backlog是什么颜色？

最近在悉尼和惠灵顿举行的软件开发大会 （SDC，Software Development Conference）上，Philippe Kruchten教授作了 一篇题为“你们的Backlog是什么颜色 ” 的演讲，主要内容是把软件架构的重要方面同交付系统的功能组件一起纳入敏捷项目中。

Kruchten认为：敏捷注重YAGNI（你不会需要它）、重构以及把决定放到“最后责任时刻（Last responsible moment）”做，这些会带来重要决定做得太晚的风险。对于任何一个项目，总有一些需要尽早作出的关键决策，为正在进行的工作铺平道路——对于这些决 策，“最后”责任时刻事实上非常接近项目的开始阶段。

这些关键决策是驱动开发产品架构结构的决策。做出不好的选择（或者做出不慎重的选择），会导致系统无法适应不断变化的业务需求。选择有关系统的架构 结构，要在开发过程早期进行考虑。

他说：许多敏捷项目注重功能性需求（以用户故事表达），而忽略架构的方面，抱着不负责任的态度“我们可以以后再重构”，总是过于频繁地把“以后” 放在一边，直到为时已晚。

他举了一个例子：一个采用敏捷方法的金融交易系统。 

用户故事已经识别好，发布计划以及开发工作已经启动。最初的几轮迭代取得了巨大成功——功 能交付了，客户参与度非常好，而且所做的功能完全符合业务需求。一旦有足够多的功能构成一个“最小的可行产品”，一个发布就会投入到生产环境中，而项目却 陷入了绝境——那些已经开发好的功能可以运行，但产品却无法应付实际环境中的交易量。客户不得不重新使用老的系统（还没有被关闭），而开发团队则回去重构 产品，以应付真实环境的需要——不幸的是，重构意味着不得不对大部分已经完成的工作进行彻底的重建，唯一可以利用的组件是界面设计。项目最终取消了，而客 户的组织非常不情愿再去尝试敏捷。

 他并不是建议回去做大的前期设计，只是鼓励大家慎重考虑系统的重要质量方面，并确保架构特性同功能性故事一起考虑。架构特性是由产品的“非功能 性”或者质量需求驱动的——诸如性能、可靠性、容量、可维护性、安全性、可用性以及可测性等方面。这些方面会影响产品的架构——一开始就必须设计好它们， 而不是事后再去重构。

他承认取得进度的迫切需要——我们不希望开发团队花费1或3轮迭代，忙于“探索”对用户没有显著价值的东西。他认为，把架构需求编进产品的整体发布 计划中是可以做到的，确保在开发产品的时候，架构基础以及实用性功能都构筑起来，并且我们能够同时在日益增长的功能上，以及满足质量目标的能力方面取得进 展。因此，例如第一轮迭代可能只能看到一个单一的输入界面，但负载测试会显示系统的那部分组件，将能够应付生产环境的要求。

他提供一种方法，让工作变得可视化，并确保架构需求得到重视，而且与基于可视化的工作一起排列优先级——把颜色代码的概念应用到产品Backlog 中的各个条目中。

 他说，backlog可能会有四种颜色的工作：

• 绿色——将要交付的功能特性，功能性用户故事
• 黄色——支持质量需求的架构基础
• 红色——确认好的缺陷，需要重视
• 黑色——开发产品过程中产生的技术债务，推迟的关键决策或者已经完成的劣质工作