源自于最近阅读的一本书《卓有成效的敏捷》，作者 Steve McConnell。
检视和调整
敏捷是一种依赖于从经验中学习的经验性方法。这需要创造机会定期反思并根据经验进行调整。
从 Scrum 开始
Scrum 并非敏捷之旅的最终目的，但它是最为结构化、支持最好的起点。
搭建跨职能团队
敏捷项目的工作发生在自我管理的团队中。要自我管理，因队必须包含做出对组织有约束力的良好决策所需的全部技能。
将测试人员整合到开发团队中
通过让做事的人更紧密地一同工作来加强开发和测试之间的反馈循环。
通过自主、专精和目标来激励团队
敏捷实践天生就支持那些有助于激励的因素。团队旨在自主地工作并不断改进（专精）。为了做到这一点，他们需要理解目标。“健康的敏捷团队”与“积极进取的敏捷团队”是互为表里的。
培养成长恩维
无论你是从自主、专精和目标的专精角度看还是从检视和调整的角度看，高效敏捷团队持续地关注于变得更好。
培养以业务为中心
开发人员经常需要在产品负责人的指导下填补需求中缺失的细节。理解业务有助于以对业务有益的方式填补这些细节。
加强反馈循环
不要花更长时间学习不需要的经验教训，而是尽可能加强反馈循环。这有助于通过检视和调整获得更快的进步，以及通过培养成长思维更快地改善效果。
修正系统，而不是处理个人
大多数软件从业人员都想做好工作。如果他们没有把工作做好，特别是如果他们看起来没有尽力把工作做好，应该去了解是什么导致了这一点。找出让个人感到挫败的系统问题。
通过培养个人能力来提高团队能力。
团队呈现的品质是团队中个人品质以及他们之间的互动，通过强调个人来加强团队。
保持 sprint 短小
短 sprint 支持频繁的检视和调整的反馈循环。短 sprint 能使问题更快暴露，更容易在小问题变成大问题前将它们消灭在萌芽状态。
以重直切片的方式交付。
敏捷中的反馈很重要。当团队以垂直切片而不是水平切片的方式交付时，他们能够得到有关其技术和设计选择方面更好的反馈 既有来自客户的反馈，也有来自业务的反馈。
管理技术债
持续关注质量是高效敏捷实施的一部分。管理技术债能带来更高的团队士气、更快的进展，以及更高质量的产品。
通过架构支撑大型敏捷项目
良好的架构能够支持项目的工作拆分并最小化大型项目特有的日常开销。优秀的架构能够让大型项目感觉上像较小的项目。
使缺陷检测的时问最短
修复缺陷的成本往往随着缺陷停留时间越长而变得越高。敏捷注重质量工作的一个好处是在更靠近源头的地方检测出更多缺陷。
制定并采用完成定义
良好的完成定义（Definition of Done）有助于及早发现不完整或错误的工作，最大限度地缩小缺陷引人和缺陷检测之间的时间。
将质量维持在可发布水平
将质量维持在可发布水平有助于捕获早期完成定义遗漏的额外缺陷。
由开发团队编写自动化测试
自动化测试有助于最小化缺陷检测时间。让团队中的每个人都负责测试强化了质量是每个人的责任这一理念。
细化产品待办事项列表
产品待办事项列表细化确保团队处理最高优先级的事项，不会在没有产品负责人的情况下自行填补需求细节，并且不会让团队 没有工作而陷人空转。
制定并使用就绪定义
待办事项列表细化的部分工作是确保需求在团队开姶实现前确实准备就绪（Definition of Ready）。
自动化重复性工作
没有人喜欢重复性工作，而且当把软件开发中能够自动化的工作进行自动化后，许多工作能的比不进行自动化带来更多收益。
管理结果，而不是管理細节
通过清晰地沟通期望结果的方式来保护团以的自主性，同时让团队自由决定完成工作的细节。
用指挥官意图明确表达目标
通过明确传达期望的最终状态的目标，来支特团队能够进行及时的内部决策。
关注吞吐量，而不是关注活动
类似管理结果，细微差别在于忙碌并非目标 —— 搞定有价值的工作才是目标。
在关键敏捷行为上以身作则
高效的领导者也会展现出他们想从员工身上看到的那些行为。
正向看待错误
正向看待错误，以便团队可以毫不犹豫地将错误暴露出来．这样能够从中汲取教训。不从过往错误中汲取教训会让公司再次蒙受损失。
以量化的团队产能为依据制订计划
敏捷是一个经验性方法，团队和组织应该基于量化的产能来计划工作。