进度
1 向进度落后的项目增加人手,只会使进度更加落后.
2 向软件项目中增加人手从三个方面增加了项目必要的总体工作量:任务重新分配本身和所造成的工作中断;培训新人员;额外的相互沟通
3 项目是怎样被拖延一年的？一次一天
4 慢性进度偏离是士气杀手
5 一天一天的进度落后比起重大灾难更难识别，更不容易防范和更加难以弥补
6 指定严格的进度表， 进度表由里程碑和日期组成
7 里程碑必须是具体的、特定的和可度量的时间，能进行清晰地定义
8 如果里程碑定义的非常明确，以至于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假
9 每个老板同时需要采取行动的异常信息以及用来进行分析和早起预警的项目状态数据
10 状态的获取是困难的，因为下属经理有充分的理由不提供信息共享
11 老板的不良反应肯定会对项目状态信息的公开造成压制。相反，仔细区分状态报告、毫不惊慌的接收报告、决不越俎代庖，将能鼓励陈实的汇报
团队
1 小型，精干队伍是最好的 - 思绪尽可能的少
2 一拥而上的开发方法是高成本的、速度缓慢、低效的，开发出的产品无法进行概念上的集成
3 类似于外科手术队伍的团队架构提供了一种方法 -- 一位首席程序员，既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底的减少了沟通的工作量
设计
1 要获得概念完整性上，就必须有人控制这些概念。这实际上是一种必要的专制
2 为了获得概念完整性，设计必须由一个人或具有共识的小型团队完成
3 过度设计
4 听取开发人员的改进建议，将创造性的实现自由完全交由开发人员
沟通交流
1 团队应该以尽可能多的方法进行相互之间的交流，正式与非正式的。
2 沟通交流是消除理解偏差的有效方式
组织结构
1 每个子项目有两种角色--产品负责人，技术主管或者结构师
2 两种角色可以任意组合： 产品负责人和技术主管是同一个人；产品负责人作为总指挥，技术主管充当其左右手；技术主管充当总指挥，产品负责人充当其左右手
3 项目经理的基本职责是使每个人都朝着相同方向前进。
4 项目经理的主要日常工作是沟通，而不是做决定。
5 只要管理人员和技术人才的天赋允许，老板必须对谈们的能力培养给予极大关注，使管理人员和技术人员具有互换性；特别是希望能在技术和管理角色之间自由的分配人手的时候
用户需求
1 软件产品易于账务的特性和不可见性，导致它的构建人员面临着永恒的需求变更
2 用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化
3 开发人员交付的是用户满意度，而不仅仅是实际的产品
4 目标上的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好的多
程序维护
1 前进两步，后退一步
2 BUG修复总会以20%-50%的几率引入新的BUG
开发辅助工具
1 磨刀不误砍柴工
2 有效的使用各种成熟的开发插件，工具能有效的提高生产率
3 如有必要，项目经理可分配一定资源为团队内部开发专业工具
欢饮补充....