1.对你完成工作过程的直觉进行建模

    2.在与同事的交流中使用这些模型

    3.用模型来模拟项目的运行结果

    4.根据项目的实际结果来调整模型

 

    资源和进度不能完全互换，人月神话一书有明确的描述。20人一年的项目进度压缩到半年时候究竟要增加多少人员，或者说增加再多的人员都无法压缩到1年，往往我们更多的是主观上的推测和判断，而没有通过适当的模型去模拟和验证我们的想法。如果我们无法给出明确的分析证据，很难去说服我们的用户和领导，去争取相应的时间和资源。在这种增加资源压缩工期的软件项目中我们需要重点考虑的问题有：

 

    A.人员增加后沟通成本的增加，5个人沟通路径是10,10个人沟通路径是45,而20个人的沟通路径是190.这显然已经不是线性关系。

    B.项目生命周期模型的选择和关键路径：前期需求没有搞清楚之前投入再多的人力资源都没有意义。如果需要就要做3个月，那半年完成项目基本就属于不可能的任务了。

    C.由于存在B因素项目各阶段不可避免存在闲置人力资源，很难充分利用。

 

 

    1.项目运行过程中要注意度量数据的收集

    2.项目结束的时候要进行复盘，要对收集的数据进行分析＆整理，形成项目历史经验数据库。

    3.要形成项目自己的度量方程式，并根据各版本的输出历史数据对公式进行验证＆调整。最终为下个项目或版本提供参考。

    4.要剔除项目中的异常数据，保证收集的度量数据的准确性。

 

 

    1.压力之下的人无法跟快速的思考问题

    2.增加加班时间只会降低生产力

    3.短期的压力乃至于加班是有用的策略，因为这能够使员工集中精力并感觉到工作的重要性。但是长期的压力肯定是错误的。

    4.使用压力＆加班的真正原因是为了在项目失败的时候让所有人看上去能好一点。

 

 

    1.早期的人员超编会使项目过早进入设计阶段

    2.设计完成之前进入开发会使人＆人之间，工作组之间接口复杂化。

    3.项目理想情况使早期由核心小团队进行需求＆设计，后期投入大量人手

   

    我们考虑下一个规模在60-100个用例的项目，实际的工作量在150人周。项目在一开始就投入到15个人花10周时间完成。而往往更合理的方法是前6周只保留2个需求人员和4个设计人员进行工作。在6周以后投入16个编码人员进行编码,2个需求人员退出。这样的工作量为116人周。这样的效果是肯定比第一种资源分配好的。