技术债务是指对不适合做法的补救成本的总和。通俗的讲就是为了快速响应需求而引入的非最优或临时性的解决方案，在之后的开发过程中，不得不承担因此所产生的副作用。但如果一直不理睬，技术债务最终会成为阻碍。 技术债务也是一种故事，需要产品负责人在代办事项中统一管理优先级。 增长的技术债务是影响产品可行的最大障碍。技术债务越大，弥补它的代价越昂贵。 技术债务的主要外在表现 系统加载的时间越来越长 某个模块缺陷率不断增加 相同的问题在不同的模块或者组件中出现 新的功能数量增加，引发新的bug数量持续增加 修复bug的时间越来越长 团队对某个模块或者组件抱怨很难理解或者很难测试 频繁修改某个模块的源代码 …...

4大价值观 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观： 个体和互动高于流程和工具 工作的软件高于详尽的文档 客户合作高于合同谈判 相应变化高于遵循计划 尽管右侧的内容有价值，但是我们更重视左侧的价值。 12大原则 我们的最高目标是通过尽早持续交付有价值的软件来满足客户的需求。 欢迎对需求提出变更，即使在项目后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。 要经常交付可用的软件，周期从几周到几个月不等，且越短越好。 项目实施过程中，业务人员与开发人员必须始终通力协作。 要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够...

项目管理的传统三角包括范围、时间和成本，它指出在确定的范围（需求）、时间要求和成本限制内交付出产品。 在现代项目中，客户的需求不断发生变化，我们很难确保之前的项目规划是正确无误的，因此需要不断的尝试和总结，所以敏捷在传统三角之上增加了价值和质量。 价值：为用户提供有价值的产品。 质量：为用户提供的产品必须满足用户的需求。 敏捷三角相较于传统三角，将范围从固定演进为可变以灵活适应市场的变化，将目标聚焦于客户价值而非既定任务以满足多元化的用户需求，加强质量的权重以提升终端用户的体验。 价值驱动的项目管理方式在当前的时代背景下显然适用于计划驱动的管理方式的。

构想阶段（展望阶段） 构想阶段确定产品构想、项目范围、项目组织以及团队共同工作的方式。为客户和项目团队创造构想，包括提供什么、谁提供和如何提供。如果没有构想，其他的项目启动活动都是无用之功。 构想是项目早期“成功的关键因素”。 推演阶段（思索阶段） 推演阶段基于项目功能的发布计划、里程碑和迭代计划，确保交付构想的产品。 推演阶段实际上是构想阶段的延伸并与它相互影响，主要包括： 收集初始的、广泛的产品要求。 将工作量定义为一个产品功能清单。 制订一个交付计划（发布、里程碑和迭代），其中包括工作的进度表和资源分配。 探索阶段 探索阶段旨在交付可运行的、已经通过测试的、已经接收的用户故事，主要活...

时间范围 详细度 承诺类型 部署 愿景 长期（2年以上） 项目目的、目标 路线图 长期（2年） 高层次的产品需求 发布计划 长期（大于6个月） 能力 项目可行性 给客户的最终版本 里程碑计划 中期（3个月） 故事 承诺能力 给客户的临时版本 迭代计划 短期（1～4周） 故事/任务 承诺故事 客户评审流程 每日计划 1天 任务 承诺任务 - 每个计划的时间范围没有具体限制。 如果项目周期短，可以只有一个发布计划、一个迭代计划，短期项目可以不需要里程碑计划。

产品路线图是关于产品发布和主要组件的可视化概述。 产品路线图是产品负责人所拥有的，对于产品需求的高层次概述，通常用来帮助做优先级排序、特性归类、确定时间框架等。 产品路线图描述出产品多个版本的演变过程，是项目层面的粗粒度计划，它关注的是目标而非细节。 制定路线图的步骤 确认需求 将需求分类或设定主题 评估相对工作量 评估粗略时间框架

发布计划又称版本计划，是覆盖超过一个迭代周期长度的高层级计划。 发布计划由产品负责人确定，可以帮助客户和敏捷团队决定每一个项目的时间范围，或者确定时间范围内应该开发的内容。 发布计划的主要任务是以价值和风险为基础把用户故事分配到迭代中。 发布计划的主要内容包括： 分解用户故事 估计工作量 定义DoD 发布产品待办事项列表 发布计划是一种用于向相关方展示产品预期发布（Release）的中长期计划，包含了近期的各种发布和需求的对应关系。 发布计划可以帮助产品负责人和团队判断产品待办量和工作量。 发布计划传递了在不同的时间期限内需要完成的待办事项，便于组织规划其他的战略活动。 发布计划可以指...

故事点是用于表达用户故事、功能或其他工作的总体规模的度量单位，它所表示的工作量是相对的而不是绝对的。故事点可以衡量整个团队，有助于形成跨职能团队协作的氛围。 故事点相对稳定，不会随着时间、人员、方法而发生变化。 故事点是一个单纯的度量单位，不需要考虑人员、资源、时间的影响。 估计故事点的工作量相对较小。 不同的人所估计的故事点数量应当是一致的，其估计结果不会因人而异。 确定故事点工作量的方法 将具有最小工作量故事点的工作量定为1，其他故事点以此为基础确定工作量。 将具有中等工作量故事点的工作量定为5，其他故事点以此为基础确定工作量。 在不清楚所有故事点的情况下，也将很难确定故事点工作...

理想时间是指在不受干扰的情况下，顺利完成一项任务所花费的时间，可以用理想天数（IdealDays）、理想时数（IdealHours）来表示。 由于对在不同角度观察同一个用户故事可能会得出不同的时长估计，因此产生了“理想时间”的概念。 理想时间的主要优点包括： 简化估计 易于启动估计工作 易于向他人进行解释 易于估计开发速度 耗用时间（ElapsedTime） 与理想时间相似的是耗用时间，它所指的是完成一项任务通常所需要耗费的所有时间，包括了通常会消耗的额外时间，例如工作打断、培训、打电话、汇报、伤病、任务切换等。 使用理想时间的背景 所估计的用户故事是将要处理的唯一工作 所有准备工作都会...

最常用的估计方法包括专家判断、类比、分解、宽带德尔菲、理想时间等，在不同阶段所使用的估计方法各不相同。 每一种方法都可以独立使用，但综合使用的效果最佳。 亲和估计 亲和估计是预测工作量的一个方法，用于将故事按照难度分级或排序，在大型的产品待办事项中作用巨大。 基本的亲和估计模式涉及从小到大范围里测量用户故事，这个范围可以是斐波那契数列或者T恤尺码，常常贴在大型会议室墙上。然后参与者在估算时可将他们的用户故事贴到这面墙上。 团队成员将产品未完项的条目放在产品未完项条目组（每个产品未完项条目的大小相同）当中，或者团队成员使用类似T恤尺码（如小号、中号、大号和特大号）作为估计尺度。 这种估计常在无声...

简单设计意味着适应比预测更有价值，其目的是让团队基于已知的知识而不是对未知的预测来进行产品设计，然后对我们未了解的东西再作出响应。 简单设计轻灵便捷，因此更容易适应需求的变化。简单设计是最有效率的，敏捷致力于追求效率。 如果一些事情变化的概率很高，就应该将他们设计成容易包含变化的。

持续集成是软件开发过程中的一项活动，团队及时将变更的代码集成到应用程序当中。同时可以在集成的过程中快速发现问题。 持续集成的目标是在开发期间尽早、频繁的确保将产品特性组合成一个整体，从而减少以后无法组合造成的高成本和测试负担。 所有代码的变更都要经过签入（Check-In），并且整个系统需要在每天结束时或以更经常的频率进行编译测试，这样可以很快地发现破坏系统其余部分的变更而不是当遭受损失的时候才察觉。 通过持续集成运行更多测试，这样发现问题所需要的花费时间将大大减少，从而缩短了问题解决周期，降低了变更成本。

重构是指重新组织代码，但不应该改变代码原本的功能。重构的前提是“团队对代码负有集体责任”。当发现了敏捷“气味”或团队认为有必要重构时而执行。重构后，做完整的回归测试来确保代码与其之前的功能一致。 持续重构旨在不断地、连续的改进产品设计，让它的适应能力更强，以满足如今和未来都能交付客户价值。 无论第一次做得多好，它都会改变，所以要将变更成本保持在较低的水平。

自动化测试又称为无情测试，可以避免人为干扰，从而确保产品在整个开发过程中保持高质量。 自动化测试要求频繁的对产品进行测试，并且将质量保证和验收测试融入开发过程中。

通过频繁的确认和验证，不断的检验项目运行是否符合预期标准，常用的方式包括： 结对编程：由开发人员和测试人员组成，随时对已完成的工作进行检验，从而避免交付后发现问题或误解。 单元测试：每编写完一个单元组件后，立即对其进行测试。 客户合作：频繁的与客户合作和交付。 每日站会：每天工作前都需要对昨日的工作进行反馈和总结。 评审会：对完成的工作进行演示，以确保符合客户的真正需求。 由于敏捷需要在各个层面进行确认与验证，所以需要采取自动化测试方式，从而可以消除人为错误，且成本较低。

验收测试驱动开发将测试的关注点从代码转向需求，在编写代码之前就确定功能的验收标准。 当团队在讨论需求的预期结果，并选择用户故事时，验收测试就会被执行。 主要步骤： Discuss：讨论 Distill：提取 Develop：开发 Demo：示范

敏捷教练是帮助企业（组织）转型的教练，敏捷教练帮助团队在工作中应用敏捷实践，从而帮助团队发展地更健壮。 敏捷教练需要与团队长时间呆在一起，让他们更加关注工作流程、关注如何更有效地协作。 敏捷教练是一个短暂的角色，不会在整个项目周期中长期存在。在你离开后，让团队能够“自我指导”并且擅长应用敏捷。 在敏捷中，整个队伍就像一只球队。 开发团队就是在场上踢球的队员，他们对场上的比赛负责，进球、丢球都有直接责任。 敏捷教练是场边的球队指导，要把队员照顾好，解决队员的伤病问题，做好球队的指导工作。 因此，教练不是场上的队员，他不能上场比赛。场上的局势再恶劣，教练也不能代替队员上场踢球。