敏捷方法知识点整理

测试积点老人

先写关键字

• 重点：快速开发、快速交付、快速反馈、沟通大于文档、可运行程序大于文档、响应变化
• 误区：可以节省工作量、高质量、文档可以省略、敏捷工具好用、敏捷很简单
  

然后来三大关键

敏捷是什么：
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

敏捷能干什么：
这个我想了很久，发现还是片面了。敏捷能管理软件开发过程。能帮助我们管理软件开发中的很多问题，比如:需求变化，客户要项目要最后才能看到成果等。

敏捷需要怎么做：
敏捷当时拿到手的时候我是懵逼的，为啥懵，因为觉得难而且麻烦。直到，看完《大教堂与集市》Eric S. Raymond 的作品，开源运动的圣经。

为啥和开源扯上关系了呢！因为他的开源思想和敏捷根本就是一回事，你看。

• 1、尽量小的开发任务。  -- 快速开发
• 2、在可运行的情况下能发布就发布。 --快速交付
• 3、尽快的收集用户的反馈，并修改。  --快速反馈
  

然后，敏捷宣言中的几点

个体和交互 重于 过程和工具。    在开源中，往往都是邮件来邮件去，基本上是没有流程的，也没有要求什么工具。

可运行的软件 重于 详尽的文档。  开源项目中，我极少能看到文档。及时有也是事后整理的api说明。设计和需求文档基本上是没有的。大家都是先去看你的软件好不好之后再去找你的文档。注意：并不是没有文档，只是文档的地位没有那么高，在有时间整理的情况下，开源也是会去整理文档。实际上这里我的理解是这样的：可运行的软件优于事前规划的文档。事后的说明性文档和设计文档都是一些必须的东西，不然根本没办法交接，过去的代码往往会变成雷坑。

客户合作 重于 合同谈判。    开源有所谓的合同说法么，工作还不是一样的做。和客户闹的不开心也是影响自己的项目，大家都不好。合同上的东西往往会变成项目的底线，而不是标准。

响应变化 重于 遵循计划。   经常性看到开源的东西，今天做这个，明天就砍掉了。这是啥，你说开源没有计划么，并不是，而是会根据实际情况去调整计划。不要的就不要了，优势就继续发挥深度挖掘。


最后使用心得：
敏捷其实最大的好处在于适应变化。需求变化，人员变化，技术变化等等。这些在瀑布式开发中都是无比痛苦的。
其实敏捷还有许多，我都没有放到关键字中比如：测试驱动、持续集成、结对编程、极限编程等等。
因为我觉得这些都和敏捷关系并不大，如果我用需求驱动（领域驱动、用户故事驱动）难道就不能用敏捷了么，我不结对编程就不能敏捷了么。我只有一次集成就不能用敏捷了吗？一个迭代的敏捷和瀑布式开发也是有根本上的不一样。

只是，用了这些东西之后，敏捷起来会更舒服，实际上这些东西对任何方式都有很大的帮助。
最后，敏捷除了适应变化之外，还有一个非常重要的一点，那就是持续改进。做任何事都要持续改进！切记切记。

误区解释：
敏捷可以节省工作量：其实如果需求没有任何变动，敏捷其实比瀑布式开发要多花费很多工作量。什么都是明确的开发起来根本不用犹豫一路到底的感觉当然会快很多。而且即使需求存在变化，敏捷也需要花费很多时间去沟通，调整变化。所以想使用敏捷来节省工作量是不靠谱的。

高质量：
敏捷根本无法保证高质量，敏捷没有任何一个思想可以解决代码质量问题，高质量的代码还是要看管理。使用测试驱动，结对编程才是提高代码质量的方式。

文档可以省略：
少文档，不代表没有文档。以需求驱动举例，在每次迭代之前就需要确定明确的需求。迭代之中出现变化要及时体现在需求文档中。决不能以口头形式去表达需求。以测试驱动而言，测试案例也是要比代码先出来的，写完代码相应的测试代码也要出来。再多的注释和极度良好的命名也没办法取代文档。

敏捷工具好用：
这个我无法评判，多长时间之后或许有更好的呢，不能迷信是吧！现在我就知道CMMI也是一种非常不错的管理方式啊。敏捷能不能用好都是一个问题呢！

敏捷很简单：
很多人看了几句话就去用敏捷，结果自己累死不说还带着项目进入泥沼。《Scrum实战——敏捷软件项目管理与开发》中就有很多例子可以说明。如果只是简单的把项目分成几个阶段，然后加上晨会啊，周报啊，必须在某时间提交什么东西啊！根本不是敏捷。敏捷能否用好，好不好用还是的看人，看项目，看公司。

最后总结，请谨记：
敏捷的核心是 沟通和响应变化以及阶段性战果。