你们的 Backlog 是什么颜色？

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

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

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

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

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

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

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

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

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

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

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

图片：Backlog 中的颜色

注意那两个维度——积极对消极价值，可视化对非可视化功能

绿色的部分是可见的功能，在产品 backlog 列表上最为常见——定义了产品中将要交付的功能的用户故事。在最终的产品中，这些对用户是可见的。

黄色部分的工作对用户是不可见的，但它们对整个产品有重大的价值。这些包括要完成以下工作：

• 架构
• 基础结构
• 公共元素
• 类库
• 框架
• 让组件可以重用

黄色（有价值但不可见的工作）部分需要在产品 backlog 和发布计划中明确说明，这样项目的利益相关者可以把它们与可见功能一起排列优先级。

红色部分（可见的缺陷）在产品开发过程中插入——在理想世界中，红色部分会非常少，但假定没有红色部分是很幼稚的。

黑色部分（技术债务）会在黄色部分被忽略时产生；技术债务也可能积累自之前的工作，如果项目基于先前的遗留代码。

建立初始发布计划时，同时计划绿色和黄色部分是很重要的，一心一意专注于可见的功能会导致产品看似完美，但却不能适用于生产环境，或者无法应付真实世界的安全威胁。同样地，单纯关注于黄色部分会把我们带回到大量的前期设计中（big up-front design），而且会导致延迟交付所有可见的价值，那时已为时已晚，缺少客户参与。

他认为，建立发布计划时应同时重视那两部分，就“像一个拉链”——把功能性部分和架构部分编织到一起，就像这幅图：

图：计划发布时，把可见和不可见的价值部分像拉链一样合并到一起

红色和黑色部分（可见的缺陷以及技术债务）不会在最初的发布计划中出现，但它们对项目进行的速率（完成的工作与交付的价值之间的比例）有很大影响。

认定缺陷确实存在时，必须马上予以解决。把它们留到以后解决的话，它们会恶化，并导致重大影响。经过几轮迭代后，团队会大致了解他们的缺陷率，并可以调整计划速率，以确保尽可能在发现新的缺陷前把它们修正掉。

如果项目启动的时候有已知的技术债务，那么计划要做的工作时必须考虑到这一点——遗留代码很可能已经有隐藏的缺陷在那里，而且重构那些代码可能并不容易，因而，再一次的、由于相关产品的质量问题导致交付价值率减少。

开发一个新产品时，没有最初的技术债务，但有引发债务的风险。推迟修复缺陷、忽略黄色部分、延迟关键决策却错过“最后责任时刻”都会导致技术债务的累积，并导致交付价值率的降低。

在项目进行的过程中，识别缺陷和技术债务时，重要的是要让项目团队可以看得到它们——这就是用颜色对 backlog 进行编码的概念。为了展示缺陷以及偿还技术债务，需要在产品 backlog 上加入新的故事。

他强烈建议对主要的故事列表标识颜色编码，以便清楚地表明工作类型——该故事是一个新的用户功能，一个架构组件，一个必须修复的缺陷还是一些需要偿还的技术债务？

通过在你的 backlog 上突出显示一些颜色，并让产品开发的所有 4 个方面都清晰可见，更加实际的项目计划和追踪是可以实现的。

你们的 backlog 中有什么样的颜色——你们使用什么方法，让所有工作变得可视化？

查看英文原文： What Color is your Backlog?