实际的项目管理经验，很是有价值
（转自http://blog.joycode.com/mvm/posts/22328.aspx）
1. 大家的项目组使用源代码管理工具了么？
应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly均可以。个人选择是VSS。程序员
2. 大家的项目组使用缺陷管理系统了么？
应该用。ClearQuest太复杂，个人推荐是BugZilla。
3. 大家的测试组还在用Word写测试用例么？
不要用Word写测试用例（Test Case）。应该用一个专门的系统，能够是Test Manager，也
能够是本身开发一个ASP.NET的小网站。主要目的是Track和Browse。
4. 大家的项目组有没有创建一个门户网站？
要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharep
oint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003能够用WSS (Windows
Sharepoint Service)。
5. 大家的项目组用了你能买到最好的工具么？
应该用尽可能好的工具来工做。好比，应该用VS.NET而不是Notepad来写C#。用Notepad写程
序多半只是一种炫耀。但也要考虑到经费，因此说是“你能买到最好的”。
6. 大家的程序员工做在安静的环境里么？
须要安静环境。这点极端重要，并且要保证每一个人的空间大于必定面积。
7. 大家的员工每一个人都有一部电话么？
须要每人一部电话。并且电话最好是带留言功能的。固然，上这么一套带留言电话系统开
销不小。不过至少每人一部电话要有，千万别搞得常常有人站起来喊：“某某某电话”。
《人件》里面就强烈谴责这种作法。
8. 大家每一个人都知道出了问题应该找谁么？
应该知道。任何一个Feature至少都应该有一个Owner，固然，Owner能够继续Dispatch给其
他人。
9. 你遇到过有人说“我觉得…”么？
要消灭“我觉得”。Never assume anything。
10. 大家的项目组中全部的人都坐在一块儿么？
须要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一块儿就
最好坐在一块儿，好处多得不得了。
11. 大家的进度表是否反映最新开发进展状况？
应该反映。可是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维
护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变动管理里面的一
个重要手段。
12. 大家的工做量是先由每一个人本身估算的么？
应该让每一个人本身估算。要从下而上估算工做量，而不是从上往下分派。除非有其余缘由
，好比政治任务工期固定等。
13. 大家的开发人员从项目一开始就加班么？
不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当
然，一些对日软件外包必须每天加班，那属于剥削的范畴。
14. 大家的项目计划中Buffer Time是加在每一个小任务后面的么？
不要。Buffer Time加在每一个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段
的加在一个Milestone或者checkpoint前面。
15. 值得再多花一些时间，从95%作到100%好
值得，很是值得。尤为当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。面试
16. 登记新缺陷时，是否写清了重现步骤？
要。这属于Dev和Test之间的沟通手段。面对面沟通须要，详细填写Repro Steps也须要。算法
17. 写新代码前会把已知缺陷解决么？
要。每一个人的缺陷不能超过10个或15个，不然必须先解决老的bug才能继续写新代码。
18. 大家对缺陷的轻重缓急有事先的约定么？
必须有定义。Severity要分一、二、3，约定好：蓝屏和Data Lost算Sev 1，Function Erro
r算Sev 2，界面上的算Sev 3。但这种约定能够根据产品质量现状适当进行调整。
19. 大家对意见不一的缺陷有三国会议么？
必需要有。要有一个明确的决策过程。这相似于CCB (Change Control Board)的概念。数据库
20. 全部的缺陷都是由登记的人最后关闭的么？
Bug应该由Opener关闭。Dev不能私自关闭Bug。
21. 大家的程序员厌恶修改老的代码么？
厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。
22. 大家项目组有Team Morale Activity么？
每月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，必定要有。不要剩这些
钱。
23. 大家项目组有本身的Logo么？
要有本身的Logo。至少应该有本身的Codename。
24. 大家的员工有印有公司Logo的T-Shirt么？
要有。能加强归属感。固然，T-Shirt要作的好看一些，最好用80支的棉来作。别没穿几回
就破破烂烂的。
25. 总经理至少每个月参加次项目组会议
要的。要让team member以为高层关注这个项目。
26. 大家是给每一个Dev开一个分支么？
反对。Branch的管理以及Merge的工做量太大，并且容易出错。
27. 有人长期不Check-In代码么？
不能够。对大部分项目来讲，最多两三天就应该Check-In。
28. 在Check-In代码时都填写注释了么？
要写的，至少一两句话，好比“解决了Bug No.225”。若是往高处拔，这也算作“配置审
计”的一部分。
29. 有没有设定天天Check-In的最后期限？
要的，要明确Check-In Deadline。不然会Build Break。
30. 大家能把全部源码一会儿编译成安装文件吗？
要的。这是每日编译（Daily Build）的基础。并且必需要可以作成自动的。
31. 大家的项目组作每日编译么？
固然要作。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source co
ntrol; 3. daily build。
32. 大家公司有没有积累一个项目风险列表？
要。Risk Inventory。不然，下个项目开始的时候，又只能拍脑壳分析Risk了。
33. 设计越简单越好
越简单越好。设计时候多一句话，未来可能就带来无穷无尽的烦恼。应该从一开始就勇敢
的砍。这叫scope management。
34. 尽可能利用现有的产品、技术、代码
千万别什么东西都本身Coding。BizTalk和Sharepoint就是最好的例子，有这两个做为基础
，能够把起点提升不少。或者能够尽可能多用现成的Control之类的。或者尽可能用XML，而不
是本身去Parse一个文本文件；尽可能用RegExp，而不是本身从头操做字符串，等等等等。这
就是“软件复用”的体现。
35. 大家会隔一段时间就停下来夯实代码么？
要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月加强安全
。Btw，“夯”这个字念“hang”，第一声。
36. 大家的项目组每一个人都写Daily Report么？
要写。五分钟就够了，写10句话左右，告诉本身小组的人今天我干了什么。一则为了沟通
，二则鞭策本身（要是不务正业一天，本身都会很差意思写的）。
37. 大家的项目经理会发出Weekly Report么？
要。也是为了沟通。内容包括目前进度，可能的风险，质量情况，各类工做的进展等。编程
38. 大家项目组是否至少每周全体开会一次？
要。必定要开会。程序员讨厌开会，但每一个礼拜开会时间加起来至少应该有4小时。包括t
eam meeting, spec review meeting, bug triage meeting。千万别你们闷头写code。安全
39. 大家项目组的会议、讨论都有记录么？
会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting m
inutes，这都是effective meeting的要点。并且，每一个会议都要造成agreements和actio
n items。
40. 其余部门知道大家项目组在干什么么？
要发一些Newsflash给整个大组织。Show your team’s value。不然，当你坐在电梯里面
，其余部门的人问：“大家在干吗”，你回答“ABC项目”的时候，别人全然不知，那种感
觉不太好。
41. 经过Email进行全部正式沟通
Email的好处是省得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，而后E
mail来确认。
42. 为项目组创建多个Mailing Group
若是在AD+Exchange里面，就建Distribution List。好比，我会建ABC Project Core Tea
m，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等
。这样发起Email来方便，并且能让该收到email的人都收到、不应收到不被骚扰。
43. 每一个人都知道哪里能够找到所有的文档么？
应该每一个人都知道。这叫作知识管理（Knowledge Management）。最方便的就是把文档放
在一个集中的File Share，更好的方法是用Sharepoint。
44. 你作决定、作变化时，告诉你们缘由了么？
要告诉你们缘由。Empower team member的手段之一是提供足够的information，这是MSF一
开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有unders
tanding。中国人作事喜欢搞限制，限制信息，彷佛可以看到某一份文件的人就是有身份的
人。大错特错。权威、权力，不在因而不是能access information/data，而在因而不是掌
握资源。
45. Stay agile and expect change
要这样。需求必定会变的，已经写好的代码必定会被要求修改的。作好心理准备，对chan
ge不要抗拒，而是expect change。
46. 大家有没有专职的软件测试人员？
要有专职测试。若是人手不够，能够peer test，交换了测试。千万别本身测试本身的。函数
47. 大家的测试有一份总的计划来规定作什么和怎么作么？
这就是Test Plan。要不要作性能测试？要不要作Usability测试？何时开始测试性能
？测试经过的标准是什么？用什么手段，自动的仍是手动的？这些问题须要用Test Plan来
回答。
48. 你是先写Test Case而后再测试的么？
应该如此。应该先设计再编程、先test case再测试。固然，事情是灵活的。我有时候在作
第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，由于不习惯，太
麻烦，至于别人推荐，那试试看也无妨。
49. 你是否会为各类输入组合建立测试用例？
不要，不要搞边界条件组合。小心组合爆炸。有不少test case工具可以自动生成各类边界
条件的组合——但要想清楚，你是否有时间去运行那么多test case。
50. 大家的程序员能看到测试用例么？
要。让Dev看到Test Case吧。咱们都是为了同一个目的走到一块儿来的：提升质量。
51. 大家是否随便抓一些人来作易用性测试？
要这么作。本身看本身写的程序界面，怎么看都是顺眼的。这叫作审美疲劳——臭的看久
了也就不臭了，不方便的永久了也就习惯了。
52. 你对自动测试的指望正确么？
别指望过高。依我看，除了性能测试之外，仍是暂时先忘掉“自动测试”吧，忘掉WinRun
ner和LoadRunner吧。对于国内的软件测试的现状来讲，只能“矫枉必须过正”了。
53. 大家的性能测试是等全部功能都开发完才作的么？
不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。工具
54. 你注意到测试中的杀虫剂效应了么？
虫子有抗药性，Bug也有。发现的新Bug愈来愈少是正常的。这时候，最好你们交换一下测
试的area，或者用用看其余工具和手法，就又会发现一些新bug了。
55. 大家项目组中有人能说出产品的当前总体质量状况么？
要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。
56. 大家有单元测试么？
单元测试要有的。不过没有单元测试也不是不能够，我作过没有单元测试的项目，也作成
功了——多是侥幸，多是你们都是熟手的关系。仍是那句话，软件工程是很是实践、
很是工程、很是灵活的一套方法，某些方法在某些状况下会比另外一些方法好，反之亦然。post
57. 大家的程序员是写完代码就扔过墙的么？
大忌。写好一块程序之后，即使不作单元测试，也应该本身先跑一跑。虽然有了专门的测
试人员，作开发的人也不能够一点测试都不作。微软还有Test Release Document的说法，
程序太烂的话，测试有权踢回去。
58. 大家的程序中全部的函数都有输入检查么？
不要。虽说作输入检查是write secure code的要点，但不要作太多的输入检查，有些内
部函数之间的参数传递就没必要检查输入了，省点功夫。一样的道理，未必要给全部的函数
都写注释。写一部分主要的就够了。
59. 产品有统一的错误处理机制和报错界面么？
要有。最好能有统一的error message，而后每一个error message都带一个error number。
这样，用户能够本身根据error number到user manual里面去看看错误的具体描述和可能原
因，就像SQL Server的错误那样。一样，ASP.NET也要有统一的Exception处理。能够参考
有关的Application Block。
60. 大家有统一的代码书写规范么？
要有。Code Convention不少，搞一份来发给你们就能够了。固然，要是有FxCop这种工具
来检查代码就更好了。
61. 大家的每一个人都了解项目的商业意义么？
要。这是Vision的意思。别把项目只当成工做。有时候要想着本身是在为中国某某行业的
信息化做先驱者，或者时不时的告诉team member，这个项目可以为某某某国家部门每一年节
省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是能够有个崇高的目标的
。
62. 产品各部分的界面和操做习惯一致么？
要这样。要让用户以为整个程序好像是一我的写出来的那样。
63. 有能够做为宣传亮点的Cool Feature么？
要。这是加强团队凝聚力、信心的。并且，“一俊遮百丑”，有亮点就能够掩盖一些问题
。这样，对于客户来讲，会感受产品从质量角度来讲仍是acceptable的。或者说，cool f
eature或者说亮点能够做为质量问题的一个过后弥补措施。
64. 尽量缩短产品的启动时间
要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。
65. 不要过于注重内在品质而忽视了第一眼的外在印象
程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感觉。而高层经
理、客户正相反。这两方面要兼顾，协调这些是PM的工做。
66. 大家根据详细产品功能说明书作开发么？
要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，
应该采起一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现
里面去，那些是后面的事情，一步步来不能着急。
67. 开始开发和测试以前每一个人都仔细审阅功能设计么？
要作。Function Spec review是用来统一思想的。并且，review过之后造成了一致意见，
未来再也没有人能够说“你看，当初我就是反对这么设计的，如今吃苦头了吧”
68. 全部人都始终想着The Whole Image么？
要这样。项目里面每一个人虽然都只是在制造一片叶子，但每一个人都应该知道本身在制造的
那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过度的把软件制造当作流水线、
车间。参见第61条。
69. Dev工做的划分是单纯纵向或横向的么？
不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么作
：首先根据功能模块分，而后每一个“层”都有一个Owner来Review全部人的设计和代码，保
证consistency。
70. 大家的程序员写程序设计说明文档么？
要。不过我据说微软的程序员1999年之前也不写。因此说，写不写也不是绝对的，偷懒有
时候也是能够的。参见第56条。
71. 你在招人面试时让他写一段程序么？
要的。我最喜欢让人作字符串和链表一类的题目。这种题目有不少循环、判断、指针、递
归等，既不偏向过于考算法，也不偏向过于考特定的API。
72. 大家有没有技术交流讲座？
要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得
，这笔花钱送到外面去培训划算。
73. 大家的程序员都能专一于一件事情么？
要让程序员专一一件事。例如说，一个部门有两个项目和10我的，一种方法是让10我的同
时参加两个项目，每一个项目上每一个人都花50%时间；另外一种方法是5我的去项目A，5我的去
项目B，每一个人都100%在某一个项目上。我必定选后面一种。这个道理不少人都懂，但不少
领导实践起来就把属下当成能够任意拆分的资源了。
74. 大家的程序员会夸大完成某项工做所须要的时间么？
会的，这是常见的，尤为会在项目后期夸大作某个change所须要的时间，以次来抵制chan
ge。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一块儿分析，并把估算时间的颗
粒度变小。
75. 尽可能不要用Virtual Heads
最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared res
ource会下降resource的工做效率，容易增长出错的机会，会让一心二用的人没有太多时间
去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精
力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个
full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。性能