BugClose 要做什么

bugclose 上线快两周了，我们的 QQ 群里非常热闹，很多热心的用户给予我们真诚的鼓励，有的说 “ 真是业界良心之作 ” ，有的说 “ 外表简单，内心强大 ” ，还有很多用户给我们提出了很多中肯的意见和建议，我们都一一回复，暂时不能采纳的建议我们会耐心的解释，为什么 BugClose 要做这个，不要做那个。于是一些用户说我们应该把这些解释集结成文，让还没有深入 bugclose 的人先读一读，来了解一下 BugClose 到底要做什么，在自己的项目中能不能用。

bugclose 源于我们自己在项目管理中的痛点，在开发 BugClose 之前，我们是一个六个人的团队，研发一款与汽车有关的 App ，一个产品，一个设计，一个后台，一个安卓，一个 IOS ，一个 Web 前端，这是一个 App 开发团队的典型配置。我们采用了典型的敏捷开发的模式，产品经理很快的拿出第一版的原型图，功能有限；设计根据原型图做界面设计，切图；后台根据原型图的功能做服务接口；安卓， IOS ， Web 前端拿到切图后也立刻投入工作。设计要素和代码的管理我们用了互联网的 svnspot ，省去了自己搭建服务器的麻烦（有时候要在家里工作）；沟通和交流我们自己建了一个群，也能管用。到了开发后期，需要开始测试了，我们开始寻找一个 Bug 管理工具，这好像是每个开发团队的必备，没有别的工具可以替代。我们只想要一个小工具， JIRA ， Redmine ， QC ， TD 等肯定不适合我们这样的团队，光是费用就把我们吓倒了，更别说安装配置的复杂性了； BugZilla 和 BugFree 是开源的项目，也容易安装，但用起来也不方便，很多现代浏览器支持的功能都没有实现；禅道是我们接触到的比较好的工具了，功能强大，界面也整洁，但我们愣是没搞太懂，概念太多，限制太多，光是模块就有三种，产品模块，项目模块，测试模块，我们也不反对这种方法论，精确的项目管理就得这么干，但这个不适合我们，我们仅仅需要一个记录和跟踪 Bug 的工具而已。后来为了简单我们采用了 easybug ，不用下载，不用安装，注册就可以使用，但是界面实在太违和了，估计产品的维护者也没有怎么想去改进一下产品。到后期我们的工作模式基本是：每天早上开一个小会，先总结一下昨天的任务完成得如何，看看 bug ，定一下今天要改哪个 bug ，老板又有什么需求需要满足，安排一下临时任务，写个会议纪要，贴到 QQ 群里，有什么问题直接在 QQ 群里讨论。问题就出现了，首先 QQ 群的聊天记录是不能永久保留的，前两天的讨论可能就看不到了；另外讨论多起来的时候，就会把各种问题混在一起，不知道谁是谁了；最要命的是，讨论的定论到底是什么，有的同志仍模棱两可，所以需要有地方认真的记录下来。后来我们想：适合我们这样的团队的项目管理工具究竟是怎么样的？

首先我们需要做需求管理，不需要太复杂。老板一般每周都和产品经理开一次会，把自己在外面见人见事的灵感乍现给我们，先不管是否值得去做，是否能做；另外团队中也会有一些关于产品的想法；这些想法或需求应该被记录下来并讨论，需求会比较多，所以更需要一一甄别，最终决定要不要做，什么时候开始做。然后我们需要做任务管理。我们不需要长期的计划（那是给老板看的），我们需要记录的是最近一两天每个人的工作是什么，记录任务并不是为了监督或者督促，我们发现，平时的口头布置任务看似大家都清楚，而实际上并不是那回事，在理解上会有偏差，甚至有些人会忘记细节或者任务本身。所以，还是不如老老实实的记录清楚，这样每个人都有明确的任务。针对任务的沟通讨论也很重要，当面讨论可以么？当然可以，但是有两个问题，一如果当时不在一起怎么办？可能等到在一起就已经忘记了（不相信？灵感是稍纵即逝的），二讨论的结果怎么确定下来？还是要记录。我们当然需要做缺陷管理。小团队的缺陷管理相当简单，有一两个测试人员，测试产品的时候要提 Bug ，一般会先提给产品经理，由产品经理确认后再分配给开发人员，开发人员修复 Bug 后会提交新的版本，并让测试进行审核。最后我们需要记录一些通知，不管是一些项目的公开信息（如配置信息等），还是会议纪要，工作计划等，需要让全体成员知道。

bugclose 从我们自身的项目实践出发，希望提供给中小开发团队一个轻量级的项目管理工具。我们希望 bugclose 是敏捷的，轻量的，是什么意思呢？大家都知道敏捷开发的 4 个中心思想，总结起来就是：沟通为王，小步迭代，客户参与，响应变化。首先我们相信项目管理是为了让项目进行的更顺畅，而不是束缚人的手脚，我们不去做个人效率分析，也不做绩效管理，我们做的是怎么让项目运转的更流畅；然后我们相信沟通是项目管理的第一要素，记录或管理是沟通的工具，而不是相反，我们希望任何一个需求或任务或缺陷都是在充分沟通的情况下决定的，记录的目的在于，一是提供沟通的素材，二是保留沟通的结论，有了结论，项目才会往前发展；最后我们希望工具本身是容易使用的，容易上手，用起来轻轻松松。

bugclose 的一大特点是用 bug 把缺陷，任务和需求统一起来，有很多人不理解，因为不管是缺陷，任务或需求，好多公司都有专门的系统来对付它，我们是不是做得过于简单了？首先我们考虑到不管是需求，任务还是缺陷，最重要的功能还是记录和跟踪，而不是去监督或者评价。我们要做的是一个实际操作的工具，即让干活的人省点心，而不是出一个牛逼的报表交给董事会审批的。我们不想让一大堆概念和一大堆按钮围着开发人员或测试人员，而是只做必要的功能。然后在我们的实践经验中发现，需求，任务和缺陷管理走的流程基本一致，没有特别显著的区别，他们的差别只在于提交的目的；而且，需求，任务和缺陷是紧密的联系在一起的，尤其是在一个周期短快速开发的项目中，从需求到任务，从任务到缺陷，再从缺陷到任务，经常性的需要转换或派生。举个例子，需求经过讨论决定要做了，有两种方式开始，一是把需求直接修改成任务（转换），分配给开发人员，如果这个需求不是一个大的改动，这种方式最直接，所有的讨论要点和决定都已经记录下来了；如果这个需求是一个大的变动，涉及到好几个产品，则需要针对该需求分配好几个任务（派生），每个任务与该需求相关（可以在任务描述里指出）；缺陷产生了，产品经理确认后，知道这个 Bug 也涉及到多个产品多个人员，这时也需要另外创建任务并让任务与这个缺陷关联。

bugclose 的另一大特点是项目组织非常灵活，可以适用于各种目的，可以针对某个产品建立不同时期不同版本的项目；可以针对某个大型的实际项目建立很多小项目，把团队分成好几组安排到小项目里来进行开发；还可以与客户共享一个交流项目，客户对产品的需求都可以一一得到解答。 bugclose 也没有对项目做任何限制，只要你的项目需要跟踪需求任务或者缺陷，就可以用上。总之， bugclose 着重的还是项目本身如何完成，如何灵活的组织人来参与项目，而不是项目之间有什么联系。

bugclose 还做了一个简单的通知管理，通知是为了正式的发布一些信息，可以供项目成员及时查看或查找。以前发布信息，可以用 QQ 或邮箱，不太好管理，过不了几天就要去邮箱里找半天。我们对项目管理中的通知简单的做了分类，目的是为了让用户一眼看到或查找通知是干什么的。根据我们的实践经验，我们分成了如下几类：会议通知，会议纪要，工作计划，版本发布，信息公布。即开即用，也不需要用户去配置什么。

关于 Bug 我们还有几个不做的选择，下面一一说明：

为什么不做模块管理？模块管理很好啊，只不过有点机械复杂。我们不想让项目管理员对着模块划分发愁（每个人都要一套模块划分方式，没有统一标准，你这么划分我很别扭），另外显示模块也是众口难调，用什么分隔符都不一定能满足要求。模块直接在标题里用自然语言表达是最清楚不过了，真的要精确？统一格式就行了。

为什么不做环境管理？ bugclose 想面向一个比较广泛的项目管理领域，不仅仅是软件开发，我们希望做智能硬件的，做系统集成，做微信推广的等等做任何中小型项目的团队都来用这个产品，所以我们没有对环境字段做过多的限制。环境本身就应该是在特殊情况下才需要的字段，不是每个缺陷都需要填写环境的。所以，自由就好。

为什么不做富文本？还是为了简单，大部分 Bug 一两句话就能描述清楚，最多有个一二三四点。图片其实已经很好的说明了一切，不需要写什么 “ 看下图 ” ，最多写一个 “ 见图 1” 就够了。做富文本加重了用户的负担，同时也带来不安全的因素 (XSS 攻击啥的）。

1. 任务关联以前想做过，但界面会稍显复杂，讨论觉得让用户自己用自然语言描述更好；因为bugclose不是MS Project那种项目管理软件，工程性质不明显，主要用于记录和跟踪；
2. 可能用户更容易理解“急”吧，在项目管理来讲，急可能更重要，对个人或公司来讲可能不是。