一、敏捷四大价值观（源自《敏捷软件开发宣言》）
敏捷宣言开宗明义地提出了四大价值主张，它们共同构成了敏捷思想的“北极星”：
1. 个体和互动 高于 流程和工具
核心：人的因素是第一位的。优秀的团队成员之间的直接、高效的沟通协作，比固化的流程和强大的工具更能解决问题、激发创造力。
实践体现：每日站会、结对编程、面对面讨论、集中办公。工具应服务于沟通，而不是阻碍沟通。
2. 可工作的软件 高于 详尽的文档
核心：衡量进展的首要标准是交付可以实际运行的、对用户有价值的软件。文档应有且必要，但不应为了文档而文档，或让其成为交付的障碍。
实践体现：每个迭代结束时交付可演示、潜在可发布的产品增量。文档保持精简、及时更新，形式可以是代码注释、Wiki或用户故事。
3. 客户合作 高于 合同谈判
核心：与客户（或产品负责人）建立持续、信任的合作伙伴关系，共同应对变化，比僵化地执行初期合同条款更重要。
实践体现：产品负责人作为团队一员，频繁参与评审和反馈；定期展示成果并根据反馈调整优先级；拥抱需求变化。
4. 响应变化 高于 遵循计划
核心：在复杂项目中，变化是常态。能够快速、灵活地响应变化，比严格按初始计划执行更能创造商业价值。
实践体现：短迭代允许频繁调整方向；任务看板可视化工作流；回顾会议持续改进流程以提升响应力。
宣言的结语至关重要：“也就是说，尽管右项有其价值，我们更重视左项的价值。” 这并非否定流程、文档、合同和计划，而是强调优先级和重心。
二、敏捷十二原则（支撑价值观的具体指南）
这十二条原则是价值观的具体展开，指导团队如何思考和行动：
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
（核心中的核心：价值驱动，尽早交付，持续交付。）
欢迎对需求提出变更，即使是在项目开发后期。敏捷过程要善于利用变更，帮助客户获得竞争优势。
（拥抱变化：将变化视为机会，而非威胁。）
要经常交付可工作的软件，交付周期可以从几周到几个月，倾向于采用较短的周期。
（短迭代：建立稳定、可信的交付节奏。）
在整个项目期间，业务人员和开发人员必须每天一起工作。
（紧密协作：打破壁垒，确保信息同步。）
围绕有动力的个体构建项目。为他们提供所需的环境和支持，并信任他们能够完成任务。
（以人为本：管理者是服务型领导，激发团队自组织。）
无论团队内外，传递信息最有效率也最有效果的方法是面对面交谈。
（高效沟通：最丰富、最直接的沟通形式。）
可工作的软件是衡量进度的首要标准。
（客观度量：不是文档写了多少页，计划完成了多少百分比，而是可以运行、测试的软件。）
敏捷过程提倡可持续的开发。赞助方、开发人员和用户应该能够长期保持稳定的节奏。
（可持续性：反对“死亡行军”，注重工作与生活的平衡，保持高质量。）
对技术卓越和良好设计的持续关注有助于增强敏捷性。
（质量内建：优秀的技术和设计不是奢侈品，而是快速响应变化的基础。）
简洁——最大化未完成工作量的艺术——是至关重要的。
（简化艺术：不做多余功能，保持代码和设计的简洁，降低维护成本。）
最好的架构、需求和设计出自自组织团队。
（自组织：团队被赋能，自己决定如何最好地完成工作，这能激发创造力和责任感。）
团队定期反思如何能变得更有效，并相应地调整自身的行为。
（持续改进：通过迭代回顾会议，不断优化流程和协作。）
价值观与原则如何指导测试团队转型？
结合您之前的问题，测试团队的转型必须植根于这些价值观和原则：
从“流程和工具”转向“个体和互动”：测试人员不再躲在测试管理工具后面，而是主动与开发、产品经理沟通，在站会上同步风险，在需求评审时积极提问。
交付“可工作的软件”：测试团队的目标不是写完美的测试报告，而是保障每个迭代都能交付一个潜在可发布、高质量的产品增量。自动化回归测试是支撑这一点的关键。
与客户“合作”：测试人员要成为产品负责人的“质量伙伴”，帮助澄清验收标准，并通过演示提供真实的质量反馈，共同决定是否发布。
“响应变化”：测试计划不再是僵化的文档，而是动态调整的。当需求变化时，测试人员能快速调整测试策略和用例。
“持续改进”：测试团队在回顾会上，不仅要关注开发过程，也要反思自己的测试实践——自动化效率如何？探索性测试有没有新发现？协作有没有障碍？
“技术卓越”：测试人员提升自动化技能、学习CI/CD，正是为了追求技术卓越，从而增强团队整体的敏捷性。
总结来说：
敏捷价值观和原则不是一套僵化的规则，而是一套思维模式和行动指南。它要求测试团队（以及整个团队）将重心从“遵循计划和控制过程”转移到“拥抱变化、快速交付价值、并通过人的协作来实现这一目标”上。深刻理解它们，是成功进行敏捷转型、并找到测试新价值的根本。
