新团队迭代项目估时不准怎么办

[zjsxwc]

上周开始新项目,新团队, 新人新入职的比较多. 上周五开始 redmine 分任务以及大家自己评估时间, 今天周四, 新来的人都没有按照他们估计的时间完成任务, 导致这次迭代难产.

应该如何处理? 下周迭代就不用考虑了, 这次的任务还没完成, 老人等新人一起拖慢进度?

[simapple]

加班 e 招人恨的样子

[liuyes]

估计时间*2

[keepcleargas]

那下次 分配任务 ，老人多些 新人少些，时间动态合理评估。

[Vindroid]

刚开始一般都很难能准确估算任务的时间吧，PL 不应该加个缓冲时间么？可以让没做完的再拆分部分放到下个周期里，部分加班赶工做出来。

[dong3580]

估时不准就调整估时啊，每天调整一下也没关系吧，不行就拉下去，慢慢的就准了，

[jmc891205]

没经验的程序员高估自己的效率很常见 团队里的 leader 要对分配给他们的任务有一个自己的时间预估。
另外一个对于新人，要对他们的工作常常 review，发现进度不如预期的话就尽快调整 schedule。

[tonghuashuai]

参考 scrum 估算扑克估时法： http://www.scrumcn.com/agile/scrum/4523.html

[pynix]

让新人预估时间你也是很牛了，老手都不一定能准确预估，生活总是会出点意外，说不定哪天就掉坑里了。。。

[zjsxwc]

@simapple 加班无法保证代码质量, 而且代码合并也要需要老人来处理审核

其他, 说新人估时不准问题的, 也确实只能靠时间来磨合.

现在我只能把, 这些没完成的任务后挪作为下次迭代, 本次迭代就不涉及新人的事情了.

[zjsxwc]

@pynix

也没给他们什么重要任务.
分给新人的都是一些很简单的任务, 其实一个老手一上午就能完成好几个新人的事情

[enenaaa]

最讨厌的事情就是评估任务时间。

[Alex6]

推荐 scrum 的时间预估方法。没有扑克，就用一张纸来写，大家写完了，再拿一起出来看。每个开发说说这个任务自己为什么要评估这个时长。大家一起讨论，当前任务就会有一个相对合适的完成时长了。

同时项目负责人需要注意几点
1.任务拆分需要精细。比如内容列表展示，就只是列表展示。不包括列表上的搜索，其他附属功能。但同时不能太细，比如分页还作为一个任务。
2.注意每个人 story 的时间，给出你的建议时间。同样的功能，一个人很熟悉与一个人不熟悉，给出的时间是不一样的。
3.项目冲刺期间，每日工作量是否完成要确认。某个人如果进度落后，可能是遇到困难了，或者任务分配太多了等。项目负责人需要及时给予帮助，协调解决。如果任务分配多了，就拿出一些给进度较好的人。遇见项目难题了，及时提出来，大家来攻关。

但如果是项目目标不明确，需求变更，或者方案有误。那就是另外的范畴了。

[SakuraKuma]

这也是我现在遇到的问题，很惆怅同样。
和你#10 楼一样所说的，一个老手可以搞定好几个新人的事情，老板又没好价钱请人，很尴尬。

[dangyuluo]

确实很难估计啊，因为开发过程随时都会有新问题产生。

[yulitian888]

同 12 楼 一个任务的时间不是由开发者一个人估的，而是全队人一起。尤为重要的是，投票出来的时间差异较大时，必须让最高和最低的两个人 PK，说出理由来，之后全队人再来第二轮投票

如，一个任务，团队 5 人时间分别为：2,2,3,4,6。那么一眼可见，估 6 个一定有某种理由（可能因为是新手，也可能是想的细节比别人多，甚至还有可能是没有走心胡乱说的）不把这个具体理由说清楚，合适？

[ThatIsFine]

这个.....不是培训班出来的吧, 一个老手干几个新手的活还只要一上午.

下次发版,估之前不要算上新人的任务

[php01]

下一秒会发生什么，谁也不知道，与预测下期彩票性质相同，机率不同而已。

[mcfog]

上周五到本周四有 5 个工作日，你（假设你是 leader ）知道这是新项目新团队，当中一次进度都不碰也是心大
还是说其实有碰进度，但大家都互相瞒着？

进度不准我觉得相比之下完全不是个事，总结原因重新排期就行呗，已经过去的时间又追不回来，该和业务沟通和业务沟通，该向老板汇报向老板回报

[moshao6]

悟性不行啊
就我遇到的情况来说，给新人的任务，基本都是很简单的，项目中其他地方有类似的功能。一般情况下只能参照或者有时候复制粘贴就行了。但是就是进度很慢。

如：作一些基本表数据的维护界面，有一个同事 A 连语言之前都没有接触过的，另一个 B 同事听说二三年该语言的工作经验，A 就比 B 快。

还有一个就是，不同人对于同一个问题的理解是不一样的。

[NUT]

时间无法估计是表象，深层含义就是：『团队可控？』。

我带的团队，每个新人进来增加 2 周~4 周 熟悉时间，不让熟悉直接干，风险太大。
我司一般迭代 2 周一次，首先对任务进行原子化细分（就是分解透需求点，技术风险点），尽量让新人做技术可控的事情，不可控的由老手直接负责。否则容易翻盘。
新人进来的 适应期，我一般会 分散到好几个开发周期中。 对于团队的信任一般的思路是， 完全不信任--团队队友信任---我信任。 前期需要加入重点 Code Review 对象，达到 预期以后逐渐 降低 Review 频率，最后达到我信任的列表。 技术人员很好判断，如果代码 Review 结果很差 /而且屡教不改的，那就可以 GG，别浪费时间。 这样从根本层面保证了，可控。

另外如果是新组建，急速扩张的团队，那么就得相关负责人，给他更大的权利。在此期间，自己要这些负责人一起进行进度控制和细节把控，虽然辛苦，但这也是树立自身领导力，和打磨核心团队的过程。 一旦成型，后面就很顺了。 如果这段时间 hold 不住 ，那可能自己不是这个团队，准备跑路吧。

团队可控，换句话也就是分而自治。领导就是原来的皇帝，要与各诸侯达到相互平衡。 门道很多，我也才入门。 希望对你有用。