公司今年提倡走敏捷，大家争先恐后的找大量的敏捷书籍、网络资料来学习，上到总经理，下到小虾米。
可敏捷到底是个什么东东呢？用公司内部的一句话来说就是：重沟通、轻文档。
但很多团队的大大们都曲解了这句话，倒是没有先去打破壁垒使沟通更畅通，协作更好，到时把“轻文档”抓的不放，然后大话它为“不需要文档”，设计文档不用写了、伪代码不用写了、测试用例不用写了，一切文档都不用写了。
这话一出，设计急了“不写文档，我们干什么？”答曰“写代码去”，好吧，确实是个思路，结果咱们公司的设计人员、开发人员不分了，统称为工程师，又干设计、又干开发，回到了N年前的模式（设计、开发一人干），果然是分久必合啊。
开发也急了“没有设计文档，我不会开发了”，好吧，设计文档不能丢，只是不必重型，而是写出重点即可，其它一些开发、测试心知肚明的“潜规则”就不写了。什么？开发、测试不知道有哪些心知肚明的“潜规则”，好吧，给梳理梳理，给讲讲。
测试也急了“没有设计文档，我按照什么标准来测试？不写测试用例，我拿什么做测试执行？闭着眼睛点？”，好吧，又一个强烈要求不能没有设计文档的，设计文档光荣的活下来了。
在产品体系，设计文档很好的保留了下来，并且引入了“用户故事”，一个个小用户故事，再细化成系统的实现设计文档。
在项目体系，则分为两种：
一是零星简单需求，这几乎就不需要设计文档了，一线发邮件告诉大家要完成什么东东，并通过电话、视频会议等方式跟大家尽可能facetoface的沟通需求怎样怎样的，可能一两句话就搞定的，开发人员直接编码，测试编写简单的测试要点，再执行测试即可。发包速度那是个快啊~！
另一是专项需求，那就是比较复杂的，一两句话说不清楚的，必须要进行设计的，否则开发不知道该实现个啥，测试不知道该怎么测试。
好吧，设计文档保留下来后，该谁来写的问题。什么？不就是设计来写么。NONONO，你out了，都敏捷了，怎么可能还是设计来写呢，不是都说人人都是“产品经理”，那么敏捷下“人人都是PM、人人都是设计、人人都是开发、人人都是测试、人人都是总经理、人人都是小虾米”。
所以，简单的需求，“程序猿”、“测试猿”可以来写设计文档，复杂的需求还是让“设计狮”来写吧。
轮到测试用例了，如何轻文档呢？
如果没有设计文档，就说明这是一个很简单的需求，无需设计、无需写测试用例，在白纸上画画要测试的点，执行测试时把该跑得点跑到，再做做探索式测试，看能不能挖掘BUG出来。
如果有设计文档，就说明这是一个比较复杂的需求，设计文档很详细了，直接在设计文档上补充即可，无需单独拿文档将设计文档上每一个点copy出来再转变成测试用例语言，遇到需要判定表、因素组合的情况，就另开sheet来用各种表细化吧。
最后，测试发现的BUG该不该登记呢？现在开发、测试的绩效中去掉了内部缺陷率这一说，那还登记BUG干嘛捏。
先来谈谈，为什么要登记BUG。
BUG是记录测试过程中发现的不符合需求的问题及建议，如果不登记，开发以什么为修改的依据，如果不登记，如何分析帮助开发分析他的薄弱技术点呢。但登记很花时间，一个BUG从描述、步骤、重现环境、等级、类型、责任人、指派人、截图等要敲3~5分钟，一个大型项目下来的所有BUG的文字都能写一篇论文了。
因此，BUG必须登记，但登记要有新的水平。
例如：我可以发现BUG，就马上截图，截图上框出问题的地方，写几笔期望结果即可，别小看这幅截图，它会暴露很多信息的，有操作步骤（模块名称、点击了哪些按钮、录入了哪些值等），开发一看就知道是什么问题，比文字描述看的爽多了。然后我立马在咱们小团队的群里丢出这幅图，如果开发有空，则会立即修改，如果他正专心思考和编码，可以之后我拿这些问题截图形成的excel/word文档找他（一般为了不打扰程序猿的思考，我们会约定好时间，如上午11点、下午5点）。如果有开发不怕被打扰的话，也可以记录的同时当面沟通。 后续，再根据这些问题分析出开发为什么会出现这些BUG，是业务不熟，还是某些技术点薄弱，帮助开发提升他的技能。 所以BUG记录是个好东西，可不能丢啊。
最后，咱们的各类文档还是没有砍砍砍，该重要的还是要留，不重要的必须得砍。
PS：分享自己遇到的这些软件公司的事儿，某些方法不一定适合大家，但却适合自己，也许某天也不适合自己。
欢迎大家来拍砖，传递一下你们的公司是怎么做的。
谢谢各位看官了~