04人月神话阅读笔记之二

《人月神话》是大学刚开始就很熟悉的一本书，当时被奉为软件工程的圣书，似乎都要在书架上摆上它才能表明软件工程学生的身份。时至今日我再读它，因为有了之前参与系统的开发的经验，很多的内容都通过记忆得到了验证，读来与大一时的“虽然不懂你在讲什么但好像很有道理” 的体会有了明显的不同。选择一些感触较深的章节写一些理解和体会。

人月神话

软件开发中最难掌握的莫过于过程管理，最开始的课程项目规模都很小，自己小作坊式的开发方式似乎也能很好完成要求，然而越到后来，项目规模越大，参与的人越多，开发进度的估计似乎成了一门玄学，每个人的能力不同，擅长的方面不同，开发中可能遇到的问题也不可预测，往往都是快到截止日期时集体赶工。我实习期间最深刻的印象正是来自于开发团队在每一个迭代开始前的计划方式。我们做完上一迭代的回顾后会讨论上一次的任务划分是否合理，时间分配是否过少或过多，然后根据产品经理对这一迭代的模块划分每个人独立进行开发测试的消耗估计。通过团队成员的集体商议确定模块需要的花费后，去除与上一迭代相比过多消耗的模块，结束后会写下来贴在白板上由每个人自由领取任务。这个过程是开发团队结合了长时间的经验积累和研究人员的研究成果所确定的方式，但是在执行的过程中仍然在不断探索改进以适应团队现阶段的开发能力。书中说“人月”是一个神话，是因为时间精力的消耗与独立投入的人力、时间不成线性相关，所以每一次的项目估算和调整都需要谨慎为之，落后太多的项目往往会滑向失败的深渊。

外科手术队伍

软件开发的团队选择往往是一个难题。在课程实践的过程中，大家往往渴望抱到大牛的大腿，因为经验丰富的程序员能起到以一敌十的效果，当一个团队中每个人的能力都很强那么这个队伍几乎就成了神话般的精英小队。对于大型的项目，小而美的团队往往有些力不从心，精英也不可能大量集中到一个团队中，这时外科手术团队的方式就值得借鉴。书中的对应是一名首席程序员相当于外科医生，一个经验相对较少的人员充当副手，一个管理员负责行政事务的决策，一个编辑用于生成文档，两个文秘使得文件与项目协作一致，一个程序职员用于维护技术记录，一个工具维护人员，一个测试人员，以及一个语言专家。这样的开发团队人员平等但是各司其职，保证了团队的有序运行。对于大型的项目，就需要在人员安排上使用分解的思路，由架构师负责整体设计，系统实现则由各个小团队协作完成。

贵族专制、民主政治和系统设计

一套大型的软件系统往往要持续开发运营，这就要求开发团队保持系统的概念一致性。世界需要秩序，就是因为每个人想法不一，产生矛盾时无法统一实现整体利益。在系统的开发中，人与人之间的思维差异是客观存在的，概念的完整性只能少数人员来实现，对于大型的项目，合理的团队组建方式就很重要。如同上一章所述，一个团队概念的提出需要架构师来实现，此时专制与民主的平衡就至关重要，