在几年前，我就对软件的敏捷开发有着很高的兴趣的。一直觉得，程序员应该是最自由，最轻松的一种职业！而且我也一直在向这个方向努力！
我们应该如何做呢？一说到程序员，大家就公认的是脑力民工！为什么？在程序员自己报怨开发环境不好，工作量大，任务重，压力大的同时，有没有想过，有些问题其实是程序员自己的原因造成的呢？

我们来看一个流程的例子：
从一个问题单开始，你要解决这个问题，首先得申请问题单的查看权限，花5分钟填写一个权限申请电子流，然后等1到2个小时生效。当然，如果你一次申请一个长久有的效的权限，第二次在解决问题单时就不须要了。
然后阅读问题单，重现问题，如果有不清楚的，可能还会咨询测试人员。假设你在1个小时以内了解清楚了问题。
然后准备修改问题，得先申请代码权限。填写电子流也就几分钟，然后等待审批，可能得1到2上小时。如果幸运的话，是这样的。
然后是代码的Checkin与Checkout，以及修改！
然后是编译，验证。最后出版本！

OK，这是一个比较简单的流程，我们看看，其实有很多因素可能导致我们的开发流程是效率很低的。例如，在权限申请的等待过程！问题确认过程！电脑文件打开等待过程！网络打开等待过程！等，一些不产生value的过程，都是精益开发中应该减少的。
我们并不能指望效率会有多高（丰田的效率也只有40%左右，效率就是把一个流程中，产生value的时间除以整个流程的总时间），但在精益开发中，就是要在各个环节中找到影响效率的点，然后尽力的去减少它！
例如，上面的例子中，当开发人员要确认问题时，应该直接找到测试人员，面对面的把问题搞清楚。而不是在邮件，或者电话中询问题！再如，给开发人员配置更快的电脑，以减少打开文件的等待时间。当然，开发人员也应该自己优化自己的开发电脑。公司优化网络等。
当然，在整个流程中，要分清楚哪些工作是有效的，哪些是没有效的，并不是件容易的事！一些非常明显的事，如前面提到的等待，就不用说了。
对于以下一些事件，哪些是有效的，哪些是无效的呢？
需求分析
需求设计
编写设计文档
测试设计
编写测试文档
编码
测试
修改BUG
技能提升
呵呵，感觉全部是有效的工作！其实不是！
从用户角度来看，只有编码一修改Bug是有效的，其它的一律无效！
当然，这是从用户角度来看。从我们开发人员来看，上面的也并不是全部有效的！
例如：设计文档，测试
而技能提升是有效的。
这里不去细致的讨论哪些有效哪些无效，只要记住精益的思想：
尽量发现开发流程中的无效工作，并尽量减少它！
当然，精益开发也给我们提供了一些简单的方法来判定有效工作与无效工作！
这就是精益开发的第一条原则！而后面的所有原则就都是由它产生的！

另一个就是敏捷开发！敏捷的第一条原则就是满足客户需求！
第二原则就是适应变化！
第一原则我觉得不用讲，没客户你就无法生存！
而第二原则，则相比之下会更重要！为什么，因为只有适应变化，才能不断满足客户需求！而且变化是非常快的，如果软件开发不能适应变化，客户的满意度也会下降。因此，我觉得，软件开发能适应变化，快速反应用户需求与变更，是敏捷开发的核心！
如何做到这些呢！
首先就是敏捷开发流程！它使用是迭代开发！
有人不明白，为什么要用迭代开发。如果在已知用户需求不会发生变化的时候，我们还要用迭代吗，为什么不一次就把事情做好，交附给用户！
说到这一点，不得不提到精益开发里的一条：一个软件真正有用的特性往往不足50%，而且经常使用的也只有20%左右。如果你觉得用户的需求不会变化，然后一次给用户把所有特性全部完成的话，你就会陷入到这个2－8理论中！
敏捷的思想是怎样的呢？我们喜欢变化，我们要适应变化，还要引导用户变化！
例如：在你收到用户的10个特性时，经过分析，可能会发现有4个特性可以不要，或者可以用前面的特性取代！但这是用户的特性，用户就是上帝，你又不好直接回复用户，说这个特性可以不要，只要用前面的特性1，稍微改一下用法就可以实现！
用户可不吃你这一套！但如果我们先把一些基础特性在前面的迭代中先完成，然后以体验版的形式给用户。一方面验证一些特性，另一方面，也可以引导客户，对后面的特性进行变化！
这时，用户很有可能对前面的一些特性有新的看法，会要求修改已经实现了的特性。然后对还没有实现的特性可能会不太关心，或者，用户在自己使用的时候，就已经意识到，后面的特性可以不要了！
这样，一方面我们要增加已经完成的特性，而另一方面就要删除原来的特性需求，或者更改需求！这是好事还是不好呢？就不说了吧！
如果我们在一开始就想着是这样的发展过程的话，那是太好不过了！当然，如果你觉得用户善变，那我也就无语了！那就还是走2－8理论吧！
敏捷的核心，就是变化，适应变化！而在软件的开发中，对代码的变化是非常讲究的，也有很多方法和工具。敏捷的迭代是从流程上来管理的，还有其它很多就不多说了。
今天也就是从培训中学习和了解一点，然后结合自己的想法写了一点！