一、敏捷宣言价值观

· 个体和互动高于流程和工具

    虽然个体和互动 高于 流程和工具，但是并不代表我们就可以省略一些做事的流程和工具，只是将后者相对弱化，在发生问题需要沟通的情况下我们更倾向于直接面对面的沟通，通过简单的演示和展示自己的想法更好的让对方了解自身的意图，从而提高大家相互理解的程度，更能了解对方意图，提高沟通和工作的效率。在通过个体沟通互动解决了当下的问题的前提下，可以按照流程和工具走相关流程存档，但是我觉得，除了存档之外这种流程和工具都将会被弱化，因为大家已经习惯于个体互动沟通带来的效率。包括我们的客户也将逐渐适应这种方式。

· 工作的软件高于详尽的文档

    详尽的文档可以很好的记录在开发之前人们的想法，但是光有想法不足以产生更高的价值。

    引用保罗·格雷厄姆的创业公式

    （1）搭建原型

    （2）上线运营（别管bug）

    （3）收集反馈

    （4）调整产品

    （5）成长壮大

    硅谷创业教父的公式也很好的阐述了这一点，我们需要尽快交付可以工作的软件系统，然后聆听用户的声音，从中发现他们真正想要的是什么，通过收集这些来自使用者的声音去迅速的调整我们的产品，去适用使用者的需求，这样才能符合更多使用者的需求，让我们交付的增量更有价值，更多的人使用。

    对于PO而言，想法都是美好的，但是一直停留在美好的想法中无法验证是否他的想法能够满足用户真正想要的东西，需要团队的快速交付增量来逐步验证他的想法，收集用户的反馈结果，以便于调整他当初的想法，去满足更多的客户，所以当初的想法是为了迎合客户一直在变的过程，详尽的文档根本无法听到这些客户的声音更不可能随时去改变，去验证。有的时候PO在得到交付的增量之后自己都会发现这其实是对用户无用的产品，从而终止开发的计划，对于整个团队来讲也可以节约大量的时间。

· 客户合作高于合同谈判

    双方最想要的结果就是心目中的产品以最快的速度上线，为达成这一目的PO和开发团队之间应该保持紧密的沟通和项目透明化，及时反馈双方遇到的问题并商量解决对策，讲出自己的想法和目的，以便于得到对方的理解和配合，如果刻意隐瞒各自背后的目的和利益，精于算计，会拖慢整个过程中问题的解决。

· 响应变化高于遵循计划

    Scrum 不做大而全的计划，因为这将耗费大量时间并且对突发状况难易灵活调整，我们做的更多的是明确的短期目标，以满足产品最有价值的增量，产品更有效的反馈，对后续产品的方向做参考，这样就使得每一步都走的比较有意义，快速响应市场和客户的调整变化，使得产品更有市场竞争力，所以敏捷是要拥抱变化。

二、敏捷宣言遵循的原则

1、我们最重要的目标，是通过持续不断的及早交付有价值的软件使客户满意。    

    Scrum的迭代是以Product Backlog优先级顺序排列的，保证了最高价值提前交付，每次迭代增量交付，按照固定的节奏保持持续不断的交付有价值的功能，使客户满意。

2、欣然面对变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌握变化。

    Scrum持续交付增量，新的增量必须是“完成”的，是满足Scrum团队对完成的定义的，是可以交付客户使用的，Product Backlog和Sprint Backlog的动态调整，使能随时响应客户的变更，保证产品满足市场需求。

3、经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

    Scrum限制了迭代周期小于或等于一个月，尽早的、固定周期的交付可工作的满足需求的软件，为了加快速度，甚至可以缩短到一周。

4、业务人员和开发人员必须互相合作，项目中的每一天都不例外。

    通过站会，PO和开发团队每天在15分钟内高效完成：昨天做了什么，今天要做什么，有什么问题？及时相互沟通，合作解决问题，避免信息断层，减少延时，随时调整。

5、激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，从而达成目标。

    引导形成自组织，Scrum Master作为仆人式领导，提供团队所需的环境和支援，引导并激励团队，并相信团队能胜任自己的工作，对于大家做出的成果毫不吝啬自己的赞许，对于欠缺实行逐步引导。

6、不论团队内外，传递信息效果最好效率最高的方式是面对面的交谈。

    Scrum中的计划会、站会、评审会、回顾会，都强调面对面沟通；人与人沟通30%来自语音，70%来自肢体表情；面对面沟通是最高效的办法。

7、可工作的软件是进度的首要度量标准。

    Scrum增量交付的软件，是满足团队对“完成”的定义，增量是可以检视的，产品负责人是否决定真正发布它，增量必须是可用的。

8、敏捷过程倡导可持续开发，负责人、开发人员和用户要能够共同维持其步调稳定延续。

    Scrum没有大而全的计划，每次迭代都增量滚动式的拉取产品待办列表，它为开发团队提供指引，能够促使开发团队向着同一目标前进，而不是孤立工作，迭代的周期固定，满足时间盒的限制。

9、坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强。

    回顾会检视自身技术，团队配合，工作方式等多个方面，为下一个Sprint创建改进的机会，团队的各个成员要求具有成长性思维，追求卓越，Scrum固定的时间盒内拉取任务，让团队有时间处理技术负债，减少后期的麻烦。

10、以简洁为本，它是极力减少不必要工作量的艺术。

    Scrum架构简洁，面对面沟通，DOD以及DOR的明确定义，都是为减少沟通、交接过程中的浪费，去掉不必要的流程和工作，为了实现目标调整最快速的工作方式，去除和弱化冗余的流程和形式。

11、最好的架构、需求和设计出自自组织团队。

    我们追求持续改进，不断完善的框架；每次Sprint来自于Product Backlog，需求目标透明清晰，团队每个成员目标一致，整个团队共同承担责任，而不是单一职权负责制，开发团队知道哪种方式最适合他们的日常工作，毕竟所谓的领导者未必真的参与到实际的开发工作中，未能感同身受。

12、团队定期的反思如何能提高成效，并因此调整自身的举止表现。

    Scrum回顾会检视自身并创建下个Sprint的改进计划；对人、关系、过程和工具进行检视，并在下个Sprint列出改进措施，使大家能在下个Sprint中更高效更愉悦，效率更高，产出更高更有价值。

三、展示和具体行动项

    在会议中逐步引导和灌输敏捷的思想，以成功案例或者鲜明对比的案例作为引导基础，让大家觉得敏捷确实是有优势所在，能够帮助客户持续的看到自己想要的东西的全貌。

    引导督促团队成员之间的面对面交流，逐渐弱化聊天工具的依赖。

    每一次会议提前想好会议的主题，设计好每个环节，逐步引导大家最终实现本次会议的目的，改善会议无限发散的情况。

    增加自组织团队在大家心中的分量，权利下放，更多的事情由开发团队来做主完成，充分的尊重他们的决定，对于有争议的问题采取引导的谈话方式，发表出各自的想法，大家相互理解以便于完成最后目标。

    改进沟通话术，给大家创造一个互相平等，互相尊重的沟通氛围。

    引导大家停止对不断变化的需求的抱怨，引导大家欣然拥抱变化，让大家明白每一个需求的变化都是为了更好的响应使用者方面并给使用者带来相应的价值。