Backog的颜色

敏捷的一个缺点是某些重要的决定在迭代的后期才能做决定，这个会为项目带来一定的风险。比如一个订单系统，在无法承受实际环境中的交易量，这及意味这大部分的以完成的工作需要重建。

 

所以架构特性也应该和用户故事一起考虑，但不是说花费一两次迭代来“探索”对用户没有显著价值的东西。

 

架构特性 - 由产品的“非功能性”或者质量需求驱动的，例如性能、可靠性、容量、可维护性、安全性、可用性以及可测性等方面。这些方面会影响产品的架构，一开始就必须设计好它们，而不是事后再去重构。

它包括：

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

将Backlog用不同的颜色表示，可以让工作可视化，并确保架构特性得到重视。

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

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

应该像下图一样，把两者组织到一起：

四种颜色，在以前应该同时出现绿色和黄色，过程中会产生红色，如果红色不解决会导致黑色出现。

 

我在Jira中的应用

来源：http://www.infoq.com/cn/news/2010/05/what-color-backlog