随着敏捷开发越来越流行，人人都在谈敏捷，人人也都在学习scrum等敏捷开发方法。。。当然，自己也是敏捷开发的实施者和受益者。



背景

我们公司引入敏捷开发的时间并不长，在实施敏捷的过程还存在一些问题，自己在实施敏捷的过程也存在很多的疑惑（毕竟原来没有学过，和真实的经历，体会），所以最近一直在学习敏捷，看敏捷的视频和阅读相关资料，同时结合自己实施敏捷的经验，通过分享博文进行一下简单的总结，目的有四： 

1. 详细的介绍和学习一下敏捷开发 

2. 和CSDN的大牛们一起分享交流，学习，提高一下 

3. 总结实施敏捷过程中的问题，不断反思，不断提高 

4. 最后，希望对不了敏捷的朋友有一定的帮助



什么是敏捷开发


  
敏捷开发（Agile Development）不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。




怎么理解呢？

首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。
其次，敏捷开发都具有以下共同的特征：

迭代式开发
增量交付
开发团队和用户反馈推动产品开发
持续集成
开发团队自我管理
最后，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。
具体方式

上面说了敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而具体的开发方式有哪些呢？

Scrum，极限编程（XP），精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。

除了Scrum和XP，对于上面的其他开发方式，我也只是简单了解，大家可以多查查相关的资料。

我们可以简单的对比一下Scrum和XP： 

1. 在开发的过程中，你可以采用Scrum方式也可以采用XP方式； 

2. Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。



敏捷开发宣言


  
《敏捷宣言》
  
  
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
  
  
个体与交互 重于 过程和工具 
可用的软件 重于 完备的文档 
客户协作    重于 合同谈判 
响应变化   重于 遵循计划
  
  
在每对比对中，后者并非全无价值，但我们更看重前者


敏捷宣言是对敏捷的高度总结和升华，即使现在不理解也没有问题，在实践的过程中我们会逐渐对它有一个深刻的认识。



敏捷开发十二原则


  
在敏捷开发中，我们遵循以下准则：
  
  
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
  
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
  
要不断交付可用的软件，周期从几周到几个月不等，且越短越好
  
项目过程中，业务人员与开发人员必须在一起工作。
  
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
  
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
  
可用的软件是衡量进度的主要指标。
  
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
  
对技术的精益求精以及对设计的不断完善将提升敏捷性。
  
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
  
最佳的架构、需求和设计出自于自组织的团队。
  
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
  

敏捷开发宣言比较抽象，但是敏捷开发十二原则就非常具体了，相信用过敏捷的人都知道，上面的十二原则都是开发过程的经验总结。看到十二条原则，一一的对比我们公司在实施敏捷的过程，还存在一些问题，这些问题直接导致了低效率的，不顺畅的敏捷，例如：最后一条，团队要定期反省，这点做的就不好，造成团队的积极性降低，开发效率下降，而且很难作出调整，甚至我开始也是拒绝的，有了这些原则作为指导，我们可以更加从容的实施敏捷。

敏捷开发十二原则是我们实践的具体指导方针，它可以指导我们实施更加成功的敏捷。当我看到这些内容时，真有一种如饥似渴的感觉，真想一下子都把他们装进我的脑子里。书到用时，方恨少。及时补充自己永远都不晚。

总结

敏捷的思想今天算是深入人心了，后面的具体方法就是教会我们如何实施敏捷。有了这些思想，整个世界都开始美好了。

下篇博文，进入我们的重点简单介绍Scrum以及Scrum的流程，敬请关注。

一、什么是敏捷开发

敏捷开发（Agile Development）不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。

怎么理解呢？首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。其次，敏捷开发都具有以下共同的特征： 

 - 迭代式开发  

 - 增量交付 

 - 开发团队和用户反馈推动产品开发 

 - 持续集成 

 - 开发团队自我管理



二、具体方式

上面说了敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而具体的开发方式有哪些呢？

Scrum，极限编程（XP），精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。这些方法还需要结合业务选择并实践，目前还没有深入学习~

三、敏捷开发宣言和准则

《敏捷宣言》

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：

个体与交互 重于 过程和工具  
可用的软件 重于 完备的文档 
客户协作 重于 合同谈判 
响应变化 重于 遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者 

敏捷宣言是对敏捷的高度总结和升华，即使现在不理解也没有问题，在实践的过程中我们会逐渐对它有一个深刻的认识。

敏捷开发十二原则

在敏捷开发中，我们遵循以下准则：

我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。 
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。 
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

原文
随着敏捷开发越来越流行，人人都在谈敏捷，人人也都在学习scrum等敏捷开发方法。。。当然，自己也是敏捷开发的实施者和受益者。



背景


我们公司引入敏捷开发的时间并不长，在实施敏捷的过程还存在一些问题，自己在实施敏捷的过程也存在很多的疑惑（毕竟原来没有学过，和真实的经历，体会），所以最近一直在学习敏捷，看敏捷的视频和阅读相关资料，同时结合自己实施敏捷的经验，通过分享博文进行一下简单的总结，目的有四： 

1. 详细的介绍和学习一下敏捷开发 

2. 和CSDN的大牛们一起分享交流，学习，提高一下 

3. 总结实施敏捷过程中的问题，不断反思，不断提高 

4. 最后，希望对不了敏捷的朋友有一定的帮助

什么是敏捷开发


敏捷开发（Agile Development）不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。


怎么理解呢？


首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。


其次，敏捷开发都具有以下共同的特征：
迭代式开发
增量交付
开发团队和用户反馈推动产品开发
持续集成
开发团队自我管理


最后，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。


具体方式

上面说了敏捷是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而具体的开发方式有哪些呢？

Scrum，极限编程（XP），精益软件开发（Lean
 Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。

除了Scrum和XP，对于上面的其他开发方式，我也只是简单了解，大家可以多查查相关的资料。
我们可以简单的对比一下Scrum和XP： 
1. 在开发的过程中，你可以采用Scrum方式也可以采用XP方式； 
2. Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。

敏捷开发宣言


《敏捷宣言》

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：

个体与交互 重于 过程和工具 
可用的软件 重于 完备的文档 
客户协作 重于 合同谈判 
响应变化 重于 遵循计划

在每对比对中，后者并非全无价值，但我们更看重前者

敏捷宣言是对敏捷的高度总结和升华，即使现在不理解也没有问题，在实践的过程中我们会逐渐对它有一个深刻的认识。


敏捷开发十二原则


在敏捷开发中，我们遵循以下准则：
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。


敏捷开发宣言比较抽象，但是敏捷开发十二原则就非常具体了，相信用过敏捷的人都知道，上面的十二原则都是开发过程的经验总结。看到十二条原则，一一的对比我们公司在实施敏捷的过程，还存在一些问题，这些问题直接导致了低效率的，不顺畅的敏捷，例如：最后一条，团队要定期反省，这点做的就不好，造成团队的积极性降低，开发效率下降，而且很难作出调整，甚至我开始也是拒绝的，有了这些原则作为指导，我们可以更加从容的实施敏捷。

敏捷开发十二原则是我们实践的具体指导方针，它可以指导我们实施更加成功的敏捷。当我看到这些内容时，真有一种如饥似渴的感觉，真想一下子都把他们装进我的脑子里。书到用时，方恨少。及时补充自己永远都不晚。

总结

敏捷的思想今天算是深入人心了，后面的具体方法就是教会我们如何实施敏捷。有了这些思想，整个世界都开始美好了。

下篇博文，进入我们的重点简单介绍Scrum以及Scrum的流程，敬请关注。

高度协作，不断使用反馈进行自我调整和完善。 

态度决定一切，学无止境。 

对事不对人，讨论的永远是问题本身，以及解决问题的方法。 

出了问题的第一件事应该是解决问题，额，或者说，查找问题发生的根源，然后再解决问题。 

What can I do for you?

永远不能满足于解决问题，在不理解代码的情况下修改代码，对系统来说是一件很恐怖的事情。在完善的同时优化，而不是增加软件的腐化程度。所以，不用坠入快速的简单修复之中，要投入时间和精力保持代码的整洁和敞亮。 

这样很蠢，没有考虑读写加锁。 or 在写的时候读，会发生什么？ 
你不需要很出色才能起步，但是你需要起步才能变得出色。 

能容纳自己并不接受的想法，表明你的头脑足够有学识。 

勇气是做事的一项基础。

即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。 

唯有变化是永恒的。 

每天计划用一段时间来学习新的即使。 

了解行业的动向，规划你的项目和职业生涯。 
总是要成为你所在乐队最差的乐手，当成为乐队中最好的乐手是，你需要重新选择乐队。 

持续，小步前进才是敏捷的。 

丢弃阻止你前进的坏习惯。 

第五项修炼：在理解一个问题时，需要渐次问5个以上为什么. 

追求问题的根源。 

把握项目的节奏。 

在有单元测试的情况下，可以下班前提交代码。 

保持事件之间稳定重复的间隔，更容易解决常见的重复任务。 

记录客户做出的决定，并标注原因。好记性不如烂笔头。 

根据需要选择技术，为具体问题评估使用技术。多挑剔，用原型来说明问题。 

不用开发容易下载的东西，从基础开发很吸引人，也很危险。 

迭代之间可以存在间隙。 

确保测试是可以重复的。 

测试驱动开发。 

估算剩余时间，而不是仅仅填写百分比。评估需要完成的待办事项。 

每一个抱怨隐藏了一个事实，找出真相，修复问题。 

代码要清晰，甚至可以牺牲部分效率，但是可以避免问题。 

设计尽量简单，并且明显没有缺陷。（代码的阅读次数，远远多于编写的次数） 

像重构代码一样重构测试 

增强代码的内聚性。 

让被调用对象来根据自己的状态确定如何处理，不要替它做出决策。 

告知而不要询问。 

派生类必须可以替换掉基类，用户可以像调用基类一样调用派生类。