无论大小团队，都会面对一个永恒的问题，如何让团队成员统一目标高效配合，并降低团队的管理复杂度，节省事件处理的时间成本与沟通成本，实现迅速的达成研发目标，最终大部分团队都将目光锁定到了敏捷开发实践中进行不断的摸索和改进。
2020年敏捷状态报告中对全球数万家企业进行了调研，得出分析结果:大多数敏捷实施的主要目的是缩短周期、降低风险、快速交付、提高软件质量和满意度。
其他实施敏捷的目的如下：
- 缩短开发周期，提升交付效率（71%）
- 增强产品市场响应能力（63%）
- 提高生产力（51%）
- 提高业务与产品一致性（ 47%）
- 提高软件质量（42%）
- 增强交付可预测性（39%）
- 降低开发风险（37%）去年 28%
- 改进产品开发过程透明度（36%）
- 增加团队士气（31%）
- 减少项目成本（26%）去年 41%
从分析结果中可以看到有71%的组织表示他们企业实施敏捷最主要的目的是缩短开发周期。这是通过更快的迭代节奏来达成的。通过敏捷可以加快研发节奏快速达成产品研发目标， 那我们如何衡量引入敏捷后是否获得了成功还是偏离了我们最初的目标通过调研，当被问及组织如何衡量敏捷转型的成功时，成功的主要衡量标准与最近几年所报告的一致。
敏捷交付成果的得分明显高于产物的得分。（outcome 大于 output）
成果方面的度量： – 客户满意度和业务价值
产物方面的度量： – 按时交付和高质量
从以上两点可以明确的得出一个结论：敏捷能快速带来价值产出与收益。但是调研分析中虽然95%的组织已经实施了某种形式的敏捷过程，但实践的成熟度仍在摸索中。大约50%的受访者表示，他们的团队中只有不到一半的人在使用敏捷，84%的人承认他们的组织没有达到高水平的敏捷能力。
那如何才能正确的进行敏捷开发，正确的开展敏捷实践，首选要避免对敏捷的不完全认识。每个人获得信息不一样，对敏捷的认识也不一样，存在一些误解。
比如：
- 每天开站立会，用上敏捷工具就是敏捷开发了。
- 敏捷开发不要求写文档，就完全不需要文档了。
- 敏捷开发中，软件架构不重要，重视交付效率，不重视设计。
- 敏捷是开发人员的事情，产品，测试，UI设计关系不大。
- 敏捷开发就是需求没有完全想清楚，就直接进入了开发阶段
要消除这些误解首先要了解下敏捷的核心思想：
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。了解敏捷的价值观与核心思想非常重要，这个决定了后面敏捷实践的判断原则，那些是适合团队的，那些是需要调整的，找到最适合团队的工作方式。
敏捷的价值观：
- 敏捷开发是一种应对快速变化需求，实现快速交付的一种软件开发能力。
- 拥抱变化，提前交付与持续改进这是敏捷开发的价值和原则。
- 相对于“非敏捷”，更强调团队紧密协作与互动而非文档，形成紧凑而自我组织型的团队。
敏捷十二原则：
- 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 交付可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
有了深刻的敏捷思想，我们还需要有一系列的工具和流程支持才可以事半功倍。
标准敏捷开发流程就像一个协议与约定，约定好了我们进入敏捷开发的角色，以及产出与输入围绕怎么样的流程进行配合和协作。
当然这个过程的产出物质量是否做的很好，还需要有一个检测机制，这个就是 Story Test 机制。 TDD，SBE, BDD,找到贴合业务的QC 机制达到事半功倍。
按照敏捷的流程与产出物检测机制，是不是就够了，可以让团队高效配合，快速实现交付呢，到这里其实团队在实践这些流程与机制的时候也是分阶段进行的，根据团队能力裁剪到适合团队的流程和检测机制。
这个不断调整的过程中也会碰到很多问题如：
1.团队阶段性目标不清晰
2.需求粒度太粗，细节不明确。
3.技术负债积压过多
4.迭代周期不稳定，迭代周期过长
5.耦合任务中有大量等待时间
6.需求功能设计不全
7.缺少合理技术设计方案
8.无法准确评估开发进度及风险
9.自动化，CI/CD缺少
10.日志监控排错设施不健全
11.团队内部协作困难
12.项目边界不清晰
13.需求变更频繁
14.质量差，改BUG消耗大量时间
15.异地团队协作障碍多
16.测试时间压缩严重
17.频繁延期交付
这些问题我们在总结归集为可以总结为这几类问题：
1.目标问题
2.设计问题
3.需求问题
4.质量问题
5.协作问题
6.进度问题
这些问题在敏捷实践中也可以找到对应的工具来优化提升，如：
1.燃尽图 ：可以对研发进度和目标进行强化管理
2.Gitflow：可以对端对协作，多版本管理，与基于 featue 功能的开发管理。
3.CMMI ：可以提升团队在设计，需求管理，过程管理，过程改进等等方面的能力。
4.Devops：可以提升整体研发流程管道与自动化。形成流水线型作业，其重要程度在某些团队项目中要高于敏捷本身。
1.然进图：
敏捷项目管理燃尽图，项目开发进度与敏捷开发成熟度的评估工具。
燃尽图（Burndown Chart）是以图表展示随着时间的减少工作量的剩余情况。
它对于预测何时完成工作很有用，经常被用于敏捷软件开发中。
燃尽图也可以用于任何可测量的进度随着时间变化的项目。
横轴：显示工作天数；
竖轴：显示剩余工作；
计划剩余工作曲线：该曲线实际上是一条直线
实际剩余工作曲线：实际工时消耗曲线。
2.GitFlow
Gitflow 是一个分布式git代码分支管理模型，适合多团队协同开发，其优点在于可以很好的同时管理不同分支与不同功能迭代。
可以有效的并行开发，提高软件交付质量与开发效率。
Production 分支
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
Develop 分支
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
Feature 分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
Release分支
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
Hotfix分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
3.CMMI
CMMI (Capability Maturity Model Integration For Software，软件集成能力成熟度模型)
CMMI是由美国卡耐基梅隆大学软件工程研究所（Software Engineering Institute，SEI）组织全世界的软件过程改进和软件开发管理方面的专家历时四年而开发出来的，
并在全世界推广实施的一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估。
敏捷给出了How to do， CMMI给出了What to do。
敏捷给出了一些价值思想观与仪式感，CMMI 给出了很多细则实践与验证方法论。
敏捷侧重建立团队的能力，CMMI侧重建立组织级的能力。
CMMI 重点会建立基线
- 量化衡量产品交付质量
- 量化衡量产品需求任务
- 量化衡量产品交付价值
最终实现聚焦客户价值，交付刚刚好的系统
4.Devops
DevOps是基于对更好的协作和更快的交付的需求而产生的, DevOps是一种软件开发方法，涉及软件在整个开发生命周期中的持续开发，持续测试，持续集成，持续部署和持续监控。
DevOps的目的是更快速，更可靠地创建质量更好的软件，同时开发，运维团队之间进行更多的沟通和协作。DevOps是在较短的开发周期内开发高质量软件的首选方法。整个DevOps周期内，研发流程关键环节，集成，测试，部署，监控都是管道式流程化运作，实现了高效，低错，标准化。现在越来越多的企业都会搭建自己的DevOps平台和管道，把DevOps作为其业务目标的前进方向，DevOps也是未来软件开发领域的标准化能力。