1. 可工作的软件 高于 详尽的文档
今天跟好几个同学讨论了敏捷实践的一些细节，讨论的重点在于设计文档是否要实时更新。我的理解是必须要更新，不更新就没有可视化的验收标准，有些同学的意思是，如果一个标点符号都要修改，这个工作量太大了，讨论到最后，终于有人又提到了那个经典的问题：敏捷宣言不是说 可工作的软件 高于 详尽的文档吗？为什么我们还要维护这些文档？
上面这个问题是敏捷开发过程中经常遇到的经典问题之一，也是很多团队敏捷转型走向失败的根本原因之一，下面我就自己的一些理解大概阐述下为什么这个理解是错误的。
这个网站是敏捷宣言的官方网站：敏捷宣言
打开这个网站，大家可以看到这幅图片：
敏捷宣言中确实明确的说了“可工作的软件 高于 详尽的文档”，但是紧挨着敏捷宣言的下方，还有一句话：
也就是说，尽管
右项有其价值，
我们更重视左项的价值。
也就是说，详尽的文档并不是不需要，而是价值没有左侧的可工作的软件高。
关于是否需要文档，我跟公司的多位敏捷教练都有沟通过，他们给出的明确回复是：像传统瀑布开发那样的概要设计、详细设计等文档是不必须的，但是像接口文档、设计文档还是必须的，这些文档不仅需要，而且要保证正确。
2. 个体和互动 高于 流程和工具
同样的问题也出现在个体和互动 高于 流程和工具这条宣言，我带过的多个团队都出现过类似情况：测试人员发现bug后，直接口头跟研发说了，然后研发自己修改掉，这个流程大部分情况下不会出问题，但是不排除个别研发疏忽，造成了上线的版本携带了某些已发现但未修复的bug，出现这个情况就很让人恼火，明明已经测试出来的bug，但是没有修复，测试也没有再回归。
后来的团队，我都会要求大家把所有的bug提交到Jira上，但是几乎每个团队都有人跳出来说：大bug必须是要记录的，小bug就没要记录了吧？
在提这个问题的时候，很多人也会同时把“个体和互动 高于 流程和工具”的敏捷宣言拿出来说事，认为我的要求违背了敏捷宣言：口头沟通bug就是在多互动，而我要求使用Jira就是在强调工具，这么做是不对的。
个人理解：个体和互动 高于 流程和工具这条宣言，确实是在强调互动，但是这里的互动，应该是关于需求理解、沟通协作的互动，而不应该是工作流程的互动。有一套好的流程和工具，可以清楚的知道自己在某个阶段应该有哪些交付物，在去到某个里程碑的时候，应该有那些具体的工作成果，等等。在有流程的基础上，作为Scrum Master，有责任去提高团队的互动性，明确大家的目标，发挥个人价值。
下面这段话是我们公司的一位敏捷教练大牛看完本文后，关于这条宣言给的补充：
工作流程并非不可沟通。只是要确认一点，工作推进的状态是团队内的公允，不是每个人想改就改的。工作流程的沟通是为了达成一致，而非每个人在没有共识的情况下按照喜好的方式工作。
3. 另外两条宣言
其实敏捷宣言除了这2条：
个体和互动高于流程和工具
可工作的软件高于详尽的文档
还有另外2条：
客户协作高于合同谈判
响应变化高于遵循计划
这两条宣言我倒是从来没有听大家说过类似这样的话：
客户协作 高于 合同谈判，所以我们不要搞什么合同谈判了吧，只要客户有需求，我们就干吧，客户给多少钱就收多少！
响应变化 高于 遵循计划，所以我们不要做任何项目计划了吧，大家随心所欲的干去吧，干多少算多少！
因为这话一说出来，大家都知道是错的。
但是在前面2条宣言的理解上，以我的经验，可以不客气的说，几乎每个新组建的团队都会遇到问题。
我也是被折腾了很多次，才终于悟到了上面的一点道理，希望对大家有所帮助。
