这是一个创建于 2365 天前的主题，其中的信息可能已经有所发展或是发生改变。
上周开始新项目,新团队, 新人新入职的比较多. 上周五开始 redmine 分任务以及大家自己评估时间, 今天周四, 新来的人都没有按照他们估计的时间完成任务, 导致这次迭代难产.
应该如何处理? 下周迭代就不用考虑了, 这次的任务还没完成, 老人等新人一起拖慢进度?
 |
1
simapple 2017-11-02 10:35:08 +08:00
加班 e 招人恨的样子
|
 |
2
liuyes 2017-11-02 10:37:58 +08:00
估计时间*2
|
 |
3
keepcleargas 2017-11-02 10:39:04 +08:00
那下次 分配任务 ，老人多些 新人少些，时间动态合理评估。
|
 |
4
Vindroid 2017-11-02 10:42:22 +08:00
刚开始一般都很难能准确估算任务的时间吧，PL 不应该加个缓冲时间么？可以让没做完的再拆分部分放到下个周期里，部分加班赶工做出来。
|
 |
5
dong3580 2017-11-02 10:44:40 +08:00
估时不准就调整估时啊，每天调整一下也没关系吧，不行就拉下去，慢慢的就准了，
|
 |
6
jmc891205 2017-11-02 10:48:56 +08:00
没经验的程序员高估自己的效率很常见 团队里的 leader 要对分配给他们的任务有一个自己的时间预估。
另外一个对于新人，要对他们的工作常常 review，发现进度不如预期的话就尽快调整 schedule。 |
 |
7
tonghuashuai 2017-11-02 11:18:14 +08:00
参考 scrum 估算扑克估时法： http://www.scrumcn.com/agile/scrum/4523.html
|
 |
8
pynix 2017-11-02 11:25:20 +08:00
让新人预估时间你也是很牛了，老手都不一定能准确预估，生活总是会出点意外，说不定哪天就掉坑里了。。。
|
 |
9
zjsxwc OP @simapple 加班无法保证代码质量, 而且代码合并也要需要老人来处理审核
其他, 说新人估时不准问题的, 也确实只能靠时间来磨合. 现在我只能把, 这些没完成的任务后挪作为下次迭代, 本次迭代就不涉及新人的事情了. |
 |
11
enenaaa 2017-11-02 11:39:46 +08:00
最讨厌的事情就是评估任务时间。
|
 |
12
Alex6 2017-11-02 12:01:14 +08:00  1
推荐 scrum 的时间预估方法。没有扑克，就用一张纸来写，大家写完了，再拿一起出来看。每个开发说说这个任务自己为什么要评估这个时长。大家一起讨论，当前任务就会有一个相对合适的完成时长了。
同时项目负责人需要注意几点 1.任务拆分需要精细。比如内容列表展示，就只是列表展示。不包括列表上的搜索，其他附属功能。但同时不能太细，比如分页还作为一个任务。 2.注意每个人 story 的时间，给出你的建议时间。同样的功能，一个人很熟悉与一个人不熟悉，给出的时间是不一样的。 3.项目冲刺期间，每日工作量是否完成要确认。某个人如果进度落后，可能是遇到困难了，或者任务分配太多了等。项目负责人需要及时给予帮助，协调解决。如果任务分配多了，就拿出一些给进度较好的人。遇见项目难题了，及时提出来，大家来攻关。 但如果是项目目标不明确，需求变更，或者方案有误。那就是另外的范畴了。 |
 |
13
SakuraKuma 2017-11-02 12:01:48 +08:00
这也是我现在遇到的问题，很惆怅同样。
和你#10 楼一样所说的，一个老手可以搞定好几个新人的事情，老板又没好价钱请人，很尴尬。 |
 |
14
dangyuluo 2017-11-02 12:02:58 +08:00
确实很难估计啊，因为开发过程随时都会有新问题产生。
|
 |
15
yulitian888 2017-11-02 12:13:07 +08:00
同 12 楼 一个任务的时间不是由开发者一个人估的，而是全队人一起。尤为重要的是，投票出来的时间差异较大时，必须让最高和最低的两个人 PK，说出理由来，之后全队人再来第二轮投票
如，一个任务，团队 5 人时间分别为：2,2,3,4,6。那么一眼可见，估 6 个一定有某种理由（可能因为是新手，也可能是想的细节比别人多，甚至还有可能是没有走心胡乱说的）不把这个具体理由说清楚，合适？ |
 |
16
ThatIsFine 2017-11-02 14:31:52 +08:00
这个.....不是培训班出来的吧, 一个老手干几个新手的活还只要一上午.
下次发版,估之前不要算上新人的任务 |
 |
17
php01 2017-11-02 14:34:08 +08:00
下一秒会发生什么，谁也不知道，与预测下期彩票性质相同，机率不同而已。
|
 |
18
mcfog 2017-11-02 14:42:34 +08:00
上周五到本周四有 5 个工作日，你（假设你是 leader ）知道这是新项目新团队，当中一次进度都不碰也是心大
还是说其实有碰进度，但大家都互相瞒着？ 进度不准我觉得相比之下完全不是个事，总结原因重新排期就行呗，已经过去的时间又追不回来，该和业务沟通和业务沟通，该向老板汇报向老板回报 |
 |
19
moshao6 2017-11-02 14:50:22 +08:00
悟性不行啊
就我遇到的情况来说，给新人的任务，基本都是很简单的，项目中其他地方有类似的功能。一般情况下只能参照或者有时候复制粘贴就行了。但是就是进度很慢。 如：作一些基本表数据的维护界面，有一个同事 A 连语言之前都没有接触过的，另一个 B 同事听说二三年该语言的工作经验，A 就比 B 快。 还有一个就是，不同人对于同一个问题的理解是不一样的。 |
 |
20
NUT 2017-11-02 14:53:45 +08:00
时间无法估计是表象，深层含义就是：『团队可控？』。
我带的团队，每个新人进来增加 2 周~4 周 熟悉时间，不让熟悉直接干，风险太大。 我司一般迭代 2 周一次，首先对任务进行原子化细分（就是分解透需求点，技术风险点），尽量让新人做技术可控的事情，不可控的由老手直接负责。否则容易翻盘。 新人进来的 适应期，我一般会 分散到好几个开发周期中。 对于团队的信任一般的思路是， 完全不信任--团队队友信任---我信任。 前期需要加入重点 Code Review 对象，达到 预期以后逐渐 降低 Review 频率，最后达到我信任的列表。 技术人员很好判断，如果代码 Review 结果很差 /而且屡教不改的，那就可以 GG，别浪费时间。 这样从根本层面保证了，可控。 另外如果是新组建，急速扩张的团队，那么就得相关负责人，给他更大的权利。在此期间，自己要这些负责人一起进行进度控制和细节把控，虽然辛苦，但这也是树立自身领导力，和打磨核心团队的过程。 一旦成型，后面就很顺了。 如果这段时间 hold 不住 ，那可能自己不是这个团队，准备跑路吧。 团队可控，换句话也就是分而自治。领导就是原来的皇帝，要与各诸侯达到相互平衡。 门道很多，我也才入门。 希望对你有用。 |
 |
21
AckywOw 2017-11-02 16:38:45 +08:00
如果真的是没有什么经验的新手，只能慢慢带，然后优胜劣汰
|
 |
22
zz92sh 2017-11-02 16:57:04 +08:00
如果不是因为难度的问题，那就是工作效率低下，你不盯着就慢慢搞……这种情况还是要强势一点，在约定时间里没有完成的话，只能让他们多加加班完成了！还有就是，敏捷里面的每日例会，每天早上花个几分钟让大家汇报自己的工作进度和计划啥的，有利于督促大家。（说实在的，我也经常遇到这种问题，但是自己没强势起来…… sad ）
ps.如果可以的话，在招聘初期就尽量多招些有质量并且有上进心有追求的人。。。要知道一个没心没肺的开发，要给测试和产品带来多少沟通成本。一个小东西嘴都说干了，还没改正确和一个基本按照需求完美开发出来的人，慢一点我也忍了~ |
 |
23
zhx1991 2017-11-03 00:02:50 +08:00
估时记得留余量
项目主 R 隔一天就跟进各端进度, 有问题及时反馈调整 |
Select Language