下面是小编为大家整理的写出质量好软件75条方法和体会（完整）,供大家参考。
写出质量好的软件的 5 75 条方法和体会
1. 你们的项目组使用源代码管理工具了么? ?
应该用。
VSS 、 CVS 、 PVCS 、 ClearCase 、 CCC/Harvest 、y FireFly 都可以。我的选择是 VSS 。
2. 你们的项目组使用缺陷管理系统了么? ?
应该用。t ClearQuest 太复杂，我的推荐是 BugZilla 。
3. 你们的测试组还在用 d Word 写测试用例么? ?
不要用 d Word 写测试用例 (Test Case) 。应该用一个专门的系统，可以是 Test Manager ，也可以是自己开发一个T ASP.NET 的小网站。主要目的是 k Track 和 和 Browse 。
4. 你们的项目组有没有建立一个门户网站? ?
要有一个门户网站，用来放 Contact Info 、 Baselined Schedule 、s News 等等。推荐 Sharepoint Portal Server X 20XX 来实现，5 15 分钟就搞定。买不起 X SPS 20XX 可以用 WSS (Windows Sharepoint Service) 。
5. 你们的项目组用了你能买到最好的工具么? ?
应该用尽量好的工具来工作。比如，应该用 T VS.NET 而不是 是 Nod tepad 来写 C# 。用 d Notepad 写程序多半只是一种炫耀。但也要考虑到经费，所以说是 “ 你能买到最好的 ” 。
6. 你们的程序员工作在安静的环境里么? ?
需要安静的环境。这一点极其重要，每个人的空间要大于某个区域。
7. 你们的员工每个人都有一部电话么? ?
需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：
“ 某某某电话 ” 。《人件》里面就强烈谴责这种做法。
8. 你们每个人都知道出了问题应该找谁么? ?
应 该知道。任何一个 e Feature 至少都应该有一个 Owner ，当然，r Owner 可以继续 h Dispatch 给其他人。
9. 你遇到过有人说 “ 我以为 …” 么? ?
要消灭 “ 我以为 ” 。
Never assume anything 。
10. 你们的项目组中所有的人都坐在一起么? ?
需要。我反对 Virtual Team ，也反对 v Dev 在美国、 Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。
11. 你们的进度表是否反映最新开发进展情况? ?
应该反映。但是，应该用 e Baseline 的方法来管理进 度表：维护一份稳定的 Schedule ，再维护一份最新更改。e Baseline 的方法也应该用于其它的 Spec 。e Baseline 是变更管理里面的一个重要手段。
12. 你们的工作量是先由每个人自己估算的么? ?
每个人都应该做出自己的估计。自下而上估算工作量，而不是自上而下分配。除非有其他原因，比如固定期限的政治任务。
13. 你们的开发人员从项目一开始就加班么? ?
不要这样。不要一开始就和疲劳做斗争。从项目一开始就加班只能说明项目进度不合理。当然，有些软件外包到日本必须每天加班，这属于剥削的范畴。
14. 你们的项目计划中 e Buffer Time 是加在每个小任务后面的么? ?
不要。e Buffer Time 加在每个小任务后面，很容易轻易的就被消耗掉。e Buffer Time 要整段的加在一个 e Milestone 或者t checkpoint 前面。
15. 值得再多花一些时间，从 95% 做到 100% 好
值得，非常值得。尤其是项目后期人累的时候，更要坚持。这将使产品产生质的变化。
16. 登记新缺陷时，是否写清了重现步骤? ?
要。这属于 v Dev 和 和 t Test 之间的沟通手段。面对面沟通需要，详细填写 s Repro Steps 也需要。
17. 写新代码前会把已知缺陷解决么? ?
要。每个人的缺陷不能超过 0 10 个或 5 15 个，否则必须先解决老的 g bug 才能继续写新代码。
18. 你们对缺陷的轻重缓急有事先的约定么? ?
必须有定义。y Severity 要分 1 1 、2 2 、3 3 ，约定好：蓝屏和t Data Lost 算 算 Sev 1 ，r Function Error 算 算 Sev 2 ，界面上的算Sev 3 。但这种约定可以根据产品质量现状适当进行调整。
19. 你们对意见不一的缺陷有三国会议么? ?
必须要有。要有一个明确的决策过程。这类似于 CCB (Change Control Board) 的概念。
20. 所有的缺陷都是由登记的人最后关闭的么? ?
g Bug 应该由 r Opener 关闭。v Dev 不能私自关闭 Bug 。
21. 你们的程序员厌恶修改老的代码么? ?
厌恶是正常的。解决方法是组织 Code Review ，单独留出时间来。P XP 也是一个方法。
22. 你们项目组有 y Team Morale Activity 么? ?
每个月都要搞一次，吃饭、唱歌、 Outing 、打球、开卡丁车等等，一定要有。不要剩这些钱。
23. 你们项目组有自己的 Loo go 么? ?
要有自己的 Logo 。至少应该有自己的 Codename 。
24. 你们的员工有印有公司 o Logo 的 的 T T- -t Shirt 么? ?
要有。能增强归属感。当然，T T- -t Shirt 要做的好看一些，最好用 0 80 支的棉来做。别没穿几次就破破烂烂的。
25. 总经理至少每月参加次项目组会议
要的。要让 r team member 觉得高层关注这个项目。
26. 你们是给每个 v Dev 开一个分支么? ?
反对。h Branch 的管理以及 e Merge 的工作量太大，而且容易出错。
27. 有人长期不 Check- -n In 代码么? ?
不可以。对大部分项目来说，最多两三天就应该 Check- -In 。
28. 在 在 Check- -n In 代码时都填写注释了么? ?
要写的，至少一两句话，比如 “ 解决了 Bug No.225” 。如果往高处拔，这也算做 “ 配置审计 ” 的一部分。
29. 有没有设定每天 Check- -n In 的最后期限? ?
要的，要明确 Check- - In Deadline 。否则会 Build Break 。
30. 你们能把所有源码一下子编译成安装文件吗? ?
要的。这是每日编译 (Daily Build) 的基础。而且必须要能够做成自动的。
31. 你们的项目组做每日编译么? ?
当然要做。有三样东西是软件项目/ / 产品开发必备的：
1. bug management; 2. source control; 3. daily build 。
32. 你们公司有没有积累一个项目风险列表? ?
要。
Risk Inventory 。否则，下个项目开始的时候，又只能拍脑袋分析 k Risk 了。
33. 设计越简单越好
越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫 scope management 。
34. 尽量 利用现有的产品、技术、代码
千万别什么东西都自己 Coding 。k BizTalk 和 和 Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的 l Control 之类的。或者尽量用XML ，而不是自己去 e Parse 一个文本文件; ; 尽量用 RegExp ，而不是自己从头操作字符串，等等等等。这就是 “ 软件复用 ”的体现。
35. 你们会隔一段时间就停下来夯实代码么? ?
要。最好一个月左右一次。传言去年年初 s Windows 组在b Stevb 的命令下停过一个月增强安全。
Btw ， “ 夯 ” 这个字念“ha ng” ，第一声。
36. 你们的项目组每个人都写 t Daily Report 么? ?
去写作。五分钟足够了。写大约 0 10 个句子，告诉你的小组我今天做了什么。一个是交流，一个是推自己( ( 我要是闲着一天就不好意思写了) ) 。
37. 你们的项目经理会发出 t Weekly Report 么? ?
是的。也是为了交流。包括目前的进度、可能存在的风险、质量状况、各项工作的进度等。
38. 你们项目组是否至少每周全体开会一次? ?
要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有 4 4 小时。包括 team meeting, spec
review meeting, bug triage meeting 。千万别大家闷头写code 。
39. 你们项目组的会议、讨论都有记录么? ?
会前发 t meeting request 和 和 agenda ，会中有人负责主持和记录，会后有人负责发 meeting minutes ，这都是g effective meeting 的要点。而且，每个会议都要形成s agreements 和 和 action items 。
40. 其他部门知道你们项目组在干什么么? ?
要发一些 h Newsflash 给整 个大组织。
Show your team’s value 。否则，当你坐在电梯里面，其他部门的人问：
“ 你们在干嘛 ” ，你回答C “ABC 项目 ” 的时候，别人全然不知，那种感觉不太好。
41. 通过 l Email 进行所有正式沟通
l Email 的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后 l Email 来确认。
42. 为项目组建立多个 Mailing Group
如果在 e AD+Exchange 里面，就建 Distribution List 。比如，我会建 ABC Project Core Team ， ABC Project Dev Team ， ABC Project All Testers ， ABC Project Extended m Team 等等。这样发起 l Email 来方便，而且能让该收到 email的人都收到、不该收到不被骚扰。
43. 每个人都知道哪里可以找到全部的文档么? ?
应该每个人都知道。这叫做知识管理 (Knowledge Management) 。最方便的就是把文档放在一个集中的，更好的方法是用 Sharepoint 。
44. 你做决定、做变化时，告诉大家原因了么? ?
要告诉大家原因。r Empower team member 的手段之一是提供足够的 information ，这是 F MSF 一开篇的几个原则之一。的确如此，y tell me why 是人之常情，y tell me why 了才能有understanding 。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能 access information/data ，而在于是不是掌握资源。
45. Stay agile and expect change
要这样。需求一定会变的，已经写好的代码 一定会被要求修改的。做好心理准备，对 e change 不要抗拒，而是 expect change 。
46. 你们有没有专职的软件测试人员? ?
要有专职测试。如果人手不够，可以 peer test ，交换了测试。千万别自己测试自己的。
47. 你们的测试有一份总的计划来规定做什么和怎么做么? ?
这就是 Test Plan 。要不要做性能测试? ? 要不要做y Usability 测试? ? 什么时候开始测试性能? ? 测试通过的标准是什么? ? 用什么手段，自动的还是手动的? ? 这些问题需要用 Test n Plan 来回答。
48. 你是先写 Tese t Case 然后再测试的么? ?
应该如此。应该先设计再编程、先 e test case 再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case 。至于先 e test case 再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。
49. 你是否会为各种输入组合创建测试用例? ?
不要，不要搞边界条件组合。当心组合爆炸。有很多e test case 工具能够自动生成各种边界条件的组合 —— 但要想清楚，你是否有时间去运行那么多 test case 。
50. 你们的程序员能看到测试用例么? ?
要。让 v Dev 看到 e Test Case 吧。我们都是为了同一个目的走到一起来的：提高质量。
51. 你们是否随便抓一些人来做易用性测试? ?
要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳 —— 臭的看久了也就不臭了，不方便的永久了也就习惯了。
52. 你对自动测试的期望正确么? ?
别期望太高。依我看，除了性能测试以外，还是暂时先忘掉 “ 自动测试 ” 吧，忘掉 r WinRunner 和 和 r LoadRunner 吧。对于国内的软件测试的现状来说，只能 “ 矫枉必须过正 ” 了。
53. 你们的性能测试是等 所有功能都开发完才做的么? ?
不能这样。性能测试不能被归到所谓的 “ 系统测试 ” 阶段。早测早改正，早死早升天。
54. 你注意到测试中的杀虫剂效应了么? ?
虫子有抗药性，g Bug 也有。发现的新 g Bug 越来越少是正常的。这时候，最好大家交换一下测试的 area ，或者用用看其他工具和手法，就又会发现一些新 g bug 了。
55. 你们项目组中有人能说出产品的当前整体质量情况么? ?
要有。当老板问起这个产品目前质量如何， Test r Lead/Manager 应该负责回答。
56. 你们有单元测试么? ?
单元测试要 有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了 —— 可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。
57. 你们的程序员是写完代码就扔过墙的么? ?
大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有 t Test Release Document 的说法，程序太烂的话，测试有权踢回去。
58. 你们 的程序中所有的函数都有输入检查么? ?
不要。虽然说做输入检查是 e write secure code 的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。
59. 产品有统一的错误处理机制和报错界面么? ?
要有。最好能有统一的 error message ，然后每个 error e message 都带一...
推荐访问:写出质量好软件75条方法和体会 质量好 写出 体会
