最近在看《知行合一——实现价值驱动的敏捷和精益开发》这本书。最初决定买这本其实是被它的名字吸引了，虽然字面意思非常通俗易懂，很容易让人一眼就理解到它可能要表达的意思，但还是想买回来看一下作者是怎样理解的。

中国明代思想家王阳明提出了“知行合一”的思想，强调了思考与实践结合的重要性。“知”是基础、前提 ，“行”是重点、关键，“未有知而不行者；知而不行，只是未知”。必须知不弃行，行不离思，慎思之，笃行之。

时代的发展，科技的进步，带来的必然是信息化突飞猛进，所以软件开发也随之经历了一次次的沧海桑田，最为大家熟知的就是CMMI（先知后行）再到现在人人都在说，人人都在其中摸爬滚打的敏捷开发（知行合一）。那么究竟什么什么是“先知后行”，什么又是“知行合一”？

“先知后行”，顾名思义，对于一个软件项目来说，我先要搞清楚这个项目所有的功能需求、技术选型、资源配置、交付时间以及所有涉众对这个项目的期望后。然后所有岗位的人员全部就位，按照完整的设计文档开发、测试、验收、最终交付。当然这是一个非常理想的过程，从项目立项、设计、开发、测试、验收到最后的交付过程完全没有任何的外界干扰，大家按部就班的完成各自的职责，最终领项目奖金——好像有点俗了啊。

但是事实往往却不是这样，从人对事物的认知过程来说，任何人对任何事物的理解是随着时间的推移逐步变换的，时间越久，经历的越多对事物的理解就越深刻，对期望的要求就越高。特别是软件项目，显然一成不变的需求与设计是难以满足人们对产品的要求的。在信息瞬息万变的互联网时代，墨守成规、一成不变就意味着被淘汰，只有不断响应变化才能跟上信息变化的浪潮。所以知行合一——以实现价值驱动的敏捷和精益的开发及管理方法，踏着时代的春风走进了我们的视野，成了适应变化的一把利剑。

相信只要在IT行业摸爬滚打过几年的人，没有人不知道敏捷开发方法的，敏捷宣言和原则相信大部分人都能倒背如流，那么是否真正的理解其中的精髓呢？

宣言也好，原则也罢，这诸多的条条框框的目的无非就是让我们的产品能够物有所值、能够真正的实现价值输出。何为价值输出？相信许多人对于ERP系统仍然记忆犹新、印象深刻，一个企业耗费大量的人力、物力、才力打造了一个ERP系统，那么这个系统的是否真的就是用户所需要的呢？当然有极少部分的功能使用量很高，也确认对日常工作有一定的帮助，但是，殊不知这样一个庞大的系统里面还有成千上万的功能估计用户从来都没有使用过，甚至有可能都不知道有这样的功能。那么我们想象，这样的产品是否真的是用户想要的，他的投入与产出是否合理？甚至还有些企业耗费了大量的资源后，发现开发出来的东西并不是他们想要的，而此时项目已经接近尾声，进入了一个进退两难的境地，最终不得不放弃......

多么痛的领悟~~~~~~

既然有了痛的领悟，是否就应该有改机的决心和方法呢？所以项目的管理者引入的敏捷开发。那么，有了过往惨痛的教训我们就应吸取教训：

1、既然传统的模式交付周期太长了，不能尽早的发现问题改进进问题，那我们就缩短交付周期，尽早、持续交付有价值的的软件，所谓船小好调头，及时发现问题，调整方向。

2、所有的开发都有一个通病，No，是所有人都存在的通病，当一件事情快接近尾声时突然被告知，事情有点问题需要调整方案，相信很多人的第一反应是“不是吧，大哥！是都要做完了现在要改，不改行吗？”，更有甚者“大发雷霆，爷我今天不干了，你们谁爱干不干”，撂挑子走人了。当然，话说回来谁愿意改来改去呢！都麻烦，但是为了适应变化，让我们的产出更有价值，我们不得不做出调整，换位思考一下，大家统一一下目标，就不会有那么多“可是”、“如果”了。所以，我们要坦然的接受需求的变更，哪怕是在需求的后期，只有变更才能为我们赢得竞争的优势。

3、开发与产品的矛盾这是历史的宿命，就像猫和狗一样，见面就是开撕。但是我们人不能和动物比啊，我们有着高智商、高情商的人，没有什么问题不是坐下来喝杯茶不可以解决的，如果真的有就出去海吃海喝一顿，回来找老板报销~~~~。所以呢，无论何时何地遇到问题，开发和业务应该保持持续沟通，双方时刻保持目标一致，只有这样才能大踏步前进。对于一个团队来说，面对面沟通才是最高效的信息传递方法方法。

及时沟通、时时沟通，所有人对同一的产品的最终价值始终保持一致，持续的、快速的交付可以工作的软件，毕竟只有可工作的软件才是有价值的产品。

书还没读完，洋洋洒洒写了这几行文字，估计再长了也没人会看了，算不上什么真理名言，纯属自己的切身体会。各位看官，有什么不同的理解的欢迎大家留言、斧正。

小生这厢有礼了！