agile - Scrum:抵抗是(不是)徒劳的

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

7年前关闭。




Improve this question




我是 PHP/MySQL 商店的第二个开发人员和最近的雇员。我之所以被录用，主要是因为我有从困惑的困惑中解决某种流程的经验。至少，我在上一家公司就是这样做的。 ;)

自从我来到这里(几个月后)，我把我的老板、我的产品经理和其他几个关键人物都带了进来(但主要是鸡，如果你原谅基于 Scrum 的刻板印象)。我还帮助了解了滞后一年多的主要产品的开发周期。人们喜欢它!

但是，我的同事(目前唯一的其他开发人员)并不喜欢它。她更喜欢关上门，专注于她的工作，一个人呆着。我？我喜欢协作、合作和开放的整个敏捷方法。没有她的意见，我开始了 Scrum 实践(每日 Scrum，燃尽图和其他我发现对我和我以前的团队有用的东西(ala H. Kniberg 很酷的挂图)。在我们每天站起来的时候，她偷偷地经过并忽略了我们好像我们实际上并没有站在她的门外(我们实际上是)。这真是太神奇了。我从来没有见过这样的阻力。

问题......我如何让她加入？同伴压力不起作用。

感谢 Scrum-borg 的同事，

美丽的

Answer 1

虽然像 Scrum 一样的其他敏捷方法体现了许多良好的实践，但有时给它一个名字并使它(正如许多博主评论的那样)成为必须在工作场所采用的“宗教”，这对很多人来说是相当令人反感的，包括我自己。

这取决于你的选择和 promise 是什么，但我知道我会更热衷于接受想法，因为它们是好主意，而不是因为它们是潮流。通过向她展示如何改善她的生活和工作流程，尝试一次实现/吸引她参与这些实践。

程序员喜欢可以帮助他们完成工作的很酷的东西。他们讨厌被宣扬或被要求登上他们认为是潮流的东西。将其呈现为前者而不是后者。 (不用说，确保它实际上是前者)

编辑:另一个问题

我实际上从未在使用特定敏捷方法的地方工作过，尽管我很高兴我现在所处的位置，因为我们在没有炒作和教条的情况下整合了许多敏捷实践(两全其美，恕我直言)。

但我只是在阅读有关 Scrum 的内容，这样的系统对 2 人团队甚至有益吗？ Scrum 确实为项目增加了一定数量的开销，看起来，当您拥有一个非常小的团队时，沟通和计划已经很容易，这可能会超过 yield 。