下载掌阅APP，畅读海量书库
立即打开
《敏捷宣言》背后有12个原则，称为敏捷12原则，如图1-2所示，句首关键字可帮大家抓住要点。
1.客户为先
以终为始，聚焦成效，围绕客户开展交付活动。
客户满意和有价值的软件是关键词。要确保开发的产品能够给客户带来真正的价值，这完全取决于在开发期间与客户的密切合作。产品需求管理是确保客户需求在开发期间被正确理解的关键。应该把精力集中在对客户最有价值的工作上。
图1-2 敏捷12原则
尽早并持续交付的能力是满足客户的关键。及时交付部分功能比需要很久才能交付全部功能更好，至少应该给客户一个选择。
2.拥抱变化
复杂和繁杂、易变和不确定是世界的主旋律，唯一不变的是变化，应该拥抱和利用变化，并将其转化成竞争优势。
我们的目标是开发出能够实现客户价值的产品，接受变化是为了更好地帮助客户解决问题并带来收益，因此，要支持这种变化的发生。
变化体现了团队和产品负责人在敏捷开发过程中的工作方式，应站在用户的角度，考虑什么是用户最需要的。
3.短迭代交付
如何探索业务？如何拥抱变化？应将不确定性的业务和需求假设通过确定的短迭代周期（1～2周）增量交付，来获得用户和市场的反馈。
开发周期和发布周期完全不同。无论发布周期多长，我们的目标都是短开发周期。发布周期的长度依赖业务决策，并且和用户的期望紧密相关。
短开发周期的频繁交付缩短了反馈周期并增强了学习。频繁交付还能让团队及早暴露问题，从而能够及时解决问题，提高敏捷性和灵活性。
4.业务参与
走出研发的“象牙塔”，与用户和业务人员一起探索，才能避免闭门造车，避免交付没有人使用的软件。
只要在业务和研发之间建立起桥梁，我们就能从中受益。
业务人员和产品管理人员需要知道市场状况、用户需求和用户的价值，开发团队需要知道产品和技术可行性。如何将这两方面有机结合？这需要我们每天都相互合作，一起做出睿智的决策。
5.以人为本
敏捷思想和方法，只有嵌入了信任、授权、主动、自主、担当的“DNA”，才能激发个体的聪明才智，处理复杂而又具有挑战性的问题，达成目标。
为了激发每个知识工作者的斗志和创造力，在目标及边界框定的情况下，自由发挥聪明才智是最重要的因素。要让角色去适应人，而不是让人去适应角色，可以采取任何需要的行动来达成目标。
6.面对面沟通
协作效率依赖面对面沟通。
面对面交谈在开发中尤为重要。不同角色工作成果的隔空传递，常常会导致信息的遗漏、误解、不一致等后果。最有效的沟通方式是面对面的基于白板的讨论。
当人们彼此交谈时，信息更多地以听的形式被传递。文档不能代替交谈，将每件事都写下来是不可能的。我们不应该只依靠文档来传递重要信息。
7.成果导向
在衡量进度时，要衡量成果，即新增的可以使用的软件功能，而不是衡量活动，如需求分析活动、编码活动和测试活动等。
瀑布模式下的阶段性进度，体现的仅仅是工作活动的进展，没有体现成果（可工作的软件）的进展。用户是为可工作的软件付费的，不会为工作活动或者阶段买单。
跟踪有多少功能已经实现、集成、测试是一种更可靠的进度度量，因为这些功能可以在测试环境或者预发环境中演示，体现了真正的进展。
8.保持节奏
复杂环境和短周期迭代给团队带来了紧张气氛和压力，稳定的迭代步调成就效率和战斗力的最佳平衡。
我们的目标应该是消除高负荷工作并保持可持续的速度工作（如不加班工作），否则，很难保证工作动力和成果。敏捷过程倡导每个迭代都交付有质量保证的产品增量。
虽然不可持续的、步调不稳定的高负荷冲刺，可以达成里程碑式的时间目标，但往往会带来质量问题，它牺牲了团队及软件系统的长期收益。人越疲劳，创造力就越低，代码就越乱、越复杂，架构就越难以演进。
9.追求卓越
随着产品的持续开发，软件系统的规模和复杂度急剧增加，卓越的技术和良好的设计可以大大降低认知负荷，以及维护和增加新特性的成本。
任何技术负债（如代码缺陷、架构缺陷、临时解决方案和架构老化）都会使开发进度变慢。
我们不应该让技术负债积压，要持续进行重构，修复发现的缺陷，持续关注已经实现的架构的质量。
10.简单务实
业务、需求、架构和代码都在持续演进，预测未来可能变化而需要的需求和代码大概率都是浪费的。
这种简单原则既适用于产品的功能特性，也适用于架构和流程。
多余的、“镀金”的功能不要增加。可复用性、可扩展性架构，若是非必要的，尽量不要增加。所有流程和步骤应该时刻面临挑战（如这一步真的需要吗？谁会读这个文档？可以通过这样的发问确认是否真的有必要）。
11.团队自组织
自组织团队成员，每个人都应积极主动思考——什么用户、为什么需要这个需求，以及如何实现。
架构、设计和需求会随着团队工作的展开不断涌现，并且团队会从做事的过程中学到很多东西。一些前置需求、架构和设计工作是需要的，但是不能把它们定义在纸面上进行传递。
架构师和系统工程师是自组织团队的一部分，不要成为“孤岛”。团队中的任何成员都可以提出任何问题、提供建议，甚至马上采取行动。
12.持续改进
以人为本的自组织团队拥有团队的工作方式，每个迭代都进行回顾改进的工作方式，是“持续敏捷、成为敏捷”的核心引擎。
团队应定期省思如何能提高成效，并依此调整自身的举止和表现。
软件开发是经验性过程，需要定期持续地计划、执行、检查和调整。