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

[Hanggi]

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

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

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

[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%可能失败，和天时地利人和有关。是不是踏出一步，自己决定，是在现在的泥坑里面照旧，还是选择冒险试一下。当然在国内人的因素比重太大，人的因素可以阻碍一切。

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