[阅读: 463] 2005-07-01 06:07:27
>26. 你们是给每个Dev开一个分支么?
>反对。Branch的管理以及Merge的工作量太大,而且容易出错。
忍不住又要说没做过产品了,2.1.13在维护, 2.2.31在开发,你倒都在main branch上折腾折腾看
>27. 有人长期不Check-In代码么?
>不可以。对大部分项目来说,最多两三天就应该Check-In。
呜呜,我们的项目从启动到现在已经半年了,还没进入编码阶段呢。
>28. 在Check-In代码时都填写注释了么?
>要写的,至少一两句话,比如“解决了Bug No.225”。如果往高处拔,这也算做“配置审计”的一部分。
注释当然要写。不过,千万不要写“解决了Bug No.255”,万一没解决好,“配置审计”大概不会让你在下一次再写一个“又解决了Bug No.255”吧。
> 29. 有没有设定每天Check-In的最后期限?
>要的,要明确Check-In Deadline。否则会Build Break。
不是吧,27的时候你还说可以两三天才check in的!
>30. 你们能把所有源码一下子编译成安装文件吗?
>要的。这是每日编译(Daily Build)的基础。而且必须要能够做成自动的。
我们的系统没有安装文件怎么办?
>31. 你们的项目组做每日编译么?
>当然要做。有三样东西是软件项目/产品开发必备的:1. bug management; 2. source control; 3. daily build。
我们的东西比较大,一天编译不完怎么办?
>32. 你们公司有没有积累一个项目风险列表?
>要。Risk Inventory。否则,下个项目开始的时候,又只能拍脑袋分析Risk了。
啧啧,积累风险,好有风险哦
>33. 设计越简单越好越简单越好。
>设计时候多一句话,将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。
晕了,设计就是勇敢的砍!那我们需求控制委员会是干嘛吃的?
>34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子,有这两个作为基础,可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML,而不是自己去Parse一个文本文件;尽量用RegExp,而不是自己从头操作字符串,等等等等。这就是“软件复用”的体现。
如果时间允许,还是尽量自己来吧,不行就自己累积,用现成的Control是烦恼之源,Control可能带来版权问题、成本问题、难以理解的BUG、难以接受的修复周期
>35. 你们会隔一段时间就停下来夯实代码么?
>要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw,“夯”这个字念“hang”,第一声。
夯字我倒会念,夯土也见过,夯代码就没见过,难道是用pkzip打个包?
每个月打个包倒是蛮不错的想法,不过既然咱已经上了VSS,这个备份是不是有点多余了。
>36. 你们的项目组每个人都写Daily Report么?
>要写。五分钟就够了,写10句话左右,告诉自己小组的人今天我干了什么。一则为了沟通,二则鞭策自己(要是游手好闲一天,自己都会不好意思写的)。
您还别说,以前有一阵子公司要求写周报,我游手好闲一周,死活也凑不出10句,愁死了,真是不好意思极了,咱表达能力咋这么差呢?旁边同事总结经验总结得特别好,你要是看我周报没写啥,那么说明我很忙没时间瞎折腾,要是写了一堆,那说明我没有干好多事也比较有空所有把什么都写上去了。
> 37. 你们的项目经理会发出Weekly Report么?
>要。也是为了沟通。内容包括目前进度,可能的风险,质量状况,各种工作的进展等。
好象经理的周报都是发给经理的经理的
>38. 你们项目组是否至少每周全体开会一次?
>要。一定要开会。程序员讨厌开会,但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。
开,当然要开了,这么多人吵一下午,啥也没搞定,还可以下回接着吵,多开心。
>39. 你们项目组的会议、讨论都有记录么?
>会前发meeting request和agenda,会中有人负责主持和记录,会后有人负责发meeting minutes,这都是effective meeting的要点。而且,每个会议都要形成agreements和action items。
兄弟们,不擅长写文档的就不要召集会议了,不然会后还不把你愁死
>40. 其他部门知道你们项目组在干什么么?
>要发一些Newsflash给整个大组织。Show your team’s value。否则,当你坐在电梯里面,其他部门的人问:“你们在干嘛”,你回答“ABC项目”的时候,别人全然不知,那种感觉不太好。
好象只有大BOSS敢给我们6千多人发垃圾邮件
>41. 通过Email进行所有正式沟通
>Email的好处是免得抵赖。但也要避免矫枉过正,最好的方法是先用电话和当面说,然后Email来确认。
测试员小S:妈的,昨天电话跟你好好说有BUG你不改,非得我发邮件并抄给经理你才知道厉害!
>42. 为项目组建立多个Mailing Group
>如果在AD+Exchange里面,就建Distribution List。比如,我会建ABC Project Core Team,ABC Project Dev Team,ABC Project All Testers,ABC Project Extended Team等等。这样发起Email来方便,而且能让该收到email的人都收到、不该收到不被骚扰。
你在40才说过要发给大家的!
>43. 每个人都知道哪里可以找到全部的文档么?
>应该每个人都知道。这叫做知识管理(Knowledge Management)。最方便的就是把文档放在一个集中的File Share,更好的方法是用Sharepoint。
Hi,神奇的KM, 请告诉我 3QF 51231 项目的 32451 AAAA DS 文档在哪?
>44. 你做决定、做变化时,告诉大家原因了么?
>要告诉大家原因。Empower team member的手段之一是提供足够的information,这是MSF一开篇的几个原则之一。的确如此,tell me why是人之常情,tell me why了才能有understanding。中国人做事喜欢搞限制,限制信息,似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力,不在于是不是能access information/data,而在于是不是掌握资源。
唔,明天我就跳到竞争对手那边去,顺便带上公司的所有文档
>45. Stay agile and expect change 要这样。
>需求一定会变的,已经写好的代码一定会被要求修改的。做好心理准备,对change不要抗拒,而是expect change。
我有病,来虐待我吧!
>46. 你们有没有专职的软件测试人员?
>要有专职测试。如果人手不够,可以peer test,交换了测试。千万别自己测试自己的。
ft,不做单元测试啦!
>47. 你们的测试有一份总的计划来规定做什么和怎么做么?这就是Test Plan。要不要做性能测试?要不要做Usability测试?什么时候开始测试性能?测试通过的标准是什么?用什么手段,自动的还是手动的?这些问题需要用Test Plan来回答。
是要有计划,要不然我们怎么知道测试组存在的意义呢?
>48. 你是先写Test Case然后再测试的么?
>应该如此。应该先设计再编程、先test case再测试。当然,事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发,我不喜欢,因为不习惯,太麻烦,至于别人推荐,那试试看也无妨。
神啊,test case倒底是什么?
>49. 你是否会为各种输入组合创建测试用例?
>不要,不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚,你是否有时间去运行那么多test case。
有道理,下次不要怪我测得不好,是test case工具没有测出来传进一个NULL程序就不干活了!
>50. 你们的程序员能看到测试用例么?
>要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的:提高质量。
想累死我呀,又要看文档,又要开会,又要写程序,连测试用例也要我管?!那还要测试组干吗?
> 51. 你们是否随便抓一些人来做易用性测试?
>要这么做。自己看自己写的程序界面,怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了,不方便的永久了也就习惯了。
测试员T : 那个棒棒,给你5块钱,来帮我做个易用性测试
棒棒B : 好嘛,测啥子?
>52. 你对自动测试的期望正确么?
>别期望太高。依我看,除了性能测试以外,还是暂时先忘掉“自动测试”吧,忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说,只能“矫枉必须过正”了。
测试员T : 我要罢工!!!这100个TEST CASE我上周已经点过一遍鼠标了,又让我点一遍!
>53. 你们的性能测试是等所有功能都开发完才做的么?
>不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正,早死早升天。
测试员T :系统速度太慢了,而且不稳定!
程序员P :你测试过我的模块的,我的模块又快又稳,肯定不是我的问题。
>54. 你注意到测试中的杀虫剂效应了么?
>虫子有抗药性,Bug也有。发现的新Bug越来越少是正常的。这时候,最好大家交换一下测试的area,或者用用看其他工具和手法,就又会发现一些新bug了。
66粉已经不让用了!换个人来测我的AREA,会不会有农药残留?
受不了了,这个唐僧怎么这么罗嗦,还没完,不玩了!