开源中国

我们不支持 IE 10 及以下版本浏览器

It appears you’re using an unsupported browser

为了获得更好的浏览体验,我们强烈建议您使用较新版本的 Chrome、 Firefox、 Safari 等,或者升级到最新版本的IE浏览器。 如果您使用的是 IE 11 或以上版本,请关闭“兼容性视图”。
为什么使用 Scrum 开发软件是错误的? - 技术翻译 - 开源中国社区

为什么使用 Scrum 开发软件是错误的? 【已翻译100%】

标签: <无>
李三石 推荐于 3个月前 (共 14 段, 翻译完成于 05-14) 评论 14
收藏  
8
推荐标签: 待读

1、由于全部产品决策权都归“产品所有者”所有,因此Scrum拒绝工程师做任何产品决策,并在产品方向上减少任何级别对产品管理的卑躬屈膝。

kevinlinkai
 翻译得不错哦!

2、Scrum用紧凑的管理方式占用工程师所有的时间,抑制了创新——这些创新向来不由自主地发生,并且超出了任何时间表或者有良好预测性系统的范畴。

kevinlinkai
 翻译得不错哦!

3、Scrum鼓励“尽可能减少工作量”的解决方案——来满足它严格的可预测性的需求。

kevinlinkai
 翻译得不错哦!

4、将每个任务都拆分成小项目,团队中的任何人理论上都能完成。Scrum劝阻工程师对自己的工作产生自豪感或者所有权。这种所有权的缺失会导致:

  • 设计质量不高

  • 乏积极性(“这不是我的事”,“我开始做之前就出问题了”)

kevinlinkai
 翻译得不错哦!

5、Scrum 对修改是非常不能容忍的,它的拥护者在实施的过程中通常秉着全有或者全无的态度。在所有的实践中都体现了以这种不宽容态度的自我反省。只对运行在Scrum框架层内部的进程开放修改——就Scrum自己而言,这被视为神圣而不可侵犯的。

“Scrum的角色,工件、事件和规则都是不可修改的,并且尽管可以只实现Scrum的某些部分,但是其结果并不是Scrum。Scrum的存在感仅仅在于作为其它技术、方法及实践的容器时它的完整性和功能尚佳。”
Scrum官方指南,http://scrumguides.org/scrum-guide.html


kevinlinkai
 翻译得不错哦!

6、Scrum是一个重型的管理工具。典型团队有产品拥有者,Scurm控制者,和团队领导。伴随更少管理的创新能促进团队做的更好,而不是更多的管理。

kevinlinkai
 翻译得不错哦!

7. Scrum通常是使用HORRIBLE任务管理工具(Jira、tfs等)实现的,这些工具对Scrum做了非常官僚化的解释,浪费了大量的开发人员时间。此外,无论多么无效,它们都可以有效地将你限制在一种操作模式中。

Tocy
 翻译得不错哦!

8. Scrum不鼓励修复bug、减少技术债务和承担风险,这全都是因为其狭隘并排他地专注于只做产品负责人认为有价值的项目。

Tocy
 翻译得不错哦!

9.Scrum是虚伪的

  • 管理人员或产品所有者是否需要跟踪和评估他们所从事的每项任务?

  • 他们是否需要出示燃尽图表来显示他们的目标是完成的?

  • 他们是否需要进行两周的抛售会议来证明他们的行为是正当的?

liyue李月
 翻译得不错哦!

10.Scrum有很多错误的假设。

  • 它假定工程师没有任务跟踪系统,他们已经使用这些系统来管理他们的时间,因此需要细致得时间管理。

  • 它假定工程师们不能被信任来指导他们自己的工作。

  • 它假定工程师们不能在没有严格监督的情况下,使自己符合本组织的最佳利益。

  • 它假设工程师不能在没有主持人的情况下有效地进行会议(Scrum Master)

  • 它假定你仅仅可以通过在 sprint planning 或者 backlog grooming 中谈论它来计划一个软件任务的每个方面。

  • 它假设所有的工程师都以同样的方式工作。

liyue李月
 翻译得不错哦!
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们
评论(14)
Ctrl/CMD+Enter

只需要最后一条,就足够放弃这套管理方式了。
好像挺有道理的
哈哈

引用来自“无限静默”的评论

只需要最后一条,就足够放弃这套管理方式了。
你是說第10條吧
敏捷宣言被翻译成这样子,也真是服了。
个人与流程和工具之间的相互作用
通过全面的文档处理软件
客户协作通过合同谈判
根据计划做出响应
刷存在感么?每种管理开发方式都有其优点和缺点。“喷”---谁都会
说一种东西对或者错,而不指出其适应范围,本身就是错的。
敏捷开发,适合类似工业生产式的生产软件,但是不适合科学研究式的开发软件。
但是实际情况中,开发的软件都是同时有这两种特质,只是各家成分比例不一样。
例如我做的软件,就偏重“研究性质”的。

引用来自“开源春哥”的评论

敏捷宣言被翻译成这样子,也真是服了。
个人与流程和工具之间的相互作用
通过全面的文档处理软件
客户协作通过合同谈判
根据计划做出响应
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
官方的翻译是这样的
请从全局来看待这里面的每一个问题,而不应该从一个一个的点来看,只有真正地深度实践过,才懂得它的好处。
内容暂不看,先顶你一下
其实我主张的是随缘开发法,一脚踏上西瓜皮,滑到哪里算哪里:stuck_out_tongue:

引用来自“无限静默”的评论

只需要最后一条,就足够放弃这套管理方式了。

引用来自“liaoxuewei”的评论

你是說第10條吧
第10条也比较狠,不过,我想指的是第14条。
以前公司为了搞个cmm3认证,需要整理这套软件开发流程,实际上没去用。
看上去有用,实际上没什么大用的东西。
一群不写代码的人整天对写代码的人指手画脚告诉他们怎么写,昨天吹这个的是你们,今天喷这个的还是你们的,就像太监告诉将军怎么打仗一样,搞笑,闲的蛋疼。
狗屁文章,木头脑袋就别来趟这趟浑水了
顶部