茶话三人的软件小组管理

    自从去年十月慢慢接过柯老组长的软件大旗，在嵌入式开发组中进行上层软件的开发管理已近一年。尽管软件分组三四人耳，但我一直想完善、规范化软件的开发流程。然而从最近的超声波仪应用软件开发工作上看，我们的开发管理还仅停留在CMM中第一级水平，软件开发成败依赖于个人的技术经验。加之我前日冲刺系统分析师未果，正如SM同学所言，我组的软件技术水平今年还只能继续停在软件设计师上了。呵呵，子曰，此“千秋重任”，落在下一接大旗仁兄身上也。
    近日浏览微软Windows Live China软件工程师郑子颖的《如何用正确的方法来写出质量好的软件的75条体会》，小有感触。我在管理的尝试中，竟也有几点与文章全然相似或截然相反的举措，时让人哭笑不得。子曰，刻鹄类鹜，好歹是个动物。此借文章之条目茶话我的方法，望wylhuake等业界人士理解批评，也望有助于我组软件管理水平的提高。

1. 你们的项目组使用源代码管理工具了么？
    “用”了！本来想用VSS的，但网络不好，只能代之以WinRAR，每天归档几个版本，并加之以说明，一月下来，文件夹像个书店一样。就好像人家用火箭点烟时，我还在雨天里钻木取火一样。

2. 你们的项目组使用缺陷管理系统了么？
    想学BugZilla，但暂还用传统的“即时语音系统”。在测试时我说“小利子(测试员)，有问题没？”“记下来”……

3. 你们的测试组还在用Word写测试用例么？
    我们用Excel。虽然不是原文推荐的系统，但我们的用例模板是符合Track/Browse目的要求的，只是要全手工完成。

4. 你们的项目组有没有建立一个门户网站？
    就目前来看，开发维护一个网站的工作量不亚于我组现有软件开发，因此暂借公用BBS。子曰，待我组做大做强之后，让网络组给我们做一个庞大的、美观的、多媒体的，要用ASP.NET、X3D、Silverlight……

5. 你们的项目组用了你能买到最好的工具么？
    幸运的是，我组组长去年在Microsoft Image Cup中赢得WindowCE Platform Builder一份，免去了盗版软件所带来的诸多隐患。
6. 你们的程序员工作在安静的环境里么？
    比较安静，除了到处是超声波。人均地用率高。

7. 你们的员工每个人都有一部电话么？
    暂不需要，大家济济一堂，通讯质量很高。

8. 你们每个人都知道出了问题应该找谁么？
    中国奉行“总理负责制”，谁让你干的就找谁。但开发过程中大家能发挥创造力解决问题，并不只想着要找谁。

10. 你们的项目组中所有的人都坐在一起么？
    无论主观如何，客观七位开发人员同处20平米的研究室里，至少交流方便。

11. 你们的进度表是否反映最新开发进展情况？
    实施上，我尽量做到每两周在网上公示一份稳定的Schedule，并在工作日中进行小范围变更说明。

12. 你们的工作量是先由每个人自己估算的么？
    我没有做到，Schedule上的工作量完全为主观推测，不仅压抑了各位同事，也增加潜在风险。

13. 你们的开发人员从项目一开始就加班么？
    原文说“从项目一开始就加班，只能说明项目进度不合理”。事实上项目前期我不提出同事晚上做什么。

16. 登记新缺陷时，是否写清了重现步骤？
    这对缺陷修改很重要，希望小利子测试员更上一层楼。

17. 写新代码前会把已知缺陷解决么？
    是的，这也是将软件实施分为三个阶段的一个原因。

20. 所有的缺陷都是由登记的人最后关闭的么？
    这是测试登记员的权利，不能剥夺。实施中，测试出的缺陷会在修改版本上重新测试，以判定是否被修正。(就一个测试员)

21. 你们的程序员厌恶修改老的代码么？
    现在每个人负责修改自己写的模块代码。但为了让后来的人不产生这样的感觉，请让自己的代码更体面些，这是程序员惟一的名片。

22. 你们项目组有Team Morale Activity么？
    我组参考ISO管理认证体系设置"输入评审""输出评审"和"结题评审"，每次评审通过后不仅集体去活动，还集体发红包。

27. 有人长期不Check-In代码么？
    原文建议最多二三天即Check-In。但是现在大家忙着开发，只等着测试出问题时才review。Check-In类似一种不错的Static Test。

33. 设计越简单越好
    对于一个需求不明确的软件开发项目，我尚在考虑这句话是否仍成立。

34. 尽量利用现有的产品、技术、代码
    原有代码对现期开发帮助很大。

36. 你们的项目组每个人都写Daily Report么？
    在项目紧张期还是写的。原文说“一则为了沟通，二则鞭策自己(要是游手好闲一天，自己都会不好意思写的)”。

38. 你们项目组是否至少每周全体开会一次？
    原文应该说的是软件分组的讨论会，对于3人小组还没有过。

39. 你们项目组的会议、讨论都有记录么？
    每次周例会指派记录员，将会议讨论提纲及要点整理并存档，但还缺乏会前agenda等记录。

43. 每个人都知道哪里可以找到全部的文档么？
    我组有专用FTP目录，进行重要文档的分发及存储。

44. 你做决定、做变化时，告诉大家原因了么？
    至少现在决定大部分由协议甲方提出。而日后决定要和大家讨论，至少是对同事的尊重，为了决定不被曲解的执行。

45. Stay agile and expect change
    嗯，这需要好的心理素质。事实上，甲方经常考验着我的技术及拷打着我的心理……

46. 你们有没有专职的软件测试人员？
    出于人手、项目规模考虑，暂不需要。但以后做大做强后应该这样。

47. 你们的测试有一份总的计划来规定做什么和怎么做么？
    有，这个文档叫做《测试计划》，这也回答了小利子的问题，以前我组是没有的。我组应该更加重视文档编写工作。我特意下载GB8567-88(近期新规范GB8567-2006已出台)软件文档模板，以重写技术文档。测试遵循测试计划-测试用例-测试顺序。

48. 你是先写Test Case然后再测试的么？
    是，先专心写Test Case头脑不乱，至少不会被现场测试的各种结果搞糊涂。但在测试中会根据测试缺陷灵活增加用例。

49. 你是否会为各种输入组合创建测试用例？
    不需要。抓重点，找主流。

56. 你们有单元测试么？
    有，但还不完善，现阶段横向分模块编写Test Case，纵向分时间段进行测试。

59. 产品有统一的错误处理机制和报错界面么？
    现出现用户操作错误或系统资源出现消息提示。通过错误号查找用户手册的确不错，但本相对小规模嵌入式系统还不必如此，而且嵌入式产品本不应该有"出现错误丢给用户"的现象。

60. 你们有统一的代码书写规范么？
    有，是参考众多同类规范整理而成，并与时俱进。

61. 你们的每个人都了解项目的商业意义么？
    原文说，想着自己是在为中国某某行业的信息化作先驱者就有动力了。我们的项目可是国内首创、国际领先的嵌入式产品啊。子曰，人的一生应该这样来度过的……他在毕业的时候就能够说:"我的整个生命和全部精力，都献给了世界上这壮丽的事业——为人类的嵌入式开发而奋斗。"

68. 所有人都始终想着The Whole Image么？
    通过交叉的实现任务、编写文档等，我尽量让每位开发人员都对代码有全面而深入地了解。

70. 你们的程序员写程序设计说明文档么？
    我要求每个软件开发人员都参与文档的编写工作，不仅对项目有益，至少提高了我们的文档撰写能力。

72. 你们有没有技术交流讲座？
    由于时间、条件限制，还没有。但我相信各位同事完全有技术讲解各自在开发中的技术积累及收获。

    以上即我个人针对原文大型软件项目部分管理规则，结合我组小型项目实施的若干总结及体会，《七十五条》原文请参见http://blog.joycode.com/mvm/archive/2004/05/24/22328.aspx