如今还有人在用 Scrum 方法吗？

[Hanggi]

在招聘网站搜索会发现确实有公司在招 Scrum master，但也确实不多。 记得 2011 ～ 2015 年（记不太清了）那会儿敏捷开发、Scrum 挺热门的，但现在好像很少有人提起。

有谁!严格!执行过 Scrum 吗？ 是否真的可以很好地应对变化、提高沟通效率、提高团队主管能动、降低成本、降低风险？

经过实践后发现有哪些缺陷？ 为何无法成为主流？

到目前为止，大部分言论是在国内推行 Scrum 难，推行了也容易变味，难以坚持。

真正实行过的人也没说用了 Scrum 有多好。

---

所以，是否可以得出结论 Scrum 不行？

http://www.woshipm.com/pd/85814.html
https://returnees.biz/t/topic/829
https://www.zhihu.com/question/23844100

[hmmm]

SCRUM 不是万能的，也没必要严格执行，适合自己团队 WoW 就是最好的。

相对于瀑布开发模型，我看到的大部分公司都转向了敏捷开发。

优缺点也不是一句话能讲清，懒得写了，你去知乎问问好了。

[feelinglucky]

请单独完成老师交代的作业

[GeruzoniAnsasu]

scrum 毕竟还是个理想模型，适用于团队很小，参与者水平都足够开发系统中任何一个模块，不存在上下属级，大家效率都差不多等情况。现实中的团队会有非常多杂七杂八的因素干扰，比如团队成员可能并不只参与一个项目，水平参差不齐上下属级制约、系统设计模块多而导致大家只能顾及自己实现的部分无法交叉 review 等等。而且标准 scrum 模型含有一些执行起来很困难的项，比如 story point 、time estimation 等；还忽略了项目文档（产品文档 /技术文档）这种可能需要集中产出的副产物。所以我们实际研发团队运行模式参考了敏捷模型，但要完全敏捷是不可能的。敏捷模型的最大特点还是持续交付，只要把需求-研发-交付的固定循环周期建立起来，那么项目组的迭代大体上就还是健康的。

[hantsy]

Scrum 迭代模型 和 Kanban 面板几乎是软件开发避免了。

[hantsy]

@GeruzoniAnsasu 这么说，你说 MS 也很小了？只适合小团队？

任何大团队都是分拆成小团队，这是管理层的问题，和 Scrum 关系不大。

至于操作方面，建议你去看一下美剧硅谷。

[hantsy]

@Hanggi 敏捷理论和实践都是非常重要。很多敏捷只有形，没有神。

不去追求理想的 TDD，XP 编程吧，测试是敏捷过程实践不可或缺的。

我在 V 站说过很多次，不写测试的敏捷开发都是假敏捷。没有 DevOps 的 Microservice 架构实践都是假 Microservice 。

[hantsy]

敏捷开发在国内水土不服，最大一个阻碍就是管理，家长式的管理或工厂式的管理从来都不可能调动员工的积极性，底下员工的主动性在一次次被打击后，到后面都是应付了事，技术债务和雪球一样越滚越大，谈什么敏捷。

[chendy]

这类东西的缺点就是对团队水平要求高…

[weixiangzhe]

大都不靠谱，还是要商量着来

[janxin]

最重要的是量体裁衣不是照本宣科

[GeruzoniAnsasu]

@hantsy 说的是落实到具体研发任务的[团队]。整个 MS 不可能只做一个产品一个项目对吧，最终每个项目都会拆分落实到那么几个人十几个人 的小团体上。而在国内来说，可能是个几十人的小团体。可以想象一个人带 5 个实习生、两三个后端一人给所有产品写中间件、一人写业务 CRUD 、一人写算法，这样的团队开个站会你能指望增进什么样的交流？ 3 个人负责方面互不交叉怎么安排相互估时和 review ？

“这是管理层的问题”。是的，我在说的就是管理层面的困难带来的水土不服

[itskingname]

现在 MTK 还在用。他们使用 redmine 上面的看板来管理任务，每两周一个 Sprint 。

[hantsy]

我之前经历好多项目都是实施 Scrum 模型，一个稍长期的目标（大的产品周期）大概会定在 6-10 Sprints 中实现，每个 Sprint 为 2-3 周（后来发现两周比较紧）， 每个 Sprint 最后一天除了必要的总结，演示和下个 Sprint 规划调整外，都是会花时间去项目清理技术债务（ code smells ） 。

多年以前在公司上班的时候，虽然推行 TDD，XP 比较困难，但是像 CheckStyles，PMD，CPD，Spotbugs 这些基本的静态代码检测工具大家还是比较认同。现在国内不知道哪个公司项目开发会配置这些东西了？据我了解我几个朋友的一些公司，都是追求快速的出来一个界面，从来不管这些（代码经不起任何工具的检测）。

当然现在什么都是云了，只要更简单的配置，代码质量检测，代码测试覆盖率等都是可以和 CI 结合的，持续生成报告。

在实践层面，写测试，Peer Code Review （和现在的 Github Flow ），CI，项目技术债务持续清理（当然和重构有关），这些方面做不到位，你说你们在实施敏捷，在我看来仅仅是一个空架子而已。

[hantsy]

@itskingname Redmine 我用过几个项目，好几年。后来一个项目切换到 Jira，现在几乎都是 Github 了。

[GeruzoniAnsasu]

我们有 ci/cd，有 codeowners 和交叉 review，有看板、需求和缺陷生命周期管理、sprint 和版本发布管理，有站会、集体 bug review，产品不是自己的在线业务所以没有运维过程但有自动化的单元测试、发版流程固定的集成回归测试环节。但我们仍然不是很敏捷，一个是前面提到的研发素质和客观属级存在会阻碍完全扁平化的敏捷模式理想，一个是对于文档和临时 feature 产出的需求会打断理想工作流，甚至迫使整个团队做一些完全不敏捷的事情去满足交付目标（ 2b 产品）。还是那句话，scrum 真就只适合小而美的团队。在我们几个 codeowners 没有感觉到人手不足而招进来一批实习生和相对低端的 crud boy 之前都还跑得挺好的。团队大了之后必须向理想妥协

[pangleon]

扯淡的玩意，太理想化了
现在客户都不傻，人家要的是一周上线几次，你跟人扯方法论扯 sprint 人家压根不吊你

[hantsy]

@GeruzoniAnsasu 这个说白了也是管理层面的问题比较大。
1. Embrace Change 和 Scrum 一些文章也提到过，对于需求变更，大部分我们处理都是进 Backlog （可以规划到下个 Sprint ），不要影响本 Sprint 执行。不然的话，这个开发状况完全是乱成一锅粥的。
2. 至于项目感觉任务紧张，临时加人，完全就是临时报佛脚的想法。开发团队在不知情就招新人进来，感觉公司整个团队沟通问题很大（归根也是管理层比较 SB ），我首先想到的是调整项目计划。不加思考的加人，这个梗在很多经典软件管理的书里面说过了。 一个女人孩子要花 10 个月，找十个女人一个月能生下来吗？做产品更是如此，更需要花时间去打磨，时间沉淀才有好的产品。

[hantsy]

@pangleon 用敏捷方法，一天都是可以上线几次，而且全自动的。你可以吗？

[Hanggi]

@hantsy 这类方法论实施起来肯定会有诸多困难。

所以我在问是否有人严格执行过 Scrum，抛开那些阻碍，认真执行过后是否真的有收益。

Scrum 是一种方法、一种思维，也可以理解成一种框架。
有很多很好的技术框架，因为涉及的概念众多、使用门槛很高，需要学习大量知识后才能灵活运用。但是一旦熟练掌握之后对项目管理、开发出健壮的程序都有很大帮助。
那么对于一些可以驾驭这类框架的团队来说，使用这个框架是利大于弊的。

Scrum 是否也是能得到此类收益的框架呢？

[hantsy]

@Hanggi

我#13 好像专门说的是实践操作方面的，我个人特别讨厌一些空理论。

如果你觉得我上面说的都是理论，我就没话说了。

对于踏进未知领域，完全不知道情况，50%可能成功，50%可能失败，和天时地利人和有关。是不是踏出一步，自己决定，是在现在的泥坑里面照旧，还是选择冒险试一下。当然在国内人的因素比重太大，人的因素可以阻碍一切。

在别人身上穿得好看的衣服，不一定适合你。但是，我要说的是，穿着漂亮的女人不一定长相一流，但一定经常打扮，懂差穿着搭配，一个长相一流的女人平时懒得打扮，怎么都不可能在别人眼里是美女。

[ChanKc]

@pangleon 真正的敏捷，肯定要 CI/CD 吧，别说一周上几次，一天上几次应该都可以吧

[515576745]

外企都是 sprint 吧 给的开发周期比较长，一半不赶。。问题就是 backlog 基本上都是越积越多，基本都是面向 business 去 pick up item，剩下的 item 很少被拿起来进 sprint

[hantsy]

@ChanKc 国内对敏捷实践误解的人太多了。

以前在上海跟别人去了解一个公司的项目外包（自己做不了把活外包出来），他们说他们在实施敏捷开发，做了什么东西呢？

1，早上 Standup Meeting
2， 下班前统计工作状况
3，每周例会（回顾工作成果，规划下一周工作）

我问你们写测试吗？对方回答：我们有专门的测试人员。

我上面提到的实践层面的东西，一丁点都没有。

这是哪门子的敏捷实践？

[ChanKc]

@hantsy 对的，我见过的都是直接把方法论当思维观念了

很多 GitHub 的开源项目反而比较敏捷，issue 当看板，然后开发者自己接了做，合并时跑测试和 linter，review 然后合并后可以 CI/CD 直接 release

[GeruzoniAnsasu]

@hantsy 老哥你是不是不管团队也不需要在客户销售老板研发中间 4 方受气。。

研发和产品岗都呆过，所以深知推行起来有多难。研发这一侧可能理想很好，把需求都挡在外面，团队内部按部就班。

但地球不是这么转的，现实情况因果依赖是反的。销售浑身解数把你做了 1 的产品吹成了 10，客户同意验收 3，现在你是产品，是项目管理，你有的选吗，没得选。你只能赶紧用尽量短的时间把没做完的 2 赶出来，不可能不干了让友商看你笑话一边接盘一边挖你的人一边嘲讽你是傻逼，这很残酷的事。

即使在这种情况下我们还是走完了发版流程，还是保证了单测覆盖率，还是跑完了全 feature 回归测试；但 —— 不可能一切都这么顺利对吧

scrum 是一个不错的模型，但它是理想化的，我们肯定要有修改的地方。讨论推进采用敏捷模型的时候，你自己就是要介入的管理层。你就是要亲手去解决你发现的问题，为什么说得好像自己置身事外“那是别人的事”一样？

[kaedea]

Scrum 的基础是有效的资源管理，而 996 的基础是“我也不知道找谁所以把所有人都拉上了谁不在就把锅甩给他”，这两者刚好互补。

所以国内福报越厉害的地方，越是 anti-Scrum 的。个人见解。

[ChanKc]

@kaedea Scrum 需要一些自我驱动吧
996 一般不是外力强迫加班？那还谈什么自我驱动

[kaedea]

@ChanKc 自我驱动那是个人的事情，太玄学了，跟管理手段无关吧。

[ChanKc]

@kaedea Scrum 的管理是项目管理，而不是对人的管理。团队是自组织的。通常任务都是团队内成员自己领取的，而不是“张三你给我做 a，明天就要上线，加班到九点也要给我做完”

[itskingname]

@hantsy Github Project 吗

[hantsy]

@GeruzoniAnsasu 一旦变更强行引进当前 Sprint，太恐怖了，这个我经历过。我以前在上海带过创业项目，一直想严格推行 Scrum，也是一些变更要求快速加入，搞得整个 Scrum 乱，执行不了，团队成员也比较不太接受，他们习惯了一天到晚摸鱼式的开发。后面其他方面实施都是在打折扣，测试也不写了， 慢慢回到了从前团队他们熟悉的状况，乱七八糟的一锅粥，东搞高西搞高一天过去了。

上面有位兄弟说得没错，外企 Scrum 实施可能比较全面。我跟过的海外项目，已经好几个基本都是实施 Scrum 了，最长的一个做了快两年，其中首先 10 个 Sprints 用来项目 Migrating 遗留项目到 Java EE/JBoss 。

[hantsy]

@itskingname 开始有两个项目用到 Zenhub （直接集成到 Github 界面中操作）+ Github Issues，现在也开始试用 Project （相对 Zenhub 还是有点简陋）.

[JerryY]

之前在一个小外企待的时候，那边就是 SCRUM 模式的。我理解的“应对变化”就是每天一个短暂的站会，交代一下目前的进展，有无瓶颈之类的，有问题及时解决，反正整个流程下来感觉还是挺清晰的。一个小团队，几个角色，各司其职。

[Tenlp]

国内对敏捷开发也不是全盘吸收吧

[moskize]

哪家公司会严格执行 scrum ？不都是因地制宜执行本公司特色的 scrum ？

所以你问它好不好，很难评价，因为讨论各方的标准都不一样。

[sggggy]

民间敏捷教练路过，辅导着两个团队。敏捷教练的关键就在于，守-破-离，如果持续非常长的一段时间都在严格执行 Scrum，而没有任何突破和改变的话，那应该才有问题。

[pangleon]

@ChanKc 你牛比，你一天能开发几个需求还能写覆盖率达标的单元测试，自己说话不脸红么

[pangleon]

@hantsy 你牛比，你一天能开发几个需求还能写覆盖率达标的单元测试，自己说话不脸红么

[ChanKc]

@pangleon 我做不到，所以我们团队不敏捷

[jiyingze]

软件开发没有银弹。

[pangleon]

@GeruzoniAnsasu 我也发现了 这个人说起来一套一套的 但是感觉好像没上过班一样
SCRUM 只是一个工具，只靠他没鸟用
靠的是项目经理和甲方产品经理 /客户能不能达成一致
或者乙方产品经理和客户能不能达成一致
或者 TEAM LEADER 和需求方能不能达成一致
你 BB 的再好，回头都给你推翻了的客户 /产品经理太常见了
人家压根不在乎你用不用 SCRUM，那是你自己的事
人家要的很简单 一周上几次线 别最后告诉人家干不完或者发现做的垃圾，产品经理 /客户 /甲方也都是吃亏吃过来的
你吹敏捷吹精益，人家最后只 CARE 结果。

[shenlanAZ]

没有办法严格执行，难以控制。老板 /领导一句话 说做就得做 不做就 gun 。职位权限过高，敏捷方法做不了挡箭牌。尤其是创业公司这种会更严重。

适当的本土化 会提升效率 以及提高团队仇恨。

[shenlanAZ]

reply #41 @pangleon 友好的提示一下 不要诋毁 hantsy 我看过他写的代码和文章。没有什么毛病的。

[msg7086]

还有一个是水平问题。其他国家不知道，在美国，能在比较好的团队里留下来的，本身都有过硬的实力。
别的不说，就我在国内读的大学里的水平来看，计算机系毕业生能独立做开发的，整个年级可能一半都不一定有。
大作业抄抄，毕业论文和项目抄抄，考试都及格了，睁眼闭眼也就给你毕业了。
放到美国的大学校园，必修课起手让你自学一门新的语言然后从第二个星期开始用这门新的语言做项目，怕是连大三都上不去了，更别提毕业了。

[zjuster]

传统公司（地铁信号、工程电力）要严格遵循 V 瀑布流的开发流程，不可能改。

互联网公司，需求每天都在变，没办法执行任何一个严格意义上的开发模型，最终就是“需求-开发-测试-迭代-开发-测试”，能做到 Kanban 和 Sprint 管理需求，就已经算正规了，毕竟项目经理，在互联网公司也太难混了。

[hantsy]

@pangleon 单元测试及其它的测试（还有各种你在 Java 中用过测试工具绝大部分我都用过）我在工作写了 10 年。我之前说过很多次，我不强调特别高每一行的覆盖率（ POJO，什么配置之类我会跳过不写测试的），但是各种业务的路径业务（正常和异常）都是必须覆盖，也就说，每个业务都是有对应的测试，这个真的不难，不是傻子都是可以做到的。我说这话为什么要脸红？

[Rob007]

SCRUM 需要自动化工具的支撑, 没有工具的支撑规范是无法落地的，最后只能束之高阁。版本管理用 Git/SVN/gerrit 等，持续集成用 Jenkins，需求缺陷用 Jira 、readmine 。有能力的会做工具间的打通，没能力的就人力沟通。自动化工具还和每个团队的风格、公司的业务模式相关，所以没有完全匹配的，不管商业和开源都需要定制开发。而工具的开发是需要成本投入的，这是很多团队不愿承担。

[xsen]

@hantsy #18 你似乎对敏捷有误解，敏捷不会出现一天上线几次这样的情况出现

[xsen]

@Rob007 #47 敏捷就是敏捷，自动化工具只是锦上添花——没必要当初充分必要的条件
但有个事实是，只要上了敏捷而且坚持下来的话——基本不会有摸鱼的存在。所以大多数人都没有动力去坚持推行敏捷，因为大家都要摸鱼

但有个是事实，就是敏捷对团队成员要求高、对成员的促进成长作用也非常明显

敏捷有几个核心的理念，
1. 应对变化
所以所有的资源（人力与时间）都是放在优先级最高、能够确切产生价值的任务或产品上

2. 团队沟通与成长
3. 可交付产品

[hantsy]

@xsen 上面有人提到没有具体实践操作，Scrum 那一套理念就是空中楼阁。CI，CD 自动化是必须品，写测试是入门石。最前面我也说了，没有这些具体的操作，你的敏捷只是虚有其表，有形没神。

》》所以大多数人都没有动力去坚持推行敏捷，因为大家都要摸鱼
这句话没错。但是跟工作环境还是有很大关系，如果人人都是要做的话，你也自然会去做。就写测试这一点，我从来没见过欧美程序员在项目中思想上抵制写测试这件事，而我在国内一些创业项目推行，很大阻力，最后都是不了了之。过去 10 年，我在项目中与欧美多个国家的 Freelancer 合作过。

之前写一些 POC 的时候，项目小的时候，而且人少好办事，我们都是直接部署，没有人工决策步骤，一天部署到生产 10 次都是经常的。当然后面慢慢大了，加入 UAT 部署（一样的的一天会多次部署），再人工决策部署到生产环境。

[hantsy]

@xsen 你说的这些理念，一些敏捷培训课可能比较偏重吧，什么 Scrum Master，ProductOwner 的证书考试。但是这里 Scrum 只是普通的管理概念，与行业关系不大，也可以用在工厂管理，或者养猪也可以，敏捷本来最初一个来源就是 70 年代丰田管理。

具体到软件开发方面的，维基上看一下 Agile Software Development，除了 Philosophy，Method 列表内容，请仔细看看 Practices 部分的列表。

我手上有一本 The Art of Agile Development 的书，你没看过的话，可以网上看看这本书目录，这本书比较老了，08 年的，内容我不多说了。

[shuangyeying]

有自己公司特色的 Scrum 方法。

[pangleon]

@shenlanAZ 脑残粉真的是讨厌，他的文章对你有帮助代表他的所有言论都是正确的？还有你那只 DOG 眼看到我在诋毁他?已 B，真 NC

[jiangbingo]

回顾下 SCRUM pattern
* product backlog
* sprint backlog
* daily scrum meeting
* retrospective
* potentialy shippable product increment