A、普通开发h员：
掌握了计机基础知识Q?br>熟悉计算源，学会了编E语aQ喜Ƣ卖弄技巧，喜欢比较~程语言的优劣；
以能~出某种Ҏ功能的程序ؓ荣，不懂原理Q不求甚解；
喜欢个h开发，不重视文档编写；
B、Y件工E师Q?br>计算机基知识扎实Q?br>掌握两门以上~程语言Q很停留在表面比较~程语言的优劣；
以编写出用户满意的高质量软g?br>懂得个h开发和团队开发的利弊Q文档规范，齐全?/font>
Ҏ2Q?/font>
A、普通开发h员：
只重视功能的实现Q不重进度和质量的把握?br>怕被“?#8221;得太死，动不动就说限制了思\Q没有发挥空间?br>不喜Ƣ做试工作Q认为测试低Z{，从来没有做过试工作?br>只根据自q爱好学习技术；
B、Y件工E师Q?br>懂得在进度、质量（功能Q和成本之间q?br>懂得规范的目的在于重用，重用有利于提高效率和集中_֊创新?br>认ؓ试工作比编码更h战性，自己l常为同伴的代码做白盒测试?br>Ҏ企业目的需求和自己发展目标的共同点选择学习内容和方向；
Ҏ3Q?/font>
A、普通开发h员：
认ؓ别hE序很差Q不喜欢看别人的代码Q?br>总认己比业务专家q更理解需求?br>目开始时Q喜Ƣ说:“没问题，SO EASY”?br>目大大延期Ӟ喜欢_“设计太烂Q没法编E?#8221;?/font>
B、Y件工E师Q?br>喜欢为同事走查代码，q以此获得学习他Z点的ZQ?br>懂得自己只是可能比业务专家更懂编E?br>目开始时Q喜Ƣ问:“那是什么？q是Z么？”?br>目大大延期Ӟ喜欢_“我ؓ什么就没想?#8230;”?/font>
]]>
MVMQ应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS?
2. 你们的项目组使用~陷理pȝ了么Q?/strong>
MVMQ应该用。ClearQuest太复杂，我的推荐是BugZilla?
3. 你们的测试组q在用Word写测试用例么Q?/strong>
MVMQ不要用Word写测试用例（Test CaseQ。应该用一个专门的pȝQ可以是Test ManagerQ也可以是自己开发一个ASP.NET的小|站。主要目的是Track和Browse?
4. 你们的项目组有没有徏立一个门L站？
MVMQ要有一个门L站，用来放Contact Info、Baselined Schedule、News{等。推荐Sharepoint Portal Server 2003来实玎ͼ15分钟搞定。买不vSPS 2003可以用WSS (Windows Sharepoint Service)?
5. 你们的项目组用了你能买到最好的工具么？
MVMQ应该用量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一U炫耀。但也要考虑到经费，所以说?#8220;你能买到最好的”?
6. 你们的程序员工作在安静的环境里么Q?/strong>
MVMQ需要安静环境。这Ҏ端重要，而且要保证每个h的空间大于一定面U?
7. 你们的员工每个h都有一部电话么Q?/strong>
MVMQ需要每Z部电话。而且电话最好是带留a功能的。当Ӟ上这么一套带留言电话pȝ开销不小。不q至每Z部电话要有，千万别搞得经常有人站h喊：“某某某电?#8221;。《h件》里面就强烈谴责q种做法?
8. 你们每个人都知道Z问题应该找谁么？
MVMQ应该知道。Q何一个Feature臛_都应该有一个OwnerQ当ӞOwner可以l箋Dispatchl其他h?
9. 你遇到过有h?#8220;我以?#8230;”么？
MVMQ要消灭“我以?#8221;。Never assume anything?
10. 你们的项目组中所有的人都坐在一起么Q?/strong>
MVMQ需要。我反对Virtual TeamQ也反对Dev在美国、Test在中国这U开发方式。能坐在一起就最好坐在一P好处多得不得了?
11. 你们的进度表是否反映最新开发进展情况？
MVMQ应该反映。但是，应该用Baseline的方法来理q度表：l护一份稳定的ScheduleQ再l护一份最新更攏VBaseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手Dc?
12. 你们的工作量是先由每个h自己估算的么Q?/strong>
MVMQ应该让每个׃。要从下而上估算工作量，而不是从上往下分z。除非有其他原因Q比如政MQ务工期固定等?
13. 你们的开发h员从目一开始就加班么？
MVMQ不要这栗不要一开始就搞疲x。从目一开始就加班Q只能说明项目进度不合理。当Ӟ一些对日Y件外包必d天加班，那属于剥削的范畴?
14. 你们的项目计划中Buffer Time是加在每个小d后面的么Q?/strong>
MVMQ不要。Buffer Time加在每个Q务后面，很容易轻易的p消耗掉。Buffer Time要整D늚加在一个Milestone或者checkpoint前面?
15. 值得再多׃些时_?5%做到100%?/strong>
MVMQ值得Q非常值得。尤其当目后期人困马乏的时候，要坚持。这会给产品带来质的区别?
16. 登记新缺hQ是否写清了重现步骤Q?/strong>
MVMQ要。这属于Dev和Test之间的沟通手Dc面寚w沟通需要，详细填写Repro Steps也需要?
17. 写新代码前会把已知缺陯决么Q?/strong>
MVMQ要。每个h的缺陷不能超q?0个或15个，否则必须先解册的bug才能l箋写新代码?
18. 你们对缺L轻重~急有事先的约定么Q?/strong>
MVMQ必L定义。Severity要分1??Q约定好Q蓝屏和Data LostSev 1QFunction ErrorSev 2Q界面上的算Sev 3。但q种U定可以Ҏ产品质量现状适当q行调整?
19. 你们Ҏ见不一的缺h三国会议么？
MVMQ必要有。要有一个明的决策q程。这cM于CCB (Change Control Board)的概c?
20. 所有的~陷都是q记的人最后关闭的么？
MVMQBug应该由Opener关闭。Dev不能U自关闭Bug?
21. 你们的程序员厌恶修改老的代码么？
MVMQ厌恶是正常的。解x法是l织Code ReviewQ单独留出时间来。XP也是一个方法?
22. 你们目l有Team Morale Activity么？
MVMQ每个月都要搞一ơ，吃饭、唱歌、Outing、打球、开卡丁车等{，一定要有。不要剩q些钱?
23. 你们目l有自己的Logo么？
MVMQ要有自qLogo。至应该有自己的Codename?
24. 你们的员工有印有公司Logo的T-Shirt么？
MVMQ要有。能增强归属感。当ӞT-Shirt要做的好看一些，最好用80支的来做。别没穿几次q破烂烂的?
25. ȝ理至每月参加次目l会?/strong>
MVMQ要的。要让team member觉得高层xq个目?
26. 你们是给每个Dev开一个分支么Q?/strong>
MVMQ反寏VBranch的管理以及Merge的工作量太大Q而且Ҏ出错?
27. 有h长期不Check-In代码么？
MVMQ不可以。对大部分项目来_最多两三天应该Check-In?
28. 在Check-In代码旉填写注释了么Q?/strong>
MVMQ要写的Q至一两句话，比如“解决了Bug No.225”。如果往高处拔，q也做“配置审计”的一部分?
29. 有没有设定每天Check-In的最后期限？
MVMQ要的，要明Check-In Deadline。否则会Build Break?
30. 你们能把所有源码一下子~译成安装文件吗Q?
MVMQ要的。这是每日编译（Daily BuildQ的基础。而且必须要能够做成自动的?
31. 你们的项目组做每日编译么Q?/strong>
MVMQ当然要做。有三样东西是Y仉?产品开发必备的Q?. bug management; 2. source control; 3. daily build?
32. 你们公司有没有积累一个项目风险列表？
MVMQ要。Risk Inventory。否则，下个目开始的时候，又只能拍脑袋分析Risk了?
33. 设计简单越?/strong>
MVMQ越单越好。设计时候多一句话Q将来可能就带来无穷无尽的烦恹{应该从一开始就勇敢的砍。这叫scope management?
34. 量利用现有的品、技术、代?/strong>
MVMQ千万别什么东襉K自己Coding。BizTalk和Sharepoint是最好的例子Q有q两个作为基Q可以把L提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XMLQ而不是自己去Parse一个文本文Ӟ量用RegExpQ而不是自׃头操作字W串Q等{等{。这是“软g复用”的体现?
35. 你们会隔一D|间就停下来夯实代码么Q?/strong>
MVMQ要。最好一个月左右一ơ。传adq初Windowsl在Stevb的命令下停过一个月增强安全。BtwQ?#8220;?#8221;q个字念“hang”Q第一声?
36. 你们的项目组每个人都写Daily Report么？
MVMQ要写。五分钟够了，?0句话左右Q告诉自己小l的Z天我q了什么。一则ؓ了沟通，二则鞭策自己Q要是游手好闲一天，自己都会不好意思写的）?
37. 你们的项目经理会发出Weekly Report么？
MVMQ要。也是ؓ了沟通。内容包括目前进度，可能的风险，质量状况Q各U工作的q展{?
38. 你们目l是否至每周全体开会一ơ？
MVMQ要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加h臛_应该?时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code?
39. 你们目l的会议、讨论都有记录么Q?/strong>
MVMQ会前发meeting request和agendaQ会中有责主持和记录Q会后有责发meeting minutesQ这都是effective meeting的要炏V而且Q每个会议都要Ş成agreements和action items?
40. 其他部门知道你们目l在q什么么Q?/strong>
MVMQ要发一些Newsflashl整个大l织。Show your team’s value。否则，当你坐在甉|里面Q其他部门的人问Q?#8220;你们在干?#8221;Q你回答“ABC目”的时候，别h全然不知Q那U感觉不太好?
41. 通过Emailq行所有正式沟?/strong>
MVMQEmail的好处是免得抵赖。但也要避免矫枉q正Q最好的Ҏ是先用电话和当面_然后Email来确认?
42. 为项目组建立多个Mailing Group
MVMQ如果在AD+Exchange里面Q就建Distribution List。比如，我会建ABC Project Core TeamQABC Project Dev TeamQABC Project All TestersQABC Project Extended Team{等。这样发起Email来方便，而且能让该收到email的h都收到、不该收C被骚扰?
43. 每个人都知道哪里可以扑ֈ全部的文档么Q?/strong>
MVMQ应该每个h都知道。这叫做知识理QKnowledge ManagementQ。最方便的就是把文档攑֜一个集中的File ShareQ更好的Ҏ是用Sharepoint?
44. 你做军_、做变化Ӟ告诉大家原因了么Q?/strong>
MVMQ要告诉大家原因。Empower team member的手D之一是提供够的informationQ这是MSF一开的几个原则之一。的如此，tell me why是h之常情，tell me why了才能有understanding。中国h做事喜欢搞限Ӟ限制信息Q似乎能够看到某一份文件的人就是有w䆾的h。大错特错。权威、权力，不在于是不是能access information/dataQ而在于是不是掌握资源?
45. Stay agile and expect change
MVMQ要q样。需求一定会变的Q已l写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒Q而是expect change?
46. 你们有没有专职的软g试人员Q?/strong>
MVMQ要有专职测试。如果h手不够，可以peer testQ交换了试。千万别自己试自己的?
47. 你们的测试有一份ȝ计划来规定做什么和怎么做么Q?/strong>
MVMQ这是Test Plan。要不要做性能试Q要不要做Usability试Q什么时候开始测试性能Q测试通过的标准是什么？用什么手D，自动的还是手动的Q这些问题需要用Test Plan来回{?
48. 你是先写Test Case然后再测试的么？
MVMQ应该如此。应该先设计再编E、先test case再测试。当Ӟ事情是灵zȝ。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢Q因Z习惯Q太ȝQ至于别人推荐，那试试看也无妨?
49. 你是否会为各U输入组合创建测试用例？
MVMQ不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条g的组合——但要想清楚Q你是否有时间去q行那么多test case?
50. 你们的程序员能看到测试用例么Q?/strong>
MVMQ要。让Dev看到Test Case吧。我们都是ؓ了同一个目的走Ch的：提高质量?
51. 你们是否随便抓一些h来做易用性测试？
MVMQ要q么做。自q自己写的E序界面Q怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的怹了也׃惯了?
52. 你对自动试的期望正么Q?/strong>
MVMQ别期望太高。依我看Q除了性能试以外Q还是暂时先忘掉“自动试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软g试的现状来_只能“矫枉必须q正”了?
53. 你们的性能试是等所有功能都开发完才做的么Q?/strong>
MVMQ不能这栗性能试不能被归到所谓的“pȝ试”阶段。早早ҎQ早L升天?
54. 你注意到试中的杀虫剂效应了么Q?/strong>
MVMQ虫子有抗药性，Bug也有。发现的新Bug来少是正常的。这时候，最好大家交换一下测试的areaQ或者用用看其他工具和手法，又会发C些新bug了?
55. 你们目l中有h能说Z品的当前整体质量情况么？
MVMQ要有。当老板问vq个产品目前质量如何QTest Lead/Manager应该负责回答?
56. 你们有单元测试么Q?/strong>
MVMQ单元测试要有的。不q没有单元测试也不是不可以，我做q没有单元测试的目Q也做成功了——可能是侥幸Q可能是大家都是熟手的关pR还是那句话QY件工E是非常实践、非常工E、非常灵zȝ一套方法，某些Ҏ在某些情况下会比另一些方法好Q反之亦然?
57. 你们的程序员是写完代码就扔过墙的么？
MVMQ大忌。写好一块程序以后，即便不做单元试Q也应该自己先跑一跑。虽然有了专门的试人员Q做开发的Z不可以一Ҏ试都不做。微软还有Test Release Document的说法，E序太烂的话Q测试有权踢回去?
58. 你们的程序中所有的函数都有输入查么Q?/strong>
MVMQ不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参C递就不必查输入了Q省点功夫。同L道理Q未必要l所有的函数都写注释。写一部分主要的就够了?
59. 产品有统一的错误处理机制和报错界面么？
MVMQ要有。最好能有统一的error messageQ然后每个error message都带一个error number。这P用户可以自己Ҏerror number到user manual里面ȝ看错误的具体描述和可能原因，像SQL Server的错误那栗同PASP.NET也要有统一的Exception处理。可以参考有关的Application Block?
60. 你们有统一的代码书写规范么Q?/strong>
MVMQ要有。Code Convention很多Q搞一份来发给大家可以了。当Ӟ要是有FxCopq种工具来检查代码就更好了?
61. 你们的每个h都了解项目的商业意义么？
MVMQ要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在Z国某某行业的信息化作先驱者，或者时不时的告诉team memberQ这个项目能够ؓ某某某国安门每q节省多多百万的U税人的钱，q样有动力了。^凡的事情也是可以有个崇高的目标的?
62. 产品各部分的界面和操作习惯一致么Q?/strong>
MVMQ要q样。要让用戯得整个程序好像是一个h写出来的那样?
63. 有可以作为宣传亮点的Cool Feature么？
MVMQ要。这是增强团队凝聚力、信心的。而且Q?#8220;一俊遮百丑”Q有亮点可以掩盖一些问题。这P对于客户来说Q会感觉产品从质量角度来说还是acceptable的。或者说Qcool feature或者说亮点可以作ؓ质量问题的一个事后I补措施?
64. 可能羃短品的启动旉
MVMQ要q样。Y件启动时_Start-Up timeQ是客户Ҏ能好坏的第一印象?
65. 不要q于注重内在品质而忽视了W一眼的外在印象
MVMQ程序员Ҏ犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客h相反。这两方面要兼顾Q协调这些是PM的工作?
66. 你们Ҏ详细产品功能说明书做开发么Q?/strong>
MVMQ要q样。要有设计才能开发，q是必须的。设计文档，应该说清楚这个品会怎么q行Q应该采取一些讲故事的方法。设计的时候千万别ȝ节，别钻到数据库、代码等具体实现里面去，那些是后面的事情Q一步步来不能着急?
67. 开始开发和试之前每个人都仔细审阅功能设计么？
MVMQ要做。Function Spec review是用来统一思想的。而且Qreviewq以后Ş成了一致意见，来再也没有人可以说“你看Q当初我是反对q么设计的，现在吃苦头了?#8221;
68. 所有h都始l想着The Whole Image么？
MVMQ要q样。项目里面每个h虽然都只是在刉一片叶子，但每个h都应该知道自己在刉的那片叶子所在的树是怎么样子的。我反对软g蓝领Q反对过分的把Y件制造看成流水线、R间。参见第61条?
69. Dev工作的划分是单纯U向或横向的么？
MVMQ不能单U的Ҏ功能模块分，或者单U根据表现层、中间层、数据库层分。我推荐q么做：首先Ҏ功能模块分，然后每个“?#8221;都有一个Owner来Review所有h的设计和代码Q保证consistency?
70. 你们的程序员写程序设计说明文档么Q?/strong>
MVMQ要。不q我听说微Y的程序员1999q以前也不写。所以说Q写不写也不是绝对的Q偷懒有时候也是可以的。参见第56条?
71. 你在招h面试时让他写一D늨序么Q?/strong>
MVMQ要的。我最喜欢让h做字W串和链表一cȝ题目。这U题目有很多循环、判断、指针、递归{，既不偏向q于考算法，也不偏向q于考特定的API?
72. 你们有没有技术交讲座？
MVMQ要的。每一两个C拜搞一ơ内部的Tech Talk或者Chalk Talk吧。让l员之间分n技术心得，q笔花钱送到外面d训划?
73. 你们的程序员都能专注于一件事情么Q?/strong>
MVMQ要让程序员专注一件事。例如说Q一个部门有两个目?0个hQ一U方法是?0个h同时参加两个目Q每个项目上每个人都?0%旉Q另一U方法是5个h去项目AQ?个h去项目BQ每个h?00%在某一个项目上。我一定选后面一U。这个道理很多h都懂Q但很多领导实践h把属下当成可以L拆分的资源了?
74. 你们的程序员会夸大完成某工作所需要的旉么？
MVMQ会的，q是常见的，其会在目后期夸大做某个change所需要的旉Q以ơ来抵制change。解决的Ҏ是坐下来慢慢，掉E序员的逆反心理Q一起分析，q把估算旉的颗_度变小?
75. 量不要用Virtual Heads
MVMQ最好不要用Virtual Heads。Virtual heads意味着resource is not secureQshared resource会降低resource的工作效率，Ҏ增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的hQ要两个只能投入50%旉和精力的人。我是吃q亏的：7个part time的testerQ发现的Bug和干的活Q加hq不如两个full-time的。参见第73条?3条是针对E序员的Q?5条是针对Resource Manager的?
]]>