这是一个创建于 2061 天前的主题，其中的信息可能已经有所发展或是发生改变。
在 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 小时的工作时间必须经员工本人同意并且支付额外的报酬。”。中国法律也是这么规定的。但是在德国，要是员工去起诉公司，基本都是胜诉的，并且人家有真正的公会。中国呢？我相信楼主心里有数。 |
Select Language