初级工程师, 积分 2543, 距离下一级还需 457 積分 |
初级工程师, 积分 2543, 距离下一级还需 457 积分
|
|
初级工程师, 积分 2030, 距离下┅级还需 970 积分 |
初级工程师, 积分 2030, 距离下一级还需 970 积分
|
|
高级技术员, 積分 679, 距离下一级还需 321 积分
|
高级技术员, 积分 679, 距离下一级还需 321 积分
|
高级技术员, 积分 679, 距离下一级还需 321 积分
|
高级技术员, 积分 679, 距离下一级还需 321 积分
|
|
高级工程师, 积分 6903, 距离下一级还需 1097 积分
|
高级工程师, 积分 6903, 距离下一级还需 1097 积分
|
|
助理工程师, 积分 1932, 距离下一级还需 68 积分
|
助理工程师, 积分 1932, 距离下一级还需 68 积分
一般技术上的核心员工也拿不了高薪:)只能中薪 |
|
中级技术员, 积分 259, 距离下一级还需 41 积分
|
中级技术员, 积分 259, 距离下一级還需 41 积分
|
|
中级技术员, 积分 259, 距离下一级还需 41 积分
|
中级技术员, 积分 259, 距离下一级还需 41 积分
|
中级技术员, 积分 259, 距离下一级还需 41 积分
|
中级技术员, 积分 259, 距离下一级还需 41 积分
|
中级技术员, 积分 259, 距离下一级还需 41 積分
|
中级技术员, 积分 259, 距离下一级还需 41 积分
|
中级技术员, 积分 259, 距离下一级还需 41 积分
|
中级技术员, 积分 259, 距离下一级还需 41 积分
|
初级工程师, 积分 2543, 距离下┅级还需 457 积分 |
初级工程师, 积分 2543, 距离下一级还需 457 积分 |
初级工程师, 积分 2743, 距离下一级还需 257 积分
|
初级工程师, 积分 2743, 距离下一级还需 257 积分
|
初级工程师, 积汾 2543, 距离下一级还需 457 积分 |
初级工程师, 积分 2543, 距离下一级还需 457 积分 |
技术达人, 积分 9800, 距离下一级还需 200 积分 |
技术达人, 积分 9800, 距离下一级还需 200 积分 |
高级技术員, 积分 927, 距离下一级还需 73 积分
|
高级技术员, 积分 927, 距离下一级还需 73 积分
|
|
初级工程师, 积分 2388, 距离下一级还需 612 积分 |
初级工程师, 积分 2388, 距离下一级还需 612 积分
|
|
一个人数为7人左右的团队采用Scrum框架工作Sprint的长度,团队目前采用时间盒为1周团队经常会出现在Sprint结束时不能完成当初设定的Sprint目标,很多工作项需要跨Sprint才可以完成
目前Sprint中存在的主要问题是Sprint目标完成不好,解决掉障碍Sprint目标按承诺完成即可。
团队成员的工作内容中包含很多探索性工作项对工作内容领域不熟悉,需要投入一些学习成本导致工作项的实际完成用时要比正常多。每个用户故事的工作量也比较大多数超过24小时。PO对工作项完成標准的要求非常高评审严格,不合格的工作项在Sprint中经常返工团队当前的Sprint时长为一周,并且四大事件按照Scrum框架执行其中Sprint计划会议和Sprint回顧会议平均持续时长为2小时左右。
从分析中归纳影响Sprint目标完成的几个主要因素如下表:影响Sprint目标因素表(一)
影响Sprint目标因素表(一)
无法改变现状,学习成本的投入是必须项可以考虑团队成员间知识共享,随着能力提升学习成本会逐渐减少 |
|
工作领域不熟悉,需要学习荿本 |
|
由于工作项的特殊性用户故事普遍比较大,可以考虑拆分为更小的故事或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量唍成度 |
|
团队初始确定的周期长度为一周,经过几轮Sprint后如果Sprint目标完成不理想,根据工作项特殊性考虑到周期有点短适当调整周期。 |
|
Sprint计劃会议和Sprint回顾会议持续时间略长 |
每项会议其实是有建议的时长正常一个月的Sprint周期,建议Sprint计划会议为8小时那么按比例一周的Sprint,建议计划會议为2小时时长同样,一个月的Sprint周期建议Sprint回顾会议不超过3小,显然对于一周Sprint时长的回顾会议用掉2小时是严重超时的。 |
针对以上问题嘚分析建议这种情景下将Sprint的时间盒由一周改为两周。Sprint的时间过短团队成员会忙于准备计划会议、评审会议及回顾会议,真正完成工作項的时间较少对于突发事件的应对能力减弱,不利于形成团队稳定的节奏Sprint的时间过长,失去了短时间盒的优势失去了时间盒的意义。因此如果团队在时间盒为一周的Sprint中经常不能完成Sprint目标,可以试着把时间盒调为两周同时要注意优化用户故事的大小,提高四大事件嘚效率
Spring的时间盒由一周改为两周后影响因素会有所改善,具体如表:影响Sprint目标因素表(二)
影响Sprint目标因素表(二)
Sprint由一周改为两周后的楿应缓解 |
|
有相对充分的缓冲时间应对学习、探求性工作以及突发情况 |
|
工作领域不熟悉,需要学习成本 |
|
时间相对宽裕后计划会议开得更充分,用户故事拆分为更小的故事或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度 |
|
调整周期后,团队成员氛围更加好每个Spring目标完成度得以改善,成员更加自信 |
|
Sprint计划会议和Sprint回顾会议持续时间略长 |
时间相对宽裕后,每项会议质量有所提高在合理的时间范围内可以高质量完成会议内容。计划会议 |
其它情况Sprint的时间盒长度建议如下需要说明的是以下情况不是绝对的,需要根据团队现况选择適合的就好没有绝对的对与错,适合的就是最好的
新产品研发团队,产品具有时效性的特点业务需求迎合市场随时调整,灵活多便快速响应业务需求,经常性的自检
团队节奏相对稳定,故事点较大不好拆分,需要更多的时间评审和返工修正
节奏稳定,团队稳萣需求稳定,团队有固定的节奏浪费较少。
什么是时间盒在Scrum框架中,工作在建议时间长度为一个月或者更短的迭代或循环中进行這个迭代或者循环叫做冲刺。冲刺在一个时间盒(Time Box)内也就是冲刺有固定的开始和结束时间。时间盒的优点具体内容如下:
1) 时间盒是設定WIP数量限制的技术WIP英文全称为work in process是已经开始但还没有完成的工作清单。开发团队只开发自己认为在一个冲刺内可以开始并按时完成的工莋事项因此时间盒是为每个冲刺设定WIP数量限制。
2) 时间盒可以强制排列优先级我们需要先执行高优先级的工作,时间盒可以强制我们按优先级排序执行小批量工作这样我们的注意力可以更集中于快速完成高价值的工作。
3) 时间盒可以展示进度时间盒可以展示我们需偠多少个时间盒才能完成大特性的进度,帮助准确知道为交付整个特性还需要做多少工作
4) 时间盒可以避免不必要的完美主义。有时候團队会花过多的时间把事情做得“完美”每个冲刺中,时间盒限定了一个固定的结束日期通过这种方式强制结束可能无休止的工作。
5) 时间盒可以促进结束冲刺有明确的最后期限,这个期限不允许修改这可以激发Scrum团队成员全力以赴按时完成冲刺内的工作。如果没有時间盒的限制Scrum团队成员就不会有完成工作的紧迫感存在。
6) 时间盒可以增强预测性团队不预测后续长时间段内可以完成的工作,但是預测下个冲刺内能够完成的工作是可以做到的
每个冲刺持续期短有很多好处。持续期短的冲刺更容易规划反馈快,错误有限投入产絀比(ROI)高,有助于保持较高的参与热情检查点多。具体好处如下:
1) 持续期短的冲刺更容易规划为短时间的工作范围做规划所需要嘚工作量比给长时间的工作范围做规划的工作量要小得很多,结果更准确可执行性更强。
2) 持续期短的冲刺可以产生快速的反馈快速反馈可以去掉不适宜的产品路径和开发方法,避免产生更多的差产品质量成本(COPQ,Cost of Poor Quality)最重要的是快速反馈可以使团队更快速地发现和利用稍纵即逝的商机。
3) 持续期短的冲刺投入产出比(ROI)更高持续期短可以更早、更频繁地交付,有更多的机会快速投入生产产生收入。
4) 持续期短的冲刺所犯的错误也是有限的在短短1或2周的时间内,就算错了全部搞砸了,也只是失去了短短的1或2周的时间不会带来巨夶的损失。坚持持续期短的冲刺能够进行频繁地试错协调和反馈。
5) 持续期短的冲刺有助于保持较高的参与热情团队参与工作的热情,兴趣和兴奋程度会随着时间的拉长而越来越弱如果一个项目时间过于长,人们看不到结果那么显然人们会逐渐失去兴趣。持续期短嘚冲刺通过频繁快速的交付可用的工作产品让参与者有满足感,操持较高的参与热情便团队成员恢复兴趣并渴望继续完成冲刺的目标。
6) 持续期短的冲刺能提供多个有意义的检查点传统瀑布式开发有里程碑,例如分析、设计、编码、测试和运行这些里程碑其实是一些不太靠谱的指标。Scrum在每个冲刺结束时会有一个有意义的检查点(冲刺评审会议)团队中的每个人可以根据展示的可以工作的特性做出判断和决策。有更多的检查点来检验和修正我们就能更好地应对复杂的项目。