Bug系统本身是为了提高工作效率，但使用者如果建立没有好的习惯，没有培养好的使用文化，则Bug系统带来的效率改进无法发挥。所以，本人根据多年使用Bug系统的体会，在此撰文进行Bug系统文化的总结，欢迎大家补充、讨论：

　　1、尽量在标题把问题说清楚。

　　大家查看Bug，多的时候使用的是列表方式。

　　列表方式下，有几个栏目：错误分类、严重性预估、状态、后更新、问题摘要描述。（在提交Bug时需输入或选择的是：错误分类、严重性预估、问题摘要描述）这些都是在查看时能得到的仅有的信息，往往也是进行选择的仅有的依据，另外也是进行统计分析的仅有的依据，所以在提交Bug时需输入或选择的3个栏目，一定要认真填写、选择，并且尽量使“问题摘要描述”能把问题讲清楚，以使得大家在查看时可以一目了然。

　　像“不能添加”这样的标题，今后应该杜绝，因为这样的标题让人不明白，在什么界面，不能添加什么内容，而且总是强迫使用者点击标题去查看内容才能知道。在大家讨论到Bug时，这样的标题也没有用处。标题的内容没有什么字数限制，显示出两行也是完全值得的。

　　在大家讨论Bug该如何分派时，“有用”的标题也可以大大提高工作效率

　　有兴趣可以看看本人带来的演示系统的Bug标题

　　2、Bug系统的工作模式是异步的。异步工作模式的工作效率，比同步的高。

　　每个Bug，从“新建”到“关闭”有多个步骤（多个状态）。对一个Bug，完成每个步骤，以及每次改变状态，都可以由不同的人进行，可以在不同的时间进行。Bug的管理工作细分化，才能提高工作效率。

　　大家使用Bug系统，都要认识到这一点。发现问题，报告上来，是做了贡献，并不一定要马上进行分析，或是马上进行分派。同样，维护人员在觉得有时间时，可以自己查看各个Bug，选择自己认为应该去处理的（可参照严重、重要、紧急程度），分派给自己，而不用等待别人给自己分派。

　　发现问题，在Bug系统中记录，维护人员分派后去解决，这是异步的；发现问题的人口头跟维护人员讲述，是同步的，这种方式会打断维护人员的工作。

　　3、Bug的内容要原子化（即：不可分割）

　　每个Bug，都是各自分派、处理的，所以，不要在1个Bug中谈2个或更多的问题，而应该分在不同的Bug中进行描述，否则会给维护、管理工作带来很大的麻烦（比如，工作难以并行开展）

　　4、报告Bug应尽量多提供线索

　　软件本身是各种逻辑的组合，所以问题的发生也是有逻辑条件的，即：在某种情况下才会发生。报告Bug，应该尽量弄清楚发生问题的逻辑条件，并尽量描述清楚，以给维护人员清楚的线索。

　　比如，软件在遇到某条数据时才会有问题，而在其它数据上没有问题，则应该写清楚是哪一条数据导致问题。

　　5、不要在报告Bug时判断原因，应只描述现象

　　使用者看到的问题，只是现象。而现象是宝贵的线索。

　　非维护人员如果每次都自己去猜测或判断原因，除了会浪费自己的时间外，往往还会忽略掉问题的现象这样的重要线索，还会误导维护人员，并浪费维护人员的时间。

　　如果报告Bug时，觉得自己大概能猜到有可能是哪些原因，则可以作为线索之一，在“问题详述”中进行说明，而不要在标题中说明。标题应只描述现象

　　6、用良好的习惯避免重复

　　如果自己打算去解决某个Bug，应在开始前刷新一下Bug系统，查看状态有否改变，若无变化，再把它分派给自己，然后才去修正Bug。否则，很可能会发现自己或同事的工作被浪费了。

　　同样，如果打算提交个Bug，应先查看一下或搜索一下是不是已经有人提过同样的Bug了，以免重复提交。这里，好的Bug标题的作用显现出来了。