小型的C++项目团队组建-Adams Wang

 “人月神话（The Mythical Man-Month）”提出了这样的论断，（盲目地）“向进度落后的项目中增加人手，只会使进度更加落后。”这中间还涉及到如何组建你的开发团队，或者面向一个软件开发任务时，如何规划开发计划、划分任务项、分配资源。紧接着，在“外科手术队伍（The Surgical Team）”中，Brooks提出了用外科医生＋副手来组织团队，保证设计思路的完整性。其中，还提到了采用“语言专家”来帮助疑难问题的解决；安排工具维护人员，也就是现在意义上的系统管理员来保证系统开发、管理环境的有效运行；而其他人来解决一些文件管理等工作。

在一个小型的C++项目操作中，对上述方法的实践中
- 由PM和结构师一用一备来分析需求、进行框架设计，确保整个项目的概念完整性。分析设计的产出物达到框架示意代码的级别，这部分框架代码主要是帮助团队对项目开发的理解，不存在于正式的代码中；

- 安排开发人员负责配置管理。这里的配置管理不仅仅局限于文档、软件产物的管理，而是在使用框架驱动的迭代开发时，需要对框架和各个组件不断地进行编译、整合、检查记录Bug。这位开发人员往往是团队中的主程序员（Chief Programmer），对各种开发方法、方法学有着一定的经验；

-安排人员对工具进行预研，如了解STL类库等。该角色具体的人员在不同的阶段会进行调整。因为，他/她需要对语言、类库、开发技巧进行学习研究，往往会占用大量的工作时间。在实际情况中，前期是有主程序员承担；后期，由PM承担；

这样的安排的确能解决产品思路的一致性，在很大程度上提高生产力和产品质量。不过，它要求：

1. PM和结构师有非常良好的沟通，包括分析方法的风格、对开发的理解等，他们之间的不一致直接会导致项目的开发方向；

2. 对分析的结果，进行良好的贯彻。软件行业具有年青、有朝气的特点，同时也有些浮躁。有的开发人员好高骛远，对代码质量重视不够，影响框架的稳定性。

这样安排的风险在于“外科医生”的工作负荷可能过大，尤其在国内的公司中，他们往往同时兼任PM和系统分析的工作。同样，相应的绩效考核机制也不容易具备。

另外一个风险在于“一用一备”的安排，在“为什么巴比伦塔会失败？（Why Did the Tower of Babel Fail?）”的“大型编程项目的组织架构”中详尽地论述。不过，在国内的开发环境下，似乎很难实行。比较折中的方案，是对某种类型的项目，包括业务类型、开发方法、语言类型，建立开发和管理指南，从而保证概念完整性。在后续所经历的一系列Domino类型的项目开发中，进行了尝试，相应在实践中遇到的问题在于如何贯彻实施。

上述方法潜在的一个声音是“软件重用性”。提到重用性，可能大家脑海里马上想到的是对象、类库等。不错，面向对象的方法、商业组件（类）库的确极大地提高了软件重用性。但对于中小型企业，甚至于一个成熟的开发团队，积累自己大粒度的框架是提高软件生产力的一个重要措施。设计模式中一些模式，如Visitor、Observe本身就可以作为软件框架来使用。以设计模式为基础，根据开发类型积累特定业务领域的框架是完全可行的最佳实践。而Brooks一再强调“概念完整性（Concept Integrity）”，以及在“外科手术队伍”中推荐由外科医生来负责系统的开发，保证了产生的系统是少数人思维的结果，它们往往简捷、纯粹，没有众多人的影响，经过了项目的洗礼之后，往往能成为重用的框架。相反，在分析设计阶段，安排许多开发人员来共同开发，尽管同样完成了项目，但会相应导致“画蛇添足（The Second-System Effect）”特征——“它极富有创造性，极端复杂，非常高效。但不知为什么，同时也感觉到粗糙、浪费、不优雅，以及让人觉得必定存在某种更好的方法”，而重用的框架往往是捕捉到了问题的根本，用简单优美的方案，解决80％的问题。

http://www.mmmbook.com/review/pratice.htm