理解敏捷思想的63句话！

序号	类别	箴言	解释
1	持续提升	敏捷转型是文化变革，前景美好，道路曲折，，必须领导先行。	冰冻三尺，非一日之寒。要想转型到敏捷文化，需要领导投入、开发人员配合、管理部门理解和支持才可能成功。 敏捷始于领导，死于领导，领导往往会成为转型的障碍，做公仆式领导不是每个领导都能做到的。
2	持续提升	短周期迭代，就是PDCA循环。	迭代策划、冲刺、每日站会、迭代评审、迭代回顾，构成了典型的PDCA循环。
3	持续提升	团队级通过迭代回顾总结经验教训，持续提升。	建设自学习的团队！
4	持续提升	组织级通过技术社区提高技能。	有专家主持的技术社区，可以实现跨团队的知识、经验分享。 人员技能是实施敏捷方法的一个前提，组织级要重视对人员培养的投入。
5	系统思维	团队的目标高于个人的目标。	聚焦于团队的共同目标。
6	系统思维	考核整个团队的业绩而不是个人的业绩。	对个人的业绩考核不利于团队成员为整体的目标奋斗，不利于培养团队协同的文化。
7	系统思维	度量团队的总体效率而不是局部效率。	设计总体的开发流程真正地顺畅地流动起来！
8	系统思维	消除团队的资源瓶颈与资源浪费。	活等人，人等活都会降低团队的整体效率。
9	系统思维	关注需求的整体价值，而不是细节需求。	满足客户最重要的需求，尽快帮客户实现价值。要整体最优而不是局部最优。
10	需求	尽早给客户交付，尽早对需求返工。	让客户尽早发现与需求的偏离，而不是我们已经偏离了很远了才调整方向！
11	需求	需求一定要排优先级，需求优先级比需求本身更重要。	需求人员的价值不是把需求越分析越多，而是越分析越少，找到最重要的需求！
12	需求	用户故事四段论：角色-功能-目的-验收标准。	用户故事的价值在于： 1 明确了为什么需要这个需求。 2 为需求沟通提供了一个话题。 3 验收标准才是对需求的细化描述，它规定了需求做到什么程度。
13	需求	需求变更时，用高价值的需求变更替代低价值的已有需求。	需求变更不是增加需求，而是替换需求，替换需求是在固定工期与投入的前提下实现需求变更的最佳策略。 单纯的增加需求，不调整工期、投入是不可能实现的。
14	需求	通过现场客户、需求梳理、需求反讲、迭代策划会议、验收标准等手段充分沟通需求。	整个项目的进展实际上是Product Owner在推动的。
15	需求	需求人员花在需求沟通上的时间超过需求文档的编写时间。	采用用户故事表达需求，用户故事仅仅是一个沟通需求的把手，提醒大家，要讨论这个需求。 每个需求的验收标准是通过持续不断的需求沟通与交流来逐步澄清的。 需求人员要不断的沟通需求，确保团队对需求理解的一致性。
16	需求	需求人员随时纠偏比一次性纠偏更重要，要每天确认当天完成的需求。	尽早反馈坏消息。 需求人员就是定方向，随时纠偏。
17	计划	在一个部门内，最多只有一个已开工的项目是缺少资源的。	要么不开工一个项目，开工了就要全力以赴，保证资源，短平快结束。 集中优势兵力打歼灭战。
18	计划	经验型过程控制是在遵循原则的基础上，对实践的最小集做加法。	经验型过程控制的本质是： 1 在遵循敏捷价值观与原则的前提下，灵活设计自己的开发过程。 2 基于已有的敏捷框架，如SCRUM，XP等基础上，对那些仪式、实践做变化，做加法。
19	计划	做最少的活动实现目标。	少做无用功。
20	计划	通过固定时间箱消除帕金森现象。	固定时间箱：在固定的时间周期内交付一定的功能，如果不能按期交付，则裁减需求。 帕金森现象：人们总是用完所有可以利用的时间。就是拖延症！
21	计划	一次只关注一件事，效率最高。	减少任务切换成本，提高开发效率。 可以参见《单核工作法》。
22	计划	通过人员隔离，时间隔离屏蔽干扰。	人员隔离：在一个团队中，指定少数人负责旧系统的维护等干扰活动； 时间隔离：每周固定一个时间段处理旧系统的服务请求，每天固定一个时间段不允许打扰别人。
23	计划	在做计划时，首先要估算规模和复杂度。	传统的方法是功能点、代码行估算，敏捷的方法是相对规模估算。
24	计划	简单的事情一次做对，复杂的事情快速试错。	1 需要培养开发人员不犯低级错误的能力。 2 通过快速迭代进行快速试错，把复杂的问题简单化，尽早消除技术风险。
25	计划	定义任务的完成标准，确保对交付质量达成一致。	在做事之前要明确任务的完成标准。
26	任务优先级	缺陷的优先级高于需求的优先级。	不欠技术债务，缺陷越早修复，成本越低。如果有未修复的缺陷，则在安排进度计划时，要优先修改缺陷。
27	任务优先级	高风险的需求优先级高于低风险的需求。	尽早报告坏消息的体现。
28	任务优先级	根据需求优先级排定开发顺序，先做优先级最高的需求。	很多项目组把需求优先级束之高阁，没有发挥其作用和价值。
29	任务优先级	尽早偿还技术债务。	技术债务是指需要优化的技术方案，需要修改的错误等。 尽早改错，尽早重构。
30	任务优先级	要事第一，专注于当前最重要的事情，而不是最紧急的事情。	做最有价值的活动，你的活动才有价值，投入产出比才最高。
31	任务优先级	通过骨架驱动的开发，尽早发现接口的问题。	在开发具体的功能之前，先开发完成所有的类定义，各个类之间的关系，各个方法或函数之间的调用关系，搭起来整个系统的骨架，然后增量式填充各个类与方法的具体实现。
32	进度跟踪	通过每日站会、持续集成、每日确认、燃尽图等手段实时跟踪项目进展。	想尽一切办法，紧盯项目进展，尽早暴露问题。
33	进度跟踪	旁观项目的进展而不是干扰项目的进展。	团队是自管理的，chickens们不要去指手画脚，迭代评审会议是最好的发表意见的机会。
34	进度跟踪	PO、测试人员要每天验证、确认需求的完成情况。	有问题，早发现，早修正。
35	进度跟踪	通过看板将项目可视化。	目标、完成准则、任务分工、计划、进度、需求、设计、风险、缺陷、问题、需求变更、度量数据等都做到可视化。
36	进度跟踪	通过燃尽图度量项目的进展。	燃尽图中可以看到历史，可以预测未来，能够直观的看到离目标有多远，是很好的可视化项目进展的工具。
37	进度跟踪	一小时内决策而不是拖延决策。	快速试错！
38	开发	不为未来的不确定做设计，不过度强调代码的通用性。	尽早实现，尽可能简单实现，后续需求变化时，重构它。
39	开发	在代码编译之前，消除80%的缺陷。	开发人员自己要做TDD，静态检查，代码评审。
40	开发	代码的内部质量决定了外部质量。	内部质量是开发关注的，外部质量是客户关注。 外部质量通过测试来检验，内部质量通过评审来检验。
41	开发	通过重构优化代码的内在质量。	代码的内部质量决定了外部质量。 短期看外部质量，长期看内部质量。 重构本质上是在优化详细设计。
42	开发	编写简洁可用的代码。	小类，小函数，职责单一，实现了当下功能即可。
43	开发	通过静态检查工具尽早发现代码的不规范与坏味道。	这是最快速的发现代码问题的手段，投入产出比最高。 静态扫描可以很好的提升代码的内部质量。
44	开发	提倡少而精，避免快而脏的工作模式，保持平稳的开发速度。	牺牲了质量而追求速度，是很多开发团队的短视行为。 不要为了速度而牺牲质量，这句话强调一百遍都不过分！
45	测试	测试用例并非一定文档化，测试要点优先于测试用例。	编写了测试要点后，有经验的测试人员可以进行探索性测试。探索性测试的效率更好
46	测试	通过自动化测试工具提高测试的效率。	导入各种自动化测试工具，开发专门的测试程序，确保可以随时进行回归测试，减少测试人员的重复劳动。
47	测试	通过测试驱动的开发，减少返工，提高开发效率。	开发人员需要改变工作习惯！ 测试驱动的开发并不会降低整体的开发效率，质量是免费的。
48	测试	通过持续集成、自动化单元测试或冒烟测试尽早发现软件的缺陷。	不犯错、少犯错、快速试错、尽早改错！ 缺陷越早发现，修改的成本越低！
49	沟通	在做项目计划之前，要通过需求梳理、规模估算、验收准则、策划会议等手段对任务进行充分沟通。	弄清楚了做什么，做到什么程度，才能制定合理的计划，短期的迭代计划才具有可行性。
50	沟通	尽早报告坏消息。	通过各种实时反馈手段，快速报告坏消息：     1 通过spike发现技术风险；     2 通过结对编程，静态扫描，测试驱动的开发，持续集成等实时发现程序缺陷；     3 通过每日确认功能完成、每日站立会议尽早发现进度问题；     4 通过迭代评审，尽早确认需求的完成；
51	沟通	和客户的合作胜过合同谈判。	需要和客户协商需求优先级、交付顺序。 需要客户在过程进行多次确认，而不是最后一行确认。 当发生需求变更时，需要和客户重新划分需求的优先级。
52	沟通	一图胜千言，通过图形表达需求、表达设计思想。	通过图形沟通效率更高。 要培养开发人员的图解力，熟练掌握在什么情况，应该采用哪种图形来表达自己的思想。 常见的图形包括：       树图       流程图       类图       交互图       状态图       二维矩阵       界面原型
53	沟通	面对面地沟通胜过文档沟通。	即使写了文档，也需要面对面沟通！
54	沟通	好代码才是文档，烂代码就是垃圾。	代码就是文档，这句话是有前提的！不是所有的代码都是文档！
55	沟通	简化一切文档的编写。	敏捷并非没有文档。 客户要求的文档是必须交付的。 其他文档都是可以简化的。 文档中的每项内容都要有价值，有后续的用途，否则就删除之。 简化文档的真正意义未必是减少了工作量，而是减少了开发人员的精神负担！
56	沟通	按技术方向分工，会人为地增加沟通成本。	传统的人员岗位划分：需求人员、设计人员、数据库专家、美工、前端开发人员、后端开发人员、测试人员等，这种模式完成一个需求需要多个角色参与，增加了误解的概率，增加了人与人之间的沟通成本，降低了开发效率与质量。
57	授权	分散决策权力给最了解情况的人员，让团队自我管理。	1 谁最了解情况，谁最有发言权。管理者站得高，看得远，但是对具体问题的决策往往太高大上而不切实际。 2 通过授权充分调动每个人的积极性。 3 让团队成员自己估算、领任务、自己做计划、自己做技术决策、自己调整计划 4 在团队内建立承诺的文化，承诺了就要兑现。
58	授权	推迟决策，对信息了解充分时才做决策。	在项目的初期，信息不完备时做出的决策，风险大，返工概率高。
59	授权	小团队才能实现自我管理。	人多了无法快速达成一致，效率反而会降低。 敏捷团队的人数一般控制在10人以下。如果人多了，需要拆分成多个团队，多个团队的敏捷应采用大规模敏捷的方法。
60	授权	用目标、放权、旁观、指导替代具体的任务安排、跟踪与决策。	少说，少参与，多看，多反思。
61	效率	全栈工程师，跨职能团队，按功能耦合划分小组。	全能工程师，全能团队，一个需求仅由一个团队来完成，这样效率最高！
62	效率	提高效率的最佳手段： 1 少做无用需求； 2 一次做对，少返工； 3 排除干扰； 4 减少非增值活动； 5 尽早改错。	仔细体会左边的5条手段，才能真正理解敏捷的各种仪式与实践。
63	效率	需求、设计、编码、测试在一次迭代内并行执行，通过并行提高效率。	缩短每个需求的交付周期！