敏捷团队在减少沟通浪费的同时，也会利用各种产品工具、技术脚本甚至是连接更多现成的文档来保证内部跟踪，因为跟踪会使团队的具体工作更加透明。缺少了内部跟踪，敏捷的重要支柱----透明性就很难做得深入。我们不能以敏捷的名义打碎了跟踪！
你们裸奔了
我在跟一个实施过敏捷的朋友聊天时，发现他们是一个典型的案例。他们从传统的瀑布转向敏捷后，似乎一下子找到了罪恶的源头，开始热火朝天地去除各种文档与流程，最后，就剩下一个用户故事。我问他们有验收标准吗？说没有；我问有测试用例吗？说也没有。
他们测试拿故事测，验收拿故事验收。开始我还抱着希望，问他们用户故事怎么写的，结果他们说用户故事也是很简单，没有更详细的内容，说写了浪费时间，交付时，只有系统和一个测试报告。他们以为什么都可以不用写，什么都是说说就好。
我最后不无感慨地对他们说：“你们裸奔了...”
现象
很多刚尝试做敏捷的团队，认为去除大部分文档就敏捷了，这是很大的误区。我们不能为了去除文档而去除文档，或是为了去除流程而去除流程。文档与流程是为了沟通，也是为了跟踪。虽然敏捷团队的现场沟通可以让我们不需浪费时间写不必要的文档，但单纯的只想着去除文档与流程却很可能会产生更严重的问题，就是把跟踪也去除了。
敏捷团队在减少沟通浪费的同时，也会利用各种产品工具、技术脚本甚至是连接更多现成的文档来保证内部跟踪，因为跟踪会使团队的具体工作更加透明。缺少了内部跟踪，敏捷的重要支柱----透明性就很难做得深入。我们不能以敏捷的名义打碎了跟踪！
这里所谓的跟踪，可能包括很多内容，以工程的视角，就是团队要了解软件工程中实际的工作状态，包括需求的变化、设计的演化、代码的版本变化、测试的覆盖，以及他们之间的关联关系等。以测试用例来说，实施敏捷过程中你可以没有叫测试用例的东西，可以写法不同，可以放在不同的地方，不管用什么方法，关键是你要能够知道你们都验证了什么，或没验证什么，这并不是可有可无的浪费工作。
现场对用户故事的讨论来说，虽然能带来一致的理解与宽频的沟通效果，但并不能让我们的大脑更精确地记录所有细节，那么我们就一定还是需要有相应的辅助手段来连接一些信息起到跟踪的作用，否则当团队有限的记忆力消退时，如何有效的还原当时的一致性理解？保证透明性的跟踪从哪里来？
原因
在导入敏捷的时候，敏捷思维（Mindset）的准备很重要，很多误区都是因为敏捷思维（Mindset）的准备不足。所以团队经常会只知其然，而不知其所以然。有时照搬照抄，不知变通；有时盲目革命，丧失理智。或是对传统管理方法深恶痛绝，把一切问题的根源都归因在传统的管理方法上。
却不知，从来没有什么银弹可以让你轻易解决所有问题，或代替所有其它方法。任何方法论都是有其适用域的，敏捷也不例外。敏捷相比传统管理方法，本质上是一种新的思维（Mindset），但传统管理方法在其适用域内仍是科学与有效的，我们看待它们时不能非此即彼，非黑即白。
要想正确地理解这种新的思维，也要能正确的看待传统流程管理方法。如果更深入了解他们间的区别，可以连接到我以前写的两篇文章《隐喻与思维之杂谈》和《敏捷与传统流程管理之杂谈》。（此处的连接方式也是一种敏捷对待文档的例子，我们不需要浪费时间重新写一个文档说明这个内容，可以简单地连接到其它文档。）
感悟
谈到思维，我经常用“道法术”来形容敏捷中的理念、原则与实践，与圈子里的敏捷教练也常用“道”来隐喻思维层面上的内容。
我觉得，每家公司或组织都应该有自己的“道法术”，没有照搬照抄可以成功的可能。每个人都应对“道”（Mindset）有足够的准备，因为它既是法与术的方向，同时也是建设符合企业实际情况的敏捷文化的依据。
