“这个任务要一天，那个任务要三天” 如何计算的？

研发过程中的计划会

场景：研发小组的敏捷中的计划会,

• （B）“....这个任务我来做，一天的时间” “....那个任务我来做，三天的时间”

一名研发的小伙伴在会中这样领取研发的任务。

• （A）".....这个任务如何实现？“
• （B）”现在不太清楚“
• （A）”那如何得到的需要一天”
• （A）“如果这个任务不清楚具体如何实现，那添加一个设计的任务，本迭代只完成设计任务，设计任务多长时间？“
• （B）"大概一天吧”
• （A）.........

如何评估

（抛开其他的不说，这里只讨论下任务的评估）

首先要理解评估

做任何的事情都要想到“成本”问题，要最大限度的实现“达成了目标，耗费的成本最小”。 如果目标错误了那么导致的成本全部是浪费的，如果实现的方式不是最优的也会导致成本的浪费，那么如何保证实现的方式的，这里有点数学中微分的感觉。 将目标拆分为小目标，将拆分的小目标进行论证。然后依次。 到最后的颗粒度的任务的时候，保证目标是清晰的，这个时候对它的评估是最准确的。

所以为了保证每一个环节、步骤等是最好的，那么就要进行各种方案的评量。 这个就是“评估”。

其它这里不讲，编程的小伙伴大部分有一个习惯，不想写重复的代码，不想写没用的代码。这个通俗的就是在想“成本”的事。做一件事情，要依次想清楚几个问题？

• 做的是什么？
• 相关的人、物有哪些？
• 如何去做？

然后才是去做。

如何做到正确的评估

软件工程中一直强调需求的重要性。需要是解决“做的是什么”的问题， 研发的要深入的理解需求，不仅仅要知道做的是什么？ 还要理解“为什么要做这个，为什么要这样做“。因为如果需求又问题了，那么导致的是”写了一堆没有用的代码“。

知道了做什么，那么就要进行分析设计，编写出设计方案，写不写文档只是形式的问题， 但是需要很明确的知道如何做？ 比如脑子里面可以浮现出代码，判断分支、循环分支等， 就是流程、逻辑。

有了这些，已经清晰的知道如何做了， 然后根据自己的代码编写效率，去估算出时间。