【IT168 分析评论】

    1. 你们的项目组使用源代码管理工具了么？

    应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是CVS.

    2. 你们的项目组使用缺陷管理系统了么？

    应该用。ClearQuest太复杂，我的推荐是BugZilla.

    3. 你们的测试组还在用Word写测试用例么？

    不要用Word写测试用例（Test Case）。使用jbuilder运行junit测试框架。

    4. 你们的项目组有没有建立一个门户网站？

    要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。

    5. 你们每个人都知道出了问题应该找谁么？

    应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。

    6. 你遇到过有人说“我以为…”么？

    要消灭“我以为”。Never assume anything.

    7. 你们的项目组中所有的人都坐在一起么？

    需要。反对Virtual Team，能坐在一起就最好坐在一起，好处多得不得了。

    8. 你们的进度表是否反映最新开发进展情况？

    应该反映。MS的project上的进度条。

    9. 你们的工作量是先由每个人自己估算的么？

    应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。

    10. 你们的开发人员从项目一开始就加班么？

    不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。

    11. 你们的项目计划中Buffer Time是加在每个小任务后面的么？

    不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。

    12. 值得再多花一些时间，从95%做到100%好值得，非常值得。

    尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。

    13. 登记新缺陷时，是否写清了重现步骤？

    要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。 所以规定了bugzilla上bug书写的格式。

    14. 你们对缺陷的轻重缓急有事先的约定么？

    必须有定义。bugzilla可以帮助我们达到这个目的。

    15. 所有的缺陷都是由登记的人最后关闭的么？

    Bug应该由BugAdmin关闭。现在由mulder负责。Dev不能私自关闭Bug.

    16. 你们的程序员厌恶修改老的代码么？

    厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。

    17. 你们项目组有自己的Logo么？

    要有自己的Logo.至少应该有自己的Codename，CVS上的model名。

    18. 有人长期不Check-In代码么？

    不可以。对大部分项目来说，最多两三天就应该Check-In.

    19. 在Check-In代码时都填写注释了么？

    要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。

    20. 你们能把所有源码一下子编译成安装文件吗？

    要的，参考realserver上的zhanhua项目。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。有三样东西是软件项目/产品开发必备的：1. bug management； 2. source control； 3. daily build.

    21. 设计越简单越好越简单越好。

    设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management.

    22. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding.我们用高级语言来开发就站在了一个很高的起点。

    23. 项目组每个人都写Weekly Report，也就是我们的工作周报。一则为了沟通，二则鞭策自己。

    24. 项目经理还需要负责发出Weekly Report，内容包括目前进度，可能的风险，质量状况，各种工作的进展等。

    25. 你们项目组是否至少每周全体开会一次？

    要。一定要开会。程序员讨厌开会。包括team meeting， spec review meeting， bug triage meeting.千万别大家闷头写code. 会中有人负责主持和记录。

    26. 其他部门知道你们项目组在干什么么？

    要发一些Newsflash给整个大组织。Show your team‘s value.否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。

    27. 通过MSN进行及时沟通，通过Email进行正式沟。

    28. 每个人都知道哪里可以找到全部的文档么？

    应该每个人都知道。通常情况下项目相关文档都放在${cvs}\{项目}\doc文件夹下。

    29. 你做决定、做变化时，告诉大家原因了么？

    要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding.中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。

    30. Stay agile and expect change 要这样。

    需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change.

    31. 你们有没有专职的软件测试人员？

    要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。

    32. 你们的程序员能看到测试用例么？

    要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。只对需要的业务写Test Case，不要Test Case满天飞，是不是都加一个。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下是好方法，过尤不及。

    33. 你们是否随便抓一些人来做易用性测试？

    要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳？？臭的看久了也就不臭了，不方便的永久了也就习惯了。

    34. 你对自动测试的期望正确么？

    别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。

    35. 你们的性能测试是等所有功能都开发完才做的么？

    不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。

    36. 你注意到测试中的杀虫剂效应了么？

    虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。

    37. 你们项目组中有人能说出产品的当前整体质量情况么？

    要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。

    38. 你们的程序员是写完代码就扔过墙的么？

    大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。

    39. 你们的程序中所有的函数都有输入检查么？

    不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。

    40. 产品有统一的错误处理机制和报错界面么？

    要有。最好能有统一的error message，也就是tomcat中声明的errorpage.

    41. 需要有统一的代码书写规范。

    42. 你们的每个人都了解项目的商业意义么？

    要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。

    43. 产品各部分的界面和操作习惯一致么？

    要这样。要让用户觉得整个程序好像是一个人写出来的那样。

    44. 尽可能缩短产品的启动时间要这样。

    软件启动时间（Start-Up time）是客户对性能好坏的第一印象。所以发布版本要带有jsp的预编译功能。

    45. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。

    46. 你们根据详细产品功能说明书做开发么？

    要这样。所以我们有了RED（需求文档）和SDD（设计文档）。

    47. 测试之前每个人都仔细审阅功能设计么？

    要做。所以除了测试计划中附带项目的简单功能说明文档，相当于简化版的用户手册。

    48. 所有人都始终想着The Whole Image么？

    要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。

    49. Dev工作的划分是单纯纵向或横向的么？

    我们现在是按功能模块划分的。

    50. 你在招人面试时让他写一段程序么？

    要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API.

    51. 你们有没有技术交流讲座？

    要的。周会时进行内部的Tech Talk或者Chalk Talk，让组员之间分享技术心得。分享是一种快乐。这方面huson就做得很好。

    52. 你们的程序员都能专注于一件事情么？

    要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂。

    53. 你们的程序员会夸大完成某项工作所需要的时间么？

    会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change.解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。