软件开发中的交流问题

        Brooks在“贵族专制、民主政治和系统设计（Aristocracy, Democracy, and System Design）”一章中，一针见血地指出了成功软件具有高度的概念一致性。“结构师难道不是新贵？……至于贵族专制统治的问题，必须回答 “是”或者“否”。就必须只能存在少数的结构师而言，答案是肯定的……”，《人月》中的体系结构更加类似于现在的需求概念，而非现在所意义的体系结构。不过，在具体的实践中，需求和体系结构依然应该由少数的人来承担。这样的观点可能会引起争议，但就个人观点而言，软件行业实际上是“精英行业”。高素质、具有丰富经验的需求分析人员、结构师往往是软件企业的核心骨干人员，相应的一般编程人员相对的流动性会大一些。
        从个人发展的角度，安安静静地作为一个螺丝钉仿佛不是这个时代精神。这个问题同企业与人之间的关系一样，很难一言以蔽之。就具体的项目操作，理想情况是程序员较少地参加前期分析工作，由有经验的同仁来负责，给出具有框架代码程度的需求和框架产物。
        在较早的项目中，有的一般编程人员不安于编码实现，过早接触于一些PM性质工作，以及项目压力等其他因素，造成了代码质量不高，使得框架的重用程度降低。而在另外公司的一个项目中，由于企业的文化，同事们严格按照分工进行开发，提高了质量。后者看似少了机会，但从长远的角度看，大家对设计的了解更加透彻，对流程的理解更加深刻，为以后的发展打下了基础。
        同样在这一章节中，Brooks提出了“在等待时，实现人员应该做什么？”的问题。他认为“首先，必须设定良好定义的时间和空间目标，……同时，在物理实现的级别，也有很多可以着手的工作。”实际项目中，早期的投入往往人员较少，一般15人月左右的项目，初期就2～3人，这其中包括了需求分析、设计人员，以及主程序员。主程序员会对系统有初步的了解，对系统开发采用的技术、工具、开发技巧进行研究，同时同PM一同负责搭建软件工程环境和软件开发的环境。这样的安排，出现的一个问题是编程人员与分析设计人员的沟通。它需要大家通畅、自由的交流，经可能对开发达成共识，减少信息的丢失。
项目交流的方法，Brooks就OS360开发经验，在“贯彻执行（Passing the Word）”一章中，进行了具体的讲解。如，会议与大会、多重实现、电话日志等。就小型项目而言，如果不考虑异地开发的情况，较正式的组内会议可以安排在一周一次，即周例会的形式。另外，在里程碑之处安排评审会议，以对开发的进展、对需求的实现以及项目计划进行调整和修正。而对于异地开发，或者用户不在本地的情形，则建议采用电话会议等形式，效果虽然不如本地开发好，不过有聊胜于无。 “为什么巴比伦塔会失败？（Why Did the Tower of Babel Fail?）”又对软件开发中的交流问题进行了强调，指出了文档是沟通的一种重要方式。后续的 “提纲挈领（The Documentary Hypothesis）”则用类比的方式阐述了如何定义软件项目的文档集合，“另外一面（The other face）”讨论了程序文档的一些形式。这些观点对实际工作也具有指导意义，相应的Rational Suite中Requisite Pro工具使用参考中，推荐了软件项目的参考文档集合。在C++和Domino若干项目的实践中，发现最小的文档集合包括需求文档（Software Requirement Specification）、项目计划（Software Development Plan）、框架设计、设计元素说明。其中，项目计划不仅仅是进度，而是从软件的配置管理、生命周期、资源分配、风险分析、培训等方面进行描述，这部分的内容往往不局限于单个项目，而是在同一种类型的项目中具有共性。因此，可以在不同项目中共享。
        总而言之，Brooks对文档的建议是“项目经理聪明的做法都是：立刻正式生成若干文档作为自己的数据基础，哪怕这些迷你文档非常简单。接着，……”以及“如果一开始就认识到它们的普遍性和重要性，那么就可以将文档作为工具友好地利用起来，而不会让它成为令人厌烦的繁重任务。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己的方向。”
本文来源【学网】网站链接是http://www.xue5.com