工期评估
无论在一个什么样的项目中，或者什么样的开发模式中，我们都会对功能进行一个工期评估。
大家可能在一些博客或者文章中看过这样一个笑话，有一个项目需要评估工期，新手研发评估需要一周能完成，熟手评估说只需要3天就能完成，最后老手评估大概需要2周完成。
我们工作中真的是这样吗？其实不然，下面我们来看看可以怎么做一个工期评估。
目的及意义
工期评估虽然是预期，不是准确的，可为什么还是需要？
因为工期预告可以让领导知道项目大概时间节点，可以对整个项目进行预测与规划。
而且每个人有个大概的预估工期节点，知道在什么时间需要拿出什么结果，如何与项目成员进行对接，更好的安排自己的工作。
评估工期流程
在每一个需求确定后，项目经理都需要过一遍，以确定该需求加入哪个迭代，哪个开发人员可以进行开发，哪个测试人员可以进行测试。
在确定了该需求后，项目经理对该需求有个大概认识，心里面能进行一个大致工期评估。
所有项目成员参与需求评审，需求评审确定相关需求功能及大致问题梳理。需求评审完成，需要开发测试人员进行工期评估。
开发人员进行工期评估，取平均值或者评估差异说明做调整。
测试人员评估同理。
开发与测试相加大致就是最后的上线时间。
网上有一些敏捷开发的工期评估方法，比如卡牌法。无论这些评估方式如何，其核心点都是一样，找到功能的大致开发时间。
工期评估存在的问题
1.无法第一时间评估工期
经常有时候开发老师无法进行评估工期，推辞说还要再梳理一下。在这种情况下，项目经理应该制定一个稍微紧凑的工期，如果有项目人员觉得不同意，那么需要作出相应说明，如果无法作出说明，那就先按照这个时间定，等研发人员数量后再进行讨论。
2.项目成员故意增加工期
针对一些项目成员会故意增加工期，只需要3天完成的，却说成10天完成。
这个时候需要他们给出这么多工期的原因。最好的一个方式就是逐个需求功能定，为什么需要这么多时间。
3.之前评估的工期和实际不相符
工期评估本来就是对未来的一个预测，没有谁能预测的非常准确。于是我们应该实时关注项目进度，找到问题原因，根据每日情况进度做好工期调整。
4.功能复杂度高无法评估
有些时候，面对一个未知功能的时候，真的没有办法进行工期预估，功能复杂度实在太高。这个时候需要将这一块功能内容单独提出来进行研究讨论，一边进行研发，一边进行工期动态调整。
5.多项目同时进行
我们曾经或多或少经历过同时开发两个甚至两个以上的项目。在这种情况下，有一个新项目需要评估工期，会让部分同学犯难。这时，该项目工期评估依然按照自身项目来，得出自身项目的一个工期。然后根据其他项目影响，对工期进行浮动。再加上每个项目均有浮动，这种浮动会更大。
小结
在工期评估上不是一味的压迫或者放宽，敏捷开发讲究的尽量准确，让大家保持一个节奏。工期评估也不需要模仿网上各种方式方法，如果非常符合自身项目，不要这些方式方法也可。当然，我还是推荐去看一下卡牌评估法，在某些场景下还是很好用的。
