敏捷开发 | 理想 vs 实践
全栈开发者
敏捷开发，理想 vs 实践 [旺柴][捂脸][捂脸] @全栈开发者 #全栈开发#
视频号
今天鲸鱼和大家聊一聊敏捷开发。
大家在应用敏捷开发过程中往往会遇到上面视频展示的冲突，现实和理想相去胜远。
什么是敏捷开发
首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。
其次，敏捷开发都具有以下共同的特征：
迭代式开发
增量交付
开发团队和用户反馈推动产品开发
持续集成
开发团队自我管理
最后，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。
具体方式
上面说了敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而具体的开发方式有哪些呢？
Scrum，极限编程（XP），精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。
除了Scrum和XP，对于上面的其他开发方式，我也只是简单了解，大家可以多查查相关的资料。
我们可以简单的对比一下Scrum和XP：
1. 在开发的过程中，你可以采用Scrum方式也可以采用XP方式；
2. Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。
敏捷开发宣言
《敏捷宣言》
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者
敏捷宣言是对敏捷的高度总结和升华，即使现在不理解也没有问题，在实践的过程中我们会逐渐对它有一个深刻的认识。
敏捷开发十二原则
在敏捷开发中，我们遵循以下准则：
我们的最高目标是：通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度（稳定持续是关键，不可抱佛脚或者怠惰）。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队（团队闭环）。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
敏捷开发宣言比较抽象，但是敏捷开发十二原则就非常具体了，相信用过敏捷的人都知道，上面的十二原则都是开发过程的经验总结。看到十二条原则，一一的对比我们公司在实施敏捷的过程，还存在一些问题，这些问题直接导致了低效率的，不顺畅的敏捷，例如：最后一条，团队要定期反省，这点做的就不好，造成团队的积极性降低，开发效率下降，而且很难作出调整，甚至我开始也是拒绝的，有了这些原则作为指导，我们可以更加从容的实施敏捷。
敏捷开发十二原则是我们实践的具体指导方针，它可以指导我们实施更加成功的敏捷。当我看到这些内容时，真有一种如饥似渴的感觉，真想一下子都把他们装进我的脑子里。书到用时，方恨少。及时补充自己永远都不晚。
敏捷开发框架参考