我觉得 QA 就是一个神奇的职业。在开发眼中、老板眼中、产品眼中，QA 无所不能。QA 测过的东西肯定是无 bug 的，不然要你干嘛呢？QA：......。然后，还有一种老板总觉得 QA 就是一个大管家，跟质量相关的事情你就得管。我的领导就是那样的。于是，我就拥有了一个新的职责 - 优化公司的项目流程并且评估研发的工作能力。
为了完成工作，我深入到产品线参加他们的每一个会议、跟踪每一个阶段，然后列出存在的问题给出优化方案，然后呈报 CTO。最后优化公司的流程，并且组织分享、学习新的流程规范。然而理想总是美好的，现实就是每个研发都是附和你的。 我还是系统的学习下项目管理，参加一些活动吧，看看别人是咋做的？毕竟这不是单纯的一个活，而是一个系统工程，涉及到管理学和人性。在学习敏捷过程中我发现最好的学习方式就是总结，把理解的东西归纳、总结、再输出。其中感受不一样！今天在这里只讨论敏捷的一些概念，只用于学习总结。不涉及落地实施 。
“敏捷” 一词在脑海中一过，就有千万种疑惑，它究竟是什么呢？我也不知道。
在一些教科书上看到敏捷的定义是这样的：
“敏捷” 一词意味着 “标记快速的优雅的移动的能力”，或者是 “拥有快速的机敏和适应能力的角色”。感觉挺绕口的，不管它啥意思。我们来看一下企业为什么要实行敏捷吧。
主要是解决 4 个方面的问题：
1.人的管理
2.生产力也就是生产效率的提升
3.产品质量
4.产品价值
先来谈谈第 1 点 - 人的管理：
敏捷强调以人为本，尊重个体，先发展员工再发展团队。这个在敏捷的一个框架 - 精益敏捷的价值观中有明确提出。精益思想之屋的 3 大支柱之一就是 “对人的尊重”。也就是说软件行业的从业者是知识工作者，知识工作者需要得到足够的尊重和发展，才能开心的工作继而发挥最大的潜能为企业创造更多的价值。
第 2 点 - 提高生产率
在传统的制造业中，提高生产率就是生产的标准化、薪酬计件、自动化生产线。在软件行业中，敏捷大师认为除了人的主观能动性、生产力的提升应该主要在过程中。也就是软件的研发过程。比如瀑布式开发模型的浪费在于消息传递过程的浪费，一个是工序之间传递的浪费、一个是文档传递的浪费。敏捷主要做的就是消除这些浪费。
第 3 点 - 产品质量
所有的开发模型、管理动作都是围绕产品质量来开展的，我们希望我们开发的产品具有高质量、让客户满意。而现实往往是测试通过了，产品交付了，发现 bug 了。这怎么解呢？敏捷的理念是：不断的交付、不断的测试、不断的集成，尽量把 bug 解决在生产的过程中，也就是内建质量。这里会有一些工程实践的例子，比如单元测试、研发自测、优先测试、持续集成等等。
第 4 点 - 产品价值
敏捷中提倡价值优先，所有工作的目标是实现客户价值及及早的交付有价值的产品。这里会引用一个概念叫 “客户参与”。也就是让客户参与到研发过程中，或者是每一次的交付、每一次迭代都要给客户演示、试用，并收集他的反馈。在最早的时间挖掘客户真正的需求。
然后，我们来看看敏捷是怎么做的？
第一个是凝聚人的力量。也就是凝聚业务负责人（产品经理）、团队（敏捷团队）、客户、管理者 4 方人员紧密配合、目标一致、交付有价值的产品。
第二个是价值驱动、消除浪费。就是说在开发的过程中我们优先开发的永远是业务价值最高的用户故事，并且识别过程中的浪费消除它。
第三个是持续学习和改进。敏捷有一个价值观是 “拥抱变化”。敏捷认为变化总是存在的，所以要拥抱变化、掌控变化、做适应和检查。通过持续不断的学习和改进来掌控变化。
那么敏捷是怎么做到持续交付业务价值高的产品呢？
有一句话叫做 “做正确的事情”。做正确的事情就是把握正确的方向，只有方向是正确的做出的产品才是有价值的。只有产品把握正确的需求研发团队才能去 “正确的做事情”。还有一个观点是 “让听得见炮火的人去指挥战斗”。敏捷理念中提倡团队去做一些小的决策，并且经常做小的决策。
我们看一下下图怎么把握方向：
从上图得出几个信息：1.需求和技术上都确定的事情优先处理。
2.需求和技术都模糊的事情，捋清楚了再处理。
3.需求和技术上都不确定的事情最后处理或者不处理。
在敏捷中，还有一个决定优先级的原则叫 MoSCoW 原则，它强调高价值高风险的故事优先处理。
说了这么多，我们回过头来回答开头的问题，敏捷是什么？
敏捷是一种框架吗？是一种工程实践吗？是一种方法吗？好像都不是。敏捷是一种综合体，它有价值观、有方法论、有工程实践、它也可以做到很好的过程控制...。它的过程围绕 3 个支柱进行：透明、检查、适应。也就是持续的沟通、客户的参与、化整为零:经常做小的决策、把决策分布到项目进展过程中去。
最后我们来看看敏捷带来的受益有哪些？
