Foreword
基本都学过软件工程，把工程的思想融入到实际的工作中，并且可以从事物的发展之中，再重新提炼出以前学到的工程管理之法，取其精华，去其糟粕。
何为敏捷
说敏捷之前，先说瀑布模型，经典的软件生命周期模型，在启动前就需要非常明确的目标和需求，启动以后按照固有的分析、设计、编码、测试、运维等流程进行，同时瀑布流也有着每个阶段明确的文档，所以每个阶段可以是解耦的，只要完成规定的要求即可。但是瀑布也有对应的问题，本身需求可能不明确，可能会变化，面对频繁变动或者理解不完全的项目来说并不适合，而且一个项目的实际分析设计到执行都需要花非常多的时间，前期并不能预见所有可能的问题。实际开发的过程中，完全理解需求或者完整准确的目标基本不存在，所以一开始计划的再大，也赶不上变化更大。瀑布模型于是就变成了其他模型中的一个子环节，大项目下的子目标可能是明确完整的，所以可以按照瀑布流完成。
而为了应对频繁变更的需求和不能准确掌握未来的需求的情况，敏捷应运而生了。敏捷是迭代式的，可以看到高楼平地而起的每一份变化，做足了应对一切的准备。如果说瀑布是面向计划的，那么敏捷就是面向变化的。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
经常可以看到说敏捷是缺乏设计和文档，这个不尽然。由于敏捷更新快，所以缺乏文档？这根本说不通。只能说敏捷如果要维护文档，那么敏捷的文档更新频率会非常高而已。同理缺乏设计也是不存在的，每次迭代都需要设计，只是变更的更快而已。
敏捷是面向变化的，所以每次迭代都需要有人拍板定下来的当前要做的需求和最终实现的效果，类似一个小瀑布。但是如果拍板的人对于项目或者需求理解不足，可能就会造成后续多次迭代和反复，所以敏捷非常依赖于拍板的人，一个好的领头可以让效率充分提高。同时敏捷也充分发挥了领头人的主观能动性，避免瀑布模型前期计划时多数人碌碌无为、成天吵架却又定不下来的情况。相对而言敏捷容错性更好，它允许领头人犯错，也有足够多的机会去修正错误。
核心原则
- 主张简单
- 不要过度设计，经常有一些框架或者一些模型，都设计的大而全，但是实际上当前你只需要10%的功能，未来可能也只需要15%，剩下的设计基本都是冗余。所以建议模型设计的时候不要过度，保持简单，本身是可迭代的，日后再丰满即可。
- 拥抱变化
- 核心原则
- 可持续性
- 设计不是一次性的，结合简单模型，让日后有更多的可能，给下次设计留下空白。
- 递增的变化
- 模型不是一步就膨胀到最终的模样，对应的软件也是一点点变化的，由简到繁，再由繁到简的过程。
- 快速反馈
- 一个东西持续进步，一定是有反馈的，快速反馈才能及时修正当前前进的方向。
我的敏捷
回顾我自己的开发过程，先拿到一个明确的需求，然后快速实现一个简版，在实现的过程中去自我反馈，修正我的设计，快速给出来一个前期等待反馈的版本和简易说明，然后再进行几次小迭代，把一个功能做到尽善尽美的程度，然后再去更新设计文档和使用文档。
何时使用敏捷
- 需求不明确
- 没有具体规划
用敏捷主要就是这两点决定的，没有明确需求，所以可以用敏捷来试，寻找真实需求。同理，没有明确规划的情况下，也可以先用敏捷，让子弹飞一会，让小树先长大一些再去规划未来。有的项目能不能活下去都不知道，可以先用敏捷试试，就算凉了，付出的成本也是可接受的范围。
何时不适用敏捷，一个对性能有极致要求的软件不适合敏捷，敏捷的这种开发模式，注定了他与性能无缘，他的迭代和膨胀模式，都会导致性能受到影响。所以如果要开发高性能的东西，就不要过度敏捷了。
规模化敏捷开发
以上的敏捷大部分都是基于单团队的敏捷开发，如果多个团队配合，做规模化的敏捷开发时，又要怎么配合呢？
Scrum of Scrums
规模化敏捷中常强调的有效沟通和交付对齐。Scrum of Scrums是一种最早的规模化敏捷技术，简单且有效，用于集成多个（建议不超过3-9个）在同一产品上工作的Scrum团队的工作。Scrum of Scrums确保团队之间有效沟通，以使每个团队的输出与其他团队的输出很好地集成在一起并交付客户，尤其是在工作重叠或时间顺序很重要的地方；同时，为了共同讨论并决策，最直观的活动就是SoS会议，由各Scrum团队中派出主要代表参加。总体目标是使团队工作保持顺畅，并使总体交付成果保持在正常状态。通常组织将这种方法用于扩展敏捷性和组织大型复杂产品交付的第一步，然后在酌情考虑采用更成熟的规模化敏捷框架。
SAFe（规模化敏捷框架），Scaled Agile Framework，是一套组织和工作流程模式，用于在企业规模上实施敏捷实践。该框架是一种知识体系，包括关于角色和责任、如何规划和管理工作以及要坚持的价值观的结构化指导。
多团队敏捷时，每个敏捷周期较多的落在2周左右的时间，而偏向硬件或者制造业的周期往往在四周及以上
Summary
没有什么绝对的方法论，无论敏捷也好，瀑布也罢，他们只是一种工程上的经验教训的极致总结。实际项目并不都是外包，或者目标不明确的情况，每个项目都得顺势改变一些。
Quote
https://zhuanlan.zhihu.com/p/162779049
https://www.atlassian.com/zh/agile/agile-at-scale/what-is-safe