用户故事INVEST规则中的第一个“I”，Independent独立的，是说用户故事应该是自包含的，没有对于其他用户故事的内在依赖。但在实践中，很多人觉得这个基本很难做到，甚至完全不可能，造成很多困惑，那到底该如何理解这条规则呢？
借鉴前人的知识，结合本人的认识和经验，这篇博文从理论和实践角度对此做一个深度剖析，希望能对你有所帮助。
用户故事为什么需要独立性？
首先必须要弄明白，为什么要有这一条规则，它的目的到底是什么？
INVEST规则最早的提出者Bill Wake在其文章中提到，用户故事的独立性主要是为了排定用户故事优先级时更加灵活自由。
独立性的对立面是依赖性，增强独立性就是要减少依赖，Bill Wake在其另一篇博文中提到，依赖性的三种常见类型是：重叠、顺序和包含。总体上来说，故事之间功能点相互重叠是需要避免的；顺序关系是现实存在，在多数情况下可以通过一些手段解决；包含关系对复杂系统是有帮助的，对排定发布和迭代计划的影响需要注意。
用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大小估算所涉及的范围更清晰，从而估算偏差更小。
三类依赖及其解决方式
三种依赖性的类型：重叠（Overlap）、顺序（Order）和包含（Containment），逐个对其进行剖析。
重叠依赖
重叠依赖是带来最多困扰的依赖形式，特别是多个用户故事包含多个不同的重叠部分时，很难找到一组用户故事可以代表该最小可行产品的功能集合，该集合应该包含且仅包含一次需要的功能。用户故事功能重叠是没有很好进行拆分的指示器，错误地使用端到端的概念，在非特性团队的情况下按照部件或架构层次拆分用户故事，但却要求所有故事必须端到端集成测试作为每一个故事的范围，也是一种重叠依赖表现形式，并且是会导致严重后果的一种依赖。
解决方式：
将重叠部分单独剥离出来做为独立的用户故事
合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的用户故事中
组建特性团队以及合理界定端到端
顺序依赖
顺序依赖是指要使某用户故事完成，另外的一个或多个用户故事必须在它之前完成。顺序依赖通常是无害的，而且有一些方式可以减轻这种依赖。
从整个系统大的视角来看，顺序依赖非常自然，甚至是必须的，从敏捷开发的角度，整个系统是从初始的最小可行产品逐步演化为强大的产品，后面的每一步是建立在前面的基础之上的，否则整个产品可能是松散组合而成的，那就丧失了产品的概念完整性、逻辑一致性和系统内聚性，完全可以拆分成多个产品。
但从另外的角度，不必要的顺序依赖使得排列和调整优先级变的比较困难，进而影响制定发布和迭代计划，也使得用户故事的大小估算更难以把握。
解决方式：
要求一个迭代内的用户故事尽量做到没有内在依赖，保持每一个用户故事的独立性。在同一迭代内，同一团队之内以及多团队之间的故事最佳情况都是做到无依赖。
保持迭代之间只有单向依赖。多个团队协作做一个产品时，迭代计划要保持同步，后面的迭代建立在前面的迭代基础之上，不管是由哪个团队负责，在时间上只有后面故事对前面故事的单向依赖（前向依赖）。
如果一个迭代内用户故事有依赖，而用户故事的拆分满足其他良好的用户故事拆分规则，说明用户故事可能拆分的太细，或者迭代期太长，首先保持单向依赖，可以尝试缩短迭代期，或者使用一个迭代内的单件流看板模式（ScrumBan）
任何情况下，不要有循环依赖。当有内容重叠且有顺序依赖时就构成了循环依赖，当依赖太多，特别是有循环依赖，说明如下几点：团队组建方式不是按特性团队来组建的，或者用户故事的拆分不是按可交付的功能特性拆分的，或者没有剥离出真正有依赖的核心功能，或者团队之间缺乏同步。此时相应的措施就组建特性团队，以可交付为导向拆分需求，加强团队间的迭代计划同步，重新组合分拆过细的用户故事，类似于剥离出优先级不同的需求，剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求混在一个故事里。核心依赖又可以拆分为多个演化的版本，起始阶段其他对其有依赖的故事可以使用它的极简版本甚至Mocking版本，从而一定程度减轻甚至消除了依赖。
顺序依赖的现实要求我们更好地制定迭代计划，对未来提高可见性，并频繁地根据各用户故事的现实进度情况调整迭代计划
包含依赖
包含依赖是指在组织用户故事时使用有层级的管理，比如常见的特性－故事两级管理，一个特性包含多个用户故事，这样就构成了特性对其属下故事的包含依赖。分级管理的问题在于虽然它非常有利于描述和理解比较复杂的系统，但却给排定迭代计划带来一定的困扰。
解决方式：
特性一级用来做发布计划
用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划
特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去
遵从最小可行产品的理念，组合多个最小市场化特性而构成最小可发布的产品，并逐个迭代增强系统，一个最小市场特性可以多个迭代实现，每个迭代实现一些用户故事。一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。极端情况下一个市场化特性可以是一个用户故事，消除了包含依赖
总结
用户故事的独立性对商业和技术实现都有帮助：从商业目标的角度，用户故事的独立性可以帮助我们聚焦在最有价值的特性上，而不是受限于技术依赖；从技术的角度，用户故事的独立性鼓励最小实现，支持那些以最小化和有效管理实现依赖的设计方法，比如从初始可行走的骨架逐步增强为功能完备产品的演化化架构设计。所以，我们要尽量保持用户故事间的独立性，并在各种情况下妥善地加以处理。
