敏捷的12条原则

    没有什么方法可以保证团队一定能开发出完美的软件，敏捷的团队也是同样地，所以，有一系列的原则来帮助敏捷团队。

1. 最优先要做的是尽早、持续地交付有价值的软件，让客户满意。
2. 欣然面对需求变化，即使在开发后期。敏捷过程利用变化为客户维持竞争的优势。
3. 频繁地交付可工作的软件，从数周到数月，交付周期越短越好。
4. 在团队内外，面对面交谈是最有效，也是最高效的沟通方式。
5. 在整个项目过程中，业务人员必须和开发人员每天都在一起工作。
6. 以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好。
7. 可工作的软件是衡量进度的首要标准。
8. 敏捷过程倡导可持续开发。
9. 坚持不懈的追求技术卓越和良好的设计，以此增强敏捷的能力。
10. 简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。
11. 最好的架构、需求和设计来自自组织的团队。
12. 团队定期反思如何提升效率，并依此调整自己的行为。

客户总是对的吗

    一个好的开发团队要交付给客户真正需要的东西，而不是提供给他们要的东西。亨利.福特曾经说过一句话“如果我问人们想要什么，他们肯定会说想要更快地马（而不是汽车）”。这个事情说明客户无法在一开始就告诉你他想要的是一辆汽车而不是一匹更快地马。敏捷所说的12条原则的初衷就是让团队构建用户真正需要的产品，有价值的软件。但是每个人都会看到软件中不同的价值，那么就要求每个人都想想其他利益相关人，想他们各自关心的事情，想想软件会给他们带来的价值。任何新产品在第一次面市的时候都是功能不全面的，尤其市面上没有同类产品的时候，随着时间以及版本的更替，产品会解决越来越多的问题，以及会变的越来越好用，我们现在去看当初的产品肯定很容易就看出来其中的问题，但是在项目刚刚开始的时候是很难思考全面的。

    按我现在说的做，而不是按我之前说的做

    很多公司，包括我现在所处的公司也是同样，做一个项目或者产品的时候会在一开始组织专门的人员找齐全部利益相关人开会讨论，然后将所有的信息整合到一起形成一份说明书，然后再发送到各利益相关人那里进行评审，然后再开会讨论，再出一份更好的说明书，一次一次的可能要耗费好几天，最终形成一份各方面都满意的说明书。拿给开发团队评估工期，综合各方面可能要12个月之久，但是各利益人都觉得很不错，因为一年之后就可以拿到一个非常棒的产品。经过一年的奋斗，开发团队终于交付了产品，产品与说明书相差无几，准确地展现了各利益人所要的功能。但是结果呢，往往一年的时间市场已经变化，一年前很被市场需要的软件并不被当前的市场所需要。

    市场存在着变数，一些变数在项目初期是可以被发现的，但是更多的变数都是在项目开始的时候无法被发现的。但是说明书已经制定了，而开发团队又不喜欢自己做的东西不停的变化。所以团队要快速地响应市场以及各利益相关人的变化，敏捷的几项原则就是帮助团队应对这种变化的。

原则1：最优先要做的是尽早、持续地交付有价值的软件，让客户满意

    敏捷团队最重要的事情就是给客户交付可工作的软件。而这条原则就包含三点，尽早发布软件、持续交付价值以及让客户满意。

    没有什么事情的完美的。尽管在项目一开始每个人都想一次性的提出全部的需求，但是问题在于客户在真正拿到可工作的软件之前，都不清楚应该提什么样的需求。所以就要求开发团队尽早的交付，尽早的给客户一个可工作的软件，即便是仅交付了一个可工作的特性，也是一种突破。这对整个团队都是有益的，因为客户可以给出有价值的反馈，这样开发团队才能朝着正确地方向推进项目。

    尽早交付也有一个缺点，就是最初交付给客户的软件完成度非常的低。很多客户很难忍受一个仅有部分功能，还有可能存在大量BUG的软件，这些客户往往认为既然交付就要交付完整地产品。敏捷的核心价值观里有一句，客户协作高于合同谈判。这就要去客户也要能够和开发团队一起成长，一起协作，共同逐步完善产品。如果客户非常官僚，那么团队就必须全新的变更管理流程，这要去与客户重新进行一轮合同谈判。真正与客户协作的团队可以在开发过程中任意进行任何有必要地改变，这也是持续交付的意义所在。而团队确定哪些特性能交付价值的唯一方法就是与客户协作，并利用前一次迭代收到的反馈。从短期看，团队可以通过尽早交付价值让客户满意，从长期看，交付最终产品的时候可以使得价值最大化。

原则2：欣然面对需求变化，即使是在开发后期。敏捷过程利用变化为客户维持竞争优势

    我以前的工作是数据安全，公司比较小，是给别人做项目的，而做项目的弊端就是会面临着大量的变化，尤其是老板不会顾及工作量，也不会改变截止时间，当这个样子有大量的变化时，开发人员就一定会有情绪，从而形成恶性循环。

    为什么会使得开发人员抱怨不止，因为在需求变更之前，开发人员会认为项目进展的很好，而且可能做了很多决策：如何规划产品结构，要开发什么产品，向客户承诺交付什么。结果一个项目外的人突然告诉你这个计划里有错误，而且是你的锅。给开发人员说它错了，是很难接收的。尤其说的人还享受着他的服务，就好比，你做了一盘菜给别人吃，那个人一边津津乐道的吃，还一边骂你做的菜难吃如屎。开发人员对自己所做的工作都是有一种自豪感的：我们交付的产品我们能负责，而且能满足用户的需求。而变化就是在质疑这种自豪感。瞬间就会感觉自己的努力没有得到尊重。

    而开发人员如何才能够接收变化。简单地说就是站在客户的角度去看待问题。其实客户也不愿意给开发人员提出变化，因为这就是要求他们承认自己在一开始犯了错误，让开发人员白做了很多事情。正因如此，往往客户都是很晚才来告诉开发人员变化，因为他们知道自己带来的是坏消息，这是让人很难堪的行为，客户还要为整个变化买单。所以，将心比心，开发和客户都要做一些不可能的事情，开发人员被要求读懂客户的心，客户被要求能预测未来。

    要做到能够欣然接收变化，就要意识到以下几点：

• 不要认为有变化就要有人要倒霉。每个人都要求知道犯错了以后就立即改正而不是期待一开始就做到完美。
• 我们是一条绳上的蚂蚱。每个人包括客户都要对全部需求以及变化负责，争论谁对谁错是没有意义的，抱怨变化是没有意义的。
• 我们不把变化拖到最后。谁都不愿意犯错误，但是这是难免的，那么就要尽早修复，将损失降到最低。
• 我们不要再把变化当做犯错。在当时的信息环境下，能做到那个程度已经很好了，出了错事才会让路变得更加明朗。
• 我们通过变化学到东西。变化才是团队成长最有效的方式。

原则3：频繁交付可工作的软件，从数周到数月，交付周期越短越好

    对于敏捷实践者来说，传统的实践方法被称作“命令-控制”。这种方式与军事的命令-控制的方式是一致的。“命令”指的是项目经理给团队分配任务的方式。尽管并不是所有成员都向项目经理汇报，但是项目经理仍然可以控制所有人的任务分配。“控制”指的是项目经理管理变化的方式。无论是项目内的变化还是员工休假、机器故障，亦或是其他一些无关的变化，都在项目经理的监控之内。当变化时对其进行评估，更新项目计划，在进度安排和文档中引入变化带来的改变，给团队分配新的任务，管理利益干系人的期待，不要让人感到意外。使用敏捷的传统项目负责人不愿意欣然接受变化的原因就是害怕变化引起的混乱。

    那么，如何才能又能欣然的接受变化，又能不引入混乱？关键在于频繁发布可工作的软件。团队将迭代的周期缩短，在每一轮迭代结束的时候，都可以交付一个可以使用或者演示的软件，然后计划下一个迭代要干什么，这样一个可预测的进度安排和持续检查可以帮助团队尽早掌握变化，同时也创建了一个没有责备的氛围。传统项目经理最大的困难就是监视变化，每日审查和迭代回顾相当于让整个团队帮助项目经理尽早的发现变化，避免将变化放在项目的晚期，从而防止这些变化对项目造成更严重的影响。

    传统的瀑布式流程一旦定义好需求就把开发团队和客户完全隔离开，而敏捷团队采取的则完全不同，后者始终与客户交互。这样就可以及时响应变化，开发出更好地产品。但是每当发现项目确实需要修改的时候，都有一半人返回去更新规格说明书，以保证计划保持最新的状态。越来越多的人觉得文档太多，但是每当想砍掉一些内容的时候，就会有人说如果不写某项功能、需求、设计或测试用例，那么就会有人产生误解。如果最终的实现不正确，他们就会因此遭到谴责。于是，文档中的任何一部分看上去都是必要地，因为少了任何一部分团队都有可能开发出错误的软件。

    自古以来，各个团队都对文档写多少而感到困惑，一直都在努力找到一种平衡。那么对于敏捷团队来说，文档写的够项目开发用就可以了，具体要参看团队要解决的问题以及沟通的情况。一个原则就是如果某种文档不能给团队开发软件带来帮助，而且也没有必须写的原因，那么敏捷团队就不写这种文档。例如监管的要求、投资者的要求、高级经理的要求或者其他利益干系人的要求。不过在传统瀑布式项目中，完整文档的全部意义就在于更好地应对变化，但是遗憾的是对于大部分团队来说，完整地文档往往给管理变化带来阻碍。团队在项目开始的时候要花大量的时间努力预测未来会发生什么，并完整地记录下来。项目执行的时候，他们需要不停地维护已经写好的文档，并记录所有新开发的内容。如果对于正在开发的产品有了新的理解，他们还需要返回去修订所有受影响的文档。随着时间的推移，过时的文档就会越来越多，团队需要花很大的功夫去维护这些过时的文档。况且各个人去编写的时候又会把视角割裂引进去。

原则4：在团队内外，面对面交谈是最有效、也是最高效的沟通方式。

    我们为什么要写文档，并不是因为要写出来一份东西，而是要把我的想法告诉你，使得我脑子里地想法和你脑子里地想法仅可能的接近。为什么面对面的交谈是最有效的，而且大于文档。因为我们都知道，一份完整地文档是很难实现的，而且是非常耗时的，到最后完成的文档又不一定在项目中有用。然而面对面去交谈，就很容易形成头脑的风暴，很容易让大家的思想达到统一，这正是交谈的良好方式，一有什么变化就可以立即进行讨论。

    团队沟通的终极目标是形成一种集体意识，在成员之间建立不必直说也能领悟的共同知识。一个团队能够形成集体意识，越能共享同样地视角，就越容易对同样地问题形成一致的答案。这酒为团队构筑了处理变化的坚实基础，可以跳过冲突，立即编写代码，而且不会因为维护文档而分心。

原则5：在整个项目中，业务人员和开发人员必须每天在一起工作。

    为了完成出色的软件，开发团队需要与业务人员进行大量面对面的讨论，业务人员了解需要什么软件，因为他们在没有软件的情况下开展了同样地工作，有了业务人员的陪伴，研发人员可以及时更改自己的开发方向，但是业务人员往往希望开上一两次会就解决剩下的问题，因为他们同样也有自己的工作。

    如何解决这个问题，首先双方要都认识到，团队要给公司开发带来价值的软件。完成后的软件应该值得公司的投入。如果软件带来的价值超过了开发软件的成本，那么公司就值得在这项开发上面投入资金。一个好的项目应该有足够的价值让业务人员赶到值得投入精力。所以业务人员应该与开发人员坐在一起工作，尽早的处理变化，因为后期修改的成本会很高。而业务人员应该很喜欢跟敏捷的团队一起合作，因为传统的开发团队把业务人员看做谈判的客户，而敏捷团队则是与客户合作的，在项目进行过程中客户具有平等的发言权。

原则6：以受激励的个体为核心构建项目，为他们提供环境和支持，相信他们可以把工作做好。

    如果团队里地每一个人都认为自己开发的软件是很有价值的，是能够给公司带来利益的，那么这个团队就会越来越好。相反，如果团队成员看不到软件的价值，或者他们没有因为开发优秀软件而得到奖励，那么在这种情况下，项目就会失败，因为项目中最重要的是人。现在大多数公司的考核与绩效往往不利于员工开展高效的敏捷方法。

    大多数公司的问题为：
1、在代码审查中，如果不断发现bug，那么这个程序员就会得到糟糕的评价，如果没有发现bug，那么这个程序员就会得到奖励。（这会导致程序员在代码审查中不愿意去寻找bug。）

2、根据发现bug的数量去奖励测试人员。（这会导致测试人员挑刺并且奖励报告的质量。这种方式还会使得程序员和测试人员之间产生敌对情绪，会阻碍程序员和测试员之间的合作。）

3、根据业务分析员产出的文档量去判定其绩效评级（而不是根据他们与团队分享的知识量评评级）

所以以这种绩效去考核程序员，最终出来的内容肯定不会好，一个很好的团队应该根据成员对团队的贡献去进行考核，鼓励贡献多的人员。比如认识到软件并没有解决的某个业务问题并将其修复的程序员，以及能够发现代码或架构中的问题并提交给团队的测试人员。

    不好的氛围容易引发一种一心自保（Cover Your Ass，CYA）的态度，在这种态度下，测试人员会努力确保每一项需求都有测试覆盖，而不去考虑测试到底能不能对软件的质量有所帮助。程序员会严格遵循需求文档中的每一个字，而不去认真想一想自己开发的功能是不是真正给用户带来价值。在这样的公司经理自然想找一个“始作俑者”为那些因变化而产生的额外工作量而负责。当这种趋势不可避免的时候，团队里的成员会逐渐转向编写“防御性文档”以保护自己。为了避免糟糕的考核或惩罚，他们可以把责任撇向他们所遵循的那部分文档。

    过于详尽的文档会增加需求含糊以及团队成员之间误解和沟通的风险。敏捷团队最有效的沟通方式就是面对面的沟通，并且输出最少的文档，让开发人员和业务人员每天工作在一起，尽快的交付最大价值的产品，并且在团队中每一位成员都会有项目的责任感，因为他们都要对项目负责，并且他们都可以为项目做出正确地决定。

原则7：可工作的软件是衡量进的的首要标准

    好的团队合作会确保所有人在任何时刻都了解项目的进展。

    在传统的“命令-控制”项目经理眼中，要想掌控项目的进展就要让成员经常更新项目的状态。但是状态汇报是很难获得项目的真正状态。汇报本身就不是一种完美的沟通工具，而且还带有很浓重的政治色彩，而且所有的项目经理到知道有时候需要在状态汇报中略去一些会让经理和团队主管难堪的东西，而别人常常需要用这些信息进行决策。

    所以，最好的汇报方式就是一个可工作的软件，只要真切的看到了软件在眼前工作，那么你就“得到了”项目的进展。当看到软件中缺少或者不满意的部分，相关人员就会主动去沟通下一步的计划了。敏捷团队在每一轮迭代结束的时候交付可工作的软件，通过真实地产品向大家展示具体成果，团队可以让大家掌握项目进展的最新情况，而且这种方式几乎不可能让人产生误解。

原则8：敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够共同、长期维持其步调，稳定向前

    很多团队就会出现一种现象，每当截止日期临近的时候，就会出现拼命的加班，尤其是在晚上和周末。这种做法是不可靠的，一个团队可以拼命工作几个星期干更多地活，但是团队的工作效率一般都会再这段时间过后一落千丈。人们会感到疲劳，而且由于加班而耽误的事情，最终都会找上门来，然后就会付出更多的时间和精力去处理。因此敏捷团队要做的就是可持续的开发节奏。会预留时间，并且制定一个切实可靠的计划，通过迭代。因为每次预估的都是接下来一周、两周的公布工作内容，而且承诺的仅是可以交付的内容，所以就不会动不动的加班，从而形成一种良性循环。

    可持续的开发节奏就是给予团队足够的开发时间，让成员不需要工作到深夜，也不需要周末加班的节奏。

原则9：坚持不懈的追求技术卓越和设计优越，以此增强敏捷的能力

    计划做的太夸张并不是老加班的唯一原因，有的时候看起来是一个很简单地功能，当做起来就觉得有点难度，而随着越做越深入，就觉得这是一个坑。然后发布了以后本来可以轻松的转向其他的事情，但是却要不停的修复这个功能的bug以及打补丁。所以从长久来看设计良好的代码会大量减少后续的维护工作。但是这并不是意味着在软件一开始就进行完整地设计。而一个良好的程序员会再编写的时候不停的寻找设计和代码的问题，一旦发现问题，就会立即进行修复。在项目的开发过程中，只需要在当下多花一点点时间编写可靠的代码并及时修复问题，那么留下来的这份代码库在未来就会非常好的维护。

原则10：简单是尽最大可能减少不必要工作的艺术，是敏捷的根本

    在开发软件的时候，要尽量的简单，解除耦合性，因为如果项目比较复杂，那么在向项目中添加新的代码的时候就会让项目变得越来越复杂，因为有了依赖关系，变化导致系统另一部分发生变化的可能性会提升，后面还有可能导致第三个变化，到最后就会形成多米诺效应。而产出好的代码的方式就是以最少计划启动项目，但是人们往往认为没有良好的计划，那么将来面对变化的时候就会很头疼，因为如果现在就开始编码的花，那么以后遇到变化的话，就有可能删除现在的代码。

   避免这种现象的方法就是迭代式的编程，每轮迭代都开发没有太多依赖或者不必要依赖的代码系统。编码的时候如果团队仅基于一些智能实现单一功能的小型自包含单元进行设计，那么就可以很好地避免多米诺效应。那么哪些单元是很有必要的，就要去业务人员与开发人员经常的进行沟通，确保只开发有价值的特性，因为后期维护一些没有价值的特性往往比这些特性给公司带来的价值要高。

原则11：最好的架构、需求和设计来自自组织的团队

    有大量事前设计的团队非常容易做出过于复杂的设计。因为在设计和架构的阶段就要尽全力就必定意味着要构建可以做到的最棒的架构。如果提出的需求比较少而且设计太简单，那么从直觉上就会给人一种偷工减料的感觉。只有他们拿出一份巨大的需求文档和一个复杂的设计才不会让人质疑。过于复杂的设计又会舍得后期做变化的时候陷入恶性循环。

    那么一个比较好的方式就是组织自组织的团队（self-organizing team），没有明确地需求和设计环节。这个团队会一起对项目进行规划，并且会作为一个团队进行改进计划，没有明确地领导，也就没有很多的干预项，他们会把项目分解成多个部分，从能给公司带来最大价值的部分着手，然后再考虑详细的需求、设计和架构。这样的团队所有人都会对架构进行设计，每个人都有责任，每个人都说的算。这样的团队就很容易循序渐进，从而设计出一个增量式的方案。

原则12：团队定期反思如何提升效率，并依此调整

    一个敏捷团队如果不能持续地改进构建软件的方式，那么团队就不算敏捷。敏捷的团队会不断的对项目进行检查，不断的进行优化，他们会从项目中学习，通过检查的结果对未来进行改造。而且他们并不只是在项目结束的时候这么做，他们会每天都在寻找需要改进的地方。增强团队实力的唯一方式就是经常回顾自己已经做的事情，然后评估作为一个团队这些事情做得怎么样，最后提出改进的计划。要经常回顾过去，看看哪些事情做对了，哪些事情做错了。这需要揪出具体的问题和错误，而很少有人会对公然指出其他的错误而感到自在。随着时间的推移，团队中的成员会对这件事情感到越来越自然。最终，大家会认为这是提意见而不是挑刺。

    很多团队认为他们并没有时间去进行这件事情，他们在一个项目结束了以后就会立即投入下一个项目中，认为与其花时间在这个上面还不如投入到下一个项目中。那么就要求团队在制定计划的时候就给项目结束后预留一些时间来进行回顾，因为这件事情很重要，团队成员可以从这其中吸取教训，提高效率。

整合所有的原则

    一个好的敏捷团队是要整合所有的原则，而不是从中寻找几个实践，整合这些实践的关键在于团队的思维方式，敏捷的价值观和原则是思维背后的动力。敏捷团队不仅要诚实的回顾开发软件的方式，还要回顾成员交流的方式，以及与公司其他同事交流的方式。首先要理解原则，然后要理解其中的原理，还要在工作中不断的评估和改进。

   一些比较牛的开发人员往往遇到这样的事情：本来开发了一段很棒的代码，结果某个根本不懂编程的人要求做出一个修改，你就不得不把这段代码弄乱然后打上补丁，之后就进行了一个沮丧的恶性循环。这个时候开发人员就会很容易被敏捷的团队所吸引。在敏捷团队中，会不断的与客户沟通，不断的做计划，在计划与沟通中，就过滤到一些棘手的问题，并且不断改变自己的编程方向，编写一些耦合性低得代码，以及一些价值高的产品，从而就可以在后期从容的面对变化。

    并且敏捷团队的沟通方式可以让开发人员真正的进步，因为他们的团队很可能是自组织团队，每个人都会去进行自主的学习，因为团队的知识决定了项目的宽度，并且团队成员自己会决定让团队正常运转的沟通内容，这不仅可以开发出更好地产品，而且你还可以向坐在身边的开发人员取长补短。