远离敏捷状态的 Scrum 框架

作者/分享人:王宇
向 Ta 提问
97年参加工作,01年接触极限编程,07年全面敏捷践行,12年接触专业教练,12年开始专职敏捷教练与咨询师生涯,平安,顺丰,招行长期敏捷咨询顾问

敏捷入门的话很多人一般都会选择 Scrum 框架进行学习和导入。但作者在国内导入敏捷的时候,发现 Scrum 框架有很多缺陷,而且这些缺陷甚至让团队远离“敏捷”的状态(Being Agile)。在商业上的成功让这一理论家喻户晓,但认证也让这一框架拥有无数的原教旨主义者。我也比较喜欢表达一些犀利观点,不一定说得都对,但我愿意表达,并通过表达获得更多思考……

文章会关注以下方面:

  • 敏捷的状态与做法(Being Agile or Doing Agile);
  • Scrum 框架与我对框架的期望;
  • 中国特色项目状态与我所坚持的导入框架;
  • Scrum 框架的反敏捷之处;
  • 放弃质疑的知识崇拜与跟随惯性。
已有510人预订
预订达标
文章出炉
交流日期
     
17.12.27
01月09日
01月16日 20:30
查看文章评论/提问
申导Jacky
文不对题
王宇: 那你给个题目?
Andy 王威
1. 用什么做标准来衡量Scrum是否敏捷?同样的标准是否适用于你提出的新做法?2. 你文章末尾的新做法,是流程?框架?方法论?还是实践?3. 你确信没有足够比例的团队在采用Scrum框架过程中获得足够大的好处吗?从你所批判的那些角度。如果只是你个人的经历,是否存在这样的可能性:这是你接触的团队在多样性方面存在的问题,而非普遍地、对于整个中国大多数团队都存在这样的问题
王宇: 1、框架本身是否敏捷,我不好说。因为静静的放着没人使用它可以说它是一切。对于Scrum来说在应用的时候我发现了它的一些特点使得团队关注的方向没有达到我对一个敏捷框架的要求。也就是说,我认为Scrum让团队关注到有些没用的关注点上,从这个角度说,尽管我承认Scrum其价值,但哪怕有1%关注到没有应该关注的东西上,我就认为框架存在缺陷。 2、我在文尾给出是另一个框架的建议,可以用我刚才的标准对我的框架进行衡量。 3、我承认对于一个几岁的孩子,让他拥有良好的生活习惯对他的健康是有帮助的。但现实情况往往更为复杂,尤其在框架有少量的关注点引起涟漪的副作用的前提下。我承认Scrum其价值,但太强调这种概念是否我们进入到了敏捷状态从而灵活面对团队呢?我的经验与总结收益于Scrum,我绝对承认,但我们不能止步于此,我们必须抬头向前。我还是会推荐一些人去参加Scrum培训(起码我的系统培训没出炉 ;P),我也会推荐大家结识更多的Scrum人士(起码这些人经常观点碰撞,相互交流)。以上全部来自我个人经验,一言之词。 鞠躬
王宇: 他们收益了,但也迷惑了。我们不能因为公路让我们出行方便了,就不去优化公路的设计与城市的规划。反而在在宣传公路好,公路妙公路呱呱叫的状态下我们要停顿一下,听一下这是谁在说?他的收入来自哪里?用户知道有铁路、飞机吗?用户知道公路可以调整设计吗?他们知道有不同的汽车吗?他们知道有不同的司机吗?
李洁(Jerry Li)
说的问题存在,但观点不认同,瑕不掩瑜,不能仅凭这点问题就全盘否定Scrum。
王宇: 这个框架我认可其价值,但达不到当下对敏捷框架的期望……
王宇: 如同雷神三中的锤子、星球大战中记录绝地武士的藏经阁。它的存在更多是在限制我们而已……你不愿放下的情怀而已……
戴红梅
你用了“你所坚持的导入框架”以后,取得了怎样的成果?除了你,还有其他人也这样用吗?
王宇: 顺丰,平安有一些我指导的团队在这么用
紫贝壳
那个 deep的d描述不对吧。
王宇: 你觉得D是什么意思?
DoIin
请问改进委员会成员间是如何分工合作的?
邵栋 南京大学
赞同文章中关于自组织团队的观点,期待能够看到具体的这种实践的描述和效果评估。
王宇: 嗯,正在总结
彭莉
拼凑出来的文章,糙之又糙。
你可能还喜欢
Docker+K8S 集群环境搭建及分布式应用部署
李熠lynn
JVM 精华知识点汇总
胡玉洋
Docker 入门之个人博客搭建教程
一念成魔
MySQL 数据同步双机互备
小闲丶
前端游戏框架哪个好
cba
美团客户端响应式框架 EasyReact 开源
美团技术团队
微信扫描登录