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等等。推荐Sharepoint 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要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算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 control； 3. daily build.
32. 你们公司有没有积累⼀个项⽬风险列表？
  要。Risk Inventory.否则，下个项⽬开始的时候，⼜只能拍脑袋分析Risk了。
  33. 设计越简单越好越简单越好。
设计时候多⼀句话，将来可能就带来⽆穷⽆尽的烦恼。应该从⼀开始就勇敢的砍。这叫scope managepeer
ment. 34. 尽量利⽤现有的产品、技术、代码千万别什么东西都⾃⼰Coding.BizTalk和Sharepoint就是的例⼦，有这两个作为基础，可以把起点提⾼很多。或者可以尽量多⽤现成的Control之类的。或者尽量⽤XML，⽽不是⾃⼰去Parse⼀个⽂本⽂件；尽量⽤RegExp，⽽不是⾃⼰从头操作字符串，等等等等。这就是“软件复⽤”的体现。
  35. 你们会隔⼀段时间就停下来夯实代码么？
  要。⼀个⽉左右⼀次。传⾔去年年初Windows组在Stevb的命令下停过⼀个⽉增强安全。Btw，“夯”这个字念“hang”，第⼀声。
  36. 你们的项⽬组每个⼈都写Daily Report么？
  要写。五分钟就够了，写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项⽬”的时候，别⼈全然不知，那种感觉不太好。
  41. 通过Email进⾏所有正式沟通Email的好处是免得抵赖。但也要避免矫枉过正，的⽅法是先⽤电话和当⾯说，然后Email来确认。
  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的⼈都收到、不该收到不被骚扰。
  43. 每个⼈都知道哪⾥可以到全部的⽂档么？
  应该每个⼈都知道。这叫做知识管理（Knowledge Management）。最⽅便的就是把⽂档放在⼀个集中的File Share，更好的⽅法是⽤Sharepoint. 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，交换了测试。千万别⾃⼰测试⾃⼰的。
  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. 你对⾃动测试的期望正确么？
  别期望太⾼。依我看，除了性能测试以外，还是暂时先忘掉“⾃动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。
  53. 你们的性能测试是等所有功能都开发完才做的么？
  不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。
  54. 你注意到测试中的杀⾍剂效应了么？
  ⾍⼦有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，⼤家交换⼀下测试的area，或者⽤⽤看其他⼯具和⼿法，就⼜会发现⼀些新bug了。
  55. 你们项⽬组中有⼈能说出产品的当前整体质量情况么？
  要有。当⽼板问起这个产品⽬前质量如何，Test Lead/Manager应该负责回答。
  56. 你们有单元测试么？
  单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项⽬，也做成功了——可能是侥幸，可能是⼤家都是熟⼿的关系。还是那句话，软件⼯程是⾮常实践、⾮常⼯程、⾮常灵活的⼀套⽅法，某些⽅法在某些情况下会⽐另⼀些⽅法好，反之亦然。
  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 feature或者说亮点可以作为质量问题的⼀个事后弥补措施。
  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所需要的时间，以次来抵制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的。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。