在实际工作中经常会提到敏捷，到底什么是敏捷呢，本篇文章将对敏捷知识体系做一次必要的解读。
首先敏捷是什么呢？敏捷它并不是什么新鲜概念，早在20世纪50年代就已经被提出来了，到目前为止已经七十多年了。我们可以认为敏捷它是一种思想，倡导简单设计，快速交付，价值导向，响应变化。从而让软件交互变得更加快速，可靠，让敏捷使用者可以更早地看到满意的产品。整个敏捷思想通过一份敏捷软件开发宣言来体现，其中包括了四个核心价值观以及12个原则。价值观定义了什么是敏捷，而原则是实施敏捷的12个指导。
来看一下四个核心价值观讲的是什么？
首先个体和交互重于流程和工具。简单来说啊，敏捷更加看重人，以及人与人之间的沟通，一个大型复杂的项目要想持续地为产品做出正确的决策是非常困难的。
很多时候都需要跨多个团队，甚至跨多个部门沟通，才能够获得有价值的信息。同时它让团队成员能够熟悉项目本身以及项目进展的情况，帮助成员尽量拓展了解的全面，甚至是项目全局，所以良好透明的沟通才能保证项目的高效运转。当业务线非常多，项目非常复杂，周期跨度也比较大的时候，团队的沟通就特别的重要了。
为了帮助成员能够更快地掌握全局，一些企业甚至会在办公区安置一块或者是多块的显示屏，上面投放项目进度。待办清单也就是有哪些事情是需要做的，进度怎么样，参与项目的成员是哪些，以及各自的情况，还有里程碑的任务，比方某一个版本周期有哪些任务是要完成的，优先级怎么样的等等，通过这些方式把项目信息可视化。让项目管理更加透明，促进了团队成员的沟通，帮助成员去分析自己的决策。由此可见，个体和互动的重要性大家应该已经很明白了。
那为什么说高于流程和工具呢？我们知道很多公司会有规范流程，比方说iso9000，cmi等等。而且会提供各种各样的工具对项目进行管控，合适的流程和工具确实能够提高开发人员的工作效率，但是，过多的工具和管控就会让人把大量的时间浪费在流程的约束之中。举个例子，在PMP里面要求做项目发生变更的时候，需要由项目变更委员会去控制，由委员会进行决策并下发项目变更内容。但实际项目中，做变更的时候可能并不需要这么复杂的流程，项目也往往没有什么所谓的项目变更委员会，多数情况下要对项目进行变更的时候，只要项目利益相关的人坐到一起开一个短会，就可以解决了。
所以，流程和工具只是工作上的辅助，如果你的公司流程和工具会对项目成败起到决定性的作用的话，那必然是本末倒置的。敏捷还是强调项目是由人来完成的，成败的关键也应该是人。另外，还可以再举一个例子，某一个流程或者工具虽然很优秀，在业界也是广泛使用的，有一天你们团队也跟风采纳了，但问题是你们团队的使用者他可能并不认可这个流程或者工具，这样的话，长期以来你的团队就很难把这个流程或者工具用到最后。所以，有些企业的管理者啊，他喜欢强推一个事情，弄到下面是怨声载道，叫苦不迭。这其中的主要原因还是没把“人”放在第一位。
第二，工作的软件高于详尽的文档。软件开发需要文档这一点是毋庸置疑的，没有文档的软件是一种灾难，代码并不是传达系统设计以及原理的理想媒介。团队要编写易于阅读的文档，从而对系统以及系统的设计原理，决策等进行描述。而编写文档，首先可能需要花费大量的时间，要想使得这些文档和代码保持同步的话，就需要花费更多的时间，因此过多的文档可能以过少的文档更加糟糕。
传统软件在文档编写的方面，简直可以说是登峰造极，因为它事无巨细，一切都在文档之中。以至于很多时候，这个开发人员他并不是在做软件开发，而是在做文档管理员，这就有点本末倒置了。
其实，很多的文档是可以精简的，比方说编码风格规范做一些约定，那这样的一些文档就可以不写了。再一个，一些业务逻辑的设计，如果在不写文档的情况下也能够读懂代码的话，那这部分文档也没有必要去书写。
另外，保持文档和代码的同步也是一个麻烦事儿，需求一旦发生变化，代码设计发生变化，文档也是要随着改动的。而文档的同步往往容易被人忘记，这个时候文档就可能会给人造成误导，甚至导致开发人员之间的沟通障碍。到底是以代码为准还是以文档为准呢？如果以文档为准可能会造成误解，而以代码为准的话，文档的价值又在哪里呢？所以敏捷它更加关注工作的软件，至于文档的话，应该足够短小并且突出主题，所谓工作的软件指的是你要交付的软件，它能够工作起来。另外有关这一点，业界还有一个“Martin文档第一定律”，讲的是“直到迫切需要并且意义重大时，才来编制文档，否则就不些文档”。大家可以做一个参考。
其他时候，还是应该尽量把精力集中在工作的软件本身，也就是想办法让我们的软件能够工作起来。
三是，客户合作高于合同谈判。传统模式下客户提出需求之后，他就做甩手掌柜了，但实际上，只有客户他最清楚自己想要什么。软件开发者他并不一定能够完全理解客户的需求，仅靠一两次的会谈或者活动谈判并不一定能够精确地定义客户的需求，沟通的过程大家理解可能会偏差，更何况客户可能随时改变主意，对吧？因此敏捷提倡，客户和开发人员应该更加密切地协作，经常沟通。这样才能够更好更快地开发出客户需要的产品。
第四，响应变化高于遵循计划，这里要说的是，项目计划当然是极其重要的，传统的软件开发它习惯在编码之前就做好严格的软件设计，但是俗话说的好，计划赶不上变化，对吧？客户的需求会变，业务环境会变，市场会变，技术也在变化，所以，敏捷他强调要响应变化，拥抱变化。
一般来说敏捷做计划的策略大概是这样的。为未来2~4周做详细的计划，为未来的三个月做粗略计划，至于一年之后要做什么，有一个粗略的想法就可以了。
有关这一点，很多实行敏捷的部门大概是这么规划时间的，首先在每年的3~4月，团队负责人以及更高级别会参加部门的共创会，那说是共创会，其实更像是脑报价茶话会。每个人会准备一张纸条，写上自己希望部门来年的重点发力方向，比方说一个部门有三条产品线，你最希望发力的方向是哪一条？并且你认为可以怎么搞？战略是怎样的？把每个人的想法贴到黑板上，由大家去投票决定。这个计划其实就是大致上的想法而已，是一个未来一年的计划，当投票决定了未来一年的计划之后，每一条产品线内部再去开会，确定最近三个月的粗略计划。在之后，每一条产品线内部的项目团队内部再去开会，确定最近一个月的工作目标，并工作安排到人，这个安排就会非常的细致，会精确的描述每一个人做什么工作，工作量大概是怎样的。
这样整个计划就完成了，真正实施的时候，这个计划也会随时调整，比方说团队有其他的小伙伴离职了，你顺带接手了他的工作。那你的工作计划也自然会改，再比如，两个团队发生的合并，团队的定位发生了变化，这个时候呢就需要重新做未来一年以及三个月的计划，又比如说你被leader安排其他工作了，这个你的详细计划也会变。总之，这个变化无处不在，有的人经历过一年换四个老大的狗血经历，然而这在敏捷型企业其实并不少见。敏捷的企业文化重要一条就是要拥抱变化，这也是敏捷思想的一个直观体现。当然了，这个过程也是非常痛苦的。
以上，就是敏捷的四个价值观。需要强调下，这四个价值观只是敏捷的侧重，大家不要过分的极端说拥抱左边的，放弃右边的，这是绝对不正确的。比方说个体和互动高于流程和工具，你千万，不要理解成不要有流程和工具了，可以随心所欲，四个核心价值观只是说前面的高于右边的。并不是否定右边，右边的部分也是非常重要的。
下一章节，一起探讨下“敏捷的12个原则”。
| 留言与评论（共有 0 条评论） “” |
