你们的项目组使用源代码管理工具了么？
采用ClearCase进行源代码管理，同时启用开发，测试，集成三个分支，对于Bug分支根据版本实际情况确认是否启用。
你们的项目组使用缺陷管理系统了么？
使用ClearQuest管理缺陷和变更
你们的测试组还在用Word写测试用例么？
采用TestManager写测试用例和管理测试用例，必要配合Excel进行。
你们的项目组有没有建立一个门户网站？
项目有专门的讨论工作室。
你们的项目组用了你能买到最好的工具么？
能够买到。主要是VS.Net和PL/SQl Developer.其它辅助工具全部用开源工具。如打包采用Nant，反翻译采用Reflector，单元测试采用Nunit.
你们的程序员工作在安静的环境里么？
是的，有独立安静空间。
你们的员工每个人都有一部电话么？
一般两人一部电话，还可以通过RTX进行沟通。
你们每个人都知道出了问题应该找谁么？
知道
你遇到过有人说“我以为…”么？
有时候会遇到，但情况不多。
你们的项目组中所有的人都坐在一起么？
没有。全部座来分开，通过RTX即时通讯，邮件，电话进行沟通。
你们的进度表是否反映最新开发进展情况？
有及时准确的进度表，但不是每个项目成员都很容易看到。进度表有专门的基线和里程碑的定义。
你们的工作量是先由每个人自己估算的么？
不是开发人员自己估算，是有项目的估算小组进行估算。估算时候会适当考虑个体差异。
你们的开发人员从项目一开始就加班么？
基本不会。
你们的项目计划中Buffer Time是加在每个小任务后面的么？
不是，总体进度有5-10%的余量。
值得再多花一些时间，从95%做到100%好值得，非常值得。
尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
登记新缺陷时，是否写清了重现步骤？
是的，有明确重现步骤描述，并配合屏幕截图。
写新代码前会把已知缺陷解决么？
要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
你们对缺陷的轻重缓急有事先的约定么？
缺陷有验证性和解决时限的明确定义。
你们对意见不一的缺陷有三国会议么？
有，意见不一致的时候由项目的CCB进行统一讨论和决策。
所有的缺陷都是由登记的人最后关闭的么？
是的，由BUG提交的测试人员来验证关闭。
你们的程序员厌恶修改老的代码么？
厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。
你们项目组有Team Morale Activity么？
有，一般一两个月一次，一般在项目版本发布后。
你们项目组有自己的Logo么？
有系统的Logo,项目组没有Logo.
你们的员工有印有公司Logo的T-Shirt么？
没有。
总经理至少每月参加次项目组会议要的。
有。一般在需要参加的时候参加。
你们是给每个Dev开一个分支么？
没有，只有一个共有的开发分支，容易管理些。
有人长期不Check-In代码么？
不会，最长不会超过1周，一般要求是当天修改只要能够编译通过都要Check In.
在Check-In代码时都填写注释了么？
有，Check-In的时候系统会自动对应到相关的活动或变更。
有没有设定每天Check-In的最后期限？
不是特别明确，需要改进。
你们能把所有源码一下子编译成安装文件吗？
是的，通过Nant自动编译和打包，所以项目很容易进行Daily Build.
你们的项目组做每日编译么？
跟测试策略有关系，当项目计划选择的策略是每日构建时候就必须进行。
你们公司有没有积累一个项目风险列表？
有，并在每周例会上对分析进行分析。
设计越简单越好越简单越好。
设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。
尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。
你们会隔一段时间就停下来夯实代码么？
没有，没有专门的这种时间。
你们的项目组每个人都写Daily Report么？
没有，当要求项目成员都有工作日志记录。成员每天工作会反馈到Project的工作日志上面。
你们的项目经理会发出Weekly Report么？
有项目周报。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。
你们项目组是否至少每周全体开会一次？
每周项目都召开项目周例会。
你们项目组的会议、讨论都有记录么？
有，有专门的会议记录人员。
其他部门知道你们项目组在干什么么？
要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。
通过Email进行所有正式沟通
是的。Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。
为项目组建立多个Mailing Group
邮件只有一个Group,但RTX及时通讯有多个Group.
每个人都知道哪里可以找到全部的文档么？
知道。应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。
你做决定、做变化时，告诉大家原因了么？
要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。
Stay agile and expect change 要这样。
需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。
你们有没有专职的软件测试人员？
项目有专门得测试人员，一般配置比例在1比6个左右开发人员。
你们的测试有一份总的计划来规定做什么和怎么做么？这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。
有专门得测试计划。
你是先写Test Case然后再测试的么？
有专门得测试用例，要求测试必须根据测试用例进行。
你是否会为各种输入组合创建测试用例？
这点项目组强调了测试数据得准备和路径分支得分析，这块做得不是很好待改进。
你们的程序员能看到测试用例么？
可以，但开发人员不会特别去关注这些测试用例，一般根据软件需求自测。
你们是否随便抓一些人来做易用性测试？
没有，需求开发阶段已经有标准得DEMO
你对自动测试的期望正确么？
不期望自动测试，LoadRunner只用来录制简单得冒烟测试脚本。
你们的性能测试是等所有功能都开发完才做的么？
是的。需要改进。
你注意到测试中的杀虫剂效应了么？
虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。
你们项目组中有人能说出产品的当前整体质量情况么？
要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。
你们有单元测试么？
有单元测试，但和自测，黑盒测试界限不明确。项目成员自测关注重点放到黑盒测试上了而忽略了百盒的分支，条件和代码的覆盖。
你们的程序员是写完代码就扔过墙的么？
不会必须自测通过。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。
你们的程序中所有的函数都有输入检查么？
不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。
产品有统一的错误处理机制和报错界面么？
有，在项目中已经复用。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。
你们有统一的代码书写规范么？
有专门的编码规范文档
你们的每个人都了解项目的商业意义么？
要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。
产品各部分的界面和操作习惯一致么？
基本一直，还在不断改进中。
有可以作为宣传亮点的Cool Feature么？
有。工作流，权限模型，多层分布式架构，队列使用，自我开发的数据访问组件都是可以宣传的亮点。
尽可能缩短产品的启动时间要这样。
软件启动时间（Start-Up time）是客户对性能好坏的第一印象。
不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。
你们根据详细产品功能说明书做开发么？
要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。
开始开发和测试之前每个人都仔细审阅功能设计么？
有专门的同行评审和多人复审。
Dev工作的划分是单纯纵向或横向的么？
不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。
你们的程序员写程序设计说明文档么？
有设计文档输出，但用处不大，更多设计内容直接体现在代码注释中。
你在招人面试时让他写一段程序么？
没有，一般以问为主。
你们有没有技术交流讲座？
有，每个项目版本都有1到2次技术交流，培训和讨论。
你们的程序员都能专注于一件事情么？
要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。
你们的程序员会夸大完成某项工作所需要的时间么？
会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。
比较少跨大的情况，因为跨大必须要说明明确的理由。
75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。
Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。