项目微管理11 - 文档
从四代回来发布第一个版本的时候起，四代就意识到了一些严重的问题：
第一，测试时验证一个功能的标准是什么？为什么说一个现象是Bug？而另外一个现象是设计成这样的，不是Bug？参与测试的所有人，包括四代，都不知道是对是错。
第二，在最近一年日常工作中，四代已经不记得有多少次发生这些的事情了：当客户发现一个软件的使用问题后，四代找遍相关的所有人后，只有极个别的人才知道是怎么回事，并且知道这样改动的历史。
第三，团队新人来了如何系统了解软件的功能？如何训练才能成为软件的专家？团队如何传承软件的功能？
这些问题都在表明，对于整个团队来说，软件功能缺少一个统一的标准。这个标准不能存在于个别人的记忆中，即使是四代也不行。这个标准只能是公开的，团队中所有人都需要知道怎么获得或查阅。
文档，文档，谁是最精通软件的那个人？
实际上，上述的那些问题描述的都是在各种不同的应用场景下，如何方便获取到软件功能的问题。这个问题的答案总结起来就是一个东西 - 文档！
只有有了文档，团队的测试才会有对照的基础，这样的测试才有可信度。也只有有了文档，软件的功能才能传承下来，团队中的每个人才有一个途径去了解软件的所有使用细节。
敏捷流程不像传统的瀑布流程，它认为能工作的软件比文档重要，所以很多人想的有些简单，就是把繁琐的文档工作直接抛弃，这样确实敏捷了，轻松了，可是传承性没了。
还是一句老话，对于团队来说，有什么比传承还重要的吗？没有！所以文档必不可少！
在众多的文档中，四代经过不断的思考和筛选，最终考虑在团队流程中只加一份文档 - 测试文档。一份文档够吗？四代觉得还是得先试一下。
确定了这个思路，四代就把整理完整的测试文档作为一个起点，作为今年最重要的一个工作来慎重对待。虽然很多人并不这么认为，四代还是坚持了自己的意见，逐步展开了整理测试文档的工作。
苦逼的文档整理生活
四代将整理测试文档的工作分为了三步：
第一步，整理一份粗略的测试文档。
在这个阶段，四代想去整理一份粗略的文档，这个文档对软件功能的覆盖不要求有多深，但是一定要广，一定要全，这份文档将作为下个阶段文档整理的大纲。
第二步，整理一份最为详细的测试文档。
在这个阶段，四代会和团队一起基于粗略的那份文档，制定一个比较长的计划，来详细的整理和归类软件的各个功能，力求使得所有的细节都有依据可以查找。
经过这个步骤，四代希望团队中的所有人都可以深入的了解软件的一部分功能，这样不仅对于测试人员是非常好的，对于开发团队中的每个人也是非常有益的。
第三步，划分测试的优先级。
完备的测试文档非常庞大和复杂，而团队平时的测试除了集成测试外，还有一些其他只需要覆盖部分功能的测试，于是四代在接下来的整理中，把功能划分为出核心功能和辅助功能，并且把每个功能的测试点进行重要性分级。
把功能和测试点按重要性分级，再结合开发人员对于修改范围的跟进，这样，在一些轻量级的覆盖性测试中，能同时达到测试高效和节约成本的目的。
整理测试文档这件事本来是测试小组的本职工作，四代提出来以后，测试小组的MM们全身心的投入到这个枯燥繁杂的整理工作中，给了四代极大的帮助。想到这里，四代觉得要给并不黑的小黑，并不憨的二狗，并不暴力的美丽点个大大的赞。
除了测试组，四代还计划给PC团队的成员分配了一定的整理任务，就从鼬开始吧。他们也需要深入的参与到这个过程中，这是测试文档的初始化过程，也是整个团队对于软件功能的了解和记忆的过程。
经过这么艰辛的整理测试文档的过程，团队熟悉了软件的功能，制定了测试的标准；团队终于有了一份正式的文档，团队成员对功能有疑问的可以查阅测试文档相关的部分，新人入职后也可以照着测试文档去熟悉软件所有的功能。
测试文档有了，那其它的文档呢？四代也不知道是否需要，等着真正需要的时候再说吧。小平同志“摸着石头过河”论大概就是这种做法吧，四代觉得非常务实。
文档生死劫 - 更新
对于团队文档，历来都有一个严重的问题：更新！什么时候，由谁更新？文档和软件一样，僵化了就会面临死亡。所以完成一个文档仅仅是完成了文档工作的第一步，接下来文档的维护工作才是更重要的。
对于这个问题，四代也考虑了很久，最后终于还是在一个时刻，突然有些想法，于是一个试运行的方案终于在四代的脑中形成了。这个方案由两个部分组成：
第一个部分是日常维护。
这一部分通常是由发现文档有问题的兄弟发起，时间是每次集成测试。
每次集成测试的过程中，当参与测试的人员发现软件功能和文档描述不符时候，需要辨别这是软件的问题还是文档过时了，软件的问题需要开Bug，文档的问题需要更新文档。发现文档问题后，测试人员需要提出问题，然后测试妹子负责核实和更新对应文档。
第二部分是激励式维护。
这一部分通常由开发的哥们完成，时间是随时。
开发完成一个修改的时候，其实他是最了解细节和改动的人，这个时候由他去完成文档的更新是最合适的，不过有个问题就是他不会有这个意识去做的，这当然不是什么责任心不责任心的问题。
为了改善这种情况，四代想到了在考评选项中加入了一项：主动的改善过时的文档。做到了这一项，可以拿到一定的激励分数，这个分数大家都懂的哈。不过，最终由于每个阶段开发任务都比较重，这一项并没有得到太多的重视和投入。
好吧，唯一不断维护的文档保证了软件的质量，保证了知识的传承。足够吗？四代不知道，不过软件功能上的传承性问题暂时解决了。
那么，下一步呢？
