预估项目

1. 项目成功的关键是什么？

答：如果项目不能成功进行，项目经理该如何应对。找出最稀缺或者不可替代的资源（人或者物），然后提前预约，保证可以拿到资源；如果拿不到资源或者资源数量不够或者资源质量不够（例如程序员不会写分布式系统），创建一个自己的备份池，能够找到合适的人替代上去。

2. 如何用CPPM/CCPM来管理项目？

• CPPM是指Critical Path Project Management，是指将项目的任务和时间图画出来，列出并列和先后顺序，其中花时间最长的那一条路径就是Critical Path。典型的项目任务（Tasks）包括:
  • Hold a kickoff meeting
  • Write specs for the new feature
  • Design the user experience/flow
  • Code the MVP (minimum viable product)
  • QA the code
  • Release as a beta feature
  • Make adjustments/improvements based on the beta feedback
  • Release improved feature to all product users
  • Write tutorials
  • Publish and promote tutorials
  • Write press release
  • Publish press release

典型的项目流程

• CCPM是指Critical Chain Project Management，是在CCPM的基础加上了对于资源可用性和分配的考虑。资源一般包括：
  • 人力
  • 设备
  • 物料
  • 营运资金
    针对上述的一般项目流程，我们一般需要以下资源：
  • Large meeting room for the kickoff meeting
  • Product manager
  • Software engineer
  • PR manager
  • QA team
  • Copywriter

  • Social media specialist
    CCPM相对CPPM的好处是增加了缓冲。CPPM超了截止日期就是超了截止日期，但是CCPM增加了关键任务之间/非关键任务和关键任务之间的缓冲时间（buffer）。通过监控任务的缓冲时间来观察项目的健康程度，如果健康程度较低，则需要采取一定的行动。同时CCPM鼓励队员做一个最有侵略性的时间估算，push队友尽早完成。当然了，如果超过了最有侵略性的时间估算，也不要惩罚队员，可以把这个当作缓冲时间buffer。

    
    CCPM

3. 项目预估时间如何防止超过时间？

• 要和顾客知道修改项目范围所带来的可能延期和后果
• 资源（包括人和物品）的使用率一般是80%，不要超过80%，会有滑坡的问题。
• 多用不同的方式去估算项目的时间，多问不同的人，这样汇合一个中间点相对来说会比较接近实际项目的时间。
• 一定要保证团队的focus在一个点，不要多任务处理，不要两个项目同时进行。

4. 假如项目的资源冲突，该怎么解决？

• 找更多资源
• 如果找不到合适的资源，只能用现有资源。则需要考虑同时要进行争夺资源的A/B/C任务，该把资源分配给谁。一般来说，可以把资源分配给已经进行的并且时间消耗最短的任务。这个分配制度是自己根据经验来定的。可以看情况变化。

5. 项目计划阶段结束之后需要完成的任务有？

• 项目范围
• 沟通计划
• 任务列表和预估时间
• 所需资源
• 任务计划表（带着时间点&buffer）
• 每个时间段的预算
• 项目完成时间

6. 如何用估算项目所用时间？

思路大致是：1）计算项目大小；2）计算每小时或者每月人可以完成多少功能点，一般来说每月每人一般完成7～15个功能点，平均是10个，如果按照7来算，可以算出下限，如果按照15来算，可以算出上限，得出时间的范围；3）用1/2得到时间，再乘以人工，得到大致需要的资金。

• consensus method or delphi，拍脑门，几个大佬坐下来，完全凭经验猜测，一般来说这种发生在项目决定之前，或者是项目的诞生期，几乎没有什么信息产生。具体方案是通过多轮讨论，每轮每人提出自己的结果，然后进行修改，直到指定的轮数到了或者大家达成共识。

• 通过delphi达成一致的结果分为三种，最有可能发生的，最乐观的情况和最悲观的情况，这三种情况可以用three-point或者PERT来计算平均值和方差，从而得出确信区间。

• code line count method，直接预测大概有多少行代码，通过这个来估算项目所用时间，这个和具体实现的语言有关，可多可少，所以估算下来也不是很精确。

• user case count method，从用户角度来看有多少用户例子，用来估算复杂度，这种估算非常简单粗暴，但是忽略了系统内部的复杂度。

• ratio or the parametric method，设定一个或者多个参数，用参数乘以平均时间来估算项目所需要时间，例如要写3个页面，那么参数可以是页面的数量。这样的估算是线性的，如果能找到合理的参数以及合理的平均时间，是可以作为初级的估算。

• template method，根据过去的相似项目，比照来估算现在的需要多少时间。将项目划分成WBS（work breakdown structure），然后再去估算任务时间和金钱。

  
  WBS

• apportioned method，也是根据过去的相似项目，知道某个子任务所占时间和消费比例，按比例来划分到现在的项目。

• 分摊风险方法，问公司内部要做的人和外部要做的人他们对同一个功能的预估时间，算平均来做。

• function point count method，ISO国际标准。
  功能点计算涉及到Record Element Type，Data Element Type和File Type Referenced。其中RET代表数据库的一个表，DET代表数据库的一个字段，FTR代表数据库所在的文件，可以简单的理解为数据库的库。我们只计算unique的DET和RET，例如数据库关系中的多对多，其中有些字段是外键，这些都是重复字段。
  功能点计算首先把找出来五个部分，其中前三个部分涉及到逻辑，后两个部分涉及到数据。

  1. input，简单而言，这个就是前端的输入界面。前端输入界面涉及到多少个FTR和DET。
  2. output，简单而言，这个就是前端的展示页面。但是我们只数处理过的数据（computed data），其他取出来就直接使用的数据不算在内，也可以算出涉及到多少个FTR和DET。
  3. queries，简单而言，就是api调用，如果调用了外部api，则需要将其影响算在内。也需要算出涉及到多少个FTR（在内部存储的时候涉及到哪几个数据库）和DET（需要获取外界的哪几个字段）。
  4. external interface files，简单而言，就是外部数据库，如果调用了api，所有的api涉及到多少个RET和DET。
  5. internal logic files，简单而言，就是内部数据库，有多少个RET和DET被使用了。
  6. 因为以上的计算并没有将用户规模考虑进去，因为用户规模的存在，可能会涉及到集群和缓存等技术，这些都是额外的实现，需要额外进行考虑。

  计算完毕之后，需要根据官方提供的表格来评判，把加起来的总数当成总的功能点数。

  
  对于1，2和3
  对于1，2和3

对于4和5
最后需要根据对于性能等的非功能性要求，进行权重调节。具体方法参看调节办法。如果需要预估测试用例需要多少功能点，则可以按照1.2倍来简单计算