【PHP开源代码栏目提醒】:以下是网学会员为您推荐的PHP开源代码-Bug管理的经验和实践 - 其它论文,希望本篇文章对您学习有所帮助。
Bug管理的经验和实践孟岩刘振飞你好。
我知道你以前是方正出版印刷系统的核心开发人员后来来到微软的Office开发组。
我认识你的时候你还在微软工作状态似乎不错。
为什么后来又离开微软了呢 刘振飞93年到96年我在北大计算机研究所读研。
96年毕业后我留在所里继续从事方正核心产品世纪RIP --- PSPNT的研发、维护、升级还有外围软件开发比如新女娲补字NewNW、PDF流程系统等。
PSPNT是国内比较大的、成功的软件产品我一直为曾参与研发过这个产品而自豪。
工作中我模模糊糊地觉得应该有一个清晰的、可控的流程而不是依靠几个开发“高手”来支撑一个项目。
方正人的个人素质非常优秀集中在一起应该做得更为出色。
我在方正的时候最多也就带过10来人的队伍但即使这么小的团队已经让我精疲力竭、疲于应付了。
我发现面临一个无法解决的难题如何有效地控制软件研发流程以保证产品质量和进度。
我意识到做好一个软件只靠技术好是很不够的必须要有一套好的研发流程和配套的支持工具。
你也知道国内软件企业的项目经理都是“全才”需求、设计、编码、测试、维护乃至产品发布都要精通事必躬亲但实践中你又不可能样样都精通所以结果只有一个四处救火累得半死但永远看不到尽头。
当时就觉得这么干有问题但究竟问题出在哪里、如何有效改进都不知道。
我最纳闷的是这么10来号人的研发管理就这么费劲人家微软上千人、分布全球的Windows、Office研发队伍是怎么有效管理的我当时深入研究了一些软件工程方面的理论比如花了一段时间仔细阅读了原版的Rational Unified ProcessRUP觉得很兴奋RUP里面的研发理论很完备和几个同事聊天觉得应该按照RUP的去做但是理论归理论具体到实际产品开发该如何做还是一筹莫展。
恰好那时候读了微软中国公司前总经理吴士宏的畅销书《逆风飞飏》提到了微软的企业管理、内部的数字神经系统及相关叙述非常感兴趣想去那里看看。
刚好有个机会得到了微软中国研发中心Office组的一个PMProgram Manager职位。
在微软的4年中我先后经历过Office XP、Office 2003的研发中间还夹着做过Project 2002。
微软所有产品的研发都遵循同样的研发模式、使用同样的研发工具来进行管理只不过产品大小不一、人员配置有点区别罢了。
经历这几个大产品的研发流程加上在方正的体验的对比总结我觉得自己比较深入的理解了微软做研发的“套路”。
我是C程序员出身当PM后就没怎么写过
代码总还想写写。
刚好几个朋友开的公司要做网站、短信、声讯还要对报纸做数据支持他们需要一个懂研发管理的人去带技术部。
我觉得已经熟悉了微软的研发流程这刚好是一个检验自己所学所思的机会所以就离开微软去做这家小公司的技术总监了而且满足我另外的愿望我对Windows之外的世界充满好奇比如每天去新浪网看新闻他们网站是如何做出来的、用到什么样的技术Linux、
开源软件到底怎么回事 不过我一直认为微软是一家伟大的公司很喜欢其工作氛围。
特别的微软的软件研发流程我认为是最先进的值得大家去学习。
孟岩那请你介绍一下你所体会的微软研发管理的妙处。
刘振飞从我理解的角度微软的研发管理可以从以下几个方面描述 1研发人员分工明确。
主要的三个角色 PM Program Manager、 Dev Developer、Tester三者分工明确、接口清晰PM来定义需求、书写出来每个功能特性 Feature的设计文档SpecDev写
代码来实现这个SpecTester来测试 Dev做出来的东西是否符合 PM定义的 Spec三个角色之间并无必然的上下级关系只是分工合作完成某个功能Feature。
我将之形容为“三权分立”三者之间有效合作并制衡。
国内企业好像还没有PM这个角色而测试人员又往往成为开发人员的附庸一个 Bug是否要被解决全由开发人员说了算这很糟糕就像政治上一个权力没有被有效的制衡一样一定会产生各种问题。
2研发工具很配套。
PM将写好的需求设计文档Spec保存到 SharePoint文档库中所有相关的人都可以随时查看Dev用Source Depot 功能类似CVS的微软内部源
代码管理工具来保存源程序Tester把发现的Bug记录到Raid中以有效跟踪这个问题的处理流程。
3分阶段的研发流程。
和任何软件公司一样微软的研发无非也分为规划、开发、测试、发布等几个阶段。
但是微软的研发流程不走形式可以统一产品组所有员工的思想并且能够有效地控制住进度。
做完一个版本后还会让所有员工匿名投票找出这次研发过程中出现的各种问题以便在下个版本中解决 此过程称为 Postmortem挺吓人的一个词。
可以这么比喻微软这套研发模式让其中的每个人都成了一架高速运转的机器上的各种零件少数零件坏了不要紧可以随时更换。
当然微软有许许多多技术高手但我认为更重要是其研发模式保证了软件产品的高品质、可持续发展。
孟岩提到微软的研发管理你说过一句话我印象很深。
你说微软的研发管理中它的bug管理系统是居于核心地位的。
你这么说有什么道理吗 刘振飞前面说过微软所有产品的研发都遵循同样的研发模式、使用同样的研发工具来进行管理。
在所有的工具中我最佩服的就是其Bug管理系统Raid现在叫Product Studio。
可以说遍布全球的微软研发人员能够保持统一的思维模式、做事及语言习惯与整个研发流程的配套工具密不可分其中最重要的就是通过Raid把整个产品的研发有机的联系起来。
阅读每个 Bug你可以详细的看到大家讨论解决该问题的完整思路。
我曾读过微软Project 2002产品的Architect写的一个备忘录其中提到 如果Raid是别家的产品需要微软每年付出一笔巨大的费用Bill Gates会支付这笔钱吗“He wouldn’t be happy but you bet he would. Microsoft depends on Raid to get the job done.”当时我“心有戚戚焉”立即给这哥儿们发Email表示赞同之意 他回信说希望Project能够做的像Raid一样成功但可惜他要离开微软自己开公司了。
在微软上班我每天第一件事是打开 Outlook来处理有关自己的重要邮件第二件事就是打开Raid来看看有关自己的Bug情况赶快处理。
我一直纳闷微软为什么不把这个Bug管理系统作为软件来出售那可是任何一家软件企业都需要的啊 表面上看Raid其实是一个简单的工具那么它的重要性体现在什么地方呢 Raid从一开始就支持多用户 一个团队中的所有人都可以创建、指派Bug或者改变Bug状态 用户可以非常自由的去定制Raid 基于SQL很多有用的报告可以被生成出来 管理层需要所有Bug都在Raid中被有效的跟踪处理 Raid的价值在于它密切跟踪当前产品的实际Bug状态使项目组中的成员非常有效的协调他们的工作。
大家都很聪明如果一个工具是容易理解的、而且管理层提供其使用指南比如Bug怎么被指派和解决那么简单的工具也能提供巨大的价值。
孟岩能否请你简要地介绍一下微软的bug管理体制 刘振飞在整个产品的研发过程中特别是在测试产品、修复Bug的中后期团队中所有人都生活在Raid中 - 测试人员Tester只要发现问题就立即新建一个Bug予以跟踪并指派给相关的开发小组长Dev Lead - 开发小组长会判断这个Bug属于某个特定的开发人员Dev并指派给他处理 - 开发人员会根据Bug的详细描述信息找到问题所在修改程序解决这个Bug并把Bug返回给当初的测试人员或者有争议的时候把Bug指派给这个Feature的定义者PM要求一个澄清说明 - 测试人员在看到某个Bug被解决后就去验证这个Bug是否真的不存在了根据最初的发现步骤去证实问题真的解决了就关闭这个Bug若还能重现或者不同意开发人员的解法可以激活这个Bug返还给当初的开发人员做进一步调查处理 - 当测试人员和开发人员无法达成一致意见的时候由对应的PM出面做协调判断这个Bug的严重程度、对用户可能的影响根据产品的进度和项目资源做出评估是否真的需要修理掉这个问题 - 管理团队利用Raid来跟踪整个进度单个人的工作、小组的进度整个产品研发进度 研发队伍中的所有人都通过Raid来商议、沟通某个Bug是否符合当前解决Bug的“门槛”决定是否需要真正修理掉这个Bug、如何修理、可能的副作用、如何测试其解决方案等等。
每个人可以在Raid中看到某个Bug的全部历史档案比如几年前发现的一个Bug一直推迟到这一版才解决前几年大家是如何讨论的可能的处理思路是什么都被完整地记录下来了。
每月、每周甚至每天参与这个产品研发的人都收到一封当前Bug状态的Email每个人都上有多少BugDev、PM、Tester头上Bug数最多的前5名都是谁哪个子产品、子模块中的问题还是处于上升阶段整个Bug的趋势怎么样等等。
这是最详尽的产品状况“内参”暴露在团队中每个成员的面前一览无遗。
只要你的名字被列在Email中你就非常紧张因为你脑袋上的Bug比较多、影响整个产品的质量。
这些该死的Bug等待着你去快速处理尽快把自己从排行榜上去掉。
每解掉一个Bug或者把Bug转给另外的人去处理就会舒一口气因为头上又少了一个某一天你头上的Bug数降为0了心里就会非常高兴 我觉得微软的Bug处理过程非常类似于“击鼓传花”的游戏。
鼓点响起你的任务就是尽快把自己手中的“花”Bug传给下一个人不要让它在自己手里耽误很长时间。
从表面上看在微软工作从不打卡、上班时间也很自由、上午很晚到办公室也没人管你但是有Email跟着、有Bug催着你永远不可能偷懒。
没有人盯着你只是事情如影随形而且所有和你相关的事情都是公开的相关的人都知道就像处于非常开放的舆论监督之中除了把事情办漂亮你还能有别的选择吗 最后要强调两点 1 上Bug不仅仅是测试人员的事情团队中的每个人发现问题时都上个Bug来跟踪 2 Raid中不仅仅是跟踪软件功能方面的Bug其他各种问题如需求文档Spec的改动、界面上的错别字、帮助文档的遣词造句问题、某项任务指派等等都可以通过一个Bug来跟踪。
我至今对刚进微软时老板的一句话印象深刻Everything should be tracked in Raid 孟岩就你了解到的情况国内的公司在这方面怎么样 刘振飞在微软这几年我也一直和国内软件公司的朋友们保持接触。
很遗憾的是国内的一些软件企业特别是不少中小企业其软件研发还是处于作坊式的状态只不过作坊规模有大中小之分罢了。
有意思的是走在国内IT最前沿做各类网站的企业根据我的了解也在走软件企业最初几个“大虾”牛人搞定一切的阶段。
我不是说个人技术好不重要而是需要更进一步把研发管理真正搞起来做出规模效应从而有效的保证质量、控制进度、把对某个人的依赖尽量降低并使产品可持续发展。
你知道国内不少软件企业在做ISO9001或CMM认证花费不菲。
少数企业纯粹是为了认证而认证对付着拿到证书就达到目的了更多的企业确实是想利用这个认证的过程把自己的研发流程规范化。
但似乎能从这些认证中享受到真正的研发管理提升的并不是很多甚至开发人员现在需要花费大量的时间去书写一些例行公事的、没有任何实际价值的格式化文档苦不堪言。
我觉得软件研发管理必须结合自己企业的实际情况不要生搬硬套书本上的理论只要人员分工、配置合理能够控制质量什么方法都可以采用。
黑猫白猫能抓耗子的就是好猫。
千万不要走形式、走过场。
孟岩其实国内公司在研发方面与微软的差距非常大也存在于很多方面。
为什么你独独看中bug管理为什么你认为中国中小型企业的软件开发管理规范化应当从bug管理入手呢 刘振飞从微软的研发管理来看主要是需求、开发、测试这三大块毫无疑问国内公司在开发这个环节一直都很重视不过需求和测试较弱一点。
大家现在都已经认识到充分理解业务需求的重豆∏Φ氖侨绾斡行УУ斫獾奈牡怠/FONTgt 但是测试这一块大家还是不够重视对测试人员的素质要求也不是很高、人员比例也较低测试人员往往依附于开发人员的直接管理人微言轻。
而在微软测试人员和开发人员的比例很多时候是1比1的有时候会更高。
测试人员和开发、需求人员一样有自己单独的行政管理路线比如我就注意到有非常资深的测试人员可以做VP专门管理某个产品的测试工作。
这在国内企业来说几乎就是不可能的。
通过前面的介绍无论人员的配置和工具的提供你可以看出微软是非常重视测试的。
所以我觉得如果我们学习微软先进的研发理念可以从测试入手打造必要的测试管理系统通过这样的系统把需求、开发、测试三个环节融合在一起让团队中所有的人都遵循同样的研发思路需求人员真正理解用户的业务需要认真研究后形成需求文档作为产品一个个功能的“合同”开发人员写出设计文档然后动手写
代码测试人员理解需求文档然后测试做出来的功能是否符合最初的设想。
整个过程碰到的任何问题都要通过Bug系统来记录、跟踪相关人员通过Bug管理来商谈、沟通相应的解决方案。
这样通过Bug管理逐步统一研发人员的思维、做事模式让整个团队可以有效地运转起来并不断优化自己项目的软件研发流程提高产品质量从而使产品可持续发展。
孟岩看来你对于bug管理可真是重视。
听说你在离开微软后开发了一个
开源项目BugFree号称是要全面模拟微软的bug管理机制。
能介绍一下大致的情况吗 刘振飞今年四月我加盟朋友的公司开始做网站发觉自己已经习惯了微软的研发模式于是建议这几个朋友先做一个 “数字神经系统”其目的是让一切可以数字化、文档化的信息被记录下来为公司的进一步发展和决策提供基础信息支持。
BugFree 就是其中有关软件研发的Bug管理系统部分。
我太了解Bug管理对软件研发的重要性、也对微软的Bug系统有了深入掌握所以需要有一个类似微软的Bug系统才好开展工作。
虽然网上有免费的Bug管理系统如Mantis、Bugzilla但是我看后觉得都不好使和我在微软用的差别太大上海科泰世纪公司的 Bug管理系统倒也很像微软的但是要花钱买。
琢磨着反正我也这一块非常熟悉了何不做一个出来自己用于是决定借鉴微软的研发流程和Bug管理工具自己开发一个以便对我们开发新网站、声讯软件、客户端软件和公司事务管理中出现的问题进行有效的跟踪处理。
“数字神经系统”中的BugFree是用开放源
代码的PHPMySQL写成、基于浏览器方式运行的。
我以前没有任何LinuxApacheMySQLPHP的开发经验但我很幸运的招聘到几名优秀的Web程序员可以在短短的两个月时间内搭建起这样的系统。
其中BugFree是由我的同事王春生开发的他用了不到一个月的时间就把
代码写完让我很是惊讶从而认识到基于Linux的Web开发魅力。
之后我们测试一个多月就可以在实际工作中使用并不断完善。
现在BugFree已经成了我们日常工作最重要的工具每个员工也都习惯用Bug来记录跟踪事情不仅仅是
代码中的缺陷可以上Bug新的需求、设计变化等都可以用这个Bug管理系统有效的管理起来。
其实Bug 不仅仅可以用来记录软件中的缺陷也可以用来跟踪公司的日常事务。
比如在公司的网上报销系统还没有建立之前我们就用 BugFree来处理报销的事情。
甚至一个同事给我上了这样的Bug你的桌面太乱了请整理一下 命名BugFree 有两层意思一是希望软件中的缺陷越来越少直到没有Free嘛二是表示它是免费且开放源
代码的大家可以自由使用传播。
也算为中国的软件业做点小小的贡献特别的希望能对国内中小企业的研发流程改进、Bug的有效管理提供参考和帮助。
和微软内部的Raid比较起来BugFree有如下特点 1Raid是Windows客户端软件BugFree是基于浏览器的。
基于此Raid 有很强大的编辑展示功能而BugFree简单、方便、易用 2Raid可以进行极其复杂的组合查询BugFree的查询功能相对弱一些但我觉得对中小企业已经够用了 3一个Bug从创建到关闭这个“生命周期”的处理过程BugFree 全面借鉴Raid的处理流程处理方法甚至一些词汇都和Raid一样 所以我现在用BugFree处理Bug的感觉和在微软时候基本一样 4BugFree 还有一个独创的功能当一个Bug被指派给你的时候系统会自动给你发一封邮件告诉你有个Bug需要你处理这样结合 EmailBugFree被完美使用起来成为我们现在网站开发、运行、维护必备的工具。
我们还增加了两个Bug统计功能一是每天早上8点钟每个同事都会收到一封Email告诉他/她头上还有多少 Bug等待处理二是每周一中午给所有人发一封邮件告知上周Bug的处理情况和到目前为止所有Bug的统计数据 5BugFree程序规模很小一个中等水平的
PHP程序员就可以在12周内看懂所有的
代码然后就可以根据自己的需要做相应的定制了 6最最重要是BugFree 是免费并且开发源
代码的。
你可以体验到微软的Bug管理精髓按自己需要自由地增加功能、修改
代码而不用担心版权问题 不过坦率的讲BugFree 仅仅是个工具而已重要的是掌握其中蕴含的软件研发的流程思想才能用好这个工具。
如果你以前没有用过 Bug管理系统那么一开始的时候也许你会觉得这个工具是在浪费时间因为一个测试人员需要费神把发现 Bug的详细步骤记录下来有时还要贴一张示意图这一切都不如当面说来得直接。
但是使用一段时间你会发现 BugFree很有用它忠实的记录着每个问题的处理过程不断提醒你存在的问题永远不会丢失和忘记。
如果你参与过较大软件项目或产品的研发就会理解它对软件可持续发展是至关重要的。
而且研发的规模越大BugFree 的作用就会越大。
感兴趣的朋友可以到http://www.okooo.com/OpenSource 来体验、下载最新版的BugFree。
孟岩好的我们下期结合BugFree来具体看看一个软件开发项目的bug管理应该怎么做。
—发表在《程序员》杂志2005年第2期3842页的原文— 孟岩刘振飞你好。
上一期文章里我们谈到了Bug管理的理念和经验。
按照我的体会Bug的控制是一个管理与技术相结合的课题。
做好Bug的管理一方面需要有完善的管理体系和制度另一方面更需要有一个坚实的基础平台来支撑。
确切地说就是要有一个比较完善适用的软件充当Bug管理的中枢神经。
显然你是很看重这个软件系统的。
我想问你一个问题如果没有这样的软件系统而是单方面强化管理比如制定完善的流程和制度来管理Bug你看这样可行吗 刘振飞从我的经验来讲只靠制度而没有良好的Bug管理软件根本无法确保Bug管理的有效性因为仅靠这些规章制度很可能流于形式、走过场。
正如源
代码管理一样如果没有类似CVS或VSS的工具很难想象一个较大项目中的源
代码仅仅靠公司的源
代码管理制度和大家的自觉性就可以让多个程序员之间的不同版本源程序保持同步、不冲突。
光有制度是不行的必须有配套工具来保证这些制度落到实处 还有做好 Bug 的管理应该是从高层领导到中间管理层再到基层人员都从内心认同其重要性然后根据自己公司的实际情况制定相关的管理体系和制度切实执行并逐步形成自己的风格。
要实用、不要随波逐流。
不能今天一个ISO、明天一个CMM、后天又来个6西格码。
工具是思想的载体再好的管理思想还是要通过工具来实现。
购买也好、自己开发也好必须有个 Bug 管理工具作为基础支撑平台。
孟岩一个企业如果有意建立自己的“Bug管理神经系统”大致可以有三种选择一是购买成熟的商业产品二是选择类似BugFree那样的
开源软件三是自己开发符合本公司现有架构的Bug管理软件。
对于某些公司来说最后一种模式应该是很有吸引力的。
你主持了BugFree的开发能否告诉我们开发一个Bug管理系统难不难 刘振飞应该说不难想自己开发一个Bug管理系统的朋友你首先要明确本公司真正的需求是什么再就是根据你的需求做出来后一定要在实际产品研发中真正应用起来根据大家的反馈不断去完善。
像我们开发BugFree从开始动手写
代码到真正能够在公司里使用前后也就两个月时间。
为什么能够这么快做出来呢最重要的原因是我把 BugFree的需求真正掌握了。
我在微软天天使用Raid、时时刻刻和Bug管理打交道。
我是站在微软这个巨人的肩上去深刻理解其20多年研发所总结出来的经验所以四年下来不让我熟悉Bug管理都难 当我决定做 BugFree 的时候脑子里很清楚为什么要做、做成什么模样、应该怎么做、做出来后大家怎么用每个环节都考虑清楚了。
这样.
上一篇:
基于PHP技术的中小企业办公系统
下一篇:
首鼠两端