鲁达 最近在学习敏捷方面的知识，于是就把自己的所学心得，整理成了文字和视频，来和大家一起分享。
今天这篇文章，继续给大家分享一下敏捷开发的概念，作为我们一起探讨的内容。希望大家留言、评论，我们一起学习。
一 敏捷的误解
大家是怎么理解敏捷呢？
1 只要负责开发软件就够了，再也不用做文档，也不用做设计了
2 用了敏捷后，周期就可以缩短
3 就是加班，用了敏捷后，由于在迭代结束时一定要完成当初的目标，所以我们加班比原来更严重了
4 自由的、无约束的，不需要那么多条条框框，随自己的心情来做就好了
这是以上四点我在和大多数人接触时，他们对于敏捷的理解，这些理解看似正确，实则是片面的，是对敏捷有误解的。
那么为什么会产生误解呢？归根结底，是忘记了做敏捷的初心，忘记了它的价值观和基本原则，而只是把注意力集中在怎么做上
所以你要想真正理解敏捷，就要从它的价值观、原则以及具体的方法和实践上，对它有一个全方位的认识，只从任何单一的方面去了解它，都像是盲人摸象，是片面的。
二 敏捷的价值观
1 个体和交互胜过过程和工具
2 可以工作的软件胜过面面俱到的文档
3 客户合作胜过合同谈判
4 响应变化胜过遵循计划
5 虽然右项有价值，但我们更重视左项
虽然右项有价值，但我们更重视左项。”这一条其实是对前 4 条的解释说明，然而很多人在传递这些价值观时，其实只讲了前面 4 句，而忽略了最后这一句，很大程度上，这导致了大家对敏捷的误解。那么结合这一条来看，前 4 条中“胜过”这两个字就可以解释为，与每一条中右面的内容相比，左面的内容是敏捷更加重视的，但要注意，这并不是说让你停止做右面的内容。
举个例子来说下：
第二条：虽然右项有价值，但我们更重视左项。”这一条其实是对前 4 条的解释说明，然而很多人在传递这些价值观时，其实只讲了前面 4 句，而忽略了最后这一句，很大程度上，这导致了大家对敏捷的误解。那么结合这一条来看，前 4 条中“胜过”这两个字就可以解释为，与每一条中右面的内容相比，左面的内容是敏捷更加重视的，但要注意，这并不是说让你停止做右面的内容。
那么对于一个项目来说，什么样的文档是没有必要的文档呢？比如说一些交接类的文档。开发人员在开发完成后要提交给测试部门测试，需要写一个提测单，再一级一级批复，我认为这样的文档就是可以省略的。因为在敏捷里，开发人员和测试人员是在一起工作的，所以提测的工作不需要走如此麻烦的申请和审批；开发人员需要提测时，直接在软件上点击一下“提交”，再告诉测试人员一下就足够了。
那么，什么又是有必要的文档呢？比如说一些写着重要设计方案的文件。如果系统在后期遇到了问题，你就要回头查看这类文件，找出问题所在；或者是系统后期开发完成后，需要转交给其他同事维护时，他们若想知道这个系统当初是怎么做的，也需要去查看当时的系统设计文档，所以这类设计方案是需要保留下来的。你可以根据自己的项目情况，考虑哪些是重要的文档，哪些是不重要的。
所以说，敏捷的价值观并未否定或贬损“右项” 的价值，“流程和工具”、“ 详尽的文档”、“ 合同谈判” 以及“ 遵循计划” 这些右面的内容也很重要，在敏捷里并不是完全不做。比如在敏捷实践中也是有计划的，只不过它计划的方式与传统瀑布模式的计划方式不一样罢了。
三 敏捷开发的原则
1 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7 工作的软件是首要的进度度量标准。
8 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9 不断地关注优秀的技能和好的设计会增强敏捷能力。
10 最好的构架、需求和设计出自于自组织的团队。
11 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
我们来举例看下其中的两个基本原则。
第二条：敏捷就是快
敏捷里的快，并不是代码编写速度快，即使代码速度变快了，那么整体项目就会加快吗？显然不是的。这里的快是指的，敏捷希望能尽快把可用的软件持续性地交付给客户，交付的时间越短越好，而不是最后才一次性交给客户。指的是反馈更快，反馈更及时，这样，我们就能更快、更准地得到客户的真实反馈，也能尽早修正。在这个过程中，客户也可能会更早一点想清楚自己要什么样的产品，你也可能更早达成客户的目标（这里你也要注意，是有“可能”，而不是“一定”）。甚至，由于客户比预计的时间早些看到了产品，他觉得很满意，结果可能比大家预想的上线时间都要早。
但这绝不是通过快速写代码来完成的，而是通过不断检视客户的需求，总是优先做最有价值的事和减少浪费来完成的。在瀑布模式下的项目管理过程中，我们把原计划的事情全都做完后，项目也就结束了；而在敏捷的原则下，只有完成客户的目标，项目才可以结束。这是因为，敏捷是以业务价值和业务目标为导向的，在这个导向下，短迭代使客户更清楚自己的需求了，不必要做的事情减少了，所以时间才减少了，交付也就更快了。
第二条：敏捷就是加班，疯狂加班
敏捷强调“可持续的开发速度”，指的是团队要能一直以稳定的开发速度持续下去，而不是为了加速开发，本次或几次迭代一直加班，透支团队成员的健康，这么做反而会因为员工身体不支，导致接下来的迭代开发产能下降。你要想一想，如果天天加班，员工能否能一直保持高昂的斗志和较高的工作效率？你能保证一直可以用这样的开发速度开发下去吗？我想这是不行的。
怎么才能保持“可持续的开发速度”呢？
1 他们在迭代开始的时候，不会过度承诺，也就是能完成多少工作，就承诺多少工作。
2 严格遵守纪律。他们在迭代开始以后，原则上不会再增加需求，如果一定要往他们的迭代待办事项列表里增加其它需求，就要同时从中拿走等量的需求。
这么做有什么好处呢？我认为这可以使开发团队聚焦在自己的事情上，不受干扰，效率更高，这样就能形成稳定的开发节奏；而稳定的开发节奏可以加强我们的预见性，这样我们预计的上线时间才可能是精准的。
四 总结
敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。单纯说敏捷是一种方法，肯定是片面的；但只强调它的价值观和原则，而不重视方法也是不对的，因为那样敏捷就飘在空中，不能落地了。
好了，这篇文章就给大家写到这里了，希望大家留言、评论。我们一起探讨，学习。大家喜欢的，可以点个关注 ，我会不定期更新文章，将自己的经验分享出来。
三人行，必有我师。传递知识，分享经验，从你我做起。