一、敏捷宣言的价值观

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

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

客户合作 高于 合同谈判

响应变化 高于 遵循计划

1、个体和交互 高于 流程工具

    无论是经验还是研究表明，人与人直接沟通的效率是远胜于通过流程和工具的，但是在Scrum中，并不是说不使用流程和工具，比如我们要敏捷看板来将工作透明化，有时我们也需要视频会议的方式来开会沟通问题。这个说法只是相对而言的，在同等情况下，我们建议通过面对面的沟通来解决问题，而非通过一些及时工具电话、qq等来解决问题。

个人示范：

    1）帮助团队成员沟通风险及跟踪进度的时候，直接去找本人面对面的沟通，而非通过微信或qq沟通

    2）跟客户汇报工作的时候，如果可以面对面的沟通就不会采用视频会议或者打电话沟通。

在我们团队具体的体现包括：

    1）团队成员物理上的坐在一起，提供一个高效沟通的环境

    2）测试人员发现问题直接与研发人员沟通，而非采用传统的提bug单的传统方式。bug仍会被记录，只是用于统计团队研发质量/

2、工作的软件高于详尽的文档

    与传统的瀑布模式相比，敏捷更强调的是软件系统的可用性，而非各种各样的详尽文档文件。与上一条价值观相同，文档不是不被需要，而是尽量简化，比如每个需求的测试文档我们还是需要的。只是相对于详尽的文档，我们更关注的是产品的可用性。

团队在Scrum中具体的体现为：

    1）迭代的成功与否是迭代内每个故事被完成，而完成的标准是开发测试完成，具备上线的标准，而非提供相关需求、开发、测试文档。

    2）需求评审会议，我们会要求团队成员演示本迭代的产品。而非提供详尽的操作文档给客户或其他利益相关方。

3、客户合作高于合同谈判

    敏捷的目标是快速响应客户需求，提供高价值的产品给客户。在传统的瀑布式项目中，项目启动初期与客户签订合同，在项目结束的时候客户来验收合同成果，只在项目头尾参与到项目中，并未参与中间生产过程。因为纸面合同对于不通的人有不同的理解，这会导致客户的最初的需求和研发出来的产品是不相符的，而且在项目最后参与的客户已经来不急变更，导致项目失败。在敏捷过程中，我们希望客户是参与到项目的全流程的，参与到每个迭代的验收，以客户为导向。

个人示范：在团队遇到外部问题的时候，我会代表团队跟客户协调相关资源。如果迭代过程中有相关的风险，也会及时告知客户，让他们及时了解开发状况。而非到了项目结束的时候再找客户沟通。

团队具体体现包括：

    1）与客户举行需求澄清会议，在迭代初期会与客户就本迭代要做的事情及优先级与客户达成一致，对需求不明确的点，由客户来澄清。

    2）在迭代评审会议时，客户参与演示验收，对于与需求不符或优化的点及时提出，对于小的优化点会在本次版本上线前优化，对于功能比较大的优化点，会排入到下一轮迭代进行改进。

    3）通过平台管理工具，透明化团队工作进度，客户可及时了解团队开发进度。

4、响应变化高于遵循计划

 敏捷开发的第四条价值观就是"拥抱变化"。人们常说"世界上唯一不变的就是变化”，现实的情况也是如此，大数据、信息化的爆炸，响应客户的需求在不断的变化，就要求我们不断适应客户不断变化的需求，而非循规蹈矩。具体的体现：

个人示范：

    与团队回顾会议类似，定期的进行复盘（目前是1个月，暂时还没有做到1周一复盘），对一个阶段的自我表现进行总结，根据实际表现情况，及时进行调整。比如考试计划，在执行过程中由于紧急工作导致计划无法按期执行，我会及时调整计划，以适应我现在的状况。

团队体现：

    1）根据客户的实际需要，需求时涌现的，动态调整Product Backlog产品代办列表的优先级，快速响应客户需求

    2）短的迭代周期2～4周，可以在迭代周期之间变更需求，团队可以快速生产出客户或市场需要的产品

二、敏捷原则

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

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

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

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

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

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

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

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

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

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

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

团队定期地反思如何能提高成效，并依此调整自身的行为表现。

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

    亲身示范：在迭代开始前，会与PO一起找客户确认下个迭代的需求内容，及优先级。在开发中会提醒并引导团队按照需求的优先级进行开发，减少并行开发。

    在Scrum中，根据客户的价值来排定产品代办列表的优先级，有限交付高优先级的产品功能，通过短迭代方式，每个迭代结束尽早交付客户需要的产品，让客户满意。

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

    亲身示范：在迭代进行中，突然新增进阶需求，我会找PO及客户确认是否必须新增紧急需求，如果新增是否要替换出同等工作量的其他需求。如果在后期，故事均处于开发中，我会与团队成员商量，是否可以承接新增的这个需求，如果可以，再新增。如果不可以，可能需要放到下个迭代，但优先级会很高。

    Scrum中不害怕变化，也支持客户的变化，支持迭代代办清单的动态调整，在迭代过程中，支持迭代需求的动态替换。优先保证高优先级的需求可以被交付。

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

    亲身示范：我们团队交付周期是2周，而且不允许中途随意变更迭代周期。

    Scrum中的迭代周期一般是2～4周，迭代间的间隔也是固定的，每个迭代交付可工作的可演示的软件。具有良好的节奏感。

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

    亲身示范：组织每日站会，保证团队成员在站会时都能参与进来，统一成员的进度。

    Scrum中有每日站会，团队成员统一团队进度，相互合作。团队成员物理上坐在一起，为团队提供了一个相互合作的环境。

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

    亲身示范：在相关会议的时候，会短暂的暂停，给团队成员思考发言的机会。回顾会议的时候，尽量不邀请领导参与，为他们提供一个比较放松的环境，站在中立的角度，不轻易给出建议。

    Scrum Master提供一起工作的环境，同时引导团队成员通过自己认领任务的方式来逐渐培养团队成员的自组织能力，给予团队成员充分的信任，让他们不断的挑战自我，从而达成目标。

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

    亲身示范：无论是跟团队还是跟跟客户沟通，如果有可能都是直接面对面沟通，减少使用微信或其他工具。

    Scrum中每日站会、迭代评审、迭代回顾、计划会议等相关活动都是通过面对面进行的，面对面的沟通效率大大提升了完成工作的效率。

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

    Scrum中，会对需求完成的标准进行定义，这个定义是可工作的软件，而非所处的节点或文档。这个增量是可以被检视、PO决定是否发布。

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

    团队在整个项目开发期间保持一个适当的、可持续的速度，从而维持最高的质量标准。

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

    Scrum站会、迭代评审会议和迭代回顾会议，都在不断的从不同的角度：每天开发进度、需求设计优化、团队的优化来进行检视调整不断的完善团队技能，使得提升敏捷能力。

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

减少工作中的没有必要的流程，面对面的沟通及完成标准的定义，都简化了迭代工作，团队更专注于工作本身，而非形式

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

Scrum中PO负责做什么，而团队负责怎么做，团队是一个自组织的团队，决定需求具体怎么设计、怎么做来交付完整的的需求。通过不断的检视调整探索适合于团队的最好的架构。

12、团队定期地反思如何能提高成效，并依此调整自身的行为表现。

亲身示范：定期自我反思，反思的基础是善于观察现状，从日常点滴中总结提升。将遇到的事情进行记录，然后定期每个月/每周进行查漏补缺。

Scrum中每日站会、迭代回顾会议，团队都在不停的调整寻找合适自己的团队的敏捷，不断的完善提升团队能力。