第二十八章 管理构建
鼓励良好的编码实践
- 给项目的每一部分分派两个人；
- 逐行复查代码；
- 要求代码签名；
- 安排一些好的代码示例工人参考；
- 强调代码是共有财产；
- 奖励好的代码；
- 所给与的奖励应该是程序员想要的；
- 只有非常出色的代码才应得到奖励；
- 一份简单的标准。
配置管理
什么是配置管理
配置管理是“系统化地定义项目工作和处理变化，以使项目一直保持其完整性”的实践活动。
需求变更和设计变更
- 遵循某种系统化的变更控制手续；
- 成组地处理变更请求；
- 评估每项变更的成本；
- 提防大量的变更请求；
- 成立变更控制委员会或者类似机构；
- 警惕官僚主义，但也不要因为害怕官僚注意而排斥有效的变更控制。
软件代码的变更
- 版本控制软件；
- 被人正在修改某一文件的同时，你修改这个文件不会和他发生冲突；
- 你能方便地将你机器上的全部项目文件的复本更新到当前版本，通常这只需要执行一条简单的命令；
- 你可以回溯到任何文件的任意版本，只要它曾经被check in到版本控制系统中；
- 你可以获得一份对任何文件的任意版本所做的更改的清单；
- 你无需担心个人文件备份，因为版本控制提供了安全保障。
核对表：配置管理
概要
工具
备份
评估构建进度表
评估的方法
你可以采取以下几种方法来评估项目的规模和完成它所需要的工作量：
- 使用评估软件；
- 使用算法方法，如Cocomo Ⅱ；
- 聘请外界的评估专家来评估有关项目；
- 为评估举行排练会议；
- 评估项目的每一个部分，然后把它们加起来；
- 参考以往的项目经验；
- 保留以往项目的评估，查看其准确度。用它来调整新的评估。
下面是一套评估项目的好方法：
- 建立目标；
- 为评估留出时间，并且做出计划；
- 清楚地说明软件需求；
- 在底层细节层面进行评估；
- 使用诺干不同的评估方法，并且比较其结果；
- 定期做重新评估。
评估构建的工作量
对进度的影响
以下是一些能影响软件开发进度，但不易被量化的因素：
- 需求开发者的经验和能力；
- 程序员的经验和能力；
- 团队的动力；
- 管理的质量；
- 重用代码数量；
- 人员流动性；
- 需求变更；
- 客户关系的质量；
- 用户对需求的质量；
- 用户对需求的参与度；
- 客户对需求开发的参与程度；
- 计算机、程序和数据的分级安全环境；
- 文档量；
- 项目目标；
评估和控制
如果你落后了该怎么办
- 希望自己能赶上；
- 扩充团队；
- 缩减项目范围；
度量
- 任何一种项目特征都是可以用某种方法来度量的，而且总会比根本不度量好很多；
- 留心度量的副作用；
- 反对度量就是认为最好不要去了解项目中到底在发生什么；
把程序员当人看
- 程序员怎样花费时间；
- 性能差异与质量差异；
- 个体差异；
- 团队差异；
- 信仰问题；
- 编程语言；
- 缩进风格；
- 大括号的摆放位置；
- 所用的集成开发环境；
- 注释风格；
- 效率与可读性的取舍；
- 对方法的选择；
- 编程工具；
- 命名习惯；
- 对
goto的使用； - 对全局变量的使用；
- 量度，特别是有关生产力的量度，如每天编写的代码行数。
管理你的管理者
- 把你希望做什么的念头馅藏起来，等着你的管理者组织一场有关你希望什么的头脑风暴/集体讨论；
- 把做事情的正确方法传授给你的管理者。这是一项需要持之以恒的工作，因为管理人员经常会被提升、掉迁或者解聘；
- 关注你的管理者的兴趣，按照他的真正意图去做，而不要用一些不必要的实现细节来分散其注意力；
- 拒绝按照你的管理者所做的去做，坚持用正确的方法做自己的事；
- 换工作。
要点
- 好的编码实践可以通过贯彻标准或者使用更为灵活的方法来达到；
- 配置管理，如果应用得当，会使程序员的工作变得更加轻松，特别包括变更控制；
- 好的软件评估是一项重大挑战。成功的关键包括采用多种方法、随着项目的开展而修缮评估结果，以及更好地利用数据来创建评估等；
- 度量是构建管理成功的关键。你可以采取措施度量项目的任何方面，而着要比根本不度量要好很多。准确的度量是指定准确的进度表、质量控制和改进开发过程的关键；
- 程序员和管理人员都是人，在把他们当人看的时候工作得最好。
