在 Scrum 中,会在 planning meeting 的时候将一个项目拆分若干个 user story, 然后再将 story 拆分为若干个子任务, 并且根据难度、时间、甚至未知程度给一个 story 打分( story points) 将能排进一个周期( Sprint )内的 story 拖进来然后进行开发,每个人根据自己的开发效率自行选择
如果是这种模式的话,是不是本身就不会产生 996 的问题
1
Muninn 2019-04-09 12:04:16 +08:00
因为一般人预估的 points 都不准……所以情况是 996 刚好做完,955 就 delay 了。
即使是纠正很久,一般人还是估计不准。我带团队的时候一般都是把时间*2 当作自己的底线最后才勉强差不多。 |
2
saulshao 2019-04-09 15:46:28 +08:00
其实,敏捷并不能加快单个需求的实现速度,按照敏捷的要求,每个 story 还是要经过需求分析,设计,代码,SIT,UAT 这几个阶段。这和传统的瀑布式开发没有任何区别。
为什么要敏捷?是因为敏捷试图通过减少上述的阶段之间的沟通成本,以加快需求的总体上线速度。同时,敏捷希望改变瀑布式开发流程的一次性收集大量需求的模式,改为将大量需求分成少量多次来处理。 换句话说,敏捷的信奉者认为,只做一个需求,其实消耗的时间是一样的,但是如果有 100 个或者 1000 个需求,敏捷也许能降低沟通和开发成本,以加快总体的实现能力。 这跟 996 没有任何关系。预估这种事情,从"预"这个字来说,就不可能准确,因为没人能预测未来。 996 本质上就是个社会制度问题,举个例子,德国法律规定“每周最多工作时间不能超过 60 小时,并且超过 40 小时的工作时间必须经员工本人同意并且支付额外的报酬。”。中国法律也是这么规定的。但是在德国,要是员工去起诉公司,基本都是胜诉的,并且人家有真正的公会。中国呢?我相信楼主心里有数。 |